两个月后，把代码审查权交给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固定： 请对以下代码变更做CodeReview，重点关注： 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的信任度出现了分歧 这是最难处理的一个变化。