让 Codex 做代码审查时，最常见的低效提示是“帮我 review 一下”。这种提示会诱导它输出很多风格建议，却不一定覆盖真正危险的行为变化。

更好的审查顺序是：先看用户可见行为是否变化，再看边界条件，再看测试是否覆盖，再看部署和数据风险，最后才看命名、重复和局部风格。审查输出也应该按严重程度排列，并且绑定文件和行号。

可以使用这样的审查框架：

  • 这次 diff 改变了哪些输入、输出、状态或副作用。
  • 有没有空值、并发、权限、时区、网络失败、缓存失效等边界。
  • 有没有测试证明关键路径没有回归。
  • 部署后失败会怎样发现，能否回滚。
  • 哪些建议只是风格问题，不应该阻塞。

如果审查结果没有测试建议，要追问它“哪个失败用例最能证明这个风险”。如果它提出重构建议，要追问“这个重构是否服务当前目标，是否会扩大风险面”。审查不是让模型展示聪明，而是帮助团队发现会影响用户和发布的具体问题。

对团队来说，Codex 审查最适合放在人工审查之前。它可以先扫出明显风险、缺失测试和不一致实现，让人类 reviewer 把注意力放在产品判断、架构取舍和团队知识上。