如何保留输出 token 而不降低回答质量

输出 token 限制很有用，直到它让模型在你真正需要的答案中途停住为止。过于宽松的上限会浪费预算，并且给输入留出的空间更少。过于严格的上限可能会删掉结论、截断 JSON、跳过必需部分，或者迫使你再发起一次调用，而这次调用的成本比你想省下的 token 还高。

实际可行的做法不是为每个上下文窗口固定预留一个百分比。先为最少可行答案预留空间，再加入任务特定的余量，然后把输入内容放进这个受保护的输出预算之内。

本指南将展示如何在不降低回答质量的前提下保留输出 token，并提供公式、示例、可直接粘贴的测试提示，以及一个你可以在 TokenTest 中运行的工作流程。

“保留输出 token”到底是什么意思

每次模型请求都必须符合你所使用路由的限制。从规划层面看，可以把请求理解为：

可用上下文 >= 输入 tokens + 预留输出 tokens + 安全余量

精确的计量方式会因提供商和模型而异。聊天封装、工具、图像、schema、缓存内容以及内部推理，都会改变哪些内容被计入或被报告。因此，规划时的估算不应被视为最终的权威依据。

因此，输出预留是一个调用前的容量决策，而不是预测模型一定会消耗完所有预留 token。你是在为一个有效答案保留足够空间，同时允许生成在完成时自然停止。

为什么较小的输出上限会降低回答质量

输出限制并不会告诉模型答案的哪一部分可以省略。如果生成达到了上限，结果可能会在任意位置停止。

这会带来四种常见失败模式：

1. 结构截断：JSON 对象、代码块、表格或编号流程在闭合前就结束了。
2. 优先级倒置：模型把 token 花在铺垫上下文上，结果遗漏了建议或结论。
3. 需求丢失：多部分指令中后面的部分消失了，尽管开头看起来很完善。
4. 假节省：不完整的答案会触发续写、修复或完全重试。

简洁且完整的答案是高效的。不完整的答案则不是。

受保护的输出公式

对每次请求，使用以下起始公式：

受保护输出预留 = 最少可行答案
               + 格式开销
               + 不确定性余量
               + 可选推理余量

1. 最少可行答案

定义仍能通过任务的最短响应。计算必需的部分、字段、示例、引用、代码块或步骤。

例如，一个返回五个 JSON 字段的支持分类任务，所需输出空间就远少于一个包含风险、命令和回滚步骤的技术迁移计划。

2. 格式开销

结构化格式会消耗不属于正文本身的 token。要为键名、大括号、Markdown 语法、代码围栏、表格分隔符、引用和重复标签预留预算。

3. 不确定性余量

当答案长度会随证据而变化时，要预留更多空间。检索结果、工具输出、来源数量、输入语言以及检测到的问题数量，都可能扩大响应长度。

4. 推理预留

某些 API 会将内部或不可见的推理 token 计入输出用量，而输出上限会同时约束这些用量和可见文本。OpenAI 目前的 token 计数指南明确警告，输出用量可能包含你看不到的 token。不要仅凭可见字数来为推理模型的响应设定大小。

实用预留表

优先根据任务形态，而不是模型上下文大小，来做首次定标信号。

这些是测试范围，不是通用模型限制。请用你自己提示词和路由中观察到的百分位数替换它们。

如何保留输出 token 而不降低回答质量

步骤 1：编写完成契约

在选择上限之前，先定义“完整”意味着什么。

答案必须包含：
- 一条直接建议；
- 三个实施步骤；
- 一个风险或注意事项；
- 一个验证检查；
- 引言不超过两句话。

这使质量下限可以被测试。它还会告诉模型，在可选细节之前优先输出有价值的内容。

步骤 2：创建一个具有代表性的答案骨架

用占位符起草最短可接受结构：

建议：[1-2 句话]

步骤：
1. [动作]
2. [动作]
3. [动作]

风险：[一个注意事项]
检查：[一个验证]

对这个骨架进行计数或估算，填入真实内容，并将其作为最低可用答案。不要只根据提示词来估算。

步骤 3：为格式和波动增加余量

对于边界严格的 JSON，一个较小的绝对缓冲可能就足够。对于有来源支撑的分析或多语言内容，则需要更大的预留，因为有效要点的数量和长度会变化。

一个简单的起始规则是：

初始输出上限 = 具有代表性的有效答案 × 1.3 到 1.8

对固定 schema 使用较低端，对开放式综合使用较高端。这个乘数只是测试经验法则，不是提供方保证。

步骤 4：在增加更多输入之前保护预留

如果某个请求接近该路由可用上下文的上限，应先减少或概括输入，再缩减受保护的答案。

按以下顺序优先处理输入：

1. 系统和安全指令；
2. 用户当前请求；
3. 所需证据和工具结果；
4. 最近的相关对话；
5. 可选示例和历史上下文。

丢弃低价值历史，通常比强行把 1,000 token 的交付内容塞进 300 个输出 token 更安全。

步骤 5：让提示词具备质量意识

要求模型进行优先级处理，而不只是追求简短。

请在可用预算内回答。保留最终建议、
必需字段和验证步骤。优先压缩背景说明。
不要让代码、JSON、表格或编号步骤不完整。

避免要求模型“用完每一个 token”。最大值是上限，不是目标。

步骤 6：验证停止条件

调用结束后，检查提供方返回的 finish 或 stop 原因以及报告的用量。仅仅因为响应包含流畅文本，就自动判定一个因达到 token 限制而停止的回答通过，这是不对的。

