Codex 完成任务是验收的开始，而不是改动已准备好提交的证明。安全的审查必须回答三个独立问题：改了什么、改动是否满足要求，以及有哪些证据支持这一结论。
OpenAI 当前的代码审查文档指出，审查面板反映的是 Git 仓库状态，而不仅仅是 Codex 所做的编辑。这一区别很重要：已暂存、未暂存、未跟踪的内容、用户此前的工作以及最新的助手回合，可能代表不同的范围。在评判实现之前，先审查正确的范围。
在审查前建立基线
首先记录你预期 Codex 会保留的状态：
- 当前打开的是哪个分支和仓库？
- 任务开始前是否有未提交的更改？
- 哪些文件或行为属于本次任务范围？
- 约定了哪些验收标准和验证命令？
- 任务是否允许修改依赖、配置、生成文件或锁定文件？
如果你没有记录初始状态，不要假设每一处可见的改动都来自 Codex。请它先说明最近一轮做了哪些更改，再将它的说法与 Git 历史记录和完整工作树进行比对。
选择正确的 diff 范围
不同的审查问题需要不同的比较：
- 上一轮： 助手最近更改了什么？
- 未提交更改： 如果现在停止，工作树中会保留哪些内容？
- 已暂存更改： 当前为下一次提交准备了哪些内容？
- 提交： 某一次具体提交引入了什么？
- 分支对比基准： 整个分支会为合并贡献哪些内容？
Codex 应用、CLI 和 IDE 扩展目前为未提交更改、选定提交或分支比较提供 /review 范围。专门的审查会报告发现结果，而不会修改工作树；之后任何应用修复的请求都是在正常权限下执行的单独操作。
你可以让审查标准更加明确：
对照原始任务审查未提交的更改。不要编辑文件。
优先关注正确性、回归、安全性、可访问性和缺失的测试。
对于每一项发现，请注明文件和行号，说明一个现实的失败场景，
并建议最小的修复方案。当 diff 不支持某个问题时，请不要编造
问题。在逐行审查前先浏览文件列表
文件列表比逐行阅读能更快地暴露范围问题。要问清每个文件为什么发生变更。
请特别关注：
- 在未请求依赖变更时出现的锁文件或清单文件；
- 环境、部署、权限或 CI 配置；
- 本不应手工编辑的生成文件；
- 可见文案变化时的语言文件；
- 被删除的测试、文档、注释或错误处理；
- 导致 diff 难以审查的媒体、测试夹具、快照或大文件；
- 位于所请求功能区域之外的文件。
出现意外文件并不自动意味着错误。它是一个必须在提交前得到回答的问题。
按风险顺序阅读 diff
不要以同等的注意力审查每一行。先从一个小错误影响最大的地方开始。
- 安全与权限： 身份认证、授权、密钥处理、文件访问、网络访问、命令执行。
- 数据与兼容性： 模式、迁移、公共 API、序列化、缓存和持久化。
- 控制流： 错误路径、清理、重试、并发、超时和回退行为。
- 面向用户的行为： 无障碍、本地化、校验、加载、空状态和失败状态。
- 测试与文档： 它们是否验证了预期行为，而不只是匹配实现。
- 风格与命名： 对可维护性很重要，但很少成为遗漏正确性问题的理由。
对于每个变更块，问自己：什么输入会到达它，它会产生什么输出或副作用，失败时会发生什么。然后将答案与原始验收标准进行比较。
识别高信号预警模式
AI 辅助的代码变更中常见的问题包括：
- 围绕细微修复进行的大范围重构；
- 新增辅助函数，却重复了现有抽象；
- 异常被捕获并忽略，且没有任何可见的失败表现；
- 测试只断言实现细节，却没有断言所报告的行为；
- 硬编码路径、本地化文本、ID、日期或凭据；
- 只在 UI 中执行校验，而底层操作仍未被检查；
- 只添加到一个语言环境或路由，却没有添加到实际对应的其他语言环境或路由；
- 声称检查已运行，但没有任何命令输出可作证明的注释或摘要。
对删除代码的排查要像检查新增代码一样仔细。删除操作可能会移除某个保护机制，即便新的正常路径看起来更简洁。
通过分层检查验证行为
静态审查不能替代执行，仅构建通过也不能证明功能可用。请使用最小且有用的分层检查：
1. 复现原有行为或故障。
2. 运行覆盖变更路径的针对性测试。
3. 运行项目相关的 lint 和类型检查。
4. 当共享契约发生变化时，构建或运行更广泛的测试套件。
5. 走查面向用户的流程，包括一个失败或边界场景。记录确切的命令、结果以及任何被跳过的内容。如果某个失败原本就存在，请保留证据，而不是自动忽略它。根据相关性和风险判断它是否会阻塞本次变更。
将发现与疑问和偏好区分开
一份有用的审查报告会区分：
- 发现： 有证据表明在可信场景下存在缺陷或回归。
- 疑问： 需求或仓库中的证据不足以作出判断。
- 建议： 代码有效，但更简洁或更清晰的实现可能更可取。
- 验证缺口： 相关检查或环境不可用。
这能防止风格偏好掩盖真实问题，也能防止将不确定性当作事实报告。
请 Codex 给出按优先级排序的发现，但你要自行验证。一条看似合理的审查评论仍可能误解调用方、不变式、生成文件或框架约定。
安全处理不需要的变更
不要仅仅因为一个差异块有误就恢复整个文件；同一文件可能包含早于该任务的用户工作。识别每个差异块的归属，保留不相关的更改，仅撤销可归因于此任务的编辑。
在接受自动还原之前，请检查其目标与范围。对于混合文件，进行小的纠正性编辑通常比用早期版本替换文件更安全。
修复后，请再次审查新的差异。第一次审查在某个变更集中发现了问题；它并不会自动批准该修复。
使用提交前验收记录
最后用一份简短的证据记录收尾：
- **预期结果：**一句话；
- **变更文件：**预期文件以及对任何意外情况的说明；
- **已检查行为：**复现步骤或手动流程及其结果；
- **已运行命令：**准确的通过或失败状态；
- **未检查项：**不可用的环境、浏览器、平台或数据；
- **残余风险：**假设和后续工作；
- **决定：**可以提交、需要修复或需要用户输入。
决定应依据证据作出。不要只是为了清空工作区或因为实现已基本完成就提交。
为了在问题发生前减少评审问题，请使用 Codex 提示词编写框架。新用户可以在 Codex 入门教程中练习完整闭环。如果你主要在终端中工作，请把 Codex CLI 命令指南放在手边。
常见问题
一份干净的 /review 报告是否足以提交？
不能。自动化审查可能遗漏需求、运行时行为或项目特定上下文。除了阅读审查结果外，还应确认预期行为并执行相关检查。
应该审查最后一轮还是所有未提交的更改？
使用最后一轮来单独定位助手最近一次编辑。使用所有未提交的更改来了解实际会保留在工作区或进入提交的内容。当存在用户先前的工作时，应同时比较两者。
如果测试因无关原因失败，我应该怎么做？
保留命令输出，尽可能确认该失败在此更改之前是否已存在，并说明不确定性。不要静默删除、跳过失败，或将失败改标为通过。
Codex 能修复它发现的问题吗？
可以，如果你要求它修复，但这会启动另一个修改步骤，并受常规沙箱和审批设置约束。应将修复作为新的 diff 进行审查，而不是假设审查者已验证自己的修复。