不要只优化 Prompt更要优化 Context。Claude Code 很强大这在前面的实践文章中我们已经验证过了但与此同时也有不少朋友说Token消耗过多成本过高。面对这个问题很多人第一反应是是不是Prompt写得太啰嗦了其实很多时候真正“烧 Token”的并不是输入的那句话而是Claude背后带着的整段上下文。它们可能包括之前的聊天记录已经读取过的代码文件工具调用输出像CLAUDE.md这样的记忆文件系统或后台注入的额外指令也就是说当Token消耗越来越高时问题往往不是Prompt不够简洁而是上下文已经变得臃肿。很多所谓的建议比如“尽量缩短对话”当然没错但太泛了真正落地时帮助有限。真正有效的做法是搞清楚Claude Code的上下文是怎么构建的、哪些内容会被重复携带以及工作流里有哪些“隐性成本”正在不断累积。这篇文章我们来讲7个真正实用的方法在不牺牲效率的前提下尽可能降低Claude Code的Token开销。1. 根据任务复杂度切换模型这一点最简单、但也最容易被忽视不是所有任务都值得用最贵的模型。如果使用按API计费不同的模型成本大概有几倍的差距如果使用订阅方案那么更重的模型也会更快消耗额度。在执行任务时可以做一个简单的分层日常任务写测试、简单改代码、解释逻辑、常规重构复杂任务多文件架构设计、棘手 bug 排查、跨系统分析轻量任务查找、格式化、重命名、重复性操作不同的任务采用不同的模型像日常任务使用适中的模型即可复杂任务则切换到能力更强具备深度分析能力的模型而且单纯的普通操作、机械性任务交给一般的低参数模型即可。以国外模型为例国内模型参考另外不少人忽略了/effort。对于一些本来就很直接的问题适当降低 effort level可以减少模型的“思考预算”从而直接降低输出 Token。一句话总结模型能力要和任务复杂度匹配不要让高性能模型去做低价值工作。2. 把CLAUDE.md当“规则索引”而不是“百科全书”如果你经常在每次对话里重复输入项目约束、开发规范、测试方式那其实是在持续浪费 Token。这正是CLAUDE.md的意义所在。在《使用Claude Code最需要做的一件事与AI签订一份契约CLAUDE.md》一文中我们也有专门讲到。CLAUDE.md会在Claude读取代码之前就被加载而且会在整个会话过程中一直驻留在上下文里。重点在于它不是按需加载的也不会轻易被“挤出去”。这意味着什么如果你的CLAUDE.md有 5000 Token那么每一轮对话几乎都要为这 5000 Token 付费。不管你本次会话只有 2 轮还是 200 轮它都会持续产生成本。那么适合放进CLAUDE.md的内容有哪些建议只放那些长期稳定、反复要用到的规则比如项目如何运行测试使用哪个包管理器代码格式要求关键架构约束哪些目录不要碰团队通用的开发约定不建议放进去的内容很多团队会把下面这些东西也一股脑塞进去会议纪要设计演进历史冗长的实现说明临时性的任务背景很长的业务文档这些都不适合。一个更好的原则是让CLAUDE.md像“速查手册”而不是“信息垃圾场”。写得越精炼长期收益越高。3. 把啰嗦任务交给 Subagent但别滥用这是一个非常值得重视的技巧因为它能从根本上改变上下文膨胀的方式。Claude Code 的 Subagent本质上是一个独立上下文窗口中的 Claude 实例。当你让 Subagent 去执行任务时它产生的很多“过程性噪音”——比如文件检索大段日志分析多轮推理过程中间步骤输出当使用Subagent去执行任务时可以避免上述噪声直接污染主会话。最终回到主线程的通常只是一个总结结果。这对于保持主上下文干净非常有帮助。但这里也有一个常见误区Subagent 并不天然更省 Token。如果只是处理很小的任务比如简单 shell 操作、快速 git 命令Subagent 往往反而更浪费。因为它本身也有启动成本包括子代理的初始提示工具定义注入额外的工具调用往返独立上下文构建开销所以正确的使用原则不是“所有事情都交给 Subagent。”而应该是“只有当它节省下来的主上下文污染足以覆盖启动成本时再使用它。”适合交给 Subagent 的任务通常有以下特征输出会很长检索范围较广过程信息多但结果摘要短不需要主线程保留完整过程细节4. 明确指定文件和行号别让Claude在仓库里“自由发挥”很多 Token 浪费根本不是因为 Claude 回答太长而是因为你给它的任务太模糊导致它要先花很多 Token 去“找问题”。比如这类说法“你帮我看看 auth 相关代码哪里有问题。”这听起来很自然但在 Claude 看来这基本等于去 repo 里搜一圈打开多个相关文件试图猜测你真正关心的点还可能走很多弯路如果问题实际上只在 1~2 个文件里这种探索就是纯浪费。更好的写法应该像这样“请对比src/auth/session.ts第 3090 行和src/api/login.ts第 1060 行说明两者之间的逻辑不一致在哪里。”这类表达有几个好处直接缩小搜索范围减少无意义文件读取降低模型重建上下文的成本更容易得到准确结论另一个容易被忽略的技巧先用 Plan Mode在执行一些可能成本较高的操作前可以先切到Plan ModeShiftTab。这个模式下Claude 会先给出一个分步骤计划而不会直接修改代码。你可以先审核这个计划把明显没必要的步骤删掉再切回正常模式执行。为什么这很重要因为实际使用中最浪费 Token 的环节之一就是试错式执行。比如 Claude 先尝试一种方案失败了再试第二种又报错然后继续修正……每一次尝试、每一次报错、每一次迭代都是在消耗 Token。而提前规划往往能大幅减少这种无效来回。5. 主动使用/compact不要等“上下文快炸了”才想起来很多人知道 Claude Code 有/compact但真正用得好的人并不多。原因通常不在于“会不会用”而在于用得太晚。一个典型场景是Claude 已经看过多个文件跑过若干命令试过几条错误方向上下文里塞满了中间过程这时候其实已经积累了很多“历史噪音”。而这些内容对你接下来的任务未必还有价值。这正是最适合执行/compact的时机。为什么要尽早 compact因为如果你拖到后面等到Claude开始遗忘前文出现上下文告警回答质量变差时才去压缩那么此时的会话已经很“脏”了。这时生成的摘要往往也不够清晰、不够高质量。相反如果在会话还比较健康的时候就主动 compact关键信息更容易保留下来无关细节更容易被清理掉后续每一步都会更轻量所以/compact的最佳用法不是“亡羊补牢”而是“定期保养”。一个很实用的心法是当关键结论已经出来而中间过程开始变多时就该考虑compact了。6. 优化之前先用/context找到真正的“耗 Token 元凶”很多开发者在发现 Token 消耗过快时第一反应是改Prompt、缩短提问、减少对话轮次。这些当然可能有帮助但很多时候你根本没打到重点。因为真正昂贵的内容未必是你当前看到的 Prompt。它可能是之前读入的超大文件工具调用留下的大段输出某个过重的记忆文件某些集成工具带来的系统开销这时候/context就非常关键。它相当于你的“上下文诊断面板”。在大改工作流之前先看一眼到底是谁在占用上下文通常会更有价值。很多优化收益最大的场景并不是你 Prompt 写得更精炼了而是你终于发现有一个“沉默的大块头”一直在每一轮对话里默默消耗 Token。所以不要盲目优化。正确顺序应该是先检查/context看看哪些内容被重复加载或重复携带找出真正的臃肿来源再有针对性地删减**先诊断再优化。**这条原则在 Claude Code 里非常重要。7. 工具链要克制集成不是越多越好Claude Code 可以接很多外部工具、数据源和辅助能力这一点非常强大。但强大的另一面是它也更容易把你的上下文结构搞复杂。当工具接得越来越多时模型可能需要额外处理工具定义调用协议上下文桥接信息工具返回结果多工具协同带来的额外说明问题在于很多任务根本不需要这么重的配置。如果你把所有能接的技能、插件、辅助器全部挂上去最后很可能出现一个尴尬局面任务很小但系统开销很大。因此一个更稳妥的策略是只保留真正高频、刚需的工具集成只接那些能持续解决重复问题的能力不要因为“可以接”就全部接上对 Claude Code 来说精简的工具链通常比“全家桶式”集成更高效。小结真正该优化的不只是Prompt而是 Context Architecture。如果只用一句话概括这篇文章那就是降低 Claude Code Token 成本的核心不是对每条 Prompt 精打细算而是设计好你的上下文架构。真正带来大收益的通常不是“把一句话少写 20 个字”而是这些更本质的动作控制自动注入的上下文缩小任务搜索范围及时压缩会话把高噪音工作隔离出去避免不必要的工具链负担说到底Claude Code 的成本问题本质上是一个上下文管理问题。很多开发者只盯着 Prompt 在优化但真正成熟的用法应该开始转向另一层思考不要只写 Prompt要设计 Context。以下是Claude Code系列其的他相关文章第1篇《国内环境下的Claude Code安装与使用教程》第2篇《使用Claude Code最需要做的一件事与AI签订一份契约CLAUDE.md》第3篇《Claude Code实践从零开始一行代码不写生成一个项目》第4篇《Claude Code的Skills实践及利器推荐工欲善其事必先利其器》第5篇《6条Claude Code实践中的经验与思考》第6篇《Claude Code的一次真实项目实践》第7篇《Claude Code在不同开发环节的应用案例分享》