codex-auto-review 适合被理解为 Codex 中面向自动代码审查的工作模式、任务标签或模型路由，而不是一个可与通用 GPT 型号直接横向比较的标准 API 模型。它的目标不是替开发者写一段泛泛的评价，而是基于代码差异和仓库上下文，发现会影响正确性、安全性、性能和可维护性的具体问题。
由于此名称可能与特定 Codex 产品界面、权限或内部路由绑定，底层使用什么模型、是否可以通过公共 API 直接调用，都应以当前产品实际显示和官方说明为准。不要在业务代码里假设它等同于固定的 GPT 模型 ID。
自动代码审查应该交付什么
一条有价值的审查意见至少包含四个要素：问题所在位置、可以触发问题的条件、实际影响，以及为什么当前测试没有覆盖。好的审查关注可操作缺陷，而不是代码风格偏好，也不会为了显得全面而罗列大量低价值建议。
例如，“这里可能有并发问题”信息不足；更好的意见是指出两个请求如何同时通过检查、随后重复写入，说明受影响的数据，并建议用唯一约束或事务内原子操作验证修复。
最适合自动审查发现的问题
- 条件判断错误、空值处理遗漏、边界越界和异常路径缺失；
- 接口兼容性破坏、字段语义变化和迁移脚本不完整；
- 鉴权绕过、敏感数据泄露、注入和不安全默认配置；
- 异步竞态、幂等失效、事务边界和资源泄漏；
- N+1 查询、无界循环、缓存失效和明显性能退化；
- 新行为缺少测试，或现有测试断言无法覆盖回归。
它不应该替代什么
自动审查不能替代产品需求确认、领域专家判断、真实环境测试和最终代码责任。模型可能不了解隐含业务约束，也可能对看似可疑但实际上有意设计的代码产生误报。安全、资金、权限和数据删除相关变更，仍应由具备责任边界的人审查。
它也不能证明代码“没有问题”。审查结果为空，只能说明当前上下文中没有发现值得报告的缺陷，不能代替单元测试、集成测试、静态分析和运行时监控。
提供什么上下文效果最好
- 完整差异：包括新增、删除和相关配置变化，而不只是单个函数截图。
- 仓库规则：架构约束、兼容性要求、测试命令和禁止事项。
- 需求说明：这次变更要解决什么问题，哪些行为必须保持。
- 相关代码：调用方、数据模型、数据库约束和公共接口。
- 验证结果：测试、构建、类型检查和日志，让审查聚焦仍未覆盖的风险。
如何控制误报和噪声
要求审查只报告能够明确说明影响的问题，并按严重级别排序。每条意见应绑定紧凑的代码行范围，避免把同一根因拆成多条。对于仅改善命名或风格的建议，可以单独归入非阻断建议，或者直接交给格式化和静态检查工具。
团队还应定期统计审查意见的采纳率、误报率、漏报案例和修复后回归情况。对频繁误报的模式补充仓库规则，对漏报缺陷加入评测样本。这样自动审查会随着项目上下文积累而更有价值。
适合接入开发流程的位置
最常见的做法是在 Pull Request 创建或更新后触发自动审查，将结果作为人工评审的输入。为了避免阻塞开发，可以先只让高严重级别问题影响合并门禁，普通建议保持非阻断。对于大型变更，可先在本地任务中审查，再在 CI 中对最终差异复查。
自动审查应与编译、类型检查、测试、依赖漏洞扫描和静态分析并行存在。确定性工具擅长发现明确规则问题，模型则更擅长理解跨文件语义和潜在行为变化，两者互补而不是互相替代。
一个实用的审查指令
审查本次变更，只报告会导致错误行为、安全风险、明显性能退化或兼容性破坏的问题。
每条意见必须包含：文件与最小行范围、触发条件、影响、修复方向。
忽略纯风格建议；如果没有可操作问题，明确返回未发现阻断项。
同时检查新增行为是否有足够测试覆盖。总结
codex-auto-review 的价值不在于取代审查者，而在于以稳定频率检查每一次变更，提前发现容易遗漏的回归。把它当作一套有上下文、有证据、有优先级的审查流程，而不是固定能力的通用模型，才能建立正确预期。
说明：codex-auto-review 的具体可用方式和底层路由可能随 Codex 产品更新而变化，请以当前 Codex 界面、组织权限和官方文档为准。