Claude Code 成本控制：六个实用技巧减少 Token 消耗

Claude Code 用得好不好，很多时候不是看它会不会写代码，而是看你会不会控制成本。上个月我做了一次成本复盘，发现一个很扎心的事实：功能都完成了，token 消耗却比我预想的高出一大截。翻细节后才发现，真正烧钱的不是模型不够聪明，而是我一直在让它背着一堆无用上下文往前走。

Claude Code 这类终端 AI 编程工具，本质上是在一个长对话里反复调用模型。每次你让它改一个东西，它都要把之前的对话历史、项目文件、工具输出重新处理一遍。历史越长，单次请求越贵。这篇文章不聊抽象的“省 token 技巧”，而是六条我在实际项目里验证过、能直接落地的做法。如果你的浪费主要出在上下文不干净、任务边界模糊、失败重试太多这些地方，组合起来成本降一半并不是夸张话。

1. 先把账算清楚：token 到底花在哪三个地方

想省钱，先要知道钱花在哪。模型计费通常按输入 token 和输出 token 分开算，Claude Code 的消耗不只是你打字的那几行，而是它“看得见的一切”。

1.1 输入 token 的三大入口

Claude Code 执行任务时，会把系统提示、项目规则、对话历史、工具调用结果、你主动提供的文件内容一起打包发给模型。很多人有个误区：我输入的提示词不多，应该不太贵。实际情况下，真正占大头的是下面三类：

• 对话历史。包括你之前所有的提问、模型的所有回答、工具调用的中间日志。只要这个会话不结束，每一轮新请求都会把前面内容重新发送一遍。
• 主动粘贴的上下文。整份源码文件、一整段报错日志、一个超大 JSON，都是常见浪费源。
• Agent 自己读取的文件和目录结构。它执行搜索、读文件、看目录时，可能一次把大量内容拖进上下文，虽然你看不到，但它确实已经计费。

1.2 会话越长，单次成本越高

这个模型有一个容易被忽略的特性：对话越到后面，每次新请求的输入都会被前面所有内容占满。比如一个会话断断续续聊了三个小时，可能当前真正的问题只有几十个 token，但模型在回答前要先消化前面几千甚至上万的历史 token。

我见过连续跑一整天的 Claude Code 会话，到下午处理一个很简单的小需求时，响应明显变慢，费用也在肉眼可见地涨。原因不是模型变笨，而是它每次都要背着整个上午的上下文往前走。所以省 token 的第一个思路不是换更便宜的模型，而是让模型每次只看它该看的那部分。

如果你用的是支持上下文占用检查的工具，可以先看每个会话到底用了多少上下文；就算不看，从响应速度和费用变化也能判断出来。别等月底账单出来才后知后觉。

2. 技巧一：用项目规则把“想当然”变成硬约束

2.1 项目指令为什么能省 token

让 AI 帮你写代码时，它面临的最大问题往往不是不会写，而是不知道你的项目约定：测试框架用哪个、目录结构怎么组织、变量命名习惯是什么、能不能直接改依赖文件。如果你不告诉它，它就会猜；猜错了再修，修的过程又是一整轮对话。

Claude Code 这类工具通常会读取项目根目录下的规则文件，比如 CLAUDE.md。项目启动时先初始化一份项目说明，把项目背景、常用命令、代码风格、禁止改动区域写清楚。之后每次启动会话，模型都会自动带上这些规则。

你可能会问：这不就是在多消耗 token 吗？确实，规则文件本身会占一部分输入，但它减少的是大量来回确认。一次猜错可能花掉几百个 token，来回试探几轮就是几千。规则文件只有几行，却能避免多次返工，这是典型的花小钱省大钱。

2.2 落地时的具体写法

初始化规则文件时，至少写这几类信息：

• 项目是做什么的，哪些目录绝对不能乱动。
• 测试和构建命令的固定写法。
• 代码风格约定，比如 TypeScript、组件命名、样式方案。
• 工作流约定：先写测试，再改实现，最后跑命令。

# 项目约定 - 技术栈: TypeScript + React - 禁止修改: vendor/ 和 generated/ - 测试命令: pnpm test - 构建命令: pnpm build - 组件命名: 使用 PascalCase - 提交前必须跑测试

写完以后，如果第二天模型还在问“这个项目用什么包管理器”，说明规则还不够细，把它补进去。这样每轮会话省下的数量不大，但积累一个月，省下的是一大批重复确认的开销。

注意：规则文件最好不要写满一屏。它应该是一份有效索引，不是项目百科。太长的指令本身也会占 token，而且会稀释真正重要的约束。

3. 技巧二：喂给 agent 的不是文件，是定位信息

3.1 少贴文件，多给路径

我见过很多人在终端工具里习惯把整个文件内容复制进来，甚至一口气贴十几个文件。对模型来说，一次性看到完整文件确实更安全，能减少理解偏差。但绝大多数情况下，文件里只有一小块和当前任务相关。大文件一旦进入上下文，即使你不引用它，它也已经占用了输入 token。

