CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
代码审查入门/课时/AI 辅助审查
RawBlame
课时目录12 节

代码审查入门

  1. 01API 语义审查
  2. 02实现语义
  3. 03文档审查
  4. 04测试审查
  5. 05代码风格
  6. 06Review 流程
  7. 07审查清单
  8. 08安全审查
  9. 09AI 辅助审查
  10. 10反馈技巧
  11. 11团队实践
  12. 12综合练习

AI 辅助审查

静态分析与 Bot。

25 分钟

AI 辅助审查

这一课你将能做到

  1. 在 CI 中接入 AI Code Review 工具(CodeRabbit、Bugbot 类),并配置合理的触发规则
  2. 判断 AI 审查结果哪些可信、哪些是误报,避免「AI 说什么就是什么」
  3. 设计「AI 预审 + 人工终审」的分工,让人专注在 AI 做不了的判断上

为什么要学

AI Code Review 工具(GitHub Copilot、CodeRabbit、Codex、Bugbot 等)已经能稳定抓出空指针、未关闭资源、常见 API 误用。但它们不会理解业务语义,也会一本正经地胡说八道。把 AI 当「永不疲倦的初级 reviewer」,而不是「绝对权威」。

人话:AI 负责 24 小时盯梢抓低级错误,人负责拍板设计和业务判断。

先建立图像

AI 辅助审查的分工模型

                ┌──────────────────┐
   PR 提交  →  │  AI 预审(秒级)   │
                │  - Lint 规则外问题 │
                │  - 常见 bug 模式   │
                │  - 安全漏洞模式    │
                │  - 性能反模式      │
                └────────┬─────────┘
                         │
              ┌──────────┴──────────┐
              │                     │
         低风险自动修复        高风险/不确定 → 人工
         (代码风格、          (设计、业务逻辑、
          导入优化等)          边界条件、架构决策)
              │                     │
              └──────────┬──────────┘
                         │
                    合并 / 打回

AI 擅长:模式匹配、规则执行、海量代码比对
AI 不擅长:业务语义、设计权衡、团队上下文

跟着做

步骤 1:接入 AI Review 工具

以 CodeRabbit 为例(GitHub App,免费版够用):

# .github/workflows/ai-review.yml(可选,CodeRabbit 本身有 App)
# 更常见的是安装 GitHub App 后自动触发

.coderabbit.yaml 配置:

reviews:
  profile: chill              # 宽松模式,只报高置信度问题
  request_changes_workflow: true   # 严重问题直接 request changes

  path_filters:
    - "!**/*.md"              # 不审 markdown
    - "!**/generated/**"      # 不审生成代码
    - "!**/*_test.go"         # 不审测试文件(或改为宽松模式)

  instructions: |
    这是 Spring Boot + MySQL + Redis + Next.js 项目。
    请关注:
    1. 空指针风险(特别是 MyBatis 返回值未判 null)
    2. SQL 注入风险(${} 占位符)
    3. 事务内是否有网络调用
    4. 并发安全问题(共享可变状态)
    不要关注:代码风格(已有 Checkstyle)、格式化问题

步骤 2:判断 AI 结果的可信度

❌ 反例:盲目采纳 AI 建议

// AI 提示:「建议使用 Optional 避免 null」
public Optional<Course> findById(Long id) {
    return Optional.ofNullable(courseMapper.selectById(id));
}

// 你照做了,但调用方全都要改
Course course = courseService.findById(id).get();   // 更糟了,get() 无 isPresent 检查

✅ 正例:结合上下文判断

// AI 建议合理,但只在「确实可能不存在」的场景采纳
public Optional<Course> findById(Long id) {
    return Optional.ofNullable(courseMapper.selectById(id));
}

// 调用方正确处理
Course course = courseService.findById(id)
        .orElseThrow(() -> new BizException(ErrorCode.COURSE_NOT_FOUND));

判断标准:

AI 建议类型可信度处理方式
明确的空指针 / 资源泄露高直接采纳
已知安全漏洞模式高直接采纳
性能优化建议中结合 benchmark 判断
设计模式建议低结合业务上下文,可能过度设计
「更优雅」的写法低看是否符合团队风格,不强制

步骤 3:用 AI 做「审查助手」而非「替代者」

❌ 反例:AI 审过就直接合并

PR → AI 通过(无评论)→ 直接合并 → 线上出问题

✅ 正例:AI 预审 + 人工重点审

PR 提交
  ├─ AI 自动扫描 → 发现 2 个空指针风险 + 1 个未关闭的 Stream
  ├─ 作者修复 AI 发现的问题
  ├─ 人工 review(专注在):
  │    - 业务逻辑是否正确
  │    - API 设计是否合理
  │    - 事务边界是否合适
  │    - 并发场景是否考虑
  └─ 合并

人工省下来的时间,应该花在 AI 做不了的事上:业务语义、架构决策、长期维护性。

步骤 4:避免「AI 疲劳」

❌ 反例:AI 报 20 条评论,作者崩溃

AI 输出:
1. 建议使用 try-with-resources
2. 变量名可以更具描述性
3. 这个方法可以拆成两个
4. 建议添加缓存
5. 建议使用 Optional
...
20. 建议添加日志

作者反应:全部忽略。

✅ 正例:配置 AI 只报高优先级问题

# .coderabbit.yaml
reviews:
  profile: chill          # 只报严重问题
  high_level_summary: false   # 不要长篇总结

  # 按路径设置不同严格度
  path_instructions:
    - path: "src/main/java/com/example/payment/**"
      instructions: |
        支付模块,严格审查:
        - 事务边界
        - 并发安全
        - 金额计算精度(BigDecimal vs double)
        - 幂等性

    - path: "src/main/java/com/example/common/util/**"
      instructions: |
        工具类,宽松审查:
        - 只看明显 bug,不看设计

