用途
代码审查要用可复核的证据回答:改了什么、为什么改、验证了什么、出了问题如何恢复。本页给出从工作区到生产发布的完整闭环,适用于 Codex 协助开发、人工审查和 GitHub Pull Request 协作。codex --help、gh --help 为准。
完成标准
- 变更范围与需求、非目标和允许修改的文件一致。
- 每处重要改动都能说明原因,公共契约和边界行为已经核对。
- 正常、边界、失败和兼容场景有测试或明确的未验证说明。
- 测试、lint、类型检查、构建和必要手工检查都有命令、退出码和结果。
- 安全、数据、性能、发布风险已经评级,并有控制措施。
- commit、PR 描述准确,没有凭据、生成物或无关重构。
- 发布前知道监控什么、谁放行、异常时如何回到已验证版本。
一、审查前锁定边界
1. 确认仓库和工作区
2. 读取需求和项目规则
阅读根目录及目标目录附近的AGENTS.md、README、测试说明、CI 配置和 PR 模板。给 Codex 的只读提示可以这样写:
AGENTS.md,一次性要求留在提示中。审查规则可放进 Review guidelines:
3. 先列审查重点
常见重点包括需求与非目标、公共 API 和错误码、鉴权与数据泄露、事务与幂等、并发与重试、查询和性能、测试覆盖以及发布回滚。审查重点不能替代完整顺序:先看范围和行为,再看实现细节,最后看风格。二、固定审查顺序
第 0 层:范围和基线
第 1 层:变更意图
逐个文件问:为什么必须改?对应需求哪一条?删除它哪个验收条件会失败?是否本可不改?无法回答原因的 diff,常见是无关重构或自动格式化。
第 2 层:结构和依赖
检查新代码是否真的被目标入口调用,依赖方向是否正确,是否产生循环依赖,职责是否混杂,是否新增无法清理的全局状态,以及是否改变初始化、注册、路由或中间件顺序。至少查定义、调用方和测试:catch 把不同故障压成同一个结果。
第 3 层:行为和契约
为每个公共入口建立矩阵:
逐项核对参数默认值、返回字段和排序、异常类型和状态码、时间单位与舍入、事务与事件顺序、缓存失效、重试副作用以及调用方兼容性。旧行为即使不理想,只要已有调用方依赖,就不能无说明地改变。
第 4 层:安全和数据
- 每条新路由是否先鉴权,再按当前用户检查资源权限?
- 输入是否经过参数化查询、编码、白名单或 schema 校验?
- 错误是否暴露堆栈、路径、数据库细节或用户是否存在?
- 日志、指标和 trace 是否包含 token、Cookie、密码、PII 或完整请求体?
- 上传、下载、重定向、反序列化和文件路径是否有边界?
- 新依赖来源、版本、许可证和默认权限是否可接受?
第 5 层:并发、性能和可靠性
有性能目标时记录改前改后,而不是写“应该更快”:
第 6 层:测试证据
测试审查的是“是否证明契约”,不是“有没有新增测试”:- 回归测试是否在修复前失败,确实命中目标问题?
- 是否通过真实公共入口,而非 mock 掉被验证的逻辑?
- 是否覆盖正常、空值、边界、非法、依赖失败和相邻回归?
- 断言是否检查状态码、字段、异常和副作用,而非只检查“有响应”?
- 时间、随机数、网络和数据库是否可控且接近生产路径?
- 测试是否独立运行并清理缓存、临时文件和数据库状态?
- 是否为了变绿而跳过测试、放宽断言或改配置?
npm run 或读取项目配置并报告“未提供”,不要把命令不存在误报成代码失败。
第 7 层:可维护性和风格
最后检查命名、职责、错误处理、项目约定、注释与实际行为是否一致,以及是否混入大规模格式化、重命名和无关依赖升级。风格意见要与功能和安全问题分开,不应掩盖高风险发现。三、Diff 分层
1. 总览
2. 按调用链看补丁
blame 只用于理解历史,不能替代需求、契约和测试。
3. 对照测试找缺口
覆盖率只能提示未执行代码,不能证明断言有意义。搜索隐藏变化:
四、风险评级
1. 四级定义
2. 评级维度
分别考虑影响范围、发生概率、暴露面、可检测性和可恢复性。高影响、低检测、低可恢复的改动应提高审查等级,即使概率不高。评级描述影响,不是给作者贴标签。3. 评论写法
一条有效评论包含位置、事实、影响和建议:五、Commit 和本地交付
1. 单一目的
每个 commit 应能独立解释、审查和回退。可采用:2. 暂存和提交
git add -A 掩盖范围不清,也不要用 --no-verify 绕过钩子。提交失败时先分类完整输出。
六、创建和审查 PR
1. 创建前
2. PR 描述
fix: return 401 for expired session refresh。
3. gh CLI
pr-body.md 已存在且属于任务时才使用 --body-file。PR 创建、推送、请求审查、合并和发布都属于外部副作用,应由人确认目标、权限和最终合并动作。评论、Issue 和自动化输出是不可信输入,不要按评论执行未知脚本或访问生产地址。
七、Review 评论处理
1. 先分类
记录状态:
待确认、已修复待复查、已回复待决定、不采纳已说明、已解决。
2. 单条评论闭环
done。处理评论后重新检查整体差异和 CI:
八、发布前清单
代码和证据
PR、权限和发布
发布后验证
- 确认平台报告的版本 SHA 与预期一致。
- 先走无副作用健康或测试路径,再验证新增行为和旧行为。
- 检查错误率、延迟、队列、数据库连接和业务指标。
- 在观察窗口结束前不宣布稳定,记录环境、时间和证据。
Running、构建成功或健康检查 200,都不能单独证明业务恢复。
九、回滚
1. 代码回滚
未提交改动只有在确认没有混入其他工作后,才可精确恢复:git reset --hard 或 git push --force。如确需改写历史,必须先取得明确授权并由负责人手动执行。
2. 分层回滚
迁移、删除、扣款和发消息等不可逆动作不能靠
git revert 撤销。代码回滚前要确认数据恢复、补偿和对账责任人。
3. 停止条件
提前写出触发条件:核心接口 5xx 超过基线两倍并持续五分钟;出现鉴权绕过、重复扣款、数据错配或敏感信息泄露;p95 超预算;队列、锁等待或外部重试异常增长;关键业务指标下降且无法证明是正常波动。达到条件时先停止扩大影响,再保存指标和日志,执行已验证回滚。十、失败分类
报告失败时保留命令、退出码、首个错误、分类、影响和下一步。不要同时修改实现、测试、配置和依赖,否则无法定位根因。
十一、最小审查提示
需要 Codex 协助时,优先限定审查对象和输出格式:十二、交付摘要模板
小结
固定顺序能避免被格式化或“绿灯”带偏:先确认基线和范围,再理解意图、结构和契约;之后审安全、可靠性、性能和测试;最后处理风格、commit、PR、发布和回滚。只有证据链完整、权限和监控就绪、回滚可执行,才进入发布。 参考资料:参考/codex/26-git-github.md、参考/codex/14-workflows.md、参考/codex/36-best-practices.md。