别让 AI 的 LGTM 成为合并理由，自动化代码评审正在毁掉团队质量

公司强推 AI 自动化 Code Review（CR），原本是想借助工具提升效率，但实际运行一段时间后，我发现这种做法更像是在给项目埋雷。真正让人不安的并不是 AI 能力不足，而是团队成员在潜意识里产生了危险的心理依赖：只要 AI 在评论区刷出「LGTM（Looks Good To Me）」，不少同事就直接点击 Merge，完全跳过了对核心业务逻辑的深入思考。

AI 擅长形式审查却不懂业务上下文

这种所谓的「效率提升」，本质上是一种伪命题。AI 确实能够以秒级速度扫描代码，但它目前的能力边界十分明显：它更擅长「形式主义」的审查，却无法感知「业务上下文」。

上周，我们团队就踩了一个巨大的坑。一个涉及高并发处理的接口修改，AI 在 CR 时不仅没有报出任何错误，甚至还在评论区夸奖代码写得「简洁优雅」。结果代码一上线，直接触发了潜在的并发死锁问题，导致生产环境服务大面积崩溃。事后复盘代码才发现，AI 根本不理解这个接口在底层数据库锁机制上的深层耦合。它只看到了代码语法正确、结构清晰，却完全没有意识到逻辑上已经走进死胡同。

从实际操作来看，AI CR 带来的痛点主要集中在三个方面，团队可以对照检查一下，自己是否也陷入了同样的陷阱。

盲目信任导致人工评审流于形式

一方面，盲目信任会让评审逐渐形式化。当 AI 成为评审的第一环节，并且自带某种「权威感」时，人工评审就容易退化成走过场。开发者会下意识地认为：「既然 AI 没说有问题，那大概率就是没问题。」这样一来，原本应该通过 CR 发现的架构缺陷和逻辑漏洞，就可能被直接带入生产环境。

另一方面，噪音干扰会变得越来越严重。AI 经常在一些无关痛痒的细节上表现得非常啰嗦，比如建议把某个变量名改得更符合某种冷门规范，或者提醒某处少了一个空行。当一个 PR 下面挂满几十条「建议优化结构」的无效建议时，真正关键的逻辑漏洞反而被淹没在噪音之中。评审者刷完这些琐碎建议后，往往会产生一种「我已经尽力 Review 了」的错觉，进而忽略更深层的 Bug。

缺乏上下文导致建议理论正确但不可行

更致命的是上下文的缺失。目前的 AI CR 工具大多只能看到当前的 Diff（差异文件），并不了解这个接口为什么必须采用这样的设计，也不知道这次改动是为了兼容三年前的某个老版本 Bug。因此，它经常给出一些「理论正确但实际不可行」的建议，导致开发者在修正这些建议的过程中，反而引入新的兼容性问题。

重新定义 AI 为初筛员而非决策者

为了止损，必须重新定义 AI 在研发链路中的定位：它应该是「初筛员」，绝对不能成为「决策者」。

更稳妥的工作流应该是：由 AI 运行静态扫描，过滤低级的语法错误、拼写问题和基础格式违规；开发者再根据 AI 的初筛建议快速自检并完成修正；最后，也是最关键的一步，必须由一名人类工程师进行逻辑层面的最终 Review。流程上还必须设置一条硬性规定：未经人工确认，禁止直接合并。

说到底，工具的本质是辅助。如果为了追求账面上那点「交付速度」的提升，而放弃对代码质量的最终掌控，那么后期花在修 Bug 和处理线上事故上的时间，绝对会远超手动 CR 所节省的时间。