我把代码审查权交给AI两个月，团队发生了什么
两个月前，我做了一个在团队里引发争议的决定。
把Code Review的第一道关，交给AI来做。
不是完全替代人工review，而是规定：所有PR提交之前，必须先过一遍AI，把AI的review意见贴到PR描述里，再等人工review。
当时老赵听完就皱眉：
"这不是把关口往前移了，是在给大家找借口——AI说没问题，人就不认真看了。"
我没和他争。
我说，先跑两个月，看数据说话。
两个月后，我把数据整理出来，叫上团队开了一次复盘会。
会上有人沉默，有人皱眉，还有一个人说了一句让我至今没忘的话。
一、为什么要做这件事
先说背景。
我们团队5个人，每周大概有30-40个PR需要review。
以前的流程是：提PR → 指定reviewer → reviewer看完approve → 合并。
问题在于：reviewer的时间是碎片化的，很多review是"扫一眼，能跑就行"。
不是大家不认真，是认真review一个PR需要15-30分钟，每周30个PR，光review就要10-15小时，这还是在主业开发没有停下来的前提下。
所以我们的review质量，说实话，参差不齐。
有时候能发现真正的问题，更多时候是走过场。
我在想：AI review的速度是秒级的，覆盖面是系统性的，如果能把AI用作第一道筛选，让人工review更聚焦在AI发现不了的问题上，整体质量会不会更高？
于是有了这个实验。
二、怎么跑的
规则很简单，三条：
第一，提PR前强制跑AI review。
我们统一用Claude，把diff喂进去，Prompt固定：
请对以下代码变更做Code Review，重点关注：
1. 潜在bug（空指针、并发、边界条件）
2. 安全风险
3. 性能问题（N+1、大循环）
4. 业务逻辑是否合理
对每个问题说明严重程度（严重/中/低）和修改建议。
如果没有问题，直接说"未发现明显问题"。
[粘贴diff]
第二，把AI的review意见原文贴进PR描述。
不允许自己过滤，AI说什么贴什么，让人工reviewer也能看到。
第三，人工reviewer要标注哪些AI意见是对的，哪些是错的或不适用的。
这个记录后来成了最有价值的原始数据。
三、两个月后，数据说了什么
跑完两个月，我统计了几个数字。
AI发现的问题里，有多少是人工以前会漏掉的？
两个月，共209个PR，AI一共标注了各类问题344条。
人工reviewer确认：
- 有效问题：214条（62%）
- 误判或不适用：130条（38%）
214条有效问题里，我们做了一个额外统计：如果没有AI，这条问题人工review会不会发现？
结论是：214条里，约有60条（28%）是人工大概率会漏掉的。
60条听起来不多，但平摊到209个PR上，相当于每3-4个PR里，AI帮我们发现了1个人工会漏掉的真实问题。
其中有2条是安全风险，1条是并发场景下的幂等性缺失，这三条如果上线，轻则功能异常，重则资损。
这是让我觉得这件事值得继续做的数据。
但数据的另一面，同样需要正视。
四、我们踩的坑
坑1：AI review变成了"免责牌"
第三周的时候，我发现了一个苗头。
小林提了一个PR，AI review结论是"未发现明显问题"。
人工reviewer老赵看了一眼，approve了，备注：
"AI过了，应该没问题。"
但那个PR里有一段逻辑我自己看的时候起了疑心，翻了一下需求文档，发现有一个业务规则没有处理。
不是bug，是漏了一个需求点。
AI发现不了，因为AI不知道需求文档说了什么。
老赵如果认真看，大概率能发现。但他没有认真看，因为AI说没问题了。
这是最让我担心的信号：AI的"通过"，开始成为人放松注意力的理由。
我把这件事在群里说了，定了一条规则：AI review结论不影响人工review的责任。AI说没问题，人照样要认真看。
之后这个问题有所改善，但没有完全消失。
坑2：有人开始懒得自己想
第五周，我在做一次普通的人工review，发现了一个有意思的现象。
那个PR的代码，有一段处理逻辑，结构上有点奇怪，绕了一个弯。
我问提交者：这里为什么这么写？
他说：AI建议这样写的，我觉得能跑就提了。
我继续问：你自己觉得这样合理吗？
他沉默了几秒，说：我没仔细想。
这不是孤立案例。后来我留意了一下，发现部分PR里，代码的"AI痕迹"越来越明显——结构是AI推荐的，注释是AI生成的，连变量命名风格都在向AI靠拢。
不是说AI的风格不好。
是因为提交者自己的判断越来越少出现在代码里了。
坑3：团队对AI的信任度出现了分歧
这是最难处理的一个变化。
老赵从一开始就不信任AI review。他会逐条反驳AI的意见，有时候反驳是对的，有时候只是本能抵触。
小林恰恰相反，她对AI的结论基本照单全收，偶尔AI建议加缓存，她不管场景合不合适，直接加了。
这两种极端，都带来了问题。
完全不信任：AI发现的那60条漏网之鱼，他review的PR里大概率还是会漏。
完全信任：引入了几次不必要的复杂度，有一次加了个Caffeine缓存，结果那个接口本身就是低频调用，完全不需要缓存。
团队里对"AI review的意见到底几分可信"，一直没有形成共识。
五、最让我没想到的一个变化
复盘会上，我让大家说说这两个月最真实的感受。
老王说了一句让全场安静的话：
"我发现我自己review代码的能力好像在退化。"
他解释：以前每次review，他会从头到尾把逻辑在脑子里过一遍，自己找问题。
现在的习惯变成了：先看AI发现了什么，然后判断AI说的对不对。
从"主动发现问题"，变成了"评判别人发现的问题"。
这是两种完全不同的思维模式。
前者需要你自己构建完整的心智模型，后者只需要你判断对错。
长期下去，主动发现问题的能力会不会真的萎缩？
老王说他不确定，但他感觉到了。
这句话让我沉默了很久。
六、两个月后，我们怎么做的
复盘完，我们调整了规则，不是停掉AI review，而是加了两条约束：
第一，每人每周至少有2个PR，必须先独立做完人工review，再看AI的结论，做对比。
目的是强制保持"主动发现"的肌肉，不让它萎缩。
第二，AI review意见分三类处理：
严重问题 → 人工必须确认，不能跳过
中等问题 → 人工判断是否适用，要留理由
低级问题 → 可以忽略，但要在PR里说明原因
这个分类，是为了让人保持判断，而不是被AI的清单牵着走。
目前新规则跑了两周，感觉比之前更健康一些。
七、写在最后
两个月跑下来，我的结论是：
AI做Code Review，有真实的价值——那60条人工会漏掉的问题，是AI给我们兜的底。
但它带来的副作用，也是真实的——有人开始不自己思考，有人感觉能力在退化，团队共识在分裂。
这不是AI的问题，是使用方式的问题。
一个工具越好用，越容易让人停止锻炼被它替代的那块肌肉。
计算器让人不再心算，导航让人不再记路，AI review会不会让人不再主动思考代码？
我不知道答案。
但我知道一件事：失去的东西，往往是在你没有察觉的时候悄悄消失的。
你们团队有没有用AI做Code Review？你觉得这件事该怎么做，才能拿到好处，又不丢掉重要的东西？
欢迎评论区聊聊。
后端AI实验室 不讲概念，只谈实战 代码开源，每周更新