对于结构化输出，解析它。对于代码，运行最窄范围的相关检查。对于报告，确认每个必需部分都存在。

步骤 7：基于有效生产样本进行调优

仅针对通过任务的响应跟踪输出用量。然后从有效输出的上四分位区间选择上限，而不是根据整体平均值。

有用的字段包括：

route
task_type
input_tokens
output_tokens
output_cap
finish_reason
task_valid
repair_required
language

如果许多有效答案使用的 token 少于上限的一半，就逐步降低上限。如果截断或修复率上升，就增加预留空间或收紧要求的结构。

可直接粘贴到 TokenTest 的实验

打开 TokenTest，选择与你的路由相关的模型或 tokenizer，然后在发送到生产环境之前比较这些提示词。

实验 1：简短但完整的支持回答

你是一名技术支持工程师。解释为什么即使可见的用户消息很短，
API 请求也可能会触及上下文限制。

完成约定：
- 回答不超过 180 个词；
- 包含一个直接解释；
- 包含三个可能的隐藏因素；
- 包含一个诊断下一步；
- 如需压缩，保留诊断步骤。

实验 2：固定 JSON 预留

对以下产品反馈进行分类。仅返回有效 JSON，键为：sentiment, topic, urgency, summary, needs_human_review。

允许的 sentiment：positive, neutral, negative。
允许的 urgency：low, medium, high。
将 summary 控制在 30 个词以内。

反馈：
“导出可以用，但昨天的使用总量缺失，而且我们的财务团队需要在中午之前拿到报告。”

实验 3：双语差异

将完成约定各粘贴一次英文版和一次中文版。保持含义和必需字段一致，然后比较输入估算，并为每种语言分别保留输出余量。Token 计数取决于模型和 tokenizer；含义相同并不意味着 token 用量相同。

比削减答案更好的节省 token 方法

如果输出预留空间不够，先从其他地方减少浪费：

• 总结较早的对话轮次；
• 按相关性和大小限制检索结果；
• 删除重复的工具输出；
• 请求有限数量的示例；
• 使用紧凑的 schema；
• 让审阅者提供补丁列表，而不是完整重写；
• 将发现阶段与最终综合阶段拆分；
• 将大型产物存放在对话之外，只传递所需摘录。

这些改动在降低输入或重复生成成本的同时，保留了回答质量的底线。

自适应输出上限比单一全局限制更有效

生产系统在分配输出上限之前，应先对任务进行分类。

if task is fixed-schema extraction:
    cap = filled_schema_estimate + small_buffer
elif task is short answer:
    cap = contract_estimate * 1.3
elif task is source-backed synthesis:
    cap = contract_estimate * 1.6
else:
    use a conservative default and collect evidence

如果请求包含更多必需章节、更多来源、更多代码文件，或者某个语言对在所选路由上的使用量更高，也可以提高上限。

常见错误

为上下文窗口预留固定百分比

10% 对分类器来说可能过多，对报告来说又可能不够。应按交付物形态来预留。

只衡量可见词数

token 与单词并非一一对应，而且某些路由会报告不可见的输出用量。最终调优时应使用路由原生的用量数据。

只把截断当作提示词问题

更好的提示词有帮助，但它不能把答案塞进一个小于所需结构的上限里。

在不控制范围的情况下提高上限

宽松的提示词会扩展到填满可用空间。应将上限与完成约束、章节限制以及清晰的优先级顺序配套使用。

所有语言共用同一个预算

tokenization 会因文本、语言、模型和 tokenizer 而异。应针对每个重要区域进行测试，而不是直接照搬英文预算。

最终检查清单

在上线 token 限制之前，请确认你已经：

• 定义了最低可用答案；
• 为结构性开销做了预算；
• 考虑了任务和语言差异；
• 在可选输入之前保护了输出空间；
• 告知模型应优先压缩什么；
• 检查了结束原因和有效性；
• 跟踪了修复和重试率；
• 并且只基于有效答案来调整上限。

这就是如何在不降低回答质量的情况下保留输出 token：先保护完整性，再约束可选细节，最后用观测证据替代估算。

使用 TokenTest 检查提示词大小，对比语言和模型，并在请求进入生产环境之前让预留空间可见。

如需了解更多实用的提示词预算工作流程，请浏览 TokenTest blog。

FAQ

我应该预留模型的完整最大输出吗？

通常不需要。预留足以生成有效响应的空间，并加上经过测量的余量即可。即使模型在用完之前就停止，过高的上限也会减少可用输入容量，并削弱成本控制。

20% 的输出预留是个好规则吗？

这过于宽泛，不能作为可靠规则。固定模式抽取可能需要少得多，而长文合成可能需要更多。首先估算所需的交付内容。

当答案达到输出上限时，我该怎么办？

在验证之前，应将其视为不完整。提高上限、减少低价值输入、收紧结构，或请求一个有边界的续写，让其从缺失部分开始，而不是重新生成全部内容。

推理 token 会减少可见答案的空间吗？

在那些将推理 token 计入输出用量，或由输出 token 上限控制的路由上，确实会。请查看特定模型和 API 路由的官方文档以及用量字段。

我应该如何为中文和英文分配输出 token 预算？

使用实际的分词器或路由对两个版本进行测试。不要从字数换算，也不要假设等效提示会有相同的 token 数。

来源

• TokenTest 首页和实时 token 规划工作流
• OpenAI token 计数指南
• OpenAI 推理指南
• Anthropic 消息 token 计数
• Anthropic Messages API
• Google Gemini token 计数