AI 编程助手的五个 Token 黑洞，以及如何堵上它们

Fri, 26 Jun 2026 09:00:00 +0800

你正在让 AI 编程助手处理一个真实的 bug。它已经理解了整个仓库的结构，面前是一个失败的测试用例，下一轮对话就能给出修复方案。突然，它停了。没有错误提示，没有预警，只有一个冰冷的提示框：使用额度已耗尽。

最让人沮丧的不是任务没完成，而是烧掉 Token 限额的，大概率不是你真正需要的工作内容。真凶往往是重复的上下文、丢失的缓存、臃肿的工具定义、过度强大的模型，以及持续膨胀的对话历史。

大多数 Token 浪费是机械性的，而不是智力性的。要堵上这些漏洞，首先得理解上下文是怎么被发送、缓存、重复和计费的。

脑内模型：每次对话都是一次「重新认识」

很多人下意识地以为 AI 编程助手在连续对话时，会像人类一样「记住」之前的交流。事实恰恰相反。

每一次你发送消息，助手都会把一整套上下文重新打包发给模型：系统指令、工具定义、历史对话、文件片段、工具执行结果，以及它认为有帮助的任何信息。模型并不会从一个「私人记忆」里延续上一轮的状态，它需要重新读一遍整个 prompt。

所以真正的消耗公式不是「我让它做了多少事」，而是：

每轮 Token 消耗 × 回合数

浪费，就发生在这个乘积和实际工作需要之间的落差里。下面是我观察到的五个最显著的泄漏点。

Prompt 缓存是所有优化手段中杠杆效应最高的。道理很简单：编码助手的对话里充满了重复内容，系统 prompt、工具定义、代码摘要、历史消息，这些东西从前一轮到后一轮几乎不变。

主流模型提供商都对重复的 prompt 前缀提供大幅折扣。Claude Opus 的标准输入价格是每百万 Token 5 美元，而缓存读取只要 0.5 美元，差了 10 倍。OpenAI 的缓存输入定价逻辑类似，重复的前缀 Token 比全新输入便宜得多。

一个关键的健康指标是缓存命中率：

缓存命中率 = 缓存读取 / (缓存读取 + 缓存创建 + 未缓存输入)

在一个正常的编码会话中，这个值应该很高。如果偏低，说明你在为模型刚刚才看过的内容支付全价。

最常见的「自毁缓存」行为包括：

修复方式并不复杂：把 prompt 的前缀保持稳定，把可变信息往后放。不要把系统上下文每轮都洗牌重来。把工具定义当成热路径的一部分来管理，因为它们确实就是热路径。

长上下文是很有用，但它不是免费的。对话中保留的每一段内容，都会被带入下一轮，除非助手主动压缩或丢弃。

一个典型的坏模式很容易识别：你让助手做一个任务，任务途中变成了三个任务；调试演变成了实现，实现又变成了发版说明。两小时前的完整考古记录还安安稳稳地躺在上下文里。

操作方法：比较前五个回合和后五个回合的平均输入长度。如果后面的回合大了两倍以上，且对话已经超过约 30K Token，那你大概率在每一轮都交了「长上下文税」。