1. 背景

1. 资深 reviewer 是稀缺资源。随着 PR 数量增加，review 排队问题会越来越明显。
2. 人工 review 很容易把大量时间花在重复扫描上，比如空指针、防御性校验、日志脱敏、测试缺失、依赖升级风险等。
3. AI 提升了代码产出速度，但 review 的吞吐能力并没有同步增长。
4. 不同 reviewer 的关注点差异很大，容易导致审查质量不稳定。

2. 价值

AI review 的真正价值不是简单“更快看完代码”，而是把审查流程前移，把基础问题筛掉，把高风险区域高亮出来，让人工 reviewer 的注意力更多投向业务、架构和风险判断。

3. 能力分层

• 第一层是基础自动化审查。重点是让所有 PR 在进入人工 review 之前，都先经过一轮自动摘要、基础 bug 扫描、安全检查、测试提醒和风险初判。
• 第二层是上下文感知审查。这时候 AI 不再只看 diff，而是结合仓库中的 AGENTS.md、REVIEW.,d、目录语义、ownership、关联 issue 等信息来理解改动的真实上下文。
• 第三层是可执行审查。AI 不只提出问题，还可以给出 patch suggestion、补测试建议、文档补充建议，甚至为发现的问题创建后续修复任务。
• 第四层是流程编排审查。比如 PR 创建自动 review、新提交自动 re-review、高风险目录触发深度审查、review 结果汇总到 issue 或周报。
• 第五层是持续学习与治理。包括误报/漏报分析、规则优化、prompt 调整、不同仓库/语言的策略分层，以及对 AI review 命中率和采纳率的持续观测。
  从实践角度看，前两层解决“能不能用”，后三层解决“值不值得长期用”。

4. 人工与 AI 的边界应该怎么划分

• AI 更适合做的，是第一轮全量扫描、重复性检查、基础安全/测试/文档问题提醒、风险点预标注、评论聚合以及低复杂度修复建议。
• 人工必须保留的职责，是业务逻辑正确性判断、架构合理性判断、系统边界和回滚策略判断，以及最终 merge 责任。AI 可以帮助团队“看得更全”，但不能替团队“承担责任”。
  因此，比较合理的人机协作流程应当是：

1. PR 打开时，AI 先生成摘要、跑基础 review、标出高风险区域。作者先处理高置信问题，再发起人工 review。
2. 人工 reviewer 进入前，AI 生成 briefing：改了什么、哪些地方最值得看、已发现但未修的问题、可能影响的上下游。
3. review 过程中，人工 reviewer 聚焦业务和架构，AI 辅助解释上下文、归纳讨论、给出 patch 建议。
4. 收尾阶段，AI 汇总所有 comment，输出 closing checklist，帮助团队确认是否仍有 unresolved risk。

4.1. 人工与 AI 的时间配置建议

AI review 的目标不是把人工减少到几乎没有，而是把人工时间结构重构掉。在传统模式下，一个 reviewer 的时间经常分布在：理解 PR、逐行扫 diff、来回写 comment、再验证修复。AI 介入后，理想状态不是“AI 做 90%，人只看 10%”，而是“AI 做掉 70% 的基础扫描，人把主要精力放在最值钱的 30% 判断上”。从单个 PR 角度看，人工可以少花时间从零理解变更，多花时间确认高风险逻辑、判断业务边界和做最终 merge judgment。

4.2. 实践建议

• 所有 PR 跑 AI review，高风险 PR 保留双人 review，每周花 30~60 分钟复盘质量。
• AI review 变成标准前置步骤，为每个仓库设 review instruction owner，每周花 1~2 小时维护规则和 prompt。