用 Codex 做 PR 与代码审查

代码审查的目标是发现会影响正确性、安全性和可维护性的具体问题，不是让 Codex复述 diff。

教程目标

完成一次只读审查，得到包含文件位置、触发条件、影响和修复建议的优先级问题清单。

第 1 步：选择审查范围

Codex App、CLI 和 IDE 中可以使用 /review。常用范围包括：相对基线分支、全部未提交改动、某个提交，或自定义审查要求。

请只读审查当前分支相对 main 的完整 diff。
不要修改文件，不要提交，不要推送。
先确认实际 merge base 和纳入审查的文件列表。

如果主分支不是 main，替换成项目真实基线。范围不清会造成漏审或把旧问题算进本次 PR。

第 2 步：给出审查标准

重点检查：
1. 正确性和边界条件。
2. 安全、权限与敏感信息。
3. 并发、事务和错误处理。
4. API、数据结构与兼容性。
5. 测试是否覆盖新增行为和失败路径。
6. 是否有与任务无关的修改。

只报告能从 diff 和项目上下文证明的问题。

样式偏好与真实缺陷要分开。项目已有 lint 或格式化规则时，不要让人工审查重复制造噪音。

第 3 步：规定输出格式

每个发现必须包含：
- 严重程度：阻断 / 高 / 中 / 低；
- 文件和尽量精确的行位置；
- 触发条件；
- 实际影响；
- 为什么现有测试没有挡住；
- 最小修复方向。

如果没有可证明的问题，明确写“未发现阻断问题”，不要为了数量编造。

先处理阻断和高严重度问题。低严重度建议不要淹没会导致故障的数据。

第 4 步：核验发现

让 Codex针对每个高严重度问题读取相关调用链、配置和测试，必要时运行最小复现。无法复现的结论应降级为风险或待确认项。

请逐条核验高严重度发现。只读为主；如果运行检查，不得修改业务文件。
对误报说明为什么不成立，对成立的问题给出最小修复和回归测试建议。

第 5 步：修复后复审

修复与审查分开进行。修复后重新审查新的完整 diff，不要只看最后一轮修改。

常见问题

• 只总结改了什么：补充明确审查标准和问题格式。
• 报告大量旧问题：重新确认 merge base 和文件范围。
• 把猜测写成事实：要求触发条件、证据和复现。
• 审查过程中改文件：中止并恢复到只读审查。
• PR 太大：按模块分块，但最后仍要审查完整集成 diff。

验收结果

1. 审查范围、基线和文件列表明确。
2. 每个问题都有位置、触发条件、影响和证据。
3. 结论按严重程度排序，未用风格噪音充数。
4. 高严重度发现已核验，误报已剔除。
5. 修复后对完整 diff 做了复审。

官方参考：https://developers.openai.com/codex/code-review

下一篇看：怎样看懂 Codex 的 diff 和修改总结。