2.1验收-调试
2026/10/2 6:12:15
1. 三个工具到底在烧什么：Token 消耗的真实账本
先把一个误区掰开：很多人以为 Token 消耗是"用多少算多少"，其实真正烧钱的是上下文重复投喂。ClaudeCode、Codex、OpenCode 这三个工具本质都是"把代码库塞进模型上下文，让模型理解后再改代码"，问题就出在这个"塞"字上。
我拿一个真实的中型项目举例，大概 300 个源文件、8 万行代码。第一次让 ClaudeCode 帮我改一个登录模块的 bug，它扫描了整个项目结构，读取了相关文件，这一轮下来输入 Token 直接干到 12 万。改完之后我让它再优化一下错误处理，它又把刚才那些文件重新读了一遍——又是 10 万 Token 打底。一天下来，光是重复读取同一个文件就烧掉了几十万 Token。
这就是标题里"节省 80%"要解决的核心问题：不是让你少用工具，而是让工具别重复干同一件事。
三个工具的 Token 消耗机制各有特点，我整理了一张对照表：
| 工具 | 上下文管理方式 | 典型浪费场景 | 可优化空间 |
|---|---|---|---|
| ClaudeCode | 会话内自动累积上下文 | 长会话后期每轮都携带全部历史 | 高，可通过会话切分优化 |
| Codex | 按请求组装上下文 | 每次调用重新读取文件 | 极高，可缓存文件摘要 |
| OpenCode | 支持 skill 按需加载 | 全量加载 skill 描述 | 中高，可精简 skill 元数据 |
理解这张表是省 Token 的第一步。ClaudeCode 的浪费在于"历史包袱"，Codex 的浪费在于"重复读取"，OpenCode 的浪费在于"元数据膨胀"。针对不同工具要用不同策略，一刀切是没用的。
提示：Token 计费里输入和输出价格差好几倍，绝大多数人的钱都花在输入上。优化重点永远放在"减少输入 Token"，而不是"让模型少说话"。
2. 省 Token 的底层逻辑：把"每次重读"变成"读一次记住"
2.1 为什么传统用法必然浪费
模型没有记忆，这是根本原因。你关掉会话再打开，它对你项目的了解归零。哪怕同一个会话里，上下文窗口也是有上限的，超了就得截断或者压缩，压缩过程本身又消耗 Token。
我见过太多人的用法是这样的：打开 ClaudeCode，说"帮我看看这个项目"，它开始扫描；改完一个功能，接着说"再帮我改另一个"，它又扫描一遍。这种"对话式连续操作"在 Token 账单上就是灾难。
正确的思路是把项目知识固化成可复用的资产，让每次新会话不用从零开始理解项目。这个资产可以是：
- 一份精炼的项目结构说明文件
- 一组关键文件的摘要缓存
- 一套按需加载的 skill 或规则文件
2.2 三层缓存策略
我实测下来最有效的方案是三层缓存，从粗到细：
第一层：项目级摘要（Project Brief）
在项目根目录放一个PROJECT_BRIEF.md，用 500 字以内说清楚：项目是干什么的、技术栈、目录结构、核心模块职责、编码规范。每次开新会话第一件事就是让工具读这个文件，而不是让它自己扫描。
这一层能省多少？我实测一个 8 万行项目，让工具自己扫描理解大概要 8-12 万 Token，读一份 500 字的 brief 只要 800 Token 左右。单次省 90% 以上。
第二层：模块级摘要（Module Digest）
每个核心模块目录下放一个MODULE.md，说明这个模块的职责、对外接口、依赖关系、关键文件列表。当任务只涉及某个模块时，只读这个模块的摘要，不读其他模块。
第三层：文件级缓存（File Cache）
对频繁修改的文件，维护一份"当前状态摘要"，包含函数签名、关键逻辑说明、最近改动点。改代码前先读摘要，确认要动哪个函数，再精准读取那一个文件，而不是整个目录。
2.3 为什么这套方案能省 80%
算一笔账。假设一个任务需要理解 20 个文件：
- 传统方式：每次任务都全量读取 20 个文件，平均每个文件 3000 Token，单次 6 万 Token
- 三层缓存：读 brief（800）+ 读 2 个模块摘要（各 500）+ 精准读 3 个相关文件（各 3000）= 1.08 万 Token
单次节省约 82%。如果一天做 10 个任务，传统方式 60 万 Token，缓存方式 10.8 万 Token，差距就是真金白银。
注意：摘要文件本身要维护，改完代码记得同步更新。我踩过的坑是摘要和实际代码脱节，导致工具基于错误信息改代码，反而浪费更多 Token 去纠错。
3. 三个工具的差异化配置实操
3.1 ClaudeCode：用 CLAUDE.md 和会话切分控制上下文
ClaudeCode 会自动读取项目根目录的CLAUDE.md，这是官方支持的机制，但很多人不知道怎么写才能省 Token。
我的CLAUDE.md模板长这样：
# 项目速览 - 技术栈：React 18 + TypeScript + Vite - 包管理：pnpm - 测试：Vitest # 目录约定 - src/components：UI 组件，一个文件一个组件 - src/hooks：自定义 hooks - src/api：接口封装，统一走 request.ts # 编码规范 - 组件用函数式，不用 class - 状态管理用 zustand，不用 redux - 样式用 tailwind，不写 css 文件 # 常用命令 - 启动：pnpm dev - 测试：pnpm test - 构建：pnpm build # 不要做的事 - 不要扫描 node_modules - 不要读取 dist 目录 - 不要修改 package.json 除非明确要求关键在最后那段"不要做的事"。ClaudeCode 有时候会"热心"地去读一些无关目录，明确禁止能省下大量 Token。
会话切分也很重要。我的习惯是一个任务一个会话，任务完成后直接开新会话，而不是在同一个会话里连续做多个不相关的任务。因为 ClaudeCode 会把整个会话历史都带上，会话越长，每轮消耗越大。
3.2 Codex：用文件摘要缓存对抗重复读取
Codex 的机制是每次请求独立组装上下文，所以它特别容易重复读取。我的做法是在项目里维护一个.codex-cache/目录，存放各文件的摘要。
具体操作流程：
- 首次让 Codex 分析项目时，要求它输出每个核心文件的摘要，保存到
.codex-cache/ - 后续任务开始时，先让 Codex 读
.codex-cache/里的摘要 - 确认要改哪个文件后，再让 Codex 精准读取那一个文件
给 Codex 的提示词可以这样写：
先读取 .codex-cache/summary.json 了解项目结构， 不要扫描整个项目。确认要修改的文件后， 只读取该文件，不要读取同目录其他文件。实测这套流程能把 Codex 的单任务 Token 从 5-8 万压到 1 万以内。
3.3 OpenCode：精简 skill 元数据，按需加载
OpenCode 的 skill 机制很强大，但每个 skill 的描述都会占用上下文。如果你装了 20 个 skill，光元数据可能就吃掉几千 Token。
我的优化原则是只装当前项目需要的 skill，其他全部禁用。比如做前端项目时，后端相关的 skill 全部关掉。
另外 OpenCode 支持在 skill 里写"触发条件"，把触发条件写得精准一些，避免不相关的 skill 被误加载。比如不要写"处理代码相关任务"，而要写"当用户要求重构 React 组件时触发"。
提示：OpenCode 的免费额度有使用范围限制，具体以官方说明为准。付费套餐的 Token 计费方式建议在官网确认最新规则，我这里只讲通用的节省思路。
4. 提示词层面的省 Token 技巧
4.1 精准描述胜过模糊提问
"帮我优化一下这个项目"——这句话会让工具去扫描整个项目。
"优化 src/utils/date.ts 里的 formatDate 函数，它现在处理时区有问题"——这句话让工具直接定位到一个文件的一个函数。
两者 Token 消耗差 10 倍以上。养成习惯：说清楚文件路径、函数名、具体问题。
4.2 用"只读摘要"代替"读取全文"
当你不确定要改哪个文件时，不要让它读全文，而是让它先列文件清单和摘要：
列出 src/api 目录下所有文件，每个文件用一句话说明职责， 不要读取文件内容。这样它只会读目录结构，Token 消耗极低。确认目标后再精准读取。
4.3 批量任务合并成一次请求
如果你要改 5 个文件的同类问题，不要分 5 次请求，而是一次性说清楚：
以下 5 个文件都有相同的空值处理问题，请统一修复： - src/api/user.ts 的 getUser - src/api/order.ts 的 getOrder ...一次请求的上下文组装成本远低于 5 次独立请求。
4.4 明确禁止"过度探索"
在提示词里加一句：
只修改我指定的文件，不要读取或修改其他文件， 不要运行测试，不要检查依赖。这句话能挡掉大量"热心"的额外操作。我实测加这句话后，单任务 Token 平均下降 30%。
5. 常见问题与排查速查表
实际用下来，省 Token 路上踩的坑不少，整理成表方便对照：
| 问题现象 | 根本原因 | 解决方法 |
|---|---|---|
| 单次任务 Token 突然暴涨 | 工具扫描了 node_modules 或 dist | 在配置文件中明确排除目录 |
| 长会话后期越来越慢越贵 | 上下文累积过多 | 任务完成后开新会话 |
| 摘要和代码不一致导致改错 | 摘要未同步更新 | 改完代码立即更新摘要文件 |
| skill 加载了不相关的内容 | 触发条件写得太宽泛 | 收窄触发条件，禁用无关 skill |
| 重复读取同一文件 | 工具没有文件级缓存 | 手动维护摘要缓存目录 |
| 提示词被误解导致大范围扫描 | 描述太模糊 | 明确文件路径和函数名 |
| 授权频繁打断操作 | 权限配置过严 | 在可信项目内适当放宽权限范围 |
关于授权打断的问题，热词里也有人提到"claudecode 在使用的时候经常需要授权"。我的做法是在个人可信项目里，把常用操作加入白名单，减少打断。但涉及删除文件、执行危险命令的操作，还是保留确认，安全第一。
6. 一套可直接抄的省 Token 工作流
把前面所有东西串起来，形成一套固定流程。我每天就是这么干的：
开工前：确认PROJECT_BRIEF.md和模块摘要是最新的，如果昨天改了核心模块，先花 2 分钟更新摘要。
任务开始：新开会话，第一句永远是"先读 PROJECT_BRIEF.md 和相关的 MODULE.md，不要扫描项目"。
任务描述：明确文件路径、函数名、具体问题、期望结果，加上"只改指定文件"的约束。
执行中：如果工具开始读取无关文件，立即打断，重新给精准指令。
任务结束：更新受影响的摘要文件，关闭会话。
定期维护：每周花半小时检查摘要文件是否和代码一致，清理不再需要的缓存。
这套流程我坚持了两个月，Token 账单从每月 200 多降到 40 左右，降幅正好在 80% 上下。而且因为上下文更精准，工具改代码的准确率反而提高了——它不再被无关信息干扰。
最后分享一个小心得：省 Token 的本质不是抠门，而是让工具把注意力集中在真正相关的事情上。上下文越干净，模型表现越好，这和省钱是同一件事。我见过有人为了省钱把上下文压得太狠，结果工具理解不了任务，反复试错反而更贵。找到那个平衡点，才是真正的省钱之道。