步骤 5:用 AI 生成 Review 上下文

AI 不只是找问题,还可以帮 reviewer 快速理解 PR:

CodeRabbit 自动生成的 PR 摘要:
- 本次 PR 修改了课程发布流程
- 新增发布前的讲师资质校验
- 将课程状态从 DRAFT 改为 PUBLISHED
- 触发 ES 索引更新(异步)
- 新增 3 个单元测试覆盖正常发布路径

⚠️  注意:PR 中未看到「发布失败时状态回滚」的逻辑,
    建议人工确认失败场景的处理。

Reviewer 看到这段,30 秒内就能抓住重点,不用从 500 行 diff 里自己梳理。

讲清楚要点

  1. AI 是「永不疲倦的初级 reviewer」:它 24 小时在线、不会漏看、不会疲惫,但判断力停留在「模式匹配」层面。把它当年假不休的实习生,而不是架构师。
  2. 配置比工具重要:AI 工具的默认配置通常太啰嗦(报太多低优先级问题)。花 10 分钟配置「只报高置信度问题」,比换工具更有效。
  3. AI 预审 + 人工终审是黄金组合:AI 过滤掉低级错误,人专注在业务、设计、架构。两者不是替代关系,是分工关系。
  4. 警惕 AI 的「权威幻觉」:AI 说话永远自信,哪怕它在胡说。对 AI 的每条建议都要问「在我的上下文里成立吗」。
  5. AI 生成的摘要很有价值:帮 reviewer 快速理解 PR 意图,比逐行读 diff 高效得多。

你可能会懵的地方

  • AI Review 会不会取代人工 Review? 短期内不会。AI 擅长「模式匹配已知问题」,不擅长「理解业务意图」「权衡设计取舍」「判断团队上下文」。它会把人工 review 从「找 bug」解放到「看设计」,但最后一公里永远是人。

  • AI 报了问题但我不认同,怎么办? 直接忽略。AI 不会生气。但如果同一个问题被 AI 报了三次,值得停下来想想「是不是我真的没考虑到」。

  • AI 建议和团队规范冲突怎么办? 团队规范优先。AI 不知道你的团队历史、技术债、业务约束。它给的是「通用最佳实践」,你要的是「当前上下文最优解」。

  • AI Review 会不会泄露代码? 会,如果用的是云端服务(CodeRabbit、Copilot)。敏感代码用本地部署的方案(如 Ollama + 本地 LLM),或者审查前脱敏。金融、政务类项目尤其注意。

  • AI 能审出所有 bug 吗? 不能。AI 擅长「已知模式的已知问题」,对「业务逻辑错误」「新型攻击手法」「特定上下文下的并发问题」无能为力。它能把 bug 率从 10% 降到 2%,但不能降到 0%。

错法对照

错法问题正解
AI 说什么就改什么引入过度设计、破坏一致性结合上下文判断
AI 报 20 条评论全忽略AI 疲劳,失去价值配置只报高优先级
AI 通过就直接合并漏掉业务/设计问题AI 预审 + 人工终审
用云端 AI 审敏感代码代码泄露风险本地部署或脱敏
指望 AI 审出所有 bug过度依赖AI 降 bug 率,不降为零

卡点急救

  1. AI 评论太多没人看:调整配置为 chill 模式或 request_changes_only: true,只保留「必须修复」级别的问题。

  2. AI 建议和业务冲突:在 AI 配置里加 instructions 说明项目上下文(「这是支付系统,金额计算必须用 BigDecimal」),减少误报。

  3. AI 突然不工作了:检查 GitHub App 权限是否过期、仓库是否在 AI 服务的覆盖范围内、配置文件语法是否有误(YAML 缩进错误常见)。

面试常问

  • 你怎么看 AI Code Review 工具? 把它定位为「永不疲倦的初级 reviewer」。价值在于:① 7x24 在线,不会疲惫漏看;② 模式匹配能力强,已知 bug 抓得准;③ 生成 PR 摘要帮 reviewer 快速进入状态。局限在于:不懂业务语义、会过度设计、对新型问题无能为力。最佳实践是「AI 预审抓低级错误 + 人工终审看设计和业务」。

  • AI Review 会不会让 reviewer 变懒? 会,这是真实风险。对策:① 明确分工——AI 管「是否有 bug」,人管「设计是否合理」;② 保留人工 approve 作为合并必要条件;③ 定期抽查「AI 通过但人工发现问题」的 case,保持人对代码的敏感度。

  • 怎么评估一个 AI Review 工具好不好? 三个指标:① 误报率(报的问题有多少是真的);② 漏报率(真实问题有多少没报);③ 上下文理解能力(能不能理解你的项目特定规则)。试用时在真实 PR 上跑一周,统计这三个指标再决定。

自测三问

  1. AI Review 和人工 Review 的分工边界应该划在哪里?
  2. 为什么 AI 的「设计模式建议」通常要谨慎采纳?
  3. 配置 AI Review 工具时,最重要的一个原则是什么?

小结一句话

AI 辅助审查的核心是「分工」——AI 负责永不疲倦地抓模式化问题,人负责拍板业务语义和设计权衡,两者结合才能把 review 做到极致。

延伸

  • CodeRabbit 文档
  • GitHub Copilot Code Review
  • 《Accelerate》(Nicole Forsgren)—— 关于工程效能与自动化
  • 下一课:反馈技巧——建设性评论。
加载本节练习…
← 上一课安全审查下一课 →反馈技巧