更省钱的做法是只给文件路径和问题描述，让模型自己按需读取。例如“看 src/components/pricing.tsx，把定价区改成三列布局”，它会先读文件，再定位到相关段落。如果你担心它找不到关键位置，可以在需求里补上函数名或行号范围。

平时可以先在命令行用 grep 或类似工具找到关键词位置，然后把“关键词 + 文件路径 + 具体问题”传给模型。这比粘贴整个文件更准，因为模型知道该看哪里，而不是在噪声里找线索。

3.2 让模型看 diff，而不是全集

另一个常见浪费源是改代码时把整个文件重新贴一遍。更符合版本控制思维的做法是：把改动差异说明给模型，或者直接用git diff生成片段。修 bug 时，git diff能把变更点压缩到几十行，而整个源文件可能几千行。

我一般会让模型先看 diff 和报错日志，判断问题来源，再去读具体文件。这个顺序可以避免它把整个项目从头扫一遍。以前我习惯让 agent 先“浏览项目结构”，听起来很专业，实际它会读目录列表和大量关键文件，一轮下来比改代码本身还贵。改成“先看 diff + 报错，再看相关文件”之后，单次修复的成本降了不少。

4. 技巧三：一个会话只做一件事

4.1 历史记录是隐形成本

这是最容易被忽视的一点。很多人用 Claude Code 像用聊天软件，想到什么问什么：先让写个函数，又让它顺便看看刚才的样式，再让它重新解释一遍上一轮代码，全部挤在同一个会话里。

问题在于，每轮新请求都会带着前面所有对话一起发送给模型。哪怕前面的讨论已经结束，模型还是要重新读一遍。如果历史里有大段工具输出、报错堆栈，这个会话就变成了一个不断膨胀的“上下文包袱”。

我的判断标准很简单：一个问题已经解决，就立刻开新会话；后续问题和当前主题关系不大，也换新会话；需要继续但历史已经很长，先压缩会话。压缩就是把长对话浓缩成一段摘要，保留关键结论，删掉中间的大段完整轮次。

4.2 什么时候压缩，什么时候清空

可以按场景快速判断：

• 任务完成了：开新会话。
• 任务进行中但对话已经很多轮：压缩历史。
• 任务换方向了：直接清空，避免旧思路干扰新任务。
• 只是临时查一下资料：可以用独立短会话，处理完就关掉。

清空也有代价，模型会忘记你刚才改到哪，需要重新提供文件路径和当前状态。所以更推荐“压缩”而不是“清空”，除非旧上下文本身不重要。把会话状态当成工作台，不要让它变成仓库。工作台上只放当前任务要用的东西，做完就清，下一次任务重新摆。

5. 技巧四：把输出“管短”也是一种优化

5.1 在指令里直接要求短输出

很多人只盯着输入 token，忽略了输出 token。模型生成的每个字都要计费，而且生成的长解释会继续留在上下文里，影响后续请求。

比如你让它“优化这段代码”，默认它可能会先解释思路，再给出完整修改版本。但你可以明确写：不要解释思路，直接输出修改后的代码；只要关键改动，不要重复整个文件；解释控制在三行以内。这些约束不需要额外配置，在支持自然语言指令的工具里基本都有效。

用一段时间后你会发现，降低输出长度不只是省 token，还能让模型更聚焦。输出越短，留给后续任务的上下文空间越大，准确率反而可能提升。

5.2 要求“定位修改”而不是“整体重写”

同一个需求，不同的表达方式消耗差异很大。“把这个函数重构一遍”可能让它输出几十行；换成“只修改第 12 行到第 18 行，保持其它不变”，它就会只输出那几行片段。

在批量调整样式或重构时，我会先让模型列出所有需要改的文件和具体改动点，确认范围后再执行修改。虽然多了一轮“列计划”，但避免了它在错误方向上一口气生成大量无用代码。这个小流程表面上多花几十个 token，实际上把返工成本压下来了。

5.3 让输出落地到文件，而不是终端

如果你需要生成一个完整文件，尤其是比较长的内容，不建议让模型在终端里把内容全部打印出来。终端输出会占用显示和上下文，而且一旦打印完，它又成为历史的一部分。可以用重定向把输出写到文件，或者让工具直接修改文件。这样既能查看落地结果，又避免整段内容反复出现在对话历史中。

6. 技巧五：失败重试前先问“为什么失败”

6.1 重试链的 token 放大效应

终端工具里最常见的费用失控场景是反复试错。模型第一次执行代码失败，你说“再试一次”，失败后你又换个说法重来。每重试一次，失败信息和前一次尝试都会作为历史重新发送，下一轮输入变得更大。

尤其是当报错信息本身非常长时，比如一个依赖栈、一段测试失败日志，再叠加模型自己的分析，全部会累加。重试三次，费用可能不是三倍，而是更多，因为历史在滚动累积。

