考察点
这道题是 AI 编程面试里的实践区分题：每个团队 review 都在变慢，面试官想知道你有没有想清楚应对，还是只会抱怨「AI 代码太多看不过来」。深层考察点是你对 review 本质的理解——review 到底是干什么的，AI 改变了其中哪部分、没改变哪部分。追问常往「AI 预审能不能替代人」「review 看什么重点」走。
参考答案
什么变了，什么没变
先说没变的：review 的三个核心目的——拦住缺陷、保证代码符合系统整体设计、在团队内传播上下文——一个都没变，AI 反而让后两个更重要了。变了的是三个现实：代码产出量翻倍甚至几倍，review 成了瓶颈；缺陷模式变了，低级笔误几乎消失，「看着对实则错」的逻辑缺陷和「自作主张」的设计膨胀增多；作者对代码的熟悉度下降了——以前写代码的过程就是理解的过程，现在作者可能也没细读自己提交的代码。
流程层面的调整
针对产出量爆炸，流程上我有几条硬规矩。PR 必须小，超过四五百行 diff 的 AI 产出大概率没人真审，要么拆小要么打回；这条在 AI 时代比过去更重要，因为 AI 天然喜欢一次性大改。作者责任前置：提交时必须写清「为什么改、改了什么、怎么验证的」，review 开场先让作者讲设计意图——讲不清自己代码的 PR 直接打回，这条能快速筛掉 vibe coding 产物。机器前置：lint、类型、测试在 CI 卡住，reviewer 不为机器能查的事浪费注意力。
审查重点的迁移
人脑的 review 预算有限，要花在 AI 缺陷密度最高的地方，我按优先级排：
| 重点区域 | 为什么 AI 容易栽 |
|---|---|
| 设计意图与必要性 | AI 倾向过度工程，先问「这个抽象真的需要吗」，砍掉比修改便宜 |
| 边界与异常路径 | happy path AI 写得很好，空值、并发、超时、重试路径是重灾区 |
| 安全面 | 输入校验、鉴权、注入、密钥处理，AI 的训练数据里坏例子太多 |
| 与现有系统的一致性 | AI 只看局部，容易绕过项目已有封装重造轮子、破坏分层约定 |
反过来，过去 review 花大力气看的格式、命名、明显逻辑错误，现在交给 lint 和测试，人不再逐行抠。
AI 预审的位置
可以用 AI 审 AI，但定位要准：AI 预审是 reviewer 的助手，不是替代者。它适合做第一轮体力活——检查 diff 是否符合 PR 描述、找出未处理的错误分支、对比项目约定。人在 AI 预审的基础上做判断题而不是搜索题，效率能翻倍。但最终的合并决定必须由人做，因为 AI 预审和 AI 生成共享同一批盲区，同源检查查不出同源错误。
一个容易被忽略的价值
AI 时代 review 多了一层新职能：它是团队里「真正理解系统的人」的最后生产线。如果所有人都只看 AI 写、没人深读代码，半年后整个团队对系统的理解会空心化，线上事故没人接得住。所以核心模块我会刻意安排人深读 AI 的产出并复述，这不是形式主义，是在给团队留救火能力。
可能的追问
- AI 预审能完全替代人 review 吗？——不能。审查者和生成者同源则盲区同源，安全、业务正确性这些 AI 系统性弱项恰恰是 review 的核心价值，最终责任也必须落在人身上。
- 作者自己都没细读 AI 写的代码怎么办？——流程上让「讲不清设计意图」成为打回理由，制度上明确合并者全责；这两条一起，作者自然会去读自己的代码。
- 小 PR 和 AI 习惯大改矛盾怎么解？——在任务层拆解，让 AI 分阶段交付而不是一次生成全部；每个阶段独立可验证，PR 自然就小了，这也是 spec/plan/todos 工作流的价值。