AI 辅助审查
这一课你将能做到
- 在 CI 中接入 AI Code Review 工具(CodeRabbit、Bugbot 类),并配置合理的触发规则
- 判断 AI 审查结果哪些可信、哪些是误报,避免「AI 说什么就是什么」
- 设计「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 做「审查助手」而非「替代者」
PR → AI 通过(无评论)→ 直接合并 → 线上出问题
PR 提交
├─ AI 自动扫描 → 发现 2 个空指针风险 + 1 个未关闭的 Stream
├─ 作者修复 AI 发现的问题
├─ 人工 review(专注在):
│ - 业务逻辑是否正确
│ - API 设计是否合理
│ - 事务边界是否合适
│ - 并发场景是否考虑
└─ 合并
人工省下来的时间,应该花在 AI 做不了的事上:业务语义、架构决策、长期维护性。
步骤 4:避免「AI 疲劳」
AI 输出:
1. 建议使用 try-with-resources
2. 变量名可以更具描述性
3. 这个方法可以拆成两个
4. 建议添加缓存
5. 建议使用 Optional
...
20. 建议添加日志
# .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 里自己梳理。
讲清楚要点
- AI 是「永不疲倦的初级 reviewer」:它 24 小时在线、不会漏看、不会疲惫,但判断力停留在「模式匹配」层面。把它当年假不休的实习生,而不是架构师。
- 配置比工具重要:AI 工具的默认配置通常太啰嗦(报太多低优先级问题)。花 10 分钟配置「只报高置信度问题」,比换工具更有效。
- AI 预审 + 人工终审是黄金组合:AI 过滤掉低级错误,人专注在业务、设计、架构。两者不是替代关系,是分工关系。
- 警惕 AI 的「权威幻觉」:AI 说话永远自信,哪怕它在胡说。对 AI 的每条建议都要问「在我的上下文里成立吗」。
- 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 率,不降为零 |
卡点急救
-
AI 评论太多没人看:调整配置为 chill 模式或 request_changes_only: true,只保留「必须修复」级别的问题。
-
AI 建议和业务冲突:在 AI 配置里加 instructions 说明项目上下文(「这是支付系统,金额计算必须用 BigDecimal」),减少误报。
-
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 上跑一周,统计这三个指标再决定。
自测三问
- AI Review 和人工 Review 的分工边界应该划在哪里?
- 为什么 AI 的「设计模式建议」通常要谨慎采纳?
- 配置 AI Review 工具时,最重要的一个原则是什么?
小结一句话
AI 辅助审查的核心是「分工」——AI 负责永不疲倦地抓模式化问题,人负责拍板业务语义和设计权衡,两者结合才能把 review 做到极致。
延伸