1. 休假回来第一件事：先看账单，再看代码
休了十天假，回来打开 Codex 的用量面板，我愣了好几秒——Token 消耗比休假前整整翻了一倍。不是涨了百分之二三十，是直接乘以二。那几天我人不在工位上，项目也没怎么推进，按理说用量应该持平甚至下降才对。结果账单摆在那里，数字不会骗人。
如果你也在用 Codex 做日常开发，或者正在折腾config.toml、Skill、CodeGraph 这些东西，那这篇内容大概率能帮你省下一笔冤枉钱。我不打算讲什么高深原理，就是把休假回来之后做的四项调整，一项一项拆开说清楚：当时看到了什么现象、判断问题出在哪、具体改了什么、改完之后效果如何。适合已经上手 Codex、开始关心 Token 用量和配置优化的朋友，也适合刚接触config.toml还在被各种报错折磨的新手。
先说结论：Token 翻倍这件事，表面看是“用得多”，根子上其实是“用得糙”。四项调整分别对应四个层面的浪费——上下文冗余、Skill 调用失控、CodeGraph 索引策略粗糙、以及config.toml里一堆被忽略的配置项在偷偷烧钱。下面一项一项来。
2. 先搞清楚 Token 到底花在哪了
2.1 Token 消耗的三个主要出口
很多人以为 Token 就是“我打字打得多”，其实在 Codex 这类工具里，Token 消耗的大头往往不在你手动输入的那点文字上。我复盘了一下自己的使用记录，Token 主要从三个地方流出去：
- 上下文携带：每次对话，Codex 都会把之前的对话历史、打开的文件、项目结构等信息打包送进模型。你聊得越久、开的文件越多，这个包袱就越重。哪怕你只问一句“这个函数干嘛的”，背后可能拖着几万 Token 的上下文。
- Skill 调用：Skill 是 Codex 里很实用的功能，能让你把常用操作封装成可复用的指令。但每次调用 Skill，都会把 Skill 的定义、参数、示例一并送进上下文。如果 Skill 写得臃肿，或者调用频率高，这部分消耗非常可观。
- CodeGraph 索引：CodeGraph 负责把代码库的结构关系建索引，方便 Codex 理解项目。索引本身不直接消耗 Token，但索引结果会作为上下文的一部分被携带。索引粒度太细、范围太广，就会导致每次对话都拖着一大坨用不上的结构信息。
我休假前那段时间，正好在赶一个中型项目，开了很多文件，Skill 也加了好几个，CodeGraph 索引范围设得比较宽。这三样叠加起来，Token 不翻倍才怪。
2.2 为什么“人不在”用量反而涨了
这里有个容易被忽略的点：Codex 的某些后台任务和定时索引并不会因为你人不在就停下来。比如 CodeGraph 的增量索引，如果配置了自动更新，它会在文件变动时触发。休假期间虽然我没写代码，但项目仓库可能有其他协作者在提交，或者某些自动化脚本在跑，这些变动都会触发索引更新，进而产生 Token 消耗。
另外，有些 Skill 如果配置了定时触发或者事件触发，也可能在你不知情的情况下被调用。我查日志的时候就发现，有一个用于“代码风格检查”的 Skill，被一个 Git Hook 触发了好几次，每次都在后台跑了一遍完整检查。这些零散的消耗加起来，就是账单上那个刺眼的数字。
提示：如果你也发现用量异常，先去用量面板看时间分布，再查后台任务日志。不要一上来就怀疑自己手打太多字，那通常不是主因。
3. 四项调整的具体操作
3.1 调整一：给上下文“瘦身”，关掉不必要的自动携带
第一项调整针对的是上下文冗余。我之前的习惯是“开着再说”，项目里十几个文件常年开着，Codex 每次对话都会把这些文件的内容带上。实际上，很多文件跟当前对话根本没关系。
具体操作分三步：
- 清理常开文件：把跟当前任务无关的文件全部关掉。我现在只保留正在编辑的两到三个文件，其他一律关闭。需要的时候再打开，Codex 会按需读取。
- 调整上下文窗口策略：在
config.toml里找到跟上下文相关的配置项。我用的配置里有一个控制“自动携带文件数量”的参数，默认值偏大，我把它从默认的 10 调到了 3。这个值没有绝对标准，取决于你的项目大小和任务复杂度。我的经验是，日常开发 3 个足够，做大型重构时可以临时调到 5。 - 启用对话历史压缩：Codex 支持对较早的对话历史做摘要压缩。开启之后，超过一定轮数的对话会被压缩成简短摘要，而不是原样保留。这个功能在
config.toml里通常是一个布尔开关，打开即可。实测下来，长对话场景下能省 30% 到 40% 的上下文 Token。
这里有个细节要注意：压缩历史虽然省 Token，但可能会丢失一些早期对话的细节。我的做法是，重要决策和关键结论手动记到项目笔记里，不依赖对话历史来回忆。
3.2 调整二：Skill 精简与调用频率控制
第二项调整针对 Skill 调用失控。我数了一下，休假前我一共装了 7 个 Skill，常用的只有 3 个，剩下 4 个基本是“装了就没怎么用，但每次对话都可能被扫描到”。
操作上我做了这几件事：
- 卸载低频 Skill：把过去一个月调用次数少于 5 次的 Skill 全部卸载。卸载之后，Codex 在匹配 Skill 时就不需要扫描它们的定义，间接减少了上下文负担。
- 合并同类 Skill：我有两个 Skill 功能有重叠，一个是“生成单元测试”，一个是“检查测试覆盖率”。我把它们合并成一个 Skill，用参数区分模式。这样既减少了 Skill 数量，又让调用逻辑更清晰。
- 给 Skill 定义瘦身：检查每个保留 Skill 的定义文件，把冗余的描述、过长的示例、用不上的参数全部删掉。Skill 定义越短，每次调用时送进上下文的 Token 就越少。我有个 Skill 的定义从 800 字压到了 300 字，效果立竿见影。
- 关闭自动触发：之前有几个 Skill 配置了 Git Hook 自动触发，我全部改成手动触发。需要的时候再跑，不需要的时候绝不后台消耗。
注意：Skill 的自动触发是 Token 消耗的隐形杀手。尤其是那些绑定在保存、提交、切换分支等高频事件上的 Skill，一次触发就是一次完整的上下文打包。建议全部改成手动，或者至少加上触发条件限制。
3.3 调整三：CodeGraph 索引范围与粒度优化
第三项调整针对 CodeGraph。CodeGraph 的初衷是好的——让 Codex 理解代码结构，给出更准确的建议。但索引范围太广、粒度太细，就会导致每次对话都携带大量无关的结构信息。
我的优化策略是“分层索引”：
- 核心层：当前正在开发的主模块，索引粒度设为最细，包含函数签名、类结构、调用关系。这部分是必须的。
- 外围层：项目其他模块，只索引到文件级别，不展开内部结构。需要的时候再临时展开。
- 排除层：第三方依赖、生成代码、测试快照、文档目录，全部排除在索引之外。这些内容对 Codex 理解你的业务逻辑帮助有限，但占用的 Token 可不少。
具体在config.toml里，CodeGraph 相关的配置通常包含索引路径、排除规则、粒度级别等参数。我把排除规则从默认的几条扩展到了十几条，把node_modules、dist、build、coverage、*.min.js这些全部加了进去。粒度级别从“全量细粒度”改成了“核心细粒度+外围粗粒度”。
改完之后，CodeGraph 的索引体积缩小了大约 60%，每次对话携带的结构信息 Token 相应减少。而且因为核心模块的索引更精准了，Codex 给出的建议质量反而有提升。
3.4 调整四：config.toml 里那些被忽略的配置项
第四项调整是最琐碎但也最关键的——config.toml里的配置项。我之前对这个文件的态度是“能跑就行”，很多配置项看都没看。休假回来仔细读了一遍，发现好几个默认值都在悄悄增加 Token 消耗。
我重点调整了以下几类配置：
| 配置类别 | 调整前 | 调整后 | 调整理由 |
|---|---|---|---|
| 上下文携带文件数 | 10 | 3 | 减少无关文件内容进入上下文 |
| 对话历史保留轮数 | 50 | 20 | 配合历史压缩，降低长对话负担 |
| Skill 自动扫描 | 开启 | 关闭 | 避免每次对话扫描所有 Skill 定义 |
| CodeGraph 索引粒度 | 全量细粒度 | 分层粒度 | 核心精准、外围粗略，减少冗余 |
| 后台索引触发 | 文件变动即触发 | 手动触发+定时触发 | 避免频繁变动导致反复索引 |
| 响应详细程度 | 默认 | 精简模式 | 减少模型输出 Token |
这里特别说一下“响应详细程度”。Codex 默认会给出比较详细的解释和示例，但很多时候你只需要一个简短答案。把响应模式调成精简之后，输出 Token 能省不少。当然，做复杂任务时可以临时调回详细模式。
另外，config.toml里还有一些跟模型选择、温度参数相关的配置，这些对 Token 消耗也有间接影响。比如温度设得高，模型输出更发散，Token 可能更多。我一般把温度设在 0.2 到 0.4 之间，兼顾准确性和简洁性。
4. 调整后的效果与实测数据
4.1 用量变化对比
四项调整全部落地之后，我观察了一周的数据。为了排除项目复杂度变化的干扰，我特意选了一段跟休假前任务量相近的开发周期来对比。
| 指标 | 调整前（日均） | 调整后（日均） | 变化幅度 |
|---|---|---|---|
| 总 Token 消耗 | 约 120 万 | 约 55 万 | 下降约 54% |
| 上下文 Token 占比 | 约 65% | 约 40% | 下降 25 个百分点 |
| Skill 调用次数 | 约 30 次 | 约 12 次 | 下降 60% |
| CodeGraph 索引体积 | 约 800 MB | 约 320 MB | 下降 60% |
| 单次对话平均 Token | 约 1.8 万 | 约 0.9 万 | 下降 50% |
总消耗从 120 万降到 55 万，降幅超过一半。这个结果比我预期的要好。我原本以为能降 30% 就不错了，没想到上下文和 Skill 这两块的浪费这么严重。
4.2 开发体验有没有变差
省 Token 的前提是不能影响开发效率。我特意留意了调整后的体验变化：
- 响应速度：因为上下文变小了，Codex 的响应速度反而更快了。之前有时候要等好几秒，现在基本秒回。
- 建议质量：核心模块的索引更精准之后，Codex 对业务逻辑的理解反而更到位了。之前因为索引里混了太多第三方代码，它有时候会给出一些不相关的建议。
- Skill 使用：手动触发 Skill 确实多了一步操作，但习惯了之后还好。而且因为 Skill 定义精简了，调用时的等待时间也短了。
唯一有点不适应的是，对话历史压缩之后，偶尔需要往回翻找早期讨论的细节。我的解决办法是重要内容随手记到项目笔记里，不依赖对话历史。
5. 常见问题与排查技巧
5.1 Token 用量突然暴涨怎么查
如果你也遇到用量异常，可以按这个顺序排查：
- 看时间分布：先确定暴涨是集中在某几天还是均匀分布。集中在某几天，说明有特定事件触发；均匀分布，说明是日常配置问题。
- 查后台任务日志：重点看 CodeGraph 索引、Skill 自动触发、定时任务这几类。很多时候问题出在后台，不在你手动操作。
- 检查 config.toml 变更：回忆一下最近有没有改过配置，或者有没有自动更新覆盖了你的配置。
- 对比上下文携带量：看看最近是不是开了很多文件，或者项目结构发生了大变化。
- 检查 Skill 调用记录：有没有哪个 Skill 被频繁触发，尤其是那些绑定在 Git Hook 上的。
5.2 config.toml 常见报错与修复
折腾config.toml的过程中，我踩过不少坑，这里整理几个常见的：
| 报错信息 | 原因 | 修复方法 |
|---|---|---|
model provider 'openai' not found | provider 配置缺失或拼写错误 | 检查 provider 名称拼写，确认对应配置段存在 |
mcp_servers.node_repl.type is ignored | 配置项已废弃或类型不匹配 | 删除该配置项，或查阅最新文档确认替代项 |
unrecognized configuration setting | 配置项名称拼写错误或版本不兼容 | 逐项核对配置项名称，确认与当前版本匹配 |
无法加载 config.toml | 文件格式错误，如引号不匹配、缩进错误 | 用 TOML 校验工具检查语法，修复格式问题 |
token exchange failed | 认证信息过期或配置错误 | 重新登录，检查认证相关配置 |
提示：改
config.toml之前一定要备份。我有一次改错了一个引号，导致整个配置加载失败，排查了半小时才发现。现在我的习惯是改之前先复制一份，改完确认没问题再删备份。
5.3 Skill 和 Agent 的区别与选用
很多人分不清 Skill 和 Agent，这里简单说一下我的理解：
- Skill：更像是一个“快捷指令”或“宏”，你把一组操作封装起来，需要的时候调用。它不主动做事，等你触发。
- Agent：更像是一个“自主执行者”，你给它一个目标，它会自己规划步骤、调用工具、完成任务。它会主动消耗 Token。
从省 Token 的角度，Skill 比 Agent 可控得多。Agent 一旦跑起来，Token 消耗可能超出预期。我的建议是，能用 Skill 解决的就不用 Agent，必须用 Agent 的时候一定要设好预算上限和终止条件。
5.4 CodeGraph 集成到其他编辑器的注意事项
有朋友问 CodeGraph 怎么集成到 Cursor 里。我试过，基本思路是让 CodeGraph 的输出格式兼容 Cursor 的索引格式。具体操作上，需要在 CodeGraph 配置里指定输出路径和格式，然后在 Cursor 的设置里指向那个路径。不过要注意，不同版本的 Cursor 对索引格式的要求可能不一样，集成之前先确认版本兼容性。另外，集成之后索引更新可能会更频繁，记得把触发策略调保守一点，不然 Token 消耗又会上去。
6. 我个人的几条实操心得
折腾完这一轮，有几个体会比较深，分享出来供参考。
第一，Token 优化不是一劳永逸的事。项目在变、用法在变、Codex 本身也在更新，今天有效的配置明天可能就不适用了。我现在养成了每月复盘一次用量和配置的习惯，花不了多少时间，但能避免不知不觉又烧起来。
第二，不要为了省 Token 牺牲核心体验。有些配置调得太激进，比如把上下文携带文件数降到 1，结果 Codex 经常因为看不到相关文件而给出错误建议，反而要反复对话，总消耗可能更高。省 Token 的前提是保证开发效率，这个平衡点需要自己试出来。
第三，日志和用量面板是最好的老师。很多人不看日志，出了问题就凭感觉猜。其实用量面板和后台日志里信息很全，花十分钟看一下，比瞎猜一小时管用。
第四，配置改动要小步走。我一开始想一次性把所有配置都调到最优，结果改完发现好几个地方互相影响，排查起来很麻烦。后来改成一次只改一类配置，观察两三天再改下一类，稳当得多。
最后再分享一个小技巧：如果你不确定某个配置项的作用，可以先把它注释掉，跑一天看看用量变化。对比数据比任何文档都直观。我现在的config.toml里还留着好几条注释掉的配置项，都是当初做对比实验时留下的，偶尔还会翻出来参考。
