一周消耗 3.5 亿 Token：我的 Codex 使用记录
记录使用 Codex 5.4 和 5.3 模型进行日常开发的 token 消耗情况，以及引入 RTK 优化 token 使用的计划。
一周消耗 3.5 亿 Token：我的 Codex 使用记录
起因
3 月 30 号开始，我像往常一样用 Codex 写代码。到今天打开用量统计一看——3.5 亿 token。
说实话，看到这个数字的时候我愣了一下。11 天，3.5 亿。平均每天 3000 万+，这消耗速度比我想象中快太多了。
我怎么用 Codex 的
我的用法不是简单地让 AI 写代码跑一遍就完事，而是两个模型配合着来：
- Codex 5.4 负责写文档初稿，表达准确，结构清晰
- Codex 5.3 在 5.4 的基础上做二次改写和迭代
实际流程是这样的：
- Codex 5.4 产出初稿
- Codex 5.3 改写优化
- 再让 AI 审阅自己的输出，提出修改建议
- 根据建议再改
- 重复 3-4 直到满意
这个「写-审-改」的循环效果确实好，文档质量明显更高。但代价也很直观——token 消耗在这种场景下会快速累积，因为每一轮审阅都要把完整文档塞进上下文。
这 3.5 亿花在哪了
粗略回忆一下，主要消耗来自这几块：
- 文档迭代：上面说的写-审-改循环，占了大头
- 功能实现：复杂逻辑的实现和多轮调试
- 代码审查：让 AI 审查代码并给出重构建议
- 长上下文对话：带着整个文件让 AI 理解上下文再操作
其中文档迭代是最烧 token 的，因为每次审阅都是全文过一遍，几轮下来就是好几倍的文档长度。
优化方案：引入 RTK
token 该省还是得省。从今天开始，我打算试试 RTK ——一个 CLI 代理工具，在命令输出送到 LLM 之前做过滤和压缩，官方说能减少 60-90% 的 token 消耗。
它的工作方式挺巧妙的：通过 hook 透明地重写 Bash 命令，比如把 git status 重写为 rtk git status，AI 工具完全感知不到，只是拿到了压缩后的输出。
每类命令会应用四种策略：
| 策略 | 作用 |
|---|---|
| Smart Filtering | 移除注释、空白、样板代码 |
| Grouping | 按目录归类文件、按类型归类错误 |
| Truncation | 保留相关上下文，截断冗余 |
| Deduplication | 折叠重复日志行并计数 |
支持 Claude Code、Codex、Copilot、Gemini CLI、Cursor、Windsurf、Cline 等主流工具，rtk init -g --codex 一条命令就能搞定。
下一步
接下来一周，我会用同样的工作流做真实开发，对比有无 RTK 的 token 消耗差异。具体会关注：
- 日均 token 消耗变化
git diff、测试输出等高频命令的压缩效果- 是否影响 AI 的理解和输出质量
测试结果会在下周的文章里更新，到时候看看 RTK 到底是省钱利器还是噱头。