Codex Token 消耗太快？我怎样验证“完成后统一测试”

编码 Agent 每跑一次完整测试，都会读取命令输出、解释失败，再把这些信息带进后续上下文。如果一个改动需要连续修改三个相邻文件，而每改一个文件就跑一次全量测试，同一批成功日志和无关警告可能被重复处理。

我注意到，当任务边界已经清楚时，先完成同一批相关修改，再集中跑测试，生成过程通常更连贯。这里可能同时包含三个原因：更少的工具往返、更少的重复日志，以及更少因为中间态必然失败而产生的无效诊断。

不要拿两个不同项目的主观体感作结论。选择两个结构相近的小任务，或者把同一任务放在两个相同起点的工作树中。保持模型版本、推理强度、AGENTS.md、依赖状态和验收标准一致。

A 组在每个局部修改后执行完整测试；B 组允许必要的静态检查和高风险针对性测试，但等相关实现完成后再执行一次完整测试。最终两组都必须通过完全相同的验收命令。

我不会要求 Codex 在所有场景都等到最后才测试。涉及数据迁移、鉴权、支付、并发、共享 API 或难以回滚的逻辑时，越早获得针对性反馈越便宜。对于页面文案、相关组件、类型补齐和同一功能内的连续修改，则可以先完成一个可评审单元，再统一运行完整套件。

更准确的提示不是“最后再测试”，而是：“先完成这个范围内的全部相关修改；实现过程中只运行能快速暴露高风险错误的针对性检查；完成后再运行指定的完整测试和构建，并修复到通过。”

速度变快不等于 Token 一定更少。缓存命中、模型调度和命令输出截断都会影响体感。结果至少要同时展示用量、耗时、测试次数和返工次数，不能只挑一个好看的数字。

如果 B 组减少了重复测试输出，却因为错误发现太晚而产生大段调试对话，那么节省可能消失。我的阶段性结论只是：把测试频率作为可设计变量，而不是机械地每改一行就跑全量，值得在自己的仓库中测一次。