别再把 Codex 当 ChatGPT 用

一个不看项目就直接改代码的 Codex，才真的危险。

很多人第一次用 Codex，以为它和普通聊天一样——你说一句，它直接给你一个答案。其实不是。

Codex 更像一个会在项目里边看边做的 Agent。它不是只靠嘴回答，它会读文件、搜代码、改文件、跑命令、看结果，然后继续调整。

所以你看到它先搜索、先打开文件、先看配置，不要觉得它在绕路。

理解 Codex 的工作方式，先记住五个词：thread、workspace、tools、patch、verification。

第一个是 thread，也就是当前这次任务会话。

同一个任务，尽量放在同一个 thread 里做。你前面让它读过什么、它已经判断过什么，都会影响后面的动作。比如前面已经分析过登录模块，后面再让它改登录按钮，它就能接着前面的上下文继续走。

但如果你新开一个会话，它很可能要重新读项目。不是它变笨了，是上下文断了。

第二个是 workspace，也就是 Codex 当前看到的工作区。

它能看到哪些文件，首先看你打开的是哪个目录；它能不能改文件、能不能跑命令，还要看当前权限和模式。新手每次开始任务前，都应该先确认这两件事。

可以直接问：

请确认当前工作区是什么，你能看到哪些文件和文件夹。先不要修改任何文件。

这句话能防住很多问题。目录开错了，后面做得越多，错得越远。

第三个是 tools。

Codex 会调用工具。读文件是工具，搜索是工具，编辑文件是工具，运行测试也是工具。你不用害怕它用工具，真正要看的是它有没有先说明理由，用完以后有没有根据结果调整判断。

如果它没看文件就开始下结论，你可以打断它：

请先搜索和这个功能相关的文件，不要根据项目惯例猜路径。

第四个是 patch，也就是它真正改了什么。

Codex 改文件时，重点不是它说了什么，而是它改了哪些文件。一个小需求，如果突然动了十几个文件，就要停下来问清楚。

可以这样问：

请按文件说明这次为什么必须修改。如果有非必要改动，请收敛到最小范围。

第五个是 verification，也就是验证。

改完不验证，就不算结束。验证不一定每次都跑全量测试，小任务可以跑 lint、typecheck，或者给出手动验证步骤。但它必须说清楚：用什么证明这次改动真的成立。

你可以在任务一开始就写完成标准：

完成标准：
1. 行为符合需求
2. 只修改必要文件
3. 运行相关检查，或者说明为什么无法运行
4. 最后总结改动、验证结果和剩余风险

一个健康的 Codex 工作流，大概是这样：

你说：帮我修复登录按钮点击后无响应的问题。

它应该先找登录页面和按钮实现，再查点击事件、表单提交、接口调用和错误处理。确认原因后，只做最小必要修改。改完以后跑相关检查，或者说明项目里没有可用检查命令。最后再告诉你改了什么、怎么验证、还有什么风险。

这就是 Agent loop。

真正要学的，不是把每一步背下来，而是看它有没有跑完整个闭环。

如果它只给结论，没有读文件，风险高。

如果它只改代码，没有验证，风险高。

如果验证失败了，还说已经完成，风险更高。

每次任务都可以用三个问题卡一下：

你是根据哪些文件判断的？

这次修改的最小范围是什么？

你怎么验证它真的好了？

这三个问题很朴素，但很管用。

看 Codex 的工作日志时，不要只看最后一句“完成了”。你要看中间有没有证据链。

一个靠谱的证据链通常是：先说要查什么，然后真的去搜文件，再引用具体文件和函数，接着提出原因，做最小修改，跑相关检查，最后把改动、验证、风险分开说。

少了哪一环，就要追问。

比如它没搜索就说“大概率是某个原因”，这是猜。

它没看测试命令就说“测试通过”，这是不可信。

它改完只说“已完成”，不说动了哪些文件，这是交付不透明。

所以这一期只记住一个判断：Codex 不是一次性给答案的机器，它是一个会在项目里循环观察和行动的 Agent。

你要做的，不是催它快点答。

你要做的是让它每一轮都更接近一个能验证、能交付的结果。