最近用 Codex 改项目时我遇到过一个比“不会写代码”更麻烦的问题它有时会改得太积极。明明只是修一个按钮最后连接口命名和无关样式也一起动了。后来我把流程固定成下面 4 步返工少了很多。1. 先让 Codex 读不要马上改第一次接触一个项目我会先让它看目录结构、启动方式和相关文件只要求它说明当前实现不执行修改。我一般会这样写先阅读项目结构和与这个问题相关的文件说明入口、数据流和测试位置。暂时不要修改任何文件。这一步看起来慢其实是在确认它有没有找对地方。尤其是老项目文件名相似、历史代码多直接开改很容易走偏。2. 把修改范围说清楚“帮我优化一下”对人和对 AI 都太宽了。我会提前写明允许改哪些文件、不能碰哪些部分以及完成后应该看到什么结果。比如只修改列表页和它对应的样式文件不改接口协议不调整数据库结构搜索只过滤当前已经加载的数据清空输入后恢复原列表修改完成后补一条相关测试。范围越清楚后面看 diff 越省时间。3. 先要方案再让它动手如果任务涉及多个文件我通常会多加一步先列出准备修改的文件和做法等我确认后再执行。这不是为了限制它而是给自己留一个发现误解的机会。很多“改偏”不是代码写错而是它理解的目标和我想要的结果不一样。4. 改完一定要验证代码改完不等于任务完成。我会让 Codex 继续运行项目已有的测试、类型检查或构建命令并把执行结果写出来。如果项目没有自动化测试至少手动确认几个关键路径页面能不能启动、按钮状态是否正常、空数据和异常输入会不会报错。我现在常用的完整顺序是读项目并复述理解明确修改边界先给方案小范围修改看 diff跑测试或做手动验证。还有哪些地方要自己把关涉及账号、权限、删除数据、支付和正式发布时我会把最后一步留给自己。业务逻辑复杂的项目也不能只看“测试通过”还要检查它有没有改变原来的业务规则。Codex 适合参与真实项目但它更像一个执行力很强、刚接手项目的同事。你需要先把背景和边界交代清楚再检查它实际做了什么。如果你刚开始用 Codex可以先拿一个小 bug 试试这套流程先读再改再验证。用过几次之后通常就能找到适合自己的节奏。