跳到主要内容

AI 代码审查

“AI 代码审查”这题如果只答“让大模型帮我看 PR”，通常太轻。更完整的理解是：把大模型接入代码评审流程，让它承担一部分模式识别、风险提示和文档化工作，但最终质量责任仍然由人和自动化基线共同承担。

0. 面试速答（30 秒版 TL;DR）​

  • AI 代码审查最适合做的是：快速扫风险、补充 reviewer 盲区、提高首轮反馈速度。
  • 它擅长发现：
    • 明显 bug 风险
    • 边界条件遗漏
    • 重复逻辑和可维护性问题
    • 测试缺口
  • 它不适合单独承担：
    • 业务正确性的最终裁定
    • 安全合规的最终签发
    • 架构方向的最终决策
  • 更稳的落地方式是：静态检查 / 测试 / 人类 Review / AI Review 组合使用，而不是“拿 AI 替代 reviewer”。

1. AI 代码审查到底在解决什么问题？​

代码评审里常见的现实问题是：

  • Reviewer 时间有限
  • PR 太大时很难完整覆盖
  • 初级 reviewer 不敢指出高阶问题
  • 同类低级问题反复出现
  • 文档、测试、边界条件经常漏

AI 在这里的价值，不是替代人“做判断”，而是先把这些问题更快暴露出来：

  • 哪些改动存在明显风险
  • 哪些文件可能需要补测
  • 哪些注释、命名、接口约束不清楚
  • 哪些改动和历史模式不一致

2. 一条更现实的落地链路​

这条链路表达了一个关键原则：

  • AI Review 适合做前置筛查和辅助分析，不适合独立做最终批准。

3. AI 代码审查最擅长什么？​

3.1 扫常见 bug 模式​

例如：

  • 空值处理遗漏
  • 异步错误未捕获
  • 并发更新条件竞争
  • 状态清理缺失
  • 资源释放遗漏

这类问题的共同点是：

  • 模式化强
  • 局部代码就能看出端倪
  • 容易被人眼漏掉

3.2 补充“测试视角”​

AI 很适合做这类提醒：

  • 改了核心分支逻辑，但没看到测试更新
  • 增加了异常分支，却只测了 happy path
  • 新增参数组合很多，但没覆盖边界值

它不一定能替你写出高质量测试，但很擅长提醒“这里应该有测试”。

3.3 帮你压缩 reviewer 的认知成本​

比如：

  • 总结这个 PR 改了什么
  • 哪些文件是核心风险点
  • 哪些变更只是重构，哪些变更会改行为

当 PR 很大时，这种“先帮人建立地图”的能力很有价值。

4. AI 不擅长什么？​

4.1 不擅长掌握完整业务上下文​

很多线上风险并不是代码写法错，而是：

  • 不符合当前业务规则
  • 和历史兼容策略冲突
  • 和某个灰度方案、租户策略、安全规则不一致

这些往往不是看 diff 就能完全判断的。

4.2 不擅长承担最终责任​

即使 AI 给出建议很靠谱，也不要把“Approve”交给它。原因很简单：

  • 它的判断是概率性的
  • 它可能漏掉关键问题
  • 它可能把风格问题误判成高风险

所以更稳的治理方式是：

  • AI 可以评论
  • AI 可以标风险
  • AI 不直接替代代码所有者和 reviewer 的责任

4.3 不擅长处理超大上下文和隐性约束​

例如：

  • 这个服务只能在某个租户模式下运行
  • 某字段虽然没标注，但必须保证幂等
  • 某个接口改动会影响移动端旧版本

这类隐性知识往往需要人类 reviewer 补位。

5. 落地时怎么设计，效果差异很大​

5.1 不要只把整个 diff 生喂给模型​

更稳的做法是给 AI 足够上下文，例如：

  • 本次 PR 描述
  • 变更文件列表
  • 关键模块说明
  • 测试结果
  • reviewer 希望重点看什么

如果上下文组织得差，AI 审查就容易变成泛泛而谈。

5.2 提示词要让它“找风险”，不是“夸代码”​

