Codex App Review：检查 diff、评论改动并决定是否提交

适用场景

这篇手册适合 Codex 完成修改后，准备检查 diff、继续评论或提交改动的用户。

OpenAI 官方 Codex App review 文档说明，App 可以帮助你查看代码改动、评论、继续迭代并推进到提交或 PR。它不是跳过审查的理由，而是把审查流程放进同一个工作区。

步骤 1：先看改动范围

打开 review 面板后，先不要逐行看细节，先看文件列表：

• 是否只包含本次任务相关文件。
• 是否出现不认识的文件。
• 是否有生成物、临时文件或本地配置。
• 是否包含敏感信息。

如果文件列表已经不对，先让 Codex 解释来源。

步骤 2：区分 Codex 本轮改动和已有改动

如果工作区本来就有未提交内容，review 面板可能会显示这些已有改动。

你可以问：

请区分哪些文件是你本轮修改的，哪些是此前已经存在的改动。
不要回滚任何文件。

必要时切换到 Last turn changes 视图，只看最近一轮。

步骤 3：逐块检查关键 diff

逐块看 diff 时，重点检查：

• 逻辑是否符合需求。
• 是否扩大了范围。
• 错误处理是否合理。
• 文案和 UI 是否符合设计规范。
• 是否删除了必要代码。

如果某块看不懂，可以让 Codex 解释：

请解释这段 diff 为什么需要改，是否有更小改法。

步骤 4：在 review 中留下具体评论

不要写“这里不行”。写清楚问题和期望：

这里不应该修改 tutorials 页面。请只保留 manual 路由相关改动。

这个判断缺少空数组情况，请补一个测试或说明为什么不需要。

评论越具体，Codex 越容易小范围修复。

步骤 5：修复后再次验证

让 Codex 根据 review 评论修改后，重新运行验证：

请根据我在 review 里的评论修复。
修复后运行 lint 和 build，并总结结果。

如果没有运行验证，要求说明原因，不要默认通过。

步骤 6：提交前做最终检查

提交前运行：

git status --short
git diff --stat

确认没有无关文件，再提交或创建 PR。

常见错误

不要不看 diff 就提交。

不要把 review 面板里的所有文件都当成 Codex 本轮改动。

不要把多个无关任务混进一个提交。

不要只看 Codex 的总结，忽略实际 diff。

小结

Codex App review 的正确流程是：先看范围，再看关键 diff，留下具体评论，要求小范围修复，运行验证，最后再提交。它能提高效率，但不能替代你的最终判断。