先明确审查对象与比较基线
审查开始前要说明是查看未提交改动、某个提交、当前分支相对主分支的差异，还是某个特定目录。比较基线不同，看到的代码也不同。对于大改动，还可以按鉴权、数据一致性、并发、错误处理和测试覆盖分别审查，减少重要问题被大量样式建议淹没。
- 未提交工作区：适合提交前自检
- 单个提交：适合定位一次明确变更
- 分支差异：适合合并请求或发布前审查
- 指定目录：适合聚焦安全或核心业务模块
把需求和不变量交给审查者
仅阅读代码无法总是推断业务意图。应补充验收标准，例如重复请求必须幂等、未授权用户不得读取数据、旧版客户端仍需兼容。Codex 才能判断实现是否违反真实要求，而不只是检查语法和风格。
如果存在关联 issue、设计文档或接口契约，也应指出位置。不要只粘贴结论，最好让审查过程能够回到仓库中的原始证据。
一条高质量发现应该包含什么
有价值的发现应包含问题位置、触发条件、实际影响和修复方向。优先级反映影响范围和发生概率，而不是文字语气。阻断发布的数据损坏、安全问题和稳定复现的崩溃应优先；纯偏好或没有证据的假设不应伪装成缺陷。
- 精确到最小相关代码范围
- 说明什么输入或环境会触发
- 解释对用户、数据或兼容性的影响
- 给出可验证的修复方向，而不是笼统要求重写
对审查结论做二次验证
AI 审查同样可能误报。处理每条发现时，应先复现或写一个失败测试，再实施修复。对框架行为、版本特性和第三方 API 不确定时，查阅项目锁定版本的官方资料。确认问题不存在时，记录反证并关闭，而不是为了迎合建议增加无用复杂度。
把修复与回归测试绑定
修复完成后，重新运行触发问题的最小测试，再执行受影响模块的回归测试，并复查差异是否引入额外变化。最终摘要应区分已经修复、暂缓处理和需要人工决策的事项，让代码审查成为可追踪流程。
官方资料与延伸阅读
本文按官方公开资料重新组织为中文实践指南。产品界面和能力可能调整，具体以官方页面为准。
相关主题与下一步阅读
ChatGPT Plus、ChatGPT Pro、Codex 与 OpenAI API 属于不同产品或使用入口。围绕充值、支付和到账问题，建议继续阅读对应专题，避免把会员方案、开发接口余额和编码工具混为一谈。
常见问题
Codex 能审查没有提交的代码吗？＋
可以。明确要求审查工作区中的未提交差异，并在审查前检查当前状态，避免把既有改动误认为本次变化。
如何减少 Codex 代码审查误报？＋
提供业务不变量、运行环境和版本信息，并要求每条发现说明触发路径；修复前用测试或复现步骤验证。
代码风格问题应该和缺陷放在一起吗？＋
可以记录，但应与正确性、安全和数据问题分级。若仓库已有自动格式化工具，优先交给工具处理。