1. 两个AI编程助手到底在“烧”什么
先把话说在前头：不管是Codex还是Claude Code，它们本质上都是把代码上下文塞进大模型的对话框里，让模型理解你的项目、生成补丁、跑命令、改文件。这个“塞进去”的过程，就是token消耗的源头。很多人以为token只跟“我问了多少字”有关，其实远不止——你的项目结构、历史对话、工具调用返回、文件读取范围，全都在悄悄吃token。
我最早用这类工具的时候，一个下午就把月度额度干掉了大半，当时还纳闷：我也没问几个问题啊。后来把日志翻出来一看，好家伙，光是让它“看一眼项目结构”，它就递归读了上百个文件，每个文件的开头都进了上下文。从那以后我开始认真研究省token这件事，踩了不少坑，也攒了一些确实管用的方法。
这篇文章适合两类人：一是刚上手AI编程助手、发现额度掉得比工资还快的新手；二是已经用了一段时间、想把这套工具真正跑进日常开发流的老手。我会把Codex和Claude Code分开讲，因为它们省token的底层逻辑有相通的地方，也有各自的门道。核心关键词就一个：上下文管理。谁把上下文管住了，谁就省下了token。
2. 先搞懂token到底花在哪
2.1 上下文窗口不是“免费仓库”
大模型每次响应，都要把当前对话的完整上下文重新读一遍。这意味着你前面聊的每一句话、工具返回的每一段日志、读进来的每一个文件，都会在后续每一次交互里被重复计费。这是最容易被忽略的一点：token消耗不是线性的，而是随着对话轮次累积放大的。
举个直观的例子。假设你第一轮让工具读了10个文件，共8000 token。第二轮你又问了个问题，这8000 token会再次进入上下文；第三轮还是如此。聊到第十轮，光是那批文件就已经被重复读了十次。所以省token的第一原则是：能不读的就不读，能晚读的就晚读，读完能丢的就丢。
2.2 四类主要消耗源
我把实际使用中的token消耗拆成四块，方便对症下药：
| 消耗类型 | 典型场景 | 占比感受 | 可控程度 |
|---|---|---|---|
| 系统提示与工具定义 | 每次请求固定携带 | 中 | 低 |
| 项目文件读取 | 让它理解代码库 | 高 | 高 |
| 对话历史累积 | 多轮来回讨论 | 高 | 高 |
| 工具调用返回 | 跑命令、看日志 | 中高 | 中 |
系统提示和工具定义是平台方定的，你基本动不了。真正能大幅压缩的是后三块，尤其是文件读取和对话历史。下面讲的所有技巧，几乎都围绕这两块展开。
2.3 一个反直觉的事实
很多人省token的第一反应是“少说话”，把问题写得越短越好。但我实测下来，提问太短反而更费token。因为你描述不清，工具就得自己猜，一猜就去读更多文件、跑更多命令来确认。一个模糊的“帮我修个bug”，可能触发它扫描整个项目；而一句“登录接口在token过期时返回500，期望返回401，相关逻辑在auth模块”，它能直奔目标。
所以省token的核心不是“少说”，而是“说准”。精准的指令 = 更少的探索 = 更少的token。这个观念转变，是我从“省字派”变成“省上下文派”的分水岭。
3. Codex的省token实战打法
3.1 用AGENTS.md把规矩一次说清
Codex支持在项目根目录放一个约定文件（不同版本叫法略有差异，常见的是AGENTS.md这类约定文件），用来告诉它这个项目的规矩。这个文件的价值在于：把重复的上下文固化成一次性的约定。
我一般会写这几类内容：项目用什么语言和框架、代码风格要求、测试怎么跑、哪些目录不用看、提交信息格式。写清楚之后，它就不会每次都去翻package.json、翻配置文件来推断这些信息。别小看这一条，一个中等项目光是把基础信息摸清楚，就得烧掉几千token。
注意：这个约定文件本身也会进上下文，所以要精简。我见过有人写了三千字的项目说明，结果每次请求都带着这三千字，反而更费。控制在几百字以内，只写“不看会出错”的信息。
3.2 精准指定文件，别让它自己找
Codex在探索型任务上很积极，你给它一个模糊目标，它会主动grep、主动读文件。这在你不熟项目时是优点，在你熟项目时就是烧钱。我的做法是：能点名就点名。
比如要改一个函数，我直接说“修改src/utils/date.ts里的formatDate函数”，而不是“帮我改一下日期格式化”。前者它直接读一个文件，后者它可能先搜一遍全项目。一次搜索加多文件读取，轻松上千token就没了。
如果确实需要它找，我会给范围：“在src/services目录下找处理支付的代码”。缩小搜索范围，等于直接砍掉一大块探索成本。
3.3 控制读取深度和文件数量
Codex读文件时，默认可能把整个文件读进来。对于大文件，这是灾难。我的经验是：
- 大文件只让它读相关片段，明确说“只看第50到120行”
- 让它先列目录结构，再决定读哪些，而不是一上来就递归
- 对于配置文件、锁文件、生成文件，直接在约定文件里声明“忽略”
有个特别容易踩的坑：node_modules、dist、build这类目录。如果没在忽略列表里，有些工具会尝试去读，那token消耗是断崖式的。一定要在项目配置里把它们排除掉。
3.4 善用“新会话”切断历史
Codex的对话历史是累积的。一个任务做完，如果继续在同一个会话里问下一个不相关的问题，前面的历史还在烧token。我的习惯是：一个任务一个会话，做完就开新的。
判断标准很简单：如果新问题和之前的上下文没关系，就开新会话。比如刚修完登录bug，接着要写单元测试，这俩虽然相关但可以分开；如果接着要改支付逻辑，那必须开新会话。开新会话的代价是重新建立一点上下文，但比起拖着几千token的历史，划算太多。
3.5 让工具输出“瘦身”
Codex跑命令的返回也会进上下文。跑个测试，输出几百行日志，全进上下文了。我的做法是：
- 跑测试时加过滤，只看失败项，比如用测试框架的“只显示失败”参数
- 看日志时先tail或grep，别把整个日志文件倒进去
- 让它跑命令时明确说“只返回错误摘要”
这一块省下来的token经常被低估。一次全量测试输出可能上万token，过滤后可能就几百。
4. Claude Code的省token门道
4.1 CLAUDE.md是省token的总开关
Claude Code对项目约定文件的依赖更重，通常用CLAUDE.md。这个文件的作用和Codex的约定文件类似，但Claude Code会更主动地去读它。所以写好这个文件，收益更明显。
我的CLAUDE.md一般包含：项目概述一句话、技术栈、常用命令、代码规范、禁止事项、目录说明。关键是禁止事项这一块——明确告诉它“不要读哪些目录”“不要改哪些文件”“不要跑哪些命令”。这能挡掉大量无谓的探索。
提示：CLAUDE.md里可以写“遇到不确定的情况先问我，不要自己猜”。这一条能显著减少它自作主张去读一堆文件的情况。
4.2 用/clear和/compact管理会话
Claude Code有两个特别实用的命令：/clear清空当前会话，/compact压缩历史。这两个是省token的利器。
/clear适合任务切换时用，直接归零。/compact适合一个长任务中途用，它会把之前的对话压缩成摘要，保留关键信息但丢掉冗余细节。我一般在长任务进行到一半、感觉上下文开始臃肿时用一次/compact，能明显感觉到后续响应变快、消耗变低。
什么时候用哪个？我的判断是：任务彻底换了用/clear；任务还在继续但历史太长用/compact。别舍不得清，拖着历史不放才是真浪费。
4.3 善用“计划模式”先对齐再动手
Claude Code有个很值钱的习惯：先出计划再执行。我会主动利用这一点，让它先给方案，我确认后再让它动手。这样做的好处是：避免它按错误理解跑一大圈。
如果它理解错了，在计划阶段就能发现，改一句话就行。要是等它读完一堆文件、改完一堆代码才发现方向错了，那token就白烧了。计划模式相当于一个低成本的“预演”，非常划算。
4.4 精确的上下文引用
Claude Code支持用@引用文件。这个功能用好了能省大量token，因为你可以精确指定它看哪个文件，而不是让它自己找。我经常这样写：“参考@src/api/client.ts的写法，在@src/api/user.ts里加一个类似的方法”。它直接读这两个文件，不会去翻别的。
反过来，如果你不给引用，它可能为了“理解风格”去读一堆相邻文件。精确引用 = 精确读取 = 省token。
4.5 控制子任务和工具调用
Claude Code在执行复杂任务时会拆子任务、调工具。子任务越多，上下文越碎，token越费。我的经验是：把大任务拆成明确的小步骤，一步步喂给它，而不是丢一个大目标让它自己拆。
比如“重构整个用户模块”这种任务，它自己拆可能拆出十几个子任务，每个都带上下文。我改成“先把user.ts里的校验逻辑抽成独立函数”，做完再做下一步。每步都清晰，它不用反复探索，token自然省。
5. 两个工具通用的省token心法
5.1 上下文要“按需加载”
这是最核心的一条。把上下文想象成工作台，你不需要把所有工具都摊在桌上，用到哪个拿哪个。具体做法：
- 先让它列结构，再决定读什么
- 读文件时只读相关部分
- 用完的信息及时通过新会话或压缩丢掉
我见过太多人一上来就让工具“了解整个项目”，这是最费token的做法。项目是了解不完的，按需加载才是正道。
5.2 提问要“带坐标”
模糊提问是token杀手。带坐标的提问能大幅减少探索。对比一下：
| 模糊提问 | 带坐标提问 | token差异 |
|---|---|---|
| 帮我修个bug | 登录接口token过期返回500，期望401，逻辑在auth模块 | 数倍 |
| 优化下性能 | 首页列表渲染慢，看下list组件有没有重复渲染 | 数倍 |
| 加个功能 | 在settings页加一个深色模式开关，参考theme配置 | 数倍 |
带坐标的提问，本质上是把你脑子里的定位信息免费送给工具，省掉它自己定位的成本。
5.3 定期“断舍离”
会话历史是会膨胀的。我的习惯是每完成一个阶段性任务，就评估一下：这段历史还有用吗？没用就清掉。别觉得可惜，历史留在那里只会持续烧token。
有个小技巧：在开新会话前，把上一个会话里得出的关键结论用一句话记下来，带到新会话里。这样既保留了必要信息，又丢掉了冗余历史。
5.4 别让工具“过度确认”
有些工具在动手前会反复确认、反复读文件来“确保正确”。这本身是好事，但过度了就费token。可以通过约定文件告诉它：“对于明确的修改指令，直接执行，不需要反复确认”。当然这个要看你自己的风险偏好，我一般对低风险操作（改注释、加日志）允许直接执行，对高风险操作（改核心逻辑、删文件）还是要求确认。
6. 常见问题与排查技巧实录
6.1 token掉得特别快，怎么排查
先看是不是这几个原因：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 刚开对话就消耗大 | 系统提示或约定文件太长 | 精简约定文件 |
| 每轮都消耗大 | 历史累积过多 | 用/clear或/compact |
| 某个操作后暴涨 | 读了大量文件或跑了全量命令 | 检查读取范围和命令输出 |
| 一直消耗但没进展 | 工具在反复探索 | 给更精确的指令 |
我一般会先看是不是读了不该读的目录，这是最常见的暴涨原因。
6.2 约定文件写了但没生效
这种情况通常是文件位置或命名不对。不同工具对约定文件的识别规则不一样，有的认根目录，有的认特定文件名。确认一下：文件是不是在项目根目录、文件名是不是工具认的那个、格式有没有问题。另外，有些工具需要重启会话才会重新读取约定文件，改完记得开新会话。
6.3 压缩历史后信息丢了怎么办
/compact压缩是有损的，可能丢掉一些细节。我的做法是：在压缩前，把关键结论、待办事项、重要文件路径手动记下来。压缩后如果发现丢了信息，补一句就行。别指望压缩能保留所有细节，它本来就是做减法的。
6.4 精确引用反而更费token
这种情况一般是因为引用的文件太大。@引用会把整个文件读进来，如果文件几千行，那确实费。解决办法是引用小文件，或者明确说“只看这个文件的某部分”。精确引用不等于无脑引用，还是要控制范围。
6.5 独家避坑技巧
几个我踩坑总结出来的：
- 别在会话里贴大段日志。要贴就贴关键几行，或者先存成文件再让它读指定行。
- 别让它“顺便”做别的事。它一旦开始“顺便”，就会读更多文件、跑更多命令。
- 定期检查忽略列表。新加的目录（比如新生成的构建产物）要及时加进忽略。
- 长任务中途主动压缩。别等上下文爆了才想起来，那时候已经烧了不少。
- 一个会话只干一件事。这是最朴素也最有效的原则。
7. 我个人的实操节奏
用到现在，我的日常节奏大概是这样：开新会话前先想清楚这次要干什么，把相关文件路径准备好；开场用一句话说清任务和坐标；让它先出计划，确认后执行；执行中如果发现它开始乱翻文件，立刻打断给更精确的指令；任务做完，把结论记下来，然后/clear开新的。
这套节奏下来，我的token消耗比早期盲目用的时候降了大概六七成。当然具体数字因人而异，但方向是明确的：省token的本质是省上下文，省上下文的本质是想清楚再动手。
工具再聪明，也替代不了你对项目的理解。你越清楚自己要什么、东西在哪，工具就越省。反过来，你要是自己都模糊，工具就只能靠烧token来帮你摸索。所以与其研究各种省token的奇技淫巧，不如先把“想清楚再问”这个习惯养起来。这是我从一开始的“额度焦虑”到现在“从容使用”最大的体会。
