大多数人优化 AI 成本，第一反应是换便宜模型。可如果你把一个请求拆开看，会发现最贵的那部分从来不在单价里，而在三类没人提醒你的重复上。下面是能自己复现的计数结果。
一、先用一个对照看清浪费
同一个「校对一段话」的任务，两版 prompt：
| 版本 | 内容 | input token |
|---|---|---|
| 干净版 | 只给任务本身 | 35 |
| 冗余版 | 多贴一段 65 字背景 | 100 |
多花 65 token，比例 186%。这段背景模型上一轮就知道，你只是每次开新对话都重贴了一遍。
计数规则用公开近似：英文约 4 字符 1 token，中文约 1 字 1 token。近似有误差，但对比同一个任务的两版时，误差方向一致，差值能复现。
二、三类隐性浪费
1. 重复贴背景。 新对话重贴 system 背景、项目说明、风格要求，贴一次算一次。
2. 被忽略的重试。 一次失败自动重试 3 次，账单是 4 次调用。800 token 变 3200，多花 3 倍，前 3 次失败的输入照常计费。
3. 失控的长输出。 只写「总结一下」，模型输出 2400 token（含免责声明、示例、客套），你只要 300 token 的五条结论，多花 700%。
三、为什么你察觉不到
账单被拆成几万次调用，单次多花的几十 token 不足一分钱，且没有报错、没有提醒、没有红字。大脑会自动把分散、微量、无反馈的小数归零。
四、落成可监控字段
想让浪费看得见，先记下这几个数：
{
"call_id": "job_001",
"input_tokens": 100,
"cached_tokens": 0,
"output_tokens": 300,
"retry_count": 0
}
字段含义：
input_tokens/output_tokens：一次调用实际吃进去、吐出来的 token 数，两者一比就知道有没有失控；cached_tokens：命中缓存的 token 数，如果长期是 0，说明你的背景每次都在重贴；retry_count：这次调用重试了几次，持续大于 0，就是重试在悄悄放大账单。
盯两个信号就够了：
input_tokens远高于output_tokens，且cached_tokens为 0 → 大概率在重贴背景；retry_count持续大于 0 → 重试在默默放大计费。
五、自查清单
- 背景只贴一次，新对话改成「接着上次的 X」；
- 重试设上限，超过就降级或排队；
- 输出说清格式：条数、每字段长度、要不要免责声明；
- 固定的放开头、临时的放结尾；
- 月底看账单拆解，不看总额看四项占比。
六、失效边界
这套方法只对「频繁、反复调用」的场景成立。一个月只用两三次的偶发用户，每次省几十 token 不值得花时间优化。真正该动手的是每天几十次、带长背景、开自动重试的调用方——对他们来说，这笔钱会一天天往上滚。
如果你在并发或批处理场景下测出不同阈值，把 consumer 数和实测 token 差贴出来，我补进正文。
