给团队搭了个AI Code Review助手,上线第一天就被PR淹没了

前阵子团队PR越来越多了。不是大家写得多了——是写得快了之后，Review跟不上了。

一个PR等两个小时才有人看，第二天想合的时候发现同事凌晨两点留了评论。这种节奏持续了大概两周，我决定搞个AI Code Review助手。

不指望AI能替代人工Review——谁都不敢这么说——但至少能在我点开PR之前，先把一眼能看出来的问题筛一遍。逻辑错误、空指针、变量命名不一致、测试覆盖率没达标——这些事情AI做得到。

然后就开始了踩坑之旅。

第一坑：LLM做Code Review，慢到没人愿意等

第一个版本最简单：给PR diff接了个LLM，每次PR提交的时候自动跑一遍，然后把评论贴回PR。

想法很美好。实际上线第一天就崩了。

一个200行不到的PR diff，等LLM出结果要45秒。Reviewer点开PR的时候，AI评论还没生成完。没人愿意等。更离谱的是，如果同时提交3个PR，队列直接卡死。

当时我在想：是我选错了模型，还是思路错了？

后来发现思路才是问题——不应该让LLM从头到尾读diff，应该先做静态分析。

回头看第一个版本，LLM干的大部分活其实是ESLint、PyLint、Go vet已经能干的。

变量没用到？PyLint告诉你。缺少空指针检查？静态分析能标记大概率路径。常量命名不是大写？公司lint规则早写了。

我犯的错误是：AI Agent能做 = 应该让AI做。

实际上应该反过来：静态分析能干的，绝对不要用LLM。LLM的定位应该是「静态分析筛完之后，剩下的那些需要理解业务逻辑才能判断的问题」。

改了架构之后，流程变成这样：

这样一改，95%的PR在静态分析阶段就处理完了，只有真正需要业务理解的case才走LLM。整个系统的响应时间从45秒降到了8秒左右。

改完架构后跑了两周，效果还行。但很快发现新的问题：当PR diff超过500行的时候，Agent开始胡说八道了——评论一些跟代码完全不相关的问题，有时候还说「这段代码有安全漏洞」但根本说不清楚漏洞在哪。

问题不在模型，在diff怎么传。

一个PR的diff可能涉及5个文件，每个文件改动量不同。以前是一股脑全塞给LLM——把整个diff当一大段文本传进去。模型读到后面就忘了前面。

后来改成了结构化分段：按文件拆成小块，每块的context只包含这个文件的修改+周围三行未改代码。文件之间用「这是一个新文件」的分隔符隔开。每个文件独立分析，最后汇总。

效果立竿见影。不相关评论从平均每PR 3.2条降到0.4条。

最后一步是把整个系统接成了MCP工具链——代码审查作为一个MCP server暴露给Agent调用，CI触发后调这个server。

MCP化了之后最爽的是可插拔——今天想换一个审查模型，改一行配置就行，不用改管道。想加一个安全检查模块（比如检查依赖版本），加一个MCP tool就行。

但新问题来了：Agent自己写的评论怎么保证质量？

我们遇到过Agent说「这个函数缺少异常处理」，但实际上外层有try-catch只是不在diff范围内。也遇到过Agent完全误解了代码逻辑，给了一个错的修改建议。

后来加了一个信心分机制：Agent对每条评论标一个confidence score（1-5）。5分的直接贴评论，3-4分的进入二次验证（同一个Agent但用不同system prompt再跑一次看看结论是否一致），1-2分的直接丢弃。

上线一个月的数据：

18%的误报率听起来不低，但实际感受还好——因为Reviewer看到AI评论后的心态是「我来验证一下」，而不是「我要从头开始」。心态变了，效率就变了。

如果你也在想搞AI Code Review，我的建议很简单：先让静态分析跑通，再让LLM做剩下的事。工具链的部分，MCP确实是目前最好的选择——不是因为新，是因为它让换模型、加模块这种事变成配置问题，不是工程问题。

上周刚聊了🔗AI应用开发最大的坑，不是模型选错了，是架构做重了^[1]，今天这个踩坑经历其实是同一个结论的不同印证——架构做对之前，工具选再好也没用。

AI Code Review也是一样。不是AI不行，是你的管道先得对。

[1]🔗AI应用开发最大的坑，不是模型选错了，是架构做重了: https://mp.weixin.qq.com/s/VfUSDn1ckys2QBqeAXYY7A