用 AI 做代码审查：能查出什么，查不出什么

AI 做 code review 最大的价值不是「代替人」，而是把人的注意力从低价值检查里解放出来，集中在设计和业务上。

它稳定能查出的四类

这四类问题它漏得很少，值得每次都过一遍：

• 空指针、越界、资源未释放这类机械缺陷。
• 异常处理缺失或吞掉异常。
• 命名与风格不一致、重复代码。
• 明显的性能问题：循环里查数据库、N+1 查询、无谓的全表扫描。

它基本查不出的

这些必须人来判断，别指望它：

• 业务逻辑是否符合需求——它不知道需求。
• 架构设计是否合理——它只看局部，没有全局上下文。
• 这段代码该不该存在——很多问题是设计层面的，不是实现层面的。
• 历史包袱：它会把「刻意保留的兼容代码」当成冗余建议删掉。

怎么问才有效果

别问「这段代码有什么问题」，太宽泛，它会给你一堆泛泛而谈。

分角度问：「只看并发安全」「只看异常分支」「只看性能」。一次一个角度，命中率高得多。

再补一句「每个问题给出行号和修复建议」，能过滤废话。

放进流程的正确姿势

提 PR 前自己跑一次 AI 审查，把机械问题清掉，再让人看——这样人的 review 时间能省一半。

别把它设成「通过才能合并」的硬门槛。它会有误报，也会给不切实际的建议，最终判断权必须在人手里。