遇到失败，不要急着说“再试一次”。先让模型“只总结失败原因，不要改代码”，把日志里最核心的报错行提炼出来。确认原因后，再让模型给一个最小修改方案。如果报错和当前任务无关，直接用新会话处理，避免污染当前上下文。

6.2 先跑最小样例，再放真实任务

批量场景下更危险。很多人拿到新需求，直接让模型同时处理十个文件。模型走到第三个文件时发现格式不对，回头改提示词，结果所有文件都要重跑。

正确的顺序是：先用一条最少量的样例验证提示词是否有效，确认输出符合预期，再扩大到全部数据。这个验证成本很低，却能拦截大多数“提示词理解偏差”问题。一旦发现提示词有误，调整的只是一个小对话，而不是整批重跑。这本质上和写代码前先写单测是同一个思路：先保证最小的路径正确，再让它规模化。

建议：给 agent 的每个批量任务都加上“先处理一个样本，停止并等待确认”这样的约束。没有这个约束，太多情况是它一口气执行完，出了问题再整体返工。

7. 技巧六：用脚本和批处理替代长时间对话

7.1 把重复操作变成可复用脚本

Claude Code 最大的价值在于处理复杂、不可预知的任务，但它并不适合做重复率高、规则明确的事情。如果你发现自己每天都要让它做同一件事，比如“把所有图片压缩一遍”“给每个接口补参数校验”，更省 token 的方式是把这些重复操作脚本化，让脚本批量执行。

脚本先把逻辑固化下来，后续执行时不需要模型参与，也就没有 token 消耗。如果必须让模型生成脚本，就让它生成一次，你保存下来长期复用。这个做法把“每次让 AI 重新理解需求”变成“一次性投资”，长期成本下降非常明显。

常见可脚本化的场景包括：

• 文件重命名、格式转换、批量替换。
• 代码样式检查和简单修复。
• 测试数据生成。
• 文档模板生成。
• 重复性的 API 调用。

7.2 使用非交互模式处理单一任务

如果你已经明确知道要做什么，不需要现场讨论，可以试试非交互模式。比如通过一条命令直接给出明确指令，让模型执行完就退出。这种方式不会维护长会话历史，单次请求的上下文非常干净。

需要多步处理时，也尽量在一个命令里把步骤写清楚，而不是分多条消息慢慢挤牙膏。这等于把“聊天式开发”变成“命令式开发”。聊天适合探索，命令适合执行。探索过程本身很贵，执行过程相对便宜。能提前把结论写清楚，就不要在终端里慢慢试。

8. 最省 token 的工作流：一个综合流程

8.1 把它变成每天都能用的检查单

上面的六个技巧，单独看都不难，难的是组合起来。组合后的理想流程是：

1. 写清目标：一句话描述任务，附上相关文件路径或函数名。
2. 确认规则：项目指令文件存在且完整，不用模型靠猜。
3. 最小上下文：优先使用 diff、报错关键行、单文件局部内容。
4. 限制输出：明确要求短输出，只改指定位置。
5. 小步验证：先执行一个样本，确认无异常再扩大范围。
6. 及时清理：完成一个子任务就压缩或新建会话，保持历史干净。
7. 固化重复：频繁操作沉淀成脚本，不再每次开对话。

这可以当作团队规范，也可以当作个人检查清单。用久了会形成一种肌肉记忆：每次打开终端工具前，先问一句“这次任务需要模型看到什么？” 这个问题的答案，基本决定了你会花多少 token。

8.2 边界：哪些情况下效果有限

需要诚实说，这六个技巧并不是在所有场景下都能让 token 下降一半。如果你的任务本质是长链条推理，比如分析一个大型代码库的调用关系、重写一个复杂模块，那模型必须看很多文件，“减少上下文”就很难执行，token 下降空间有限。

相反，如果你的痛点主要是闲聊式提问、反复修改、贴了一大段代码之后又说“刚才不算”，那这六个技巧组合起来，成本降一半并不是夸张。不同模型和工具的计费结构也不一样，有些按输入输出统一计费，有些分开算，还有缓存机制。实际优化效果要结合你用的具体计费方式来看，思路可以借鉴，但不要当成万能公式。

如果你刚接触这类工具，第一步不是研究怎么省 token，而是先把安装和登录跑通。很多人在安装后卡在登录环节，看到类似 “token exchange failed” 的报错就慌了。这里的 token 指的是访问凭据，和我们前面一直在说的模型计费 token 是两回事。遇到这种报错，先检查网络是否连通、系统时间是否准确、登录授权是否过期，再重新登录。如果是在团队环境，还要确认当前网络策略是否允许访问对应域名。把登录问题解决掉，再回来按这个流程优化成本。

8.3 从省 token 到省时间

关于 token 成本，一个更底层的看法是：不要只盯着费用，更要看它是否在改变你的工作流程。当模型每次只处理它该处理的内容时，你的需求也会变得更清晰；需求清晰了，返工自然变少。这时候省下来的不只是 token，还有时间。后者往往比 token 成本更值得长期关注。