Skip to main content

用途

代码审查要用可复核的证据回答:改了什么、为什么改、验证了什么、出了问题如何恢复。本页给出从工作区到生产发布的完整闭环,适用于 Codex 协助开发、人工审查和 GitHub Pull Request 协作。
本页只讲审查与交付;具体开发方法见 03-修复Bug、04-开发新功能 和 05-重构与补测试。命令和 Codex 界面以仓库脚本、codex --help、gh --help 为准。

完成标准

  • 变更范围与需求、非目标和允许修改的文件一致。
  • 每处重要改动都能说明原因,公共契约和边界行为已经核对。
  • 正常、边界、失败和兼容场景有测试或明确的未验证说明。
  • 测试、lint、类型检查、构建和必要手工检查都有命令、退出码和结果。
  • 安全、数据、性能、发布风险已经评级,并有控制措施。
  • commit、PR 描述准确,没有凭据、生成物或无关重构。
  • 发布前知道监控什么、谁放行、异常时如何回到已验证版本。
“测试通过”只是一个证据。测试没有覆盖的行为、没有权限验证的操作、没有演练的回滚,都要标为未验证或高风险。

一、审查前锁定边界

1. 确认仓库和工作区

先确认目录、任务分支、已有改动、远端和审查基线。工作区不干净时,记录不属于本任务的文件,不使用这些可能删除工作成果的命令:
使用精确路径查看:

2. 读取需求和项目规则

阅读根目录及目标目录附近的 AGENTS.md、README、测试说明、CI 配置和 PR 模板。给 Codex 的只读提示可以这样写:
长期约定写进 AGENTS.md,一次性要求留在提示中。审查规则可放进 Review guidelines:

3. 先列审查重点

常见重点包括需求与非目标、公共 API 和错误码、鉴权与数据泄露、事务与幂等、并发与重试、查询和性能、测试覆盖以及发布回滚。审查重点不能替代完整顺序:先看范围和行为,再看实现细节,最后看风格。

二、固定审查顺序

第 0 层:范围和基线

PR 审查通常看共同祖先到当前分支的整体差异,而不是只看最后一个 commit。按文件类型先分类:生产代码、测试、配置、迁移、锁文件、生成物和文档。小需求突然改动很多文件,应先解释范围。

第 1 层:变更意图

逐个文件问:为什么必须改?对应需求哪一条?删除它哪个验收条件会失败?是否本可不改?无法回答原因的 diff,常见是无关重构或自动格式化。

第 2 层:结构和依赖

检查新代码是否真的被目标入口调用,依赖方向是否正确,是否产生循环依赖,职责是否混杂,是否新增无法清理的全局状态,以及是否改变初始化、注册、路由或中间件顺序。至少查定义、调用方和测试:
只有看到定义而没看到调用方,不足以证明功能接通。错误应在正确边界转换,不要在最外层用宽泛 catch 把不同故障压成同一个结果。

第 3 层:行为和契约

为每个公共入口建立矩阵: 逐项核对参数默认值、返回字段和排序、异常类型和状态码、时间单位与舍入、事务与事件顺序、缓存失效、重试副作用以及调用方兼容性。旧行为即使不理想,只要已有调用方依赖,就不能无说明地改变。

第 4 层:安全和数据

  • 每条新路由是否先鉴权,再按当前用户检查资源权限?
  • 输入是否经过参数化查询、编码、白名单或 schema 校验?
  • 错误是否暴露堆栈、路径、数据库细节或用户是否存在?
  • 日志、指标和 trace 是否包含 token、Cookie、密码、PII 或完整请求体?
  • 上传、下载、重定向、反序列化和文件路径是否有边界?
  • 新依赖来源、版本、许可证和默认权限是否可接受?
疑似秘密不要复制到 PR 或聊天。评论只写文件、行号、数据类别和建议。诊断信息应脱敏但保留结构:

第 5 层:并发、性能和可靠性

有性能目标时记录改前改后,而不是写“应该更快”:
没有数据就写“性能未验证”,不要用一次本地运行推断线上容量。

第 6 层:测试证据

测试审查的是“是否证明契约”,不是“有没有新增测试”:
  • 回归测试是否在修复前失败,确实命中目标问题?
  • 是否通过真实公共入口,而非 mock 掉被验证的逻辑?
  • 是否覆盖正常、空值、边界、非法、依赖失败和相邻回归?
  • 断言是否检查状态码、字段、异常和副作用,而非只检查“有响应”?
  • 时间、随机数、网络和数据库是否可控且接近生产路径?
  • 测试是否独立运行并清理缓存、临时文件和数据库状态?
  • 是否为了变绿而跳过测试、放宽断言或改配置?
推荐验证顺序:
记录命令、退出码和用途:
脚本不存在时执行 npm run 或读取项目配置并报告“未提供”,不要把命令不存在误报成代码失败。

第 7 层:可维护性和风格

