发送前计算 Token：一套可执行的桌面工作流
1. 先定义这次请求的 Token 预算
在打开终端或编辑器之前，先写下这次任务的三个数字：输入上限、预留输出长度、总预算。不要只看模型的上下文窗口。上下文窗口是理论容量，真正可用的输入空间还要扣除系统提示词、工具定义、历史消息和模型准备生成的内容。
例如，你准备让模型审查一个中型项目，可以把总预算设为 40,000 tokens，其中输入最多 28,000，输出预留 12,000。若当前对话已经使用了 9,000 tokens，新的文件内容就只能占用约 19,000 tokens。预算写下来后，是否继续添加文件会变成可判断的问题，而不是凭感觉发送。
- 短问答：输入预留 2,000 至 6,000 tokens。
- 单文件修改：输入预留 8,000 至 20,000 tokens。
- 跨文件排查：输入预留 20,000 至 60,000 tokens，并保留更大的输出空间。
2. 用正确的工具计算文本 Token
不要用字符数直接代替 Token 数。中文、英文、代码、路径和 JSON 的切分方式不同，字符数只能做非常粗略的预估。最可靠的办法是使用目标模型或兼容模型对应的 tokenizer；如果没有对应 tokenizer，则使用近似工具，并在预算中增加余量。
实际操作时，可以先把准备发送的提示词、文件片段和历史摘要合并成一个临时文本，再运行 tokenizer 计算。很多编辑器插件、模型控制台和 API 调试工具都能显示 Token 数。对于命令行工作流，也可以保留一个固定的计数脚本：读取标准输入，输出 tokens、字符数和字节数。这样每次检查的方式一致，结果也容易记录。
如果工具只支持英文 tokenizer，不要把它的结果当成精确值。中文说明和混合代码可能出现明显偏差。此时可以使用它做下限估计，再增加 15% 至 25% 的缓冲。
3. 按文件和消息分别计数
一次性把所有内容粘贴进输入框，会让你失去对预算的控制。先为每个文件、日志片段和错误信息单独计数，再计算总和。建议在桌面建立一个临时清单，记录名称、用途和 tokens。
- src/auth.ts：实现目标，4,280 tokens。
- tests/auth.test.ts：现有行为，2,160 tokens。
- 错误日志：复现证据，1,340 tokens。
- 项目约束说明：必须遵守，920 tokens。
这样做可以快速删除低价值内容。例如，完整依赖锁文件通常没有必要发送；长日志也可以只保留首次错误、相关堆栈和最后一段上下文。每删掉一个片段，都重新计算总量，避免因估计误差把请求推过上限。
4. 把历史对话压缩成可验证摘要
长对话的成本常常来自重复上下文。每完成一个阶段，就生成一份短摘要，包含已确认事实、已修改文件、失败尝试、当前问题和不可改变的约束。下一次请求带摘要，不要继续携带所有历史消息。
摘要也需要计数。把它控制在原历史的 10% 至 20% 通常比较合适，但不要为了短而删除关键细节。文件路径、函数名、错误码、版本号和已经验证过的命令应当保留。对于代码任务，摘要不能只写“已经修复认证问题”，还应写明修复位置、测试命令和仍未覆盖的情况。
5. 发送前检查输入和输出的双重上限
计算完输入后，再检查输出预算。模型可能需要生成补丁、测试、解释和命令。如果只为输入留出空间，响应可能被截断；如果只追求超长输出，请求成本又会增加。
- 代码修改：为完整补丁和测试结果预留空间。
- 代码审查：限制每个问题的说明长度，避免重复转述代码。
- 日志分析：要求先给结论，再给证据和下一步。
- 批量生成：设置每项的最大长度，并明确总项数。
把“请详细回答”改成可执行限制，例如“最多列出五个问题，每个问题包含文件位置、原因和一个修复建议”。这种写法既降低输出 Token，也更容易检查结果是否完整。
6. 在 API 和命令行中记录实际用量
预估不是账单。发送后应记录 API 返回的输入 tokens、输出 tokens 和请求耗时。对 OpenAI 兼容 SDK，检查响应中的 usage 字段；对命令行工具，查看它提供的会话统计或日志。把预估值与实际值对照几次，就能得到适合自己项目的修正比例。
RelayVano 适合把这种习惯接入日常开发：它提供按量使用的 AI 模型中转服务，可配合 Claude Code、Codex、Gemini CLI 以及 OpenAI 兼容 SDK，API 地址为 https://api.relayvano.com。你可以在发送前用本地工具估算，在请求后用 usage 数据校准预算，再决定下一轮是压缩上下文还是切换模型。
7. 建立每天都能执行的发送清单
把检查步骤固定成一分钟流程，效率会高于临时排查超限错误。桌面上可以放一份纯文本模板，每次复制后填写：
- 任务目标是否能用一句话说明。
- 输入包含哪些文件、日志和约束。
- 输入 Token 总数是多少，使用了哪种 tokenizer。
- 输出需要多长，是否设置了明确上限。
- 是否删除了重复历史、无关代码和完整日志。
- 上次请求的实际 usage 是否已经用于修正本次预算。
当你准备持续使用模型时，可以注册 RelayVano，把这套计数和记录流程接入现有工具链。先从一个固定项目开始，连续记录十次请求，再根据实际数据调整缓冲比例和输出上限，通常比一次性追求最精确的 Token 预测更有效。