用 Codex 时最容易误判的一点是：你以为 Token 都花在写代码上，其实很多时候花在反复验证、跑偏调试和无边界探索上。
下面这些是项目里烧过额度后总结出来的，按消耗从高到低排。
先看结论
- UI 大改时，限制视觉验证次数。 页面没成型前，反复截图和浏览器检查很容易烧掉最多 Token。
- 复杂技术路线先做最小验证。 例如我项目中不确定 WASM、WebGPU、WebGL 哪条路能走通时，先写探针，不要直接改正式项目。
- E2E 不要一开始全量跑。 先跑相关页面和相关用例，收尾时再考虑全量。
- 小任务不要开 subagent。 大范围阅读和并行审查适合拆，小 bug 和小组件直接在当前线程做。
- 多语言 i18n 先冻结非目标语言。 重构和验证阶段先维护简体中文，其他语言后补。
- 长日志只看关键部分。 先看错误摘要、关键行和最后几十行，不要把整段输出吞进上下文。
- 任务边界写清楚。 不升级依赖，不改无关页面，不顺手重构样式系统。
1. UI 大改时，别让 Codex 反复做视觉验证
这是我见过最容易烧 Token 的场景。
我把一个 Vue3 网页项目的 UI 从 Vuetify 换成 Tailwind + shadcn-vue + Lucide。这不是换几个按钮，而是把底层组件体系一起换掉。表单、弹窗、菜单、图标、布局间距，全都要重新对齐。
问题出在我没有限制验证方式。Codex 改一点就打开页面看一下，再修一点，再截图，再调样式。首页还没完全迁完，5 小时额度已经烧掉了 90%。
后来我给这类任务加了一句：
先完成代码迁移，不要边改边做视觉验证。视觉验证只在页面完成后，且你认为有必要时，申请执行一次。
这句话很有用，后面再改其他页面，烧的 Token 明显减少一半以上。UI 大改时，真正贵的往往不是写代码，而是反复打开页面、截图、比较、解释截图。
页面还没成型时，看一次页面的价值不高。等结构迁完，再做一次视觉验证，通常更划算。
2. 技术路线不确定时，先做最小验证
复杂重构不要一上来就进正式项目。
我之前想用 onnxruntime-web 替代 OpenCV-DNN，在浏览器里加载一个 AI 微模型识别形状。看起来只是换个推理方案，实际问题很多，AI 能把 WASM、WebGPU、WebGL 都能讲出理由，且坑不一样。
WASM 比较稳，也比较容易拿下载进度，但速度不够理想。WebGPU 推理更快，但模型下载进度不好处理。WebGL 又涉及兼容性和包体问题。
我一开始直接让 Codex 在项目里改。结果它在几条路线之间来回试：改加载逻辑、改进度条、改 fallback、再修类型错误。5 小时剩余额度用光了，测试结果却是不能用！。
更好的做法应该是先写探针：
先不要修改正式项目。请创建一个最小验证脚本，只验证三件事：
1. onnxruntime-web WebGPU 能否成功加载模型
2. 是否能拿到模型下载进度
3. WASM 与 WebGPU 的加载时间差异大概是多少
验证完后只给结论和推荐路线。
路线没定前，业务代码越改越乱。先用最小验证把路探清楚，再回到项目里改，反而更快。
这类任务还可以加一个停止条件：
如果连续两次尝试仍失败，停止并总结原因，不要继续猜。
3. 不要一开始就跑全量 E2E
E2E 测试 UI 很有用，但不要太早全量跑。
比如你只是改登录页按钮文案，或者修一个表单校验逻辑。Codex 如果顺手跑完整 Playwright，失败的可能不只是登录页。订单页、设置页、权限页都可能因为环境、数据或旧问题失败。
这时任务会被拖偏。你本来只是想改一个页面，最后却变成分析整套系统的测试日志。
可以这样说：
只运行与当前页面相关的测试。不要运行全量 E2E；除非相关测试通过后你认为全量测试是必要的，再说明理由并等待确认。
相关测试通过之后，再决定要不要全量跑。这个顺序更省，也更容易判断失败是不是你这次改出来的。
4. 小任务不要开 subagent
subagent 不是省 Token 的默认选项。
它适合大范围阅读和并行审查。比如一个大 PR，你可以让几个 subagent 分别看安全、测试、性能和可维护性。它们各看各的，最后汇总，值得。
但如果只是修一个表单校验 bug、改一个 Vue3 组件、调一个页面样式，就没必要拆。每个 subagent 都要读上下文、跑命令、总结结果，主线程还要再合并一次。
我一般用这个判断：
这个任务范围很小，请直接在当前线程完成，不要使用 subagent。
或者写得更明确一点：
只有当任务需要并行阅读多个互不依赖的模块时，才使用 subagent。否则保持 inline execution。
能由一个人连续做完的任务，不要开 subagent。需要几个人分头看、最后汇总判断的任务，再开。
5. 多语言项目先冻结非目标语言
多语言项目也很容易扩散。
Vue3 项目里经常有 locales/zh-CN.ts、en-US.ts、ja-JP.ts、ko-KR.ts。你本来只是想改一个中文文案，或者验证一个交互，Codex 可能会顺手同步所有 locale。
然后测试又因为某个语言缺 key 失败。它继续修，继续补，任务越来越大。
如果这次只是重构结构、验证交互或先跑通中文，可以直接说：
本次 i18n 只维护简体中文，其他语言保持不变。非中文 locale 引起的测试失败可以记录，但不要修。
这不是永久忽略其他语言，只是控制变量。功能稳定后，再统一补齐翻译。
6. 控制日志、截图和测试输出长度
长输出会占上下文，也会带偏判断。
终端日志、测试失败、页面 DOM、截图说明，都不要一上来给全量。先让 Codex 看关键部分，判断是否需要继续展开。
可以这样说：
如果命令输出很长，请先只读取关键错误行和最后 80 行。不要把完整日志放进上下文，除非需要继续定位。
或者：
先根据错误摘要判断问题范围；如果需要完整日志，再说明原因。
截图反馈也一样。不要只说“页面不对”。最好说清楚哪个元素、哪个状态、你希望它怎么变。
7. 把任务边界写死
很多 Token 是被“顺手”花掉的。
顺手升级依赖，顺手重构工具函数，顺手调整全局样式，顺手把无关页面也改了。每一件事看起来都合理，加起来就会让任务变大。
新手用 Codex，最重要的是先把范围压住：
只修改完成这个任务所必需的文件。不要升级依赖，不要重构无关代码，不要调整全局样式系统。
大任务也要切小。不要说“重做后台管理系统”，可以先说“只迁移用户列表页，保持功能不变”。能验收的小任务，才容易控制额度。
可用的提示词
下面这段可以放在任务开头。经常用的话，也可以整理进项目的 AGENTS.md。
请优先控制 Token 消耗：
1. 先阅读相关文件并给出简短计划，不要直接大范围修改。
2. 只修改完成任务必需的文件，不要升级依赖，不要重构无关代码。
3. UI 任务先完成代码修改，视觉验证只在页面完成后且有必要时申请执行一次。
4. 测试先运行相关用例，不要默认运行全量 E2E。
5. i18n 默认只维护简体中文，其他语言冻结；相关测试错误可先记录。
6. 如果日志很长，先读取关键错误行和最后 80 行。
7. 如果连续两次尝试仍失败，停止并总结原因，不要继续猜。
最后
省 Token 不是少用 Codex，而是别让它在不确定、无边界、低价值的循环里空转。
先把范围说清楚，把验证放到合适的位置，把大问题拆成小验证。Codex 还是照样干活，只是少走很多弯路。
