Amy青梅有一段时间，我每个月看到 API 用量都很意外：明明没有跑什么大工程，只是每天都在终端里用 Claude Code 修 bug、写测试、调样式，但 Token 消耗却在悄悄上涨。直到我重新翻了一遍会话记录，才意识到问题不在某一个复杂任务，而在于那些看起来无害的日常会话——上下文不断累积，文件反复读取，输出越来越啰嗦。这个经验让我确定了一个判断：使用 Claude Code 编程时，Token 成本的核心变量，不是模型的单价，而是你对会话上下文的管理能力。省钱不是靠某条命令，而是要把整条工作流重新设计一遍。
1. Token 消耗的四大黑洞：先搞清楚钱到底花在哪
在讨论省钱之前，先建立一张成本地图。Claude Code 的一次使用，远不止是“发一条消息，然后得到回复”。它实际上包含四个主要的消费来源，而大多数人只盯着最后一个，前面三个才是真正的大头。
1.1 上下文重读：你以为的“接着聊”，每次都重新计费
很多人有一个习惯：在同一个会话里一直往上叠加任务。上午分析了一个问题，中午让它继续改代码，下午又让它跑一下测试。从使用者角度来看，这只是一次连续的对话；但从底层机制来看，每一轮新请求都需要基于前面的对话历史生成结果。也就是说，上下文越堆越长，单次请求的 Token 基数也越大。到后面，哪怕你只是问一句“这里是不是少了个分号”，模型也可能要把前面几万字的历史重新处理一遍。
这里有一个容易被忽略的反直觉点：一条消息本身可能只有几个字，但这一轮实际产生的 Token 消耗远高于这几个字。原因就是上下文重读。它不是 Claude Code 的缺陷，而是对话式编程工具的普遍特性。理解这一点，才能理解为什么“省 Token”很大程度上等于“缩短有效上下文”。
1.2 工具调用：读写、搜索、执行命令都会产生 Token
Claude Code 并不仅仅在“聊天”。它可以搜索文件、读取目录、编辑代码、执行命令。每一次工具调用，都会产生对应的输入输出 Token。例如，为了确认一个函数在哪里被引用，模型可能会先搜索整个仓库，再读取多个文件，然后给出结论。这个过程的成本往往比直接问答高得多。
实际体验中，工具调用是很有用的，但也是成本变化最大的变量。一个需要跨多个文件重构的任务，可能产生几十次工具调用；而一个纯问答任务可能只需要两三次。如果你发现某个会话的 Token 消耗异常高，可以先数一数其中有多少次工具调用。通常那些读文件多、搜目录多的任务，消耗会明显高于纯粹闲聊式问答。
1.3 大文件与目录扫描：最容易被忽略的成本来源
如果项目很大，而你又没有给模型足够精确的路径，它可能不得不扫描很多无关文件才能定位问题。特别是依赖目录、构建目录和临时文件目录，如果被纳入搜索范围，会白白消耗大量 Token。常见的做法是在项目配置里明确排除这些目录，或者在使用时直接给出具体文件路径和行号。这一条往往能立竿见影地降低成本。
从工程经验看，很多人第一次做 Token 成本复盘时，都会发现一个共同现象：消耗最高的会话并不是那些高难度任务，而是那些目标模糊、让模型自己去“找问题”的会话。让模型全仓库搜索“为什么这里报错”，和告诉它“只读取 src/utils/format.ts 的第 10 到 30 行”，成本差距可能在十倍以上。
1.4 冗余输出：回答太详细也是一种隐性浪费
输出侧也很容易被忽略。当你不做任何约束时，模型会默认给出“解释 + 代码 + 注意事项”的完整回答。对复杂问题，这种回答是必要的；但对于简单问题，就是一种浪费。开发场景中，很多需求其实只需要一个补丁、一段命令、或者一句话结论。
举个例子，与其让模型解释“为什么要这样修改”，不如直接要求“只输出修改后的代码”。输出约束可以明显减少单轮 Token。更关键的是，这种约束并不损伤质量，反而会让答案更精准，因为你强制模型把注意力集中在真正需要交付的内容上。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 输入侧优化：让模型只读该读的内容
输入侧优化的核心，是控制模型每一次请求需要处理的信息量。大量 Token 花在模型“看太多”上面，尤其是上下文累积和无用文件扫描。这一节讲三个可立即落地的方向。
2.1 项目级指令文件：精简到 50 行以内
在 Claude Code 的常见配置里，项目级指令文件通常叫 CLAUDE.md，或者类似的机制，它会作为长期上下文进入会话。好处是让模型始终清楚项目规范，但它也是每一轮都会占用 Token 的常量。如果你的指令文件写得像百科全书，每次对话的成本都会增加。
正确做法是只写稳定且必须遵守的信息，例如构建命令、测试命令、目录结构约定、代码风格。尽量控制在 50 行以内。那些会频繁变化的内容不要放进去，比“最近在改接口”这类临时信息，否则既占上下文，又容易过时。你可以把它理解成一个新成员的入职手册，而不是项目 Wiki。
2.2 会话清理：该断就断，不要怕重新开始
每个任务最好独立成会话。任务结束，立刻清理上下文，而不是“顺便再问一个相关的问题”。一些版本会提供会话重置或清理指令，比如 /clear 这类的命令。具体命令名以你的版本帮助信息为准。这里的关键是心理上的转变：不要害怕重新描述。你重新描述的那几十个字，通常比带着一大段旧历史继续对话要便宜得多。
注意：不要一上来就把会话压到最短。省 Token 的前提是任务能完成，清理上下文前先确认当前进度已经足够清晰。
2.3 手动指定文件路径和行号，减少无谓搜索
日常开发里，如果你明确知道问题在哪个文件哪个函数，就直接写进提示词。这样模型不需要搜索、不需要猜测、也不会被无关代码干扰。例如：
text复制请只读取 src/utils/format.ts 的 10 到 30 行，帮我看看时间格式化函数为什么在时区为 UTC 时输出错误。
相比“帮我看看时间格式化为什么有问题”，这条输入明显更省。它还附带了一个额外好处：答案质量更高。因为模型没有被多余信息淹没，更容易专注于真正的范围。
3. 输出侧优化：让模型说最少的话，做最准的事
输入侧是少读，输出侧是少写。在编程场景，输出 Token 通常包括代码、解释、调试思路、备选方案等。输出侧优化不是让模型偷工减料，而是让它的输出高度对齐你的真实需求。
3.1 用任务边界替代长对话
一个常见浪费场景：在同一会话里先问“这个函数为什么慢”，再问“帮我优化”，再问“顺便测试一下”。模型为了回答后续问题，可能要把之前所有分析都纳入上下文。长对话中的每一轮，都在为历史买单。
更合理的做法，是把大任务拆成几个边界清楚的小任务，每个小任务在相对独立的上下文里完成。比如：
- 任务 A：分析性能瓶颈，输出结论清单。
- 任务 B：基于结论清单，生成优化代码。
- 任务 C：运行测试并修复失败。
每个任务开始时，你可以把上一个任务的结论粘贴进去，作为新的上下文。这样总 Token 消耗，往往比一个超长对话低得多，而且每个阶段的输出都更容易检查。这个思路和编程里的模块化很像：让每个会话只负责一个职责。
3.2 在提示词里直接限定回答格式
在提示词中指定输出格式，是成本优化里性价比最高的一步。你不需要懂任何参数，只要把需求写清楚。比如：
text复制不要解释背景。只返回修改后的代码。不要提供备选方案。
text复制请用不超过 100 字说明失败原因，并给出可执行操作。
这不仅是在省 Token，也是在提升协作效率。模型在没有明确边界时，会倾向于完整输出。你给出边界，它才能把输出收敛到最小单位。实际使用里，我会把这类约束直接写进常用提示词模板里，而不是每次临时输入。
3.3 压缩历史：牺牲部分上下文，换取单次成本可控
有些长对话确实中途不好切。比如你正在排查一个跨模块问题，已经积累了大量中间过程，清空会话又怕丢失信息。此时可以考虑压缩历史：让模型把当前进度总结成一份简洁清单，包括已尝试的方案、当前结论、下一步计划。然后开一个新会话，以这份清单作为输入继续。
这样虽然丢掉了一些细节，但单次请求的 Token 基数会大幅下降。这条策略的本质，是把“原始上下文”转换成“摘要上下文”，在需要继续长任务时非常有效。使用时要注意，模型总结时可能会丢失某些关键细节，所以尽量在压缩前，让它把结果写讽刺一点也可以，但最好是写进外部笔记里。
如果你发现一个会话里连续追问了十几个问题，说明任务可能已经超出单一边界，是时候拆任务或重置会话了。
4. 把优化沉淀为工作流：一次会话只做一件事
到了这个层级，省钱不再靠单个技巧，而是靠一套稳定的工作流。如果你每天都用 Claude Code，建议把以下流程变成习惯。下面这张表可以作为策略选择参考：
| 策略 | 主要省的 Token | 代价 | 适合场景 |
|---|---|---|---|
| 精简项目指令文件 | 输入侧上下文重读 | 需要额外维护 | 项目结构比较稳定时 |
| 独立会话 | 上下文重读 | 需要重新描述背景 | 小任务、明确需求 |
| 压缩历史 | 单次请求基数 | 部分细节丢失 | 长任务需要重置时 |
| 手动指定路径 | 搜索与目录扫描 | 需要熟悉项目 | 问题范围明确时 |
| 脚本化固定操作 | 工具调用、多轮对话 | 需要维护脚本 | 高频重复流程 |
4.1 一次会话只做一件事
这是最简单也最有效的规则。一个会话对应一个明确需求，需求结束，会话重置。这会让每次请求的上下文都保持在较低水平，同时避免不同任务之间的信息污染。如果你同时要改 A 模块和 B 模块，那就开两个会话，而不是在同一个窗口里来回切换。
从实际经验看，这条规则执行难度不在于“不知道”，而在于“舍不得”。很多人觉得继续聊很方便，不愿意重新描述一遍。但只要你算一笔账：一个已经累积了 200 轮历史的会话，每问一句话都在为 200 轮的历史付费，重新开一个会话的成本通常低得多。
4.2 像 git commit 一样设置检查点和预算
在长任务中，我会在每一阶段结束时，让模型输出一个简短的进展清单，然后清空上下文。这就像给会话做 commit。即使后面出了问题，也能回到最近的检查点重来，而不是保存着一整段臃肿历史。
成本控制上，可以给每个阶段预留预算。比如一个大重构包含分析、编码、测试三个阶段，每个阶段结束后先检查本轮 Token 消耗。若超出预期，就用压缩历史的方式重置，而不是放任它继续膨胀下去。
记住，压缩历史会丢掉部分细节。压缩前先确认关键信息已经落在输出里，最好保存一份外部笔记。
4.3 固定操作脚本化
如果某个流程经常出现，比如“拉取最新代码、运行 lint、执行单测、构建镜像”，与其让模型每次重新理解并逐步执行，不如把它写成一个脚本，让模型直接调用。脚本的好处是输入成本低、输出结果固定、不容易产生额外轮次。从成本角度看，它把一类反复出现的对话变成了一次单次命令。
这种方法也适用于你经常做的代码格式化、日志抓取、环境切换等操作。把重复劳动从对话里剥离出去，模型就可以把宝贵的 Token 用在真正需要判断和设计的地方。
4.4 成本异常时的排查链路
如果某一天用量异常偏高，可以按这个顺序排查：
- 看会话长度：是不是有一个会话撑了几百轮？如果有，先清理或压缩。
- 看输入侧：指令文件是否太庞杂？是否在反复读取大型目录？是否让模型扫描了依赖目录？
- 看输出侧：是不是每个回答都很长？是否让模型做了大量备选方案说明？
- 看工具调用：是不是模型频繁搜索文件？很多搜索都能通过直接给出路径避免。
- 看任务边界：是否把不同类型任务堆在同一会话？一个会话里既要重构又要测试，会让上下文互相干扰。
这个排查链路不需要复杂工具，通常看最近几个会话就能定位问题。最需要警惕的其实是“没有异常感”的状态，因为累积型消耗总是在不知不觉中发生的。
5. 成本优化的边界：哪些场景不值得省 token
任何优化都有边界。一味省 Token，可能让结果变得更差。这一节主要防止用力过猛。成本不是唯一指标，很多时候，多花的 Token 其实买到了更重要的东西。
5.1 排查复杂 Bug 时，完整上下文比省钱更重要
如果一个问题涉及多个模块、多种状态、多次实验，清空上下文就是灾难。你之前告诉模型的每个细节，都可能是排查线索。此时保持较长会话、保留历史，反而能减少总轮次。因为如果不断重置，每次都要重新解释背景，还容易遗漏关键信息，最后付出的总成本更高。
这种场景下，我会刻意不去执行 2.2 里的“会话清理”规则，而是让上下文保留足够完整，等问题解决后再整体重置。省钱应服务于效率，不是反过来。
5.2 学习陌生项目时，连续理解需要更多 Token
当你刚接手一个项目，需要模型帮你理解整体结构时，不应该频繁清理上下文。这种场景的价值不在于“省”，而在于“理解连续”。连续提问能让模型不断整合信息。如果每问一次就清空，它每次都是从零开始，你也很难获得深层理解。
这里适合用一点笨办法：先花较多 Token 建立项目心智模型，再开始做具体任务。这笔前期投入会在后续开发中得到回报，因为你后续每次写代码，都能更快说清楚需求的上下文。
5.3 判断优化策略是否有效的四个标准
面对任何一种省钱技巧，可以先问四个问题：
- 它是否减少了不必要的输入？比如重复扫描、无关文件读取。
- 它是否减少了不必要的输出？比如冗长解释、多方案罗列。
- 它是否缩短了有效会话？上下文能否维持在较小规模。
- 它是否提升了任务的可复用性？比如脚本化、文档化。
如果一个策略只是让对话记录变短，却让任务结果变差，那它就不是真正的优化。省 Token 的终点不是把对话压到最短，而是让每一段对话都刚好够用。
我自己的感受是，Claude Code 这类工具带来的效率提升，往往会掩盖成本增长的速度。等到月底看账单才意识到超标，其实已经晚了。真正合理的做法，是在使用过程里把会话当成一个可以管理的资源，而不是一个永远延续的聊天窗口。你可以把成本优化理解成编程中的重构：不要追求每行代码最短，而要让模块边界清晰、职责单一、复用性更好。当你开始用这种思路管理会话，Token 成本自然会降下来。
如果你想从今天开始改变，我建议不要先背命令，而是打开最近三天最长的几个会话，做一次成本复盘。看哪些轮次读了无关文件、哪些回答超出了需求、哪些历史其实早就该清理。从那里起步，你会知道省 Token 不是一个技巧清单，而是一套围绕上下文的工程习惯。