基于大模型 + 知识库的 Code Review 实践

听我说完这个故事。

那天我正盯着两段代码发愁——A写法三行搞定但读起来像天书，B写法啰里八嗦但一眼就懂人话。顺手把两段都丢给Claude，随口问了一句：“哪个更好？”

你猜怎么着？它不光分析了我脑袋里纠结的点，还揪出一个我完全没看到的边界情况。那一瞬间我冒出一个念头：这家伙，也许能帮我扛活儿？

下班路上越想越兴奋，到家就打开电脑开始干了。

你绝对想不到，第一个坑差点把我劝退

公司代码直接扔给ChatGPT？你当我是三星啊？他们引入ChatGPT后，不到20天就出了好几起机密泄露的情况。这种锅，谁背得起？

要想安全就得先脱敏——把具体业务逻辑抽象成天书一样的描述。我试了一次，写描述花了我半个多小时，回头一看：还不如我自己Review来得快。

但真正让我铁了心要搞点事的，是另一幕。

我们团队每天要审10到20个MR。单元测试和Lint已经干掉了明显低级的错（缩进不对、变量没用到），但剩下的那些——代码写得合不合理、业务逻辑对不对、这个MR动到的东西会不会牵连其他地方——全都得人肉扛。忙起来你懂的，眼睛扫一眼就点了Approve，上线出事了才拍大腿。

更气的是，团队不是没写规范。飞书文档几十页，写得清清楚楚。可谁审的时候真去翻那玩意儿？今天张三review说这么写，明天李四review说那么写，全凭心情和习惯。

说白了，得有人兜底，而且是每次都能按规矩兜底的家伙。

头版代码？别想太多，跑起来再说

我没一上来就申请GPU搞私有化大模型。一来流程太长，二来鬼知道这玩意儿值不值得。所以先走API试水——DeepSeek，便宜到你不敢相信。我往里充了十块钱，用到现在两个多月还没花完。

写了个脚本，20行不到，大概是这样的：

import openai

openai.api_key = "你的key"
openai.api_base = "https://api.deepseek.com"

code_diff = "从这里读取 MR 的 diff"

review_prompt = f"请 review 以下代码变更，重点关注逻辑缺陷、安全风险和性能问题：{code_diff}"

response = openai.ChatCompletion.create(
 model="deepseek-chat",
 messages=[{"role": "user", "content": review_prompt}]
)

print(response.choices[0].message.content)

好了！我的第一个AI Reviewer诞生了！——然后它傻得出奇。

它揪出来的全是缩进、空格、换行这种鸡毛蒜皮，真正的逻辑漏洞？一个没找到。AI跟人一样：你不告诉它重点看什么，它就会瞎看。所以我加了个规则文件 .ai-review.json：

{
 "priority": ["null_pointer", "sql_injection", "transaction", "sensitive_data"],
 "ignore": ["format", "naming_convention"]
}

静态格式问题？那是ESLint/Pylint的事。AI只管动态逻辑和安全。这下输出才算勉强能看。

真正的核心：知识库，才不是模型

API调用模式跑了一段时间，两个问题始终缠着我不放：

• **没团队上下文**。AI不知道我们队里的习惯——比如必须用某个封装好的工具类发请求，不能直接写HTTP调用。这些在飞书文档里写得明明白白，但AI看不到。它就像一个刚到新公司的实习生，连文档都没读。
• **幻觉成精**。它经常自己编出一些压根不存在的API，或者推荐一些我们根本没用过的库。

这时候我才想到：知识库。

把飞书的规范文档抽出来，用embedding模型转成向量扔进数据库。每次review，先搜出跟当前改动相关的规范片段，和diff一起塞给大模型。

我用的是LangChain那一套。embedding模型选了BGE-small-zh（中文好还快），向量数据库用了Milvus的轻量版。流程简简单单：

1. MR触发 → 拉diff

2. 从知识库里找出跟这些代码相关的文档片段（比如“用户信息接口必须加权限校验”）

3. 把搜索结果 + diff + review指令丢给大模型

4. 拿回评论，通过GitLab API写到对应代码行

这一步太关键了。没有知识库，AI只能泛泛而谈；有了知识库，它才清楚你们团队踩过哪些坑。

效果你看：之前AI给一条建议叫“建议使用分布式锁”，加了知识库之后变成——“建议使用公司封装的 RedisLock 工具类，详见内网文档链接”。团队自定义的那套东西，终于活过来了。

让AI当“第一道防线”，别直接放行

集成到CI是必须的。我在 .gitlab-ci.yml 里加了几行配置：

code_review:
 stage: test
 script:
 - python ai_review.py --mr-id $CI_MERGE_REQUEST_IID
 only:
 - merge_requests

简单是简单，但有个天大的坑：千万别让AI自动放行。

我见过有人把AI review结果设成门禁——必须通过才能合并。结果AI误报一堆，开发们一个个炸毛，天天在群里骂。

所以我的做法是：AI给出建议并标记风险等级。LOW的自动忽略，MEDIUM的提醒人工确认，HIGH的必须有人手动确认才能合并。

还有个细节：规则扫描不能丢。

空指针、SQL注入、敏感字段暴露、事务边界缺失——这些问题确定性极强，就应该用静态规则引擎兜底。我做了两层：

• **第一层：规则扫描**（基于AST或正则），跑得贼快，发现必定违规直接打HIGH标记。
• **第二层：AI分析**，看逻辑缺陷、上下文关联、业务合理性。

