团队使用 Codex 做代码审查：规则、证据与责任边界

Codex 可以帮助团队阅读差异、追踪调用关系并发现潜在问题，但代码审查的最终责任仍属于提交者和审查者。高质量的 AI 审查不是生成大量评论，而是提供少量、准确、可复现并与团队标准一致的发现。

## 先定义审查范围

告诉 Codex 本次变更的目标、基线分支、重点模块和不在范围内的内容。若只提供一段孤立代码，它可能无法判断调用方、数据约束和兼容性。必要时允许它只读搜索相关接口和测试，但不要默认扩大写入范围。

## 统一发现标准

- 真实的功能错误或边界条件遗漏。 - 安全、权限、数据泄露或破坏性风险。 - 与现有接口、数据库或部署流程不兼容。 - 测试无法覆盖的关键行为。 - 会造成明显性能或可靠性问题的实现。

纯个人偏好、没有证据的猜测和与本次变更无关的重构建议，应与阻塞性问题分开。

## 每条评论需要什么证据

一条有效发现应包含文件与位置、触发条件、实际后果和建议修复方向。最好给出最小复现步骤或对应测试。仅写“可能有问题”会增加沟通成本，也无法判断优先级。

## 设置清晰优先级

高优先级用于会造成数据丢失、安全漏洞、服务不可用或主要功能错误的问题；中优先级用于特定条件下的功能缺陷；低优先级用于不会阻塞发布的改进。团队应对优先级定义达成一致，不让模型自行创造标准。

## 处理误报

要求 Codex 在提出结论前搜索现有保护逻辑、测试和调用方。审查者应验证发现，而不是直接接受自动生成的评论。若某类误报反复出现，把正确约束写入 AGENTS.md 或审查规则，并增加可执行测试。

## 审查后的责任分工

提交者解释设计并修复确认的问题；人工审查者决定是否合并；Codex 提供辅助证据和候选测试。涉及架构、安全或业务规则时，应由相应负责人最终确认。

## 团队落地步骤

先在低风险仓库试运行，比较人工与 Codex 的发现，统计有效率和误报原因。规则稳定后再纳入合并流程。任何自动化审查都不应绕过测试、分支保护和人工批准。