PR 才是主战场：AI 时代的 Code Review 新规则

LeonGao
0 阅读6分钟

0、先破后立：别再把 Review 当“挑代码毛病”，AI 时代真正要审的是“改动是否可控、可验证、可撤回”。

以前产出慢，Review 可以细抠实现；现在 AI 产出快，PR 数量暴涨，你还按老办法逐行看，结局只有两个：要么大家麻木点 Approve，要么队伍卡死在 Review 队列里。新规则的核心很现实：把 Review 从“看你怎么写”转成“看你交付了什么证据” 。PR 才是主战场，因为它把代码、说明、测试、风险与责任绑在一起。

1、交付：合格 PR 的第一标准是“交付完整”，没有材料就别进 Review 池。

一句话中心论点：PR 先像一份可执行的交付单，再像一段代码。

建议把 PR 模板固定下来，最少包含这些块（缺一块就退回，不讨论质量）：

  1. 目的（Why） ：要解决什么问题，用一句话写清。
  2. 范围（Scope） ：改了哪些模块/路由/接口；有没有数据库/权限/协议变化。
  3. 截图或录屏（UI 相关必填） ：前后对比，状态要覆盖（loading/empty/error/disabled）。
  4. 验证步骤（How to verify） ：从启动命令到操作路径，按步骤能复现。
  5. 测试情况：新增/更新了哪些测试；没测到的地方写明原因。
  6. 风险与回滚：潜在风险点、回滚方式（开关/回版本/降级）。
  7. AI 使用声明（可选但推荐） ：哪些文件主要由 AI 生成，方便 Review 时更谨慎看关键点。

一句话：你交付的是“可验收的改动”，不是“我写完了”。

2、可控：AI 时代的 Review 要先控范围，再谈优雅；范围控不住，一切都白搭。

一句话中心论点：PR 越大，Review 越假；PR 越可拆，质量越真。

新规则建议这样落：

  • 硬限制：PR 尺寸门槛

    • 例如：非生成文件改动 > 400 行就要求拆分（阈值你们自己定，但要有）。
    • 混合 PR（重构 + 新功能 + 格式化）一律拆；格式化必须单独 PR。

  • 文件类型分区

    • 业务逻辑、UI 展示、配置/脚本、依赖升级分开 Review。
    • AI 常把无关文件也动了：这类“顺手改”默认不收，除非有明确理由。

  • 关键路径标红

    • 权限、支付、写库、队列、外部调用这些路径，需要 CODEOWNERS 或指定 Reviewer。
    • 让系统帮你控，不要靠人记。

一句话：可控的 Review，是把“看不完”变成“看得完”。

3、复现：Review 不应该靠脑补；你给不出复现方式，就等于没验证。

一句话中心论点：能复现，才有资格讨论对错。

把复现从“口头承诺”变成“PR 必备证据”，建议三层：

  1. 本地复现
  • 启动命令、环境变量、测试账号（如有）
  • 必须能跑到你说的页面/接口
  1. 自动化复现
  • 最少新增或更新一类：单测/集成测/e2e
  • 改 bug 就补回归用例，别只改代码
  1. 线上等价复现（灰度/特性开关）
  • 高风险改动要有开关或配置隔离
  • Reviewer 要能判断：出事时怎么关、关了会怎样

一句话：Reviewer 不是来替你测试的，Reviewer 是来检查你“有没有把测试这件事做成系统”。

4、成本：AI 把代码成本打下来，但把 Review 成本抬上去；新规则要让 Review 变快而不变糙。

一句话中心论点：省 Review 时间，靠的是标准化，不靠催人。

可落地的降本打法：

  • 两段式 Review

    1. 先过“门槛检查”（模板是否完整、范围是否过大、是否有测试/回滚说明）
    2. 再过“内容检查”（逻辑正确性、边界条件、可维护性）
      门槛不过，直接退回，不进入内容讨论。

  • 评论要可执行

    • 禁止“我感觉这样更好看”，要写成“为什么 + 怎么改 + 参考例子”。
    • 对 AI 生成代码尤其要防“审美争论”，优先按规范、按性能、按安全判。

  • 把争议收敛到规则

    • 代码风格交给 formatter/linter
    • 可读性用命名规范与注释规范
    • 架构边界用目录与依赖规则
      规则越硬，Review 越快。

一句话：真正省下来的不是几分钟，而是少掉三轮来回扯皮。

5、安全：AI 写代码最常见的坑，是“能用但不该用”；Review 要把红线放到最前面。

一句话中心论点：安全审查不是专门团队的事，PR 就是第一道门。

PR 安全检查建议固定成清单，Reviewer 按清单点名：

  • 敏感信息：日志、报错、注释、测试数据里有没有 token、手机号、身份证、密钥。
  • 鉴权一致性：新接口有没有沿用统一鉴权/权限校验；有没有绕开中间件。
  • 输入校验：参数长度、类型、枚举范围、SQL/命令注入风险点是否被挡住。
  • 依赖风险：新增依赖是否必要；版本升级是否看过公告；是否引入高危包。
  • 输出与错误：错误信息是否泄露内部实现（堆栈、路径、表名）。

一句话：AI 生成的“方便写法”，经常就是安全事故的起点。

6、质量门禁：让机器做机器该做的事，让人做只有人能做的判断。

一句话中心论点：门禁把下限抬高，Review 才能把上限抬高。

建议把门禁分三类，配到 CI 里，没过就不允许请求 Review：

  1. 静态门禁：lint、format、类型检查、死代码、依赖扫描。

  2. 测试门禁：关键路径用例必须过；覆盖率阈值可以分模块设。

  3. 变更门禁：

    • 禁止大范围无意义改动（比如全仓换行/排序）
    • 关键目录改动必须带对应测试
    • 生成代码需标注来源并经过更严的规则检查（例如更严格的 lint preset）

同时，人该看的点也要明确：

  • 业务规则是否正确
  • 边界条件是否覆盖
  • 可读性是否达标（不是优雅，是可维护）
  • 失败策略是否合理（超时、重试、降级）

一句话：把重复检查交给 CI，人才能把精力花在“真正值钱的判断”上。

快速测评清单（你们照着执行一周，就能看到 Review 速度和质量的变化）

  1. PR 模板是否强制执行，缺项能否直接退回。
  2. 大 PR 是否明显减少，拆分是否变成默认动作。
  3. 格式化与风格争论是否下降（formatter/linter 是否覆盖到位）。
  4. Reviewer 是否能按“验证步骤”在 10 分钟内复现关键改动。
  5. 每个高风险改动是否都有回滚说明与开关策略。
  6. AI 生成代码是否被更严格地检查关键点（鉴权、校验、错误处理、日志）。
  7. PR 的 diff 是否更干净：无关文件改动是否减少。
  8. 自动化测试是否随 bug 修复同步补齐，而不是“下次再说”。
  9. CODEOWNERS/责任人机制是否真的在起作用，而不是摆设。
  10. Review 周期是否更可预测：从提交到合并的中位时长是否下降。
avatar
文章
阅读
粉丝