差的 prompt 常常会得到这种输出：

  • 代码整体不错
  • 建议增加注释
  • 建议注意可维护性

这类话没有审查价值。

更有效的提示方向通常是：

  • 优先找行为回归风险
  • 优先找 bug 和边界条件
  • 指出缺少哪些测试
  • 如果证据不够，不要编造问题

5.3 要求输出带证据的结论​

例如：

  • 文件路径
  • 代码位置
  • 风险原因
  • 可能后果
  • 建议修法

这样 reviewer 才能快速确认，而不是再自己重新猜一遍。

6. 一套更稳的工程方案​

如果面试官问“你会怎么落地”，可以按下面说：

第一步：先用静态基线过滤低级问题​

把这些放在 AI 前面：

  • lint
  • typecheck
  • 单元测试
  • 安全扫描
  • 覆盖率阈值

因为规则型问题不该浪费 AI 预算。

第二步：AI 专注看“规则难覆盖”的问题​

例如：

  • 逻辑一致性
  • 边界条件
  • 测试遗漏
  • 架构异味

第三步：控制输入规模​

常见做法：

  • PR 太大时只看高风险目录
  • 按文件类型用不同提示词
  • 先做 PR 摘要，再做重点文件深审

第四步：人类 reviewer 做最终裁决​

AI 的评论是输入，不是结论。

7. 一个高质量 AI Review 输出应该长什么样？​

不是“建议优化命名”这种泛建议，而应该更像：

  1. 这里的缓存 key 缺少租户维度，可能导致串数据。
  2. 这里把异步任务改成并发后，没有看到错误回滚逻辑，可能部分成功部分失败。
  3. 这里新增了状态分支，但测试只覆盖了原有两种状态，没有覆盖新分支。

这类输出的共同点是：

  • 明确指出风险
  • 给出依据
  • 能帮助 reviewer 做判断

8. AI 代码审查常见落地模式​

8.1 PR Bot 评论​

最常见，优点是接入简单。

适合：

  • GitHub / GitLab PR 工作流
  • 团队先试点

8.2 本地预审​

开发者在发 PR 前先跑一次 AI Review。

优点：

  • 问题更早暴露
  • 降低 PR 往返成本

缺点：

  • 开发者未必持续执行
  • 需要和本地 IDE / CLI 集成

8.3 CI 门禁增强​

不是让 AI 直接卡死 PR，而是让它参与风险分层：

  • 低风险：只评论
  • 中风险：要求 reviewer 关注
  • 高风险：要求补测试或补说明

这比“AI 一票否决”更稳。

9. 面试高频题与标准答法​

9.1 AI 代码审查能替代人类 Review 吗？​

标准答法：

不能。AI 更适合做辅助审查和首轮筛查，能提高反馈速度、补充 reviewer 盲区，但对业务上下文、隐性约束和最终责任承担仍然需要人类 reviewer。

9.2 AI 代码审查最适合检查什么？​

标准答法：

最适合检查模式化较强、证据主要在代码局部可见的问题，比如明显 bug 风险、边界条件遗漏、测试缺口、重复逻辑和可维护性问题。

9.3 怎么避免 AI Review 变成“正确的废话”？​

标准答法：

要给足上下文，并把提示词聚焦到风险识别、测试缺口和行为回归，而不是让它泛泛评价代码质量。同时要求它输出带文件路径和理由的结论，减少空话。

10. 常见坑​

  • 把 AI 当审批者 风险很大，责任边界会失控。
  • 不给上下文，只喂 diff 容易得到低质量评论。
  • 把规则型问题也交给 AI 成本高，而且不稳定。
  • PR 太大还全量审 模型容易泛化、遗漏关键点。
  • 没有反馈闭环 AI 一直报无效问题，团队很快就会弃用。

11. 速记要点（可背）​

  • AI Review 价值 = 提速 + 补盲区 + 提醒测试缺口
  • 最适合 = 模式化风险识别
  • 不替代 = 人类最终审批
  • 最稳方案 = 规则检查 + AI Review + 人审 组合
  • 关键不是“接没接 AI”，而是上下文和流程设计是否合理