让 Codex 做代码审查时，最重要的是设定审查姿态。你不是要它总结“改得不错”，而是要它像一个严格同事一样找问题。

审查前先准备上下文

如果你审查的是本地改动，先确认：

git status
git diff

如果你审查的是某个 PR，需要把需求背景、主要变更和风险点告诉 Codex。否则它只能从代码猜意图。

推荐提示词

请审查当前未提交改动。

审查重点：
- 真实 bug；
- 行为回归；
- 边界条件；
- 安全和权限风险；
- 缺失测试。

输出要求：
- 先列问题，按严重程度排序；
- 每个问题给出文件和位置；
- 不要泛泛夸奖；
- 如果没有发现问题，明确说没有，并说明剩余风险。

为什么不要先要总结

总结很容易让审查变软。好的 review 应该先回答：“这次改动有没有可能坏掉？”然后才是“改了什么”。

尤其是后端接口、计费、权限、数据库迁移和线上配置，审查应该优先看风险，而不是看风格。

让 Codex 检查测试缺口

可以继续问：

这些改动覆盖了哪些测试？还有哪些行为没有测试到？
如果只补 2 个最关键测试，你建议补哪里？

这样 Codex 会从行为角度补测试建议，而不是机械地追求覆盖率。

审查结果怎么处理

不要把 Codex 的所有建议都照单全收。你应该分三类：

  • 必修：会导致 bug 或线上风险
  • 可选：能提升可维护性，但不影响当前任务
  • 暂不做：超出本次范围

对于“可选”和“暂不做”，可以让 Codex 帮你写成后续 TODO 或 issue。

常见坑

第一，不要让 Codex 同时“审查并修改”。先审查，确认问题，再改。

第二，不要接受没有文件位置的问题。没有位置的问题往往不可执行。

第三，不要让审查变成重构建议会。Review 的核心是风险，不是审美。

官方来源

  • https://developers.openai.com/codex/learn/best-practices
  • https://help.openai.com/en/articles/11096431-openai-codex