迟子realClaude Code 这类 AI 编程助手在写代码、改 bug、做重构时确实能省不少事，但如果不把 Token 成本当回事，很容易出现任务做完、费用也比预期高好几倍的情况。很多开发者以为省钱就是减少提问次数，实际上更大的浪费藏在上下文管理、文件读取和无效输出里。这篇文章不聊账号和模型选择，只讲在使用 Claude Code 做编程时，如何通过控制上下文、拆分任务、优化交互、建立基线监控，把 Token 消耗压下来，同时保持代码质量和开发速度。适合长期使用 AI 编程工具的开发者，也适合刚入门、想从一开始就养成省 Token 习惯的人。
1. 先搞清楚 Claude Code 的 Token 成本到底消耗在哪
Token 可以粗略理解成模型处理文本的最小单位，一个英文单词大概对应一到两个 Token，中文则要看分词方式。Claude Code 每执行一次请求，都会把当前会话里需要处理的文本一起算成 Token，再产生一次费用。一个常见误区是：很多人以为成本只和你输入了多少字有关，实际上，模型需要重新处理整个会话上下文。
1.1 一次对话里，有哪些环节会消耗 Token
一次正常的会话中，至少这几个环节都会产生 Token：
- 系统提示和工具定义。Claude Code 运行时会注入系统级指令，用来告诉模型自己是编程助手、有哪些工具、怎么使用。这部分每次请求都会固定出现。
- 用户消息。你的指令、问题、粘贴的代码片段、补丁内容、错误日志，都会进入上下文。
- 模型输出。包括生成的代码、解释、修改说明、可能的 Markdown 报告。
- 工具调用。当 Claude Code 调用读文件、运行命令、搜索代码等工具时，工具返回的具体内容也会进入上下文。
这意味着，你让模型读一个大文件，哪怕最终没用上，它也会为那次读取支付 Token。很多人只注意到“我让它生成了什么”，却忽略了“我让它读了什么”。
1.2 最隐蔽的浪费：上下文像雪球一样滚大
Claude Code 采用的是对话式上下文机制。模型要理解当前任务，得把之前的消息全部纳入计算。不是它“记得”你说过的话，而是它重新“读”了一遍。
我在测试时经历过一个典型场面：为了改一个按钮的样式，先让 Claude Code 读了两个组件文件，又跑了一下构建日志，然后来回调整了四轮。最后一轮它只是回了一行代码，但那一次请求的输入 Token 已经非常大，因为前面读过的东西全都还在上下文里。
所以优化 Token 成本，第一优先级不是少问问题，而是让每次请求携带的上下文尽可能短，并且保持结构清晰。
下面用一个简单对比帮助理解，这里的数值只是量级参考，不是计费标准：
| 做法 | 上下文影响 | 资源消耗 |
|---|---|---|
| 粘贴整个 500 行文件 | 后续每次请求都会重新包含 500 行内容 | 高 |
| 只粘贴函数片段 | 后续请求会包含片段，但长度可控 | 中低 |
| 新开会话做下一个任务 | 后续请求不会带上旧文件全文 | 低 |
同一件事，不同喂法，Token 消耗可能是几倍甚至十几倍的差距。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 优化之前，先建立一条成本基线
没有基线，就没有优化。我一般会先连续记录 5 个真实任务，让数据告诉自己什么最费。这里的任务不是随便写几行代码演示，而是你日常真正会做的事，比如实现一个接口、修复一个崩溃、给两个模块做小重构。
2.1 记录一个典型任务的 Token 消耗
记录的核心字段很简单：
- 任务类型
- 请求次数
- 输入 Token 约值
- 输出 Token 约值
- 最终效果
我习惯用表格保存：
| 任务类型 | 请求次数 | 输入 Token 约值 | 输出 Token 约值 | 备注 |
|---|---|---|---|---|
| 新增接口 | 4 | 高，因为读了多个文件 | 中 | 会话较长 |
| 修崩溃 | 8 | 很高，因为反复看日志 | 低 | 返工多 |
| 批量重构 | 10 | 很高，因为每轮都带旧文件 | 高 | 上下文堆积 |
如果 Claude Code 有内置统计，直接用统计值。如果没有，可以从 API 控制台查看总消耗，或者自己按请求次数和上下文长度估算。重点不是精确到分，而是能看出不同任务的量级。
2.2 找出高消耗环节
做完记录后，最关键的一步是回看。我会问自己三个问题：
- 这个会话是不是拖得太长了？
- 是不是读了太多无关文件？
- 是不是模型在反复试错？
如果有一个答案是肯定的，那个任务就有优化空间。
修 Bug 类任务往往最费，因为日志和报错天然很长。批量重构也容易费，因为你会反复让模型读取不同文件。相比之下，功能实现反而更容易控住，前提是你能说清楚需求。
记录时还有一种常见误区：只看总共花多少钱，不看具体是哪个环节偏贵。比如某个会话输出 Token 不高，但输入 Token 特别高，说明问题大概率在读取文件和上下文堆积，而不是模型生成太多。另一个会话如果请求次数不多，但每次输入都很大，那就是上下文太长。区分这两种情况后，优化方向会非常清楚。
3. 减少上下文输入，从读文件开始
很多 Token 浪费并不是发生在模型输出阶段，而是发生在输入阶段。因为每次请求都带着之前的全部上下文，所以输入越长，成本越高。想省钱，第一件事就是管住输入。
3.1 缩小项目可见范围
Claude Code 在工作时会扫描当前工作区，做搜索、读文件、跑命令。如果你的项目根目录下有大量依赖和构建产物，没有规则约束时，它就可能读到很多和任务无关的内容。
很多项目会使用忽略规则，把 node_modules、dist、build、.git、vendor、临时日志这类目录排除掉。具体配置语法会因为工具版本不同而有点差别，建议直接看当前版本的帮助文档，但思路是一致的：让模型只看到该看的目录。
我见过一个项目，根目录里有几千个文件，但真实要改动的地方只有两三个。如果不做忽略规则，模型搜索时会频繁命中无关文件，每次命中都会增加 Token 开销。最好在项目一开始就配好，而不是等到消耗起来再改。
3.2 用精确内容替代“整文件粘贴”
不要为了省事把整个文件丢进去。一个 500 行的文件，真正相关的也许只有 30 行，剩下 470 行都是额外费用。更聪明的做法是先用命令行工具把关键片段抓出来，再交给 Claude Code。
bash复制# 定位函数位置
grep -n "function createUser" src/user.js
# 提取第 120 到 180 行
sed -n '120,180p' src/user.js
# 查看最近改动，适合发给模型做审查
git diff src/user.js
这些命令的结果本身就在终端里，可以直接复制给 Claude Code。输入长度变短了，模型注意力也更集中。如果确实需要完整文件，我建议只在文件小、且大部分内容都相关时才这么做。
3.3 把长对话切成短会话
很多 AI 编程工具支持连续对话，但连续对话不是免费的。每一轮新请求都会把之前的对话内容重新算一遍。所以，一个会话里堆的需求越多，后续每一轮就越贵。
我一般按任务分会话：一个会话只做一件事。比如“新增登录接口”是一个任务，“给订单列表加分页参数”是另一个任务。做完一个，新开一个。写下一个任务时，我会先看一眼上一个任务留下的 git diff 或输出结果，把它们作为下一轮的新输入，而不是让模型慢慢回忆。
刚开始会担心丢失上下文，但实际操作下来，只要任务描述清楚，加上你贴出的关键片段，模型的理解效果往往比几十轮长对话更好。上下文短，模型反而更不容易被旧消息带偏。
4. 换一种交互方式，让模型少返工
返工越多，输出 Token 越浪费。模型如果不懂你的意图，就会输出大量猜测代码。所以，省 Token 的起点是写好第一条指令。
4.1 先把需求描述清楚
高效指令通常具备四个部分：背景、目标、约束、验收标准。背景告诉模型它在什么项目里；目标告诉它要完成什么；约束告诉它不要动什么；验收标准告诉它什么时候算完。
| 模糊指令 | 高效指令 |
|---|---|
| “页面有点问题，帮我改改” | “在移动端宽度小于 375px 时，登录表单右侧溢出，请调整按钮 flex 布局，保持桌面端样式不变。验收：在 Chrome 模拟器 375px 宽度下没有横向滚动。” |
| “报错了，帮我看看” | “Node 18 下运行 npm test，出现 TypeError: Cannot read properties of undefined。堆栈指向 src/utils/parser.js 的 parseLine 方法。我的输入是 xxx，请给出最小修复。” |
| “每个 if 里都套了一层 try-catch，请统一” | “项目中 auth.js、order.js、user.js 三个文件都有相似的 try-catch 包裹逻辑，需要改成统一的自定义异常处理。先给出修改计划，再逐文件改。” |
第二种指令看起来长一些，但第一次就能跑对，整体反而便宜。模糊指令带来的连续追问，才是真正的 Token 消耗大户。
4.2 先要方案，再要代码
不是每次都要直接写代码。遇到重构、跨模块改动、需要动数据库结构这类任务，我建议先让模型出方案，确认后再写代码。
例如，你可以这样写：
“先不要改代码，分析 src/order.js 里 authorize 和 calculateTotal 两个函数，找出订单金额不对的潜在原因，列出三到五个可能点，按可能性排序。”
这一步的输入很小，模型输出也不多，但能避免模型按错误理解直接写出一大堆代码。你明确让它“先不要改代码”时，它通常只会输出分析，不会贸然生成大量补丁。这样返工概率明显降低。
4.3 批量修改时，一次拿到完整计划
批量重构最忌讳的是改一个文件对话一次。每对话一次，旧文件内容可能被重新加载，输出结果也一段一段地积累。
更省的办法是：把重复性问题归类，一次给模型总结所有需要改的模式，让它先生成一份修改计划。计划里要有文件路径、修改点、改动类型、风险级别。确认计划后，再让它按计划执行。
你可以这样写：
“请先不要改代码，分析 src/util 下所有包含 validate() 的文件，找出重复的参数校验模式，生成一个修改计划，按文件和改动类型分组。计划确认后，我会让你逐个执行。”
这样模型只需要读一遍相关文件，而不是每轮重新理解。批量任务的核心是减少无效读取和重复生成。
5. 三个高频场景的 Token 优化套路
说了一堆原则，最后还是落到具体场景。下面三个场景是我平时用到最多的，也是 Token 浪费最容易出现的地方。
5.1 场景一：在现有项目里新增功能
新增功能时，我一般只提供相关文件的路径和接入点，不让模型扫描整个项目。
示例指令：
text复制项目使用 Flask + SQLAlchemy。新增 /api/export 接口，数据来自 Order 表，输出为 Excel。相关文件：
- controllers/order.py
- models/order.py
- services/export.py
请参考现有 /api/order_list 的写法，保持同样的错误处理风格。开始前先列出改动点。
这样模型有明确的文件边界，不会到处翻。等它列完改动点，你再决定是一次性输出补丁还是分段执行。加功能时最怕让模型去读全局配置和所有路由，很多地方其实和这次改动无关。
5.2 场景二：修复一个 Bug
修 Bug 很容易让上下文爆炸，因为你会本能地贴长日志、贴大报错。我建议只带三样东西：错误信息的关键几行、出错函数的代码片段、复现时的输入条件。
日志很长时，先用 grep 抽关键行，而不是整段复制。
bash复制grep -n -A 10 "Traceback" server.log
grep -n -E "TypeError|ReferenceError" src/**/*.js
然后把结果发给模型：“下面是报错堆栈，函数在 xxx，调用参数为 yyy，请分析可能原因。”如果模型第一次给出的方向不对，你再补一条关键信息，不要直接让它全文搜索。全文搜索会带回来大量不相关内容，成本翻倍还不一定有用。
5.3 场景三：批量重构
批量重构的 Token 风险在于：每一轮都可能带上多个文件的内容，如果还要反复试错，成本会很高。
我的流程是：
- 先给模型看两三个典型文件的重复片段，让它总结规律。
- 让它生成重构计划，列出文件清单和每个文件的改动类型。
- 每次只改两三个文件，改完用
git diff检查。 - 某个文件改失败时，新开会话重新描述，不要继续在旧会话里滚。
旧会话里的失败案例越多，后续输入 Token 越贵。很多人下意识会继续追问，但更便宜也更高效的做法是关闭旧会话，把失败现象和当前文件状态重新描述一遍。新会话不携带旧日志，上下文马上变短。
6. 用数据和习惯持续盯住成本
优化不是一次性动作，而是一个循环。建基线、控上下文、改交互，最后还要用数据验证。
6.1 日常记录与复盘
如果每个会话的成本是固定的，就不用太操心，但实际每次差异很大。我建议每次使用后记录三件事：请求次数、输入 Token、输出 Token。如果可以，也记一下成本估算。
记录本身不一定需要新工具，一个简单的表格就有用。每周花十分钟看一遍，发现异常会话就问自己：为什么这个会话输入 Token 很高？是上下文太长，还是读了无关文件？
6.2 不要被缓存和参数带偏
有些产品会提供缓存能力，对重复前缀做缓存，确实可能降低一定成本。但缓存命中才有效，如果你为了命中缓存故意重复粘贴同样内容，很可能得不偿失。缓存不是万能兜底，真正的长期优化还是减少无效上下文。
输出侧也有一个容易被忽视的参数：最大输出长度。如果你发现模型经常在长篇大论地解释，可以检查是不是设置了过高的上限，或者指令里要求了多种方案。日常开发中，明确写“只要一种推荐方案，并说明原因”，输出 Token 会明显更少。
6.3 一个可复用的省 Token 检查清单
最后留一个检查清单，我每次用 Claude Code 前都会过一遍。它不复杂，但能拦住大部分浪费。
- [ ] 当前任务是否只涉及少数几个文件？有没有一开始就发“看看整个项目”这类宽泛指令？
- [ ] 是否已经配置忽略规则，排除了依赖目录、构建目录、日志和缓存？
- [ ] 粘贴内容是否只保留关键片段，而不是整个文件或整段日志？
- [ ] 需求描述里是否包含背景、目标、约束、验收标准？
- [ ] 是否先让模型出方案，确认后再写代码？
- [ ] 是否为一个任务单独开一个会话？
- [ ] 批量任务是否已经列清文件清单和改动类型？
- [ ] 报错信息是否经过裁剪，只留下关键行？
- [ ] 输出验证是否用
git diff快速检查，而不是反复让模型重新生成？ - [ ] 本次会话的消耗是否已记录，方便下次复盘？
这十条不是死规矩，而是一种习惯。刚开始会觉得多花了一点时间，但长期算下来，省下的 Token 成本远大于那点额外的心智成本。
踩过几次之后我发现，Claude Code 的 Token 成本问题，很多时候不是工具本身的问题，而是开发者没有把上下文当资源来管理。优化是一个持续过程：先建基线，再控上下文，然后改进交互方式，最后用数据验证。只要这一套循环跑起来，你的每一次提问都会变得更值钱。