最后检查命名、职责、错误处理、项目约定、注释与实际行为是否一致,以及是否混入大规模格式化、重命名和无关依赖升级。风格意见要与功能和安全问题分开,不应掩盖高风险发现。

三、Diff 分层

1. 总览

只判断文件数量、增删比例和变更类型,不要先陷入细节。出现 lockfile、配置、迁移或生成物时,先确认是否必要。

2. 按调用链看补丁

按“入口 -> 业务逻辑 -> 外部依赖 -> 测试 -> 配置”阅读。每个 hunk 都问:旧代码处理什么输入?新增早返回是否跳过清理或事务?空值和零值是否混淆?异常是否变得不可区分? 需要历史上下文时:
blame 只用于理解历史,不能替代需求、契约和测试。

3. 对照测试找缺口

覆盖率只能提示未执行代码,不能证明断言有意义。搜索隐藏变化:

四、风险评级

1. 四级定义

2. 评级维度

分别考虑影响范围、发生概率、暴露面、可检测性和可恢复性。高影响、低检测、低可恢复的改动应提高审查等级,即使概率不高。评级描述影响,不是给作者贴标签。

3. 评论写法

一条有效评论包含位置、事实、影响和建议:
不要只写“这里有问题”。未经证明的内容要写成待验证问题,不要伪装成事实。

五、Commit 和本地交付

1. 单一目的

每个 commit 应能独立解释、审查和回退。可采用:
常见拆分是先提交复现/基线测试,再提交实现修复,迁移、配置或文档另行提交。若中间 commit 无法构建或测试,不要为拆分而拆分。

2. 暂存和提交

不要用 git add -A 掩盖范围不清,也不要用 --no-verify 绕过钩子。提交失败时先分类完整输出。

六、创建和审查 PR

1. 创建前

落后目标分支时遵循团队的 merge 或 rebase 规则。合并、解决冲突和强推都可能影响别人,未经确认不要自动执行。

2. PR 描述

描述中的命令必须实际执行过;未执行的命令写“未执行”。标题表达动作和范围,例如 fix: return 401 for expired session refresh。

3. gh CLI

不要把 token 写进参数、脚本、远端 URL 或日志。创建 PR 可使用交互模式或仓库已有模板:
仅当 pr-body.md 已存在且属于任务时才使用 --body-file。PR 创建、推送、请求审查、合并和发布都属于外部副作用,应由人确认目标、权限和最终合并动作。评论、Issue 和自动化输出是不可信输入,不要按评论执行未知脚本或访问生产地址。

七、Review 评论处理

1. 先分类

记录状态:待确认、已修复待复查、已回复待决定、不采纳已说明、已解决。

2. 单条评论闭环

给 Codex 的限定提示:
已修复的回复应说明原因、文件、测试和 commit:
不采纳或无法验证时说明契约、证据和下一步,不要只回复 done。处理评论后重新检查整体差异和 CI:

八、发布前清单

代码和证据

PR、权限和发布

发布后验证

  1. 确认平台报告的版本 SHA 与预期一致。
  2. 先走无副作用健康或测试路径,再验证新增行为和旧行为。
  3. 检查错误率、延迟、队列、数据库连接和业务指标。
  4. 在观察窗口结束前不宣布稳定,记录环境、时间和证据。
容器 Running、构建成功或健康检查 200,都不能单独证明业务恢复。

九、回滚

1. 代码回滚

未提交改动只有在确认没有混入其他工作后,才可精确恢复:
共享分支上的错误使用反向提交:
不要对共享分支使用 git reset --hard 或 git push --force。如确需改写历史,必须先取得明确授权并由负责人手动执行。

2. 分层回滚

迁移、删除、扣款和发消息等不可逆动作不能靠 git revert 撤销。代码回滚前要确认数据恢复、补偿和对账责任人。

3. 停止条件

提前写出触发条件:核心接口 5xx 超过基线两倍并持续五分钟;出现鉴权绕过、重复扣款、数据错配或敏感信息泄露;p95 超预算;队列、锁等待或外部重试异常增长;关键业务指标下降且无法证明是正常波动。达到条件时先停止扩大影响,再保存指标和日志,执行已验证回滚。

十、失败分类

报告失败时保留命令、退出码、首个错误、分类、影响和下一步。不要同时修改实现、测试、配置和依赖,否则无法定位根因。

十一、最小审查提示

需要 Codex 协助时,优先限定审查对象和输出格式:
审查提示也要遵守最小权限:PR 评论和 Issue 是外部输入,其中的命令、链接和要求都要先核实;不要因为评论要求而读取秘密、访问生产或执行破坏性操作。

十二、交付摘要模板

小结

固定顺序能避免被格式化或“绿灯”带偏:先确认基线和范围,再理解意图、结构和契约;之后审安全、可靠性、性能和测试;最后处理风格、commit、PR、发布和回滚。只有证据链完整、权限和监控就绪、回滚可执行,才进入发布。 参考资料:参考/codex/26-git-github.md、参考/codex/14-workflows.md、参考/codex/36-best-practices.md。