3 Codex 第一次进仓库：读结构、改小点、跑检查

Codex 第一次进仓库手绘图

第一次让 Codex 进项目，最重要的是别急。

你不是在测试它会不会“凭空生成代码”，而是在训练一套协作节奏：先读、再问、再改、再验、最后看 diff。这个节奏一旦养成，后面用 Codex 修 bug、写测试、重构、写文档都会稳很多。

第一步：只读，不改

进入项目根目录：

codex

第一条消息可以这样写：

先不要修改任何文件。请阅读当前项目，告诉我：
1. 这是一个什么技术栈
2. 主要入口文件在哪里
3. 本地启动、测试、构建命令分别是什么
4. 哪些目录或文件修改风险最高
5. 你建议我第一次从哪个小任务开始

这一步是在给 Codex 建地图，也是在让你判断它有没有读对项目。

假设你想改一个登录页面，不要说“优化登录”。可以说：

我想调整登录页的错误提示文案。请先定位相关组件、接口和样式文件。
仍然不要修改文件，只说明你找到这些文件的依据。

Codex 会通过搜索、读取、调用链分析找到相关文件。你要看的不是回答漂不漂亮，而是它定位的文件是不是靠谱。

确认入口以后，再给一个很窄的任务：

只修改登录失败时的文案，不改接口、不改状态管理、不新增依赖。
改完后运行项目里最小的相关验证命令。

如果它想改很多文件，先停下来问为什么。第一次任务越小，越容易建立信任。

官方 best practices 里强调，Codex 在能验证自己工作时效果更好。你可以明确要求：

请运行最相关的检查命令，并报告：
1. 命令是什么
2. 是否通过
3. 如果失败，失败和本次改动是否有关

前端项目常见是 npm run build、pnpm lint、npm run type-check。Python 项目可能是 pytest。不要让它随便新增测试框架，先复用项目已有命令。

Codex 改完后，别只看它说“完成”。运行：

git diff

或者让它总结：

请按文件列出这次改动。标出任何可能的无关改动、风险和还没验证的地方。

你真正要建立的是一条闭环：目标明确、范围可控、结果能检查。Codex 不是替你跳过工程判断，而是让你更快抵达需要判断的位置。

第一个错误，是把任务说得太大。比如“把项目优化一下”，这种需求没有边界，Codex 很容易读很多文件、改很多地方，最后你反而更难 review。

第二个错误，是不给复现步骤。修 bug 时，复现步骤比猜测原因更重要。告诉 Codex 怎么启动、怎么点击、看到什么错误、期望结果是什么，它就能围绕真实行为定位。

第三个错误，是不要求验证。不要满足于“我已经修好了”。你应该让 Codex 跑最小相关检查，并说明失败是否和本次改动有关。这样即使检查没有全绿，你也知道问题在哪里。

第一次进仓库的目标不是一次做大事，而是确认 Codex 能不能稳定完成一个小闭环。小闭环跑顺了，再把任务逐步放大。

参考资料：