两者一配合，完美。千万千万别把规则交给AI，又贵又慢还不一定准。

事实不会骗人：实测数据出来了

我们拿一个真实的Java 8老系统测了一轮。对比50个PR：

• 人工Review平均发现问题数：每个PR 3.2个（包括格式和逻辑）
• AI辅助后（规则+AI+知识库）：每个PR平均发现7.6个问题

翻了一倍多！

不过放心，没有天上掉馅饼的事。AI的误报率大概30%。误报主要出现在：

• 它觉得某个变量可能为空（但上游已经判断过了）
• 它推荐用新语法（但老系统不支持Java 8以上特性）

这时候知识库又派上大用场了——我们把历史误报案例也塞进去，当作反例。后续AI看到类似的场景就会想：“哦，上次这个被骂了，这次别傻了。”

从单Agent到编排器，就像从一个人干到拉一支队伍

最开始一个Prompt走天下，所有维度都在一个Agent里。用着用着就发现问题大了：

• 同一Agent既要管安全又要管性能，顾此失彼
• Prompt越堆越长，像一本说明书，改一个维度就影响别的
• 单次全量分析太慢，平均花90秒，开发等到花都谢了

后来咬咬牙，拆了！变成“编排器 + 多个专项Agent”：

编排器（调度+合并+过滤）
 ├── 安全 Agent
 ├── 性能 Agent
 ├── 逻辑 Agent
 ├── 可维护性 Agent
 ├── 业务规范 Agent（依赖知识库）
 └── 架构一致性 Agent

编排器自己不干活，只管派活儿、收成果、去重。每个Agent的Prompt独立维护，同时跑完再合并。延迟从串行的O(6t)降到了接近O(t)——现在实测平均22秒搞定六个维度的审查。

而且，不同的Agent还能用不同模型！ 安全那个可以用更谨慎的模型（比如qwen），逻辑那个用便宜又快的（deepseek-chat），灵活得很。

踩过的坑，我说几个让你也能避开

第一，别只扫新增行。

不少AI review工具只看diff里“+”开头的代码。但你想，如果你删掉了一个null判断，只看“+”根本发现不了。我后来改了全量diff（连带上下文一起扔给AI），并在提示里说清楚——“请同时关注新增行和删除行之间的语义变化”。

第二，review结果必须结构清晰。

最开始我直接把一大段文字贴在GitLab上，乱成一锅粥。后来统一成结构化输出：文件、行号、风险等级、风险类型、原因、建议。这样才好自动贴评论，也好后续统计——哪个模块问题多、哪类风险最常出现，一目了然。

第三，绝别让AI自动改代码。

有人出馊主意：“AI发现bug直接提交修复patch。” 你疯了吗？AI改的代码你敢不review就直接上线？review结论永远只是建议，执行的必须是人。它给建议，你确认后自己改。可以帮你提patch，但必须人工审核。

第四，集成到CI，但别用它阻塞CI跑。

之前我把AI review放在test阶段，一旦有风险就让流水线变红。后来改成review阶段，只输出结果，不改变CI状态。合并前人工看看HIGH风险项，手动确认一下就行。

效果到底怎么样？说几句实在的

用了段时间，三个变化肉眼可见：

• **Review效率**：原来每个人review一个MR平均15分钟。现在先扫一眼AI标出的HIGH和MEDIUM项，大概5分钟就能搞定。LOW的直接扔。
• **规范执行度**：以前文档写着“接口必须有业务日志”，但没人真正每条都检查。现在AI自动检查并提示，违规率肉眼可见往下掉。
• **新人上手**：刚来的同事不熟悉代码规范，AI评论里会带上知识库片段，等于边review边学习。

当然也有翻车的时候。有次AI把正常的业务判断标成“空指针风险”，开发兄弟气得不行，直接给我提了个issue。我查了查，发现是因为那个接口的入参在代码上层的过滤器里已经判空了，但AI看不到全貌。解决办法：把这类误报也塞进知识库当反例，后面再遇到类似场景它就不会再犯了。

未来：模型再牛，知识库才是护城河

这事儿还早着呢。

几个明显的方向：

模型能力还会涨，但知识库才是自己的。 大模型越来越聪明，可团队自己的业务规范、踩坑历史、技术栈限制，大模型不知道也不应该知道。谁的知识库更全、更新更快，谁的AI review就更落地、更靠谱。

微调还是Prompt工程？我现在选后者。 Code review场景变得太快，微调一次成本高、周期长，还不如Prompt加知识库来得灵活。将来如果能搞个轻量持续微调方案，比如每周拿最近的误报数据微调一次，可能会更好。

Code Review不会消失，但人的角色会变。 将来你很可能不再逐行检查代码有没有错，而是看AI的建议有没有遗漏，重点放在架构和业务决策上。Reviewer更像是“审核AI审核结果”的人。

多模态还没到上场的时候。 现在的AI review只能分析代码文本。架构图、时序图、数据库设计文档还得人来读。等哪天模型能直接看懂那些图，那才叫真起飞。

最后说句真话：别想一步登天。

第一次跑通，就算只是把一段diff扔给AI让它回一句话，也比什么都不做强。然后加规则、加知识库、调Prompt、接IM通知……一步步迭代。

我踩过的坑你十有八九也会踩。但照着上面我说的那些，至少能省你两三次从头再来的时间。

——对了，记住一句话：

最怕的不是开始得太糙，而是你一直不敢开始。