一周 1.5 亿 Token：RTK 优化后我的 Codex 使用记录
在上周 3.5 亿 token 的基础上，引入 RTK 后一周 token 消耗降至 1.5 亿，降幅 57%。记录实际使用数据和体验。
一周 1.5 亿 Token：RTK 优化后我的 Codex 使用记录
背景
上周 我记录了 11 天消耗 3.5 亿 token 的数据，并提到要引入 RTK 试试优化效果。一周过去了，结果出来了：1.5 亿 token。
还是那套工作流——Codex 5.4 和 5.3-codex 混用，写-审-改循环，同样的项目复杂度。唯一的变化就是加了 RTK。
数据对比
| 指标 | 上周（无 RTK） | 这周（有 RTK） | 变化 |
|---|---|---|---|
| Token 消耗 | 3.5 亿 | 1.5 亿 | -57% |
| 使用模型 | 5.4 + 5.3-codex | 5.4 + 5.3-codex | 不变 |
| 工作流 | 写-审-改循环 | 写-审-改循环 | 不变 |
| 日常开发任务 | 功能实现、文档迭代、代码审查 | 同上 | 不变 |
从 3.5 亿降到 1.5 亿，直接省了 2 亿 token。RTK 的压缩效果比我预期的要好。
RTK 实际体验
最大的感受：感知不强，效果明显
说实话，用了 RTK 一周，日常开发过程中我几乎感觉不到它的存在。它就是个透明代理——AI 工具该干啥干啥，输出的代码质量也没觉得有什么退化。
但回头看用量统计，差距就摆在那了。
哪些场景压缩效果最好
git diff/git status：大项目的 diff 输出非常长，RTK 压缩后 AI 拿到的是精简版本，不影响理解- 测试输出：大量重复的 pass/fail 日志被折叠，只保留关键信息
- 错误日志：堆栈追踪被截断到关键行，不再把整个调用链塞进上下文
- 文件列表：
find、ls之类的输出按目录分组，去重折叠
没什么变化的场景
- 直接的代码编写对话，本身 token 消耗就不大，RTK 能压缩的空间有限
- 简短命令的输出，压缩前后差异不大
省下的 token 意味着什么
- 成本直接砍半。如果按上周的消耗速度，一个月就是十几亿 token，成本不可忽视。现在省下来的是真金白银
- 上下文窗口更耐用。同样大小的上下文窗口，能塞进更多轮对话，长任务不容易被截断
- 开发节奏更从容。不用时刻想着"这个 diff 太长了会不会爆 context"，该看的照看
结论
上周我说"下周的文章里更新测试结果，看看 RTK 到底是省钱利器还是噱头"。现在结论很明确：是省钱利器。
57% 的 token 降幅，零学习成本（rtk init 一条命令），对开发体验几乎零影响。对于重度使用 Codex 或类似 AI 工具的开发者来说，RTK 基本上是必装的。