最近我发现一个挺实用的小技巧：让 Codex 自己回顾最近的运行记录，分析哪些地方在浪费 token。
本文同步发布于 AI Coding 指北。
关于 Codex 会员，我经常去chong-zhen.com这家购买
这件事看起来有点绕，但实际很简单。你不用先去翻一堆日志，也不用自己算每次工具调用占了多少上下文，直接把下面这段话甩给它就行：
text
回顾你过去的运行记录，分析怎样才能更省 token，可以考虑用某些 skill、脚本，或者切换模型，根据分析结果去调整设置，但不能牺牲原本的性能和能力。我自己跑了一遍，发现它真能把一些平时看不见的浪费点翻出来。
很多时候我们以为 token 是花在"写代码"上，其实不是。真正贵的地方，往往是它为了找到信息、理解上下文、处理工具返回结果、带着一堆历史继续跑子任务时，一点点烧掉的。
它会看什么
这个提示词的核心，不是让 Codex 给一堆泛泛而谈的省钱建议，而是让它基于自己的历史记录做诊断。
它通常会去看几类东西：
| 观察对象 | 重点看什么 |
|---|---|
| 最近的会话 | 哪些任务消耗最高，消耗是否和任务难度匹配 |
| 输入和输出比例 | 是不是喂进去很多，真正产出的很少 |
| 工具调用结果 | 搜索、读取文件、日志输出是不是太长 |
| 截图和图片 | 有没有没必要地使用高精度素材 |
| 子 agent | 有没有把主会话一大包历史全带过去 |
| skill 和规则 | 是不是加载了当前任务用不上的东西 |
这些问题人当然也能查，但麻烦。让 Codex 自己查，优势是它离运行现场更近，能把"我刚才到底浪费在哪"说得比较具体。
我这次查出来的主要问题
我这边最明显的问题是：喂给它看的东西太杂、太多。
比如一个任务本来只需要看某个函数附近几十行代码，结果它可能整篇文件都读进来了。一个工具返回了几千行日志，真正有用的只有中间两段，但上下文里已经被原始日志塞满。再比如一个子 agent 只负责查一个小问题，却带着主 agent 前面所有讨论一起出门。
这些都不是"模型不聪明"，而是工作方式太粗。
对于 Agent 来说，上下文不是免费的草稿纸。每多读一点，每多塞一点，每多保留一点，都会变成后续推理的负担。
它给我的几条规则
这次诊断后，Codex 给我列了几条比较实在的优化方向。
第一，读文件不要一上来整篇塞进去。先搜索定位，再分批读，只读和当前问题有关的部分。如果工具返回结果太长，先截断、筛选或者摘要，再把关键信息交给模型。
第二，截图这类素材不用默认上最高精度。能用低分辨率判断布局、颜色、结构的，就没必要动不动传原图。尤其是只做初步判断时，高精度往往只是增加成本。
第三，同一个操作失败了，不要原地重试好几遍。先看错误信息、确认失败原因，再动手。很多 token 就浪费在"没搞清楚问题但又跑了一遍"上。
第四，子 agent 接任务时，只给它完成这个任务必需的信息。不要把主 agent 一路积累的历史全部打包甩过去。子任务越小，上下文越应该干净。
第五，skill 也不是越多越好。需要哪个加载哪个，不要每次都把一堆用不上的规则放进上下文。skill 的价值是让模型更懂当前任务，不是让它背着一个工具箱跑全程。
但别把诊断当圣旨
这里有个很重要的前提：Codex 输出的分析不一定全都准确。
它能看到一部分运行痕迹，也能根据日志做推断，但这不代表每条建议都适合你的项目。比如有些任务确实需要读完整文件，有些截图确实需要高清，有些复杂重构也确实应该用更强模型。
所以更稳的做法不是"它说什么就改什么"，而是拿几个自己平时常跑的任务做对比：
| 对比项 | 看什么 |
|---|---|
| token 消耗 | 优化前后是否明显下降 |
| 结果质量 | 有没有漏改、误判、理解变浅 |
| 工具调用次数 | 是不是少了无效搜索和重复读取 |
| 任务完成时间 | 有没有因为过度节省反而变慢 |
| 人工介入 | 是否需要你补更多上下文 |
省 token 的目标不是让 Codex 少干活，而是让它少做没必要的活。
这个命令还能继续扩展
我觉得这个玩法还有一个更有意思的方向：把它扩展成项目知识库蒸馏。
因为它真正依据的不是某个抽象理论，而是你过去的对话历史、任务记录、失败案例和项目上下文。这些东西本来就有价值，只是平时都散落在会话里。
如果进一步整理，就可以沉淀出几类数字资产：
| 可沉淀内容 | 用处 |
|---|---|
| 常见任务流程 | 下次同类任务不用重新摸索 |
| 项目结构说明 | 减少重复读代码和解释背景 |
| 失败案例 | 避免反复踩同一个坑 |
| 高质量提示词 | 变成可复用命令或 skill |
| token 优化规则 | 固化到配置、记忆或项目规范里 |
换句话说，省 token 只是第一层收益。更长期的收益，是把一次次对话变成可以复用的项目经验。
最后
如果你最近用 Codex 比较频繁，可以试试这句提示词：
text
回顾你过去的运行记录，分析怎样才能更省 token，可以考虑用某些 skill、脚本，或者切换模型，根据分析结果去调整设置，但不能牺牲原本的性能和能力。跑完之后不要急着全盘照抄，先挑两三个高频任务做 A/B 对比。只要能在不牺牲结果质量的情况下减少无效读取、重复调用和过载上下文，这条规则就值得留下来。
真正省 token 的方法，从来不是让 Agent 少知道一点，而是让它更快知道该知道什么。
我这边也有一些AI Coding（SDD Agent AI工具等） 和 Node技术交流交流群，感兴趣的可以加微信 ikoala520 进群，一起学习，共同进步。
本文同步发布于 AI Coding 指北。