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

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

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

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

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

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

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

每轮 Token 消耗 × 回合数

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

漏洞一：Prompt 缓存频频失效#

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

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

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

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

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

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

  • 频繁修改 prompt 开头的上下文。
  • 在稳定内容前面注入动态状态、时间戳、或变化的进度文本。
  • 每轮对话之间重新排列工具定义或 MCP 工具 schema。
  • 把大文件整段粘贴到对话里，而不是让助手按需读取。

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

漏洞二：上下文持续膨胀#

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

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

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

对策：

  • 任务边界变了就开新会话。别指望一个会话搞定所有事。
  • 在会话爆炸之前主动压缩，而不是等模型已经开始挣扎再动手。
  • 让助手总结当前进度和待解决问题，然后从那个摘要重新开始。
  • 引用文件路径，而不是把文件内容粘贴进去。除非你真的想为那些行重复付费。

这和看日志是一个道理。你不会把一万行的日志文件硬塞给人看，用 grep ERROR 就够了。

漏洞三：MCP 和工具定义的开销#

MCP 服务很有用，但它们不是隐形的。每个 MCP 服务暴露的工具定义都会占据上下文空间，而且每一轮对话都会重复发送。

一两个精心选择的服务通常没问题。一堆永远开着的服务会变成每轮对话的固定课税，在你还什么都没要求做之前，预算就已经被吃掉了。

检查方法很简单：

工具 Schema Token / 总输入 Token

如果工具定义占了会话 Token 的很大比例，尤其是那些你根本没用到的工具，直接断开连接。当任务需要的时候再加回来。

这不是在反对 MCP，这只是基本算力管理。

漏洞四：模型和推理能力的大材小用#

这里实际上有两个独立的问题。

第一个是「牛刀杀鸡」：格式化 JSON、重命名变量、写 commit message、应用机械性重构，这些通常是低波动任务，用不着堆栈里最贵的模型。但在默认配置下，你的 AI 助手往往把所有请求都发给最强的模型。

第二个是对推理 Token 的无感。模型生成推理过程时，那些思考 Token 被记为输出 Token 来计费。而输出 Token 通常是请求中单价最高的一侧。

解决思路是路由，但要带护栏：

  • 模糊的架构设计、复杂的调试、改错一步代价极高的工作，用最强的模型。
  • 格式化、提取、摘要总结、机械性代码变动，切换到便宜的模型。
  • 简单任务降低推理深度参数。
  • 路由变更前后都要跟踪输出质量。

这是唯一一个「修复可能导致质量下降」的漏洞。不要盲目自动化。从一个工作流开始，测量便宜路径是否真的能保持质量。

漏洞五：缺少消耗速率可见性#

最后一个漏洞是运维层面的。

大多数人只有在会话窗口突然关闭时，才发现自己烧得太快了。这是一个糟糕的告警，它在用户已经被踢出会话之后才触发。

你需要的是速率，而不只是总量：

  • 当前会话的 Token 数。
  • 当前小时的 Token 数。
  • 最近 N 轮的缓存命中率。
  • 上下文大小趋势。
  • 推理 Token 与输出 Token 的比例。
  • 工具 Schema 开销占比。

一条以平时三倍速率在燃烧的会话，应该在还有时间调整行为的时候被发现。这才是告警，不是事后复盘。

好消息是，这些数据其实已经存在本地。Claude Code 和 Codex 都会把每次会话的 Token 明细写入磁盘：未缓存输入、缓存读取、缓存写入、输出、推理 Token，按模型分门别类。你不需要获取 prompt 原文来发现这些泄漏，模型名称、时间戳、工具使用和 Token 计数就足够了。

小结#

AI 编程助手的 Token 浪费很少是神秘不可解的，关键是你得能看见它。常见原因来来去去就是那几个：缓存失效、上下文膨胀、闲置工具开销、大材小用、缺少消耗可见性。

好消息是，这几个问题都不需要什么「新的哲学」，它们需要的是仪表盘和几个无聊的好习惯。

从缓存命中率开始查。如果那个数字不好看，先修它。它通常是全栈里 ROI 最高的优化。

参考来源：Five ways your AI coding agent wastes tokens (and how to fix each one) by Rob Newto — 2026-06-24, Dev.to