Codex用户发现，简单排错任务会经历“修改—测试—再修改”的循环，Token消耗远超预期，甚至出现23万多项测试通过后程序仍无法启动的情况。真正值得关心的不是贵，而是AI编程工具开始暴露“不会收尾”的工程短板。

这是什么

Codex是OpenAI面向软件开发的AI编程工具，可以读取代码、修改文件并运行测试。掘金文章中的核心教训是：当程序没有修好时，智能体（Agent，能自主拆解任务并调用工具执行操作的AI系统）容易重复猜测，而不是停下来汇报已知信息、定位失败步骤并提出单一修复方案。

更现实的风险是范围膨胀。修一个导出问题，AI可能顺手重构页面、增加预留功能；对每个小改动都运行全套测试，又会让等待时间和Token成本一起上升。作者因此建议设置“两次未修好即暂停”的叫停点，并在修改前明确范围、依据和验收方式。

行业怎么看

这不只是Codex一家的使用技巧，而是AI编程从“能写代码”走向“可交付代码”必须补上的流程能力。Anthropic内部代码审查采用三轮后退一步复查等措施后，需要五轮以上审查才能通过的比例从8.9%降至1.5%；OpenCode和Gemini CLI也把范围确认、分层测试及复用有效检查写进项目规则。

但另一种意见同样成立：暂停和人工确认不能削弱必要的质量检查。Google的测试资料显示，有些检查虽然严格，却可能只验证代码写法，没有验证真实结果；如果为了节省Token而删除失败测试、跳过验收，问题只是被藏起来。Anthropic的改善数字来自内部流程，也不能直接外推到所有代码库。更稳妥的做法是按改动范围选择检查，并在真实环境复验结果。

对普通人的影响

对企业IT：企业部署AI编程工具时，应把Token预算、任务范围、停止条件和人工验收写进流程；不能只按生成代码量衡量效率，还要看返工轮次和最终可用率。

对个人职场：产品、运营和管理者使用这类工具排错时，应要求它先复现问题、列出已试办法，再提出下一步；否则“看起来很忙”可能只是重复消耗预算与时间。

对消费市场：AI应用会更强调结果验收。搜索失败却返回“没有结果”、测试全绿却无法启动，都可能直接影响用户信任，厂商需要用真实场景测试替代只看测试数量。