AI 代码 Review 的三个时机

前言

「让 AI 看代码」很容易做成两件事之一：要么从不做，要么每次都全量扫一遍。前者漏问题，后者贵、慢、噪音大。

更稳的做法是按时机拆开：不同阶段看不同范围，频率和深度也不一样。

这篇文章只讲选型与节奏，不重复贴 workflow YAML。落地配置可以看：

• 前端全栈项目的开发规范链 — 本地 / CI / PR 门禁总览
• GitHub 仓库怎么给 PR 加上自动 Review — PR-Agent 具体接法

三个时机总览

日常开发
   │
   ├─ commit ──→ ② 提交时 Review（轻、快、只看 diff）
   │
   ├─ 开 PR ──→ ③ MR/PR Review（自动评论 + 人看意图）
   │
   └─ 发版/隔版 ──→ ① 全量 Review（重、慢、找系统性债务）

三条原则：

• 全量贵：适合周期性做，不要绑在每次 commit 上。
• 提交要快：只扫本次改动，结论要可执行、噪音要低。
• 合入要严：MR/PR 是最后一道自动 Review 门，再配上人工看 Test plan。

① 仓库全量 Review

适合什么

整仓或某个大目录做一次「体检」。适合问这类问题：

• 有没有明显的重复实现、死代码、过期注释？
• 错误处理、鉴权、日志是否在几个模块里风格分裂？
• 有没有跨文件才能看出来的设计问题？

这类问题看单次 diff 很难发现，适合全量或半全量上下文。

建议节奏

隔一个版本做一次，或按发版周期穿插（例如：奇数版做功能冲刺，偶数版留半天做全量 AI Review + 人读结论）。

不要指望每周全量：上下文长、费用高，模型也容易泛泛而谈。

怎么做（最小落地）

在 IDE / Agent 里明确范围和目标，例如：

对 server/ 做一次缺陷优先的全量 review：
- 先列高风险问题（安全、数据一致性、错误吞掉）
- 再列中风险（可维护性、重复逻辑）
- 不写大段重写建议，每个问题给文件路径 + 为什么 + 改法一句话

输出建议落成 issue 清单 或短文档，挑 2～3 个真要改的进下一迭代，而不是一次改完所有「建议」。

不适合什么

• 紧急修 bug、当天要上线的小改动
• 还没定分支策略、PR 习惯还很乱的阶段（先把 ②③ 和 CI 立住）

② 提交时 Review

适合什么

只看即将提交或刚改完的 diff：命名、明显逻辑漏洞、漏改测试、敏感信息、和本仓库规范不一致的写法。

目标是：在代码进远程之前，便宜地拦一层。

建议节奏

不必每个 commit 都跑。更实用的触发：

• 涉及鉴权、支付、数据库迁移、公共 API 的改动
• 自己觉得「有点绕、怕漏」的提交
• 准备开 PR 前的最后一次整理提交

日常小改（文案、样式微调）可以跳过，靠 lint 和 CI 即可。

怎么做（最小落地）

工具任选其一即可，关键是范围锁在 diff：

提问模板可以固定：

缺陷优先 review 当前 diff：
1. 正确性 / 边界
2. 安全与敏感信息
3. 是否破坏现有约定（API、命名、错误处理）
不要复述代码，只列问题。

不适合什么

• 替代 lint / typecheck / test（这些仍应由门禁跑）
• 在 hook 里跑「全仓深度思考」——提交会变得又慢又烦，最后大家 --no-verify

③ MR / PR Review

适合什么

合入 develop / main 前，对 PR 变更集 做自动审阅：评论打在 diff 上，人再看意图和验收清单。

这是三个时机里最该默认开启的一环：和 CI、分支策略绑在一起，噪音可控、收益稳定。

建议节奏

每个要合入的 PR 都跑（打开与后续 push 更新时可再跑）。
小团队也可以约定：只有进生产的 PR（如 develop → main）必须有自动 Review + 人工过一眼。

怎么做（最小落地）

用 GitHub Actions + PR-Agent（或 Copilot Review / CodeRabbit）即可。本仓库已有一篇完整接法：

→ GitHub 仓库怎么给 PR 加上自动 Review

和人工怎么分工：

机器审代码，人审意图——两边都要。

不适合什么

• 把自动 Approve 当成合并条件的唯一依据
• 忽略 CI：没有 lint/test 的 PR，再漂亮的 AI 评论也兜不住

怎么组合

一套可执行的默认组合：

每天 / 每功能
  → 重要提交用 ②
  → 开 PR 必开 ③ + CI

每个发版周期（或隔一版）
  → 抽半天做 ①，结论进 backlog

和规范链对齐时，可以记成：

小团队起步顺序建议：先 ③ → 再按需 ② → 稳定后再加 ①。先把「合入前一定有人（或机器人）看 diff」做实，再谈全仓体检。

小结

AI 代码 Review 不是开关，是分层节奏：

1. 全量：隔版做，找系统性债务
2. 提交时：按需、只看 diff，保本地速度
3. MR/PR：默认开启，合入前多一双眼睛

它补的是「没人看就合并」和「只盯着 diff 永远看不见仓库整体」这两种盲区；替代不了 CI、测试和人对产品意图的判断。

如果你已经在推 开发规范链，把这三个时机嵌进去，比单独堆一个「全能 AI Review」更可持续。