输出层：管住模型的嘴
明确的负向约束砍掉 30% 废话；润色用 Diff 别重写整段；停止序列做物理截断
本页解决的问题
先给结论「输出层：管住模型的嘴」要解决的关键问题是什么？
明确的负向约束砍掉 30% 废话；润色用 Diff 别重写整段；停止序列做物理截断
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
很多人知道要求「请简洁回答」，但这是有问题的——「简洁」对模型来说太抽象了，它不知道你要多简洁。有效的写法是把「别干什么」列清楚：
实测下来，Agentic 场景能砍掉 30% 的废话。说白了就是告诉它：别整那些有的没的，直接上结果。
这是文字润色场景最大的成本坑：用户说「把这句话改通顺一点」，模型把 2,000 字的文章从头输出一遍。就算约束到只输出那个段落，Token 也在哗哗地烧。
换个思路：让模型只输出修改的部分——用 Diff 格式标出「原文→改后」，或者直接返回正则表达式，程序拿到后再做替换。只动那两三个词，1 秒搞定：成本差几十倍，体验还更好——速度快，用户还能直接看到改了哪里，不用自己对比。
在 Prompt 里写「请只输出 3 项」，模型听不听是玄学——可能输出 3 项，也可能 5 项再加一段总结。但停止序列（stop sequence）是物理截断，和模型「听不听话」无关：API 检测到指定字符串就直接掐断生成流，被掐掉的部分不计费、不进历史上下文。
简单，粗暴，但好用。有效控制输出，就是控制成本和用户体验。
负向约束要具体：「不要寒暄、不要总结、不要客套」比「请简洁」有效得多，Agentic 场景砍 30% 废话。
润色输出 Diff 或替换指令，别让模型重写整段：成本差几十倍，用户体验反而更好。
停止序列是物理开关：列表掐「4.」、单行答案掐换行、JSON 掐「}」、防自问自答掐「用户：」。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》实战篇「04｜输出」。停止序列参数见各家 API 文档（OpenAI 兼容接口为 stop 字段，最多可设 4 个序列）。
「指令层 · 写明确的负向约束」的完整成本怎么算
「很多人知道要求「请简洁回答」，但这是有问题的—— 「简洁」对模型来说太抽象了，它不知道你要多简洁 。有效的写法是把「别干什么」列清楚」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「实测下来， Agentic 场景能砍掉 30% 的废话 。说白了就是告诉它：别整那些有的没的，直接上结果」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「停止序列是物理开关： 列表掐「4.」、单行答案掐换行、JSON 掐「}」、防自问自答掐「用户：」」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「指令层 · 写明确的负向约束」走到「代码层 · 润色用 Diff，别重写整段」
「指令层 · 写明确的负向约束」先把问题落在「很多人知道要求「请简洁回答」，但这是有问题的—— 「简洁」对模型来说太抽象了，它不知道你要多简洁 。有效的写法是把「别干什么」列清楚」上；到了「代码层 · 润色用 Diff，别重写整段」，讨论继续推进到「这是文字润色场景最大的成本坑：用户说「把这句话改通顺一点」，模型把 2,000 字的文章从头输出一遍。就算约束到只输出那个段落，Token 也在哗哗地烧」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「指令层 · 写明确的负向约束」：很多人知道要求「请简洁回答」，但这是有问题的—— 「简洁」对模型来说太抽象了，它不知道你要多简洁 。有效的写法是把「别干什么」列清楚
- 「代码层 · 润色用 Diff，别重写整段」：这是文字润色场景最大的成本坑：用户说「把这句话改通顺一点」，模型把 2,000 字的文章从头输出一遍。就算约束到只输出那个段落，Token 也在哗哗地烧
- 「最后的要点」：停止序列是物理开关： 列表掐「4.」、单行答案掐换行、JSON 掐「}」、防自问自答掐「用户：」
最后的「最后的要点」把讨论落到「停止序列是物理开关： 列表掐「4.」、单行答案掐换行、JSON 掐「}」、防自问自答掐「用户：」」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。