用大模型做代码评审：能用的和不能用的

团队把大模型接进了 Code Review 流程，跑了一个季度，今天聊聊实测结论：它擅长什么、对什么无能为力、怎么把它嵌进流程才不添乱。

它真的能查出来的问题

• 空指针和边界条件：NPE、数组越界、空集合遍历这类机械性问题，命中率很高。人 review 时最容易疲劳漏掉的恰恰是这些
• 资源泄漏：流没关、锁没释放、连接没归还，识别得相当准
• 并发问题：共享变量没加锁、check-then-act 竞态，简单的能查出来，复杂的查不全
• 命名和坏味道：变量名和语义不符、超长函数、复制粘贴的重复代码，指出来的时候还挺委婉
• 安全和规范：SQL 拼接、密码明文、日志打印敏感字段，规则明确的东西它毫不含糊

它查不出来的

业务逻辑对不对。它不知道"下单金额为 0 时应该走免费单流程而不是报错"这种业务规则。这是最重要的盲区：代码层面完全正确，业务上完全错误，这类问题它一个都查不出来。

架构层面的取舍。该不该引入这个依赖、表结构这么设计合不合理、这个抽象会不会过度设计——需要全局上下文和承担后果的判断，AI 给的意见只能当参考清单。

需求的正确理解。它默认你写的代码就是对的，顺着你的实现看问题，而不是反过来问"这里是不是该用另一个方案"。

流程上怎么嵌才不添乱

• 定位成前置过滤，不是终审：AI 评审在提 PR 时自动跑，人工 review 前 AI 已经把低级问题清完了，人可以把注意力留给设计问题
• 分级输出：高危（潜在 bug/安全）阻塞提示，建议（命名/风格）折叠不展开。第一版所有问题平铺直叙，评论又臭又长，开发直接选择性失明
• 误报要能反馈：误报标注后进规则库，三个月后误报率从 30% 降到 10% 以下。不建反馈闭环，大家只会把它静音
• 敏感仓库私有化部署：核心代码走内部部署的模型，别为了省事把代码全喂出去

数据说话

一个季度的样本：AI 平均每个 PR 提 4.2 条意见，采纳率 55%；人工 review 的低级问题（空指针、泄漏类）同比下降了约七成，review 轮次从平均 2.3 轮降到 1.6 轮。最大的变化不是效率，是人 review 时可以聊设计，不用再当人肉 lint 工具。AI 干脏活，人干判断活，这个分工我认为是对的。