让 AI 帮我做代码评审之后，我总结了三个它最容易放过的坑

上周一个 MR 提了 800 多行，我 review 到半夜眼冒金星，干脆先让 AI 过一遍。它 30 秒甩出 20 条意见，我心想这波稳了，扫了两眼就合。结果合并后第三天，线上出一个并发问题——那个文件，AI 刚刚"看过"，一条相关的意见都没提。

从那以后我没敢再把 AI 的评审意见当放行依据。它确实能筛掉一部分问题，但有三类坑它最容易放过，不注意就是把 review 关白送出去。

第一个坑：只盯风格，真正的逻辑错它秒过。 那 20 条意见里，17 条是命名不规范、空行、import 顺序这类 style 问题，剩下 3 条是无关紧要的小建议。而真正会炸的那个问题——同一个配置对象被两个线程共享修改——它一个字没提。AI 对"能写进规范文档的问题"很敏感，对"符合语法但语义错了"的问题经常视而不见。

第二个坑：它不知道这个改动会碰到什么。 人工 review 的价值一半在脑子里的项目上下文：这个函数还有三个老调用方、上游服务上周刚改过协议、这个配置下周三要下线。AI 只看到这个 MR 的 diff，看不到这些。它说"没问题"，意思是"这段 diff 自身没问题"，而不是"合进去不会出事"。这两句话差着十万八千里。

第三个坑：没检查的地方也敢说"未发现问题"。 我复盘过两次事故 MR 的 AI 评审记录，两次都写着"逻辑清晰，建议合入"。人对不确定的地方会说"这块我没细看"，AI 不会——它的输出里没有"存疑"这个档位，通篇都是同样笃定的语气。危险就在这：你分不清哪条是它真看过的，哪条是它扫都没扫。

我的判断很明确：AI 当第一遍筛子没问题，放行权不能交。我现在的用法是 AI 先筛风格和显性错误，省掉我一小时；然后逻辑正确性、向后兼容、边界条件必须自己过一遍。这个我建议先收藏，回头给团队的 review 流程定规矩时能直接用上。

你们团队现在让 AI 过 MR 了吗？我更想聊一个具体的：你们敢让 AI 的意见直接算"通过"吗，还是只当参考？我反正只敢当参考。