企业官网建设流程全解析

你有没有过这种周五？PR 列表里躺着二十多个待审查的请求，最早的已经卡了两天，开发在群里咳嗽两声暗示你抓点紧。你硬着头皮打开其中一个，几百行 diff，前半段还能跟上逻辑，看到后半段脑子已经开始发飘，最后囫囵点个 Merge，心里其实没底。

这是团队规模变大之后很常见的状态。我们团队从 5 个后端扩到 15 个人之后，MR 数量从每周 10 多个涨到 40 多个，可人的注意力没有跟着涨。后来我把 AI 接进了 Code Review 流程，让它在人看代码之前先把 diff 扫一遍，按严重程度把问题列出来。跑了大约 30 天，我的实际体感是：审查周期从平均 3.2 天降到 0.9 天，一些本来只能等线上报警才能发现的问题，在 PR 阶段就被拦住了。这篇文章把这套实践完整复盘一遍，包括方案怎么选、流程怎么搭、提示词怎么写、哪几个坑一定绕不过去，适合被 PR 堆积压得喘不过气的研发团队参考，也适合想用 AI 做工程效率提升但不想被噪声淹没的开发者。

1. 为什么要把 AI 拖进 Code Review：问题的根源在哪

1.1 传统 PR Review 的三个典型痛点

先说清楚一个前提：人做代码审查这件事，本身没有问题，有问题的是"人的精力是有限的"。

我观察到的第一个痛点是延迟。代码写完了，CI 绿了，结果在"等人审批"这一步卡住。开发不敢合并，怕漏看，可 reviewer 手上同时排着好几个 PR，每个人的时间都是零散切碎的。这段等待时间比很多 CI 流水线还要长，直接拉低了整个团队的交付节奏。

第二个痛点是疲劳。几百行 diff 摆在那儿，逐行看下去，前 100 行是认真的，100 到 200 行开始凭惯性，超过 300 行基本就是走马观花。这个疲劳曲线是人无法对抗的生理规律，跟责任心没关系。很多漏掉的空指针、数组越界，不是 reviewer 不负责，而是他盯到后半段的时候，注意力已经被透支了。

第三个痛点是质量不均。团队里有人对边界条件很敏感，习惯性追"如果这个字段为空会怎样"，有人则更关注命名和格式。这没有对错之分，但意味着同一个错误，换个 reviewer 就可能漏过去。于是出现一种很尴尬的情况：上一周在这个 PR 里拦住的问题，下一周在另一个 PR 里原样放行。

这三个痛点叠加起来，导致的不是某一次 review 出问题，而是整个迭代质量的方差变大。代码审查变成了一件"做了但没完全做"的事情，大家都很疲惫，但结果依然不稳定。

1.2 为什么 AI 只能做"初筛"而不是"替代人类评审"

聊到 AI 辅助审查，很多人第一反应是"机器能理解代码逻辑吗"或者"以后是不是不用人审了"。我的观点很直接：AI 在这里的作用是"排序"和"兜底"，不是"替代"。

所谓排序，就是让 AI 先把显而易见的问题挑出来，按严重等级排好。人打开 PR 评论时，看到的是一个已经被处理过的高频列表：这条是高危、那条是建议、还有几条可以忽略。这样 reviewer 的时间优先花在判断高优先级问题上，而不是花在"从零开始扫雷"上。我们团队在没有 AI 辅助之前，一个不熟悉的模块要花接近半天才能进入状态；有 AI 初筛之后，进入状态的时间被压缩到很短的范畴。

所谓兜底，指的是那些"摆在明面上但被忽略"的低级错误。经验再丰富的开发者，连续提交代码的时候也可能漏掉一个没判空的返回值。AI 不会疲劳，不会因为"这个 PR 是刚来的新同事写的"就不好意思提意见，它会稳定地把同一个问题反复标出来，直到有人处理。这一点在代码审查中非常重要——流程的稳定性比某一个单点的聪明程度更可靠。

所以我的定位是：AI 负责"广撒网"，人负责"一锤定音"。人仍然是最终决策者，但不用再从零开始找问题了。

2. 工具选型思路：核心方案怎么搭

2.1 主流的三种 AI 审查方案，怎么选不后悔

接入 AI 做代码审查，现在市面上有几种路径，我先做一轮对比。

第一种是直接用商业 SaaS 服务，比如 CodeRabbit、GitHub Copilot 自带的代码审查这类产品。接入成本最低，在仓库里挂个 bot，PR 一开就会自动触发审查。适合想快速验证效果、不想折腾基础设施的团队。缺点也很明显：代码要经过第三方服务，对有合规要求或者数据敏感的业务来说是个坎；审查规则跟着别人的产品走，你要想自定义某些检查项，往往受平台限制。

第二种是自己写一个 bot，调用云端大模型 API。灵活度高了一些，可以把代码 diff 拿过来，自己拼 prompt，再把这个过程接到公司的 Git 平台上。但代码还是出了内网，如果你所在团队的代码资产比较敏感，这一步也要谨慎。成本上则按 token 计费，每次大 PR 烧掉几万字 token，积少成多也是一笔开销。

第三种是自己写 bot，本地部署一个开源模型。Qwen2.5-Coder、DeepSeek-Coder 这类模型已经能跑出不错的效果，配合 vLLM 等推理框架，可以把审查服务完全放在内网。代码不出门，规则完全自定义，长期跑下来边际成本很低。缺点是前期部署有门槛，你得有 GPU 机器，也得有人维护这个模型服务。

横向放个表，方便大家看差异：

2.2 我为什么选"自建 bot + 本地模型"这条路

我最终选的是第三种，自建 bot 加本地部署模型。可能有读者觉得这个方案重，我承认前期确实有点折腾，但选它的理由很扎实。

第一是数据隐私。我们代码里有一部分内部业务逻辑，交给外部产品审查，心理上就过不去。而且代码审查涉及的是全量代码变迁，不是单个文件，长期喂给第三方，无形中等于把核心资产交给别人分析。本地部署之后，模型服务只在内网，diff 不出服务器，这条顾虑彻底消失。

第二是成本。商业 SaaS 按 repo 数量收费，仓库一多，每年费用不小。云 API 又要按 token 算，团队一周 40 个 MR，一个中型 PR 几万字，一个月下来并不便宜。本地部署模型前期花一块 GPU 的钱，后续跑审查基本是电费。对长期主义来说，这笔账很划算。

第三是可定制性。我可以在请求模型之前自己写规则引擎，可以在提示词层面调优，可以在输出之后做二次过滤。比如"相同类型问题最多只显示 3 条""没有具体修复建议的评论默认降级"这种规则，商业产品很难帮你实现。本地化之后，这套系统完全长在自己手里。

但我也要说句公道话：如果你们的代码不敏感，团队也只想快速看到效果，商业 SaaS 是最稳妥的起点。装一个跑两周，看看 AI 审查的评论对你团队有没有价值，再决定要不要深入自建。不用一上来就上最重的方案。

3. 关键一步：怎么把 AI 审查接进现有 Git 工作流

3.1 从 MR 事件到评论回写，一条完整链路

整体架构听上去玄乎，其实就是一台内网服务器加一个 webhook 监听服务。以 GitLab 为例，在项目设置里配置一个 Merge Request Hook，指向我部署的这台服务器。每当 MR 被创建或者代码被推送更新，GitLab 会发一个 JSON 格式的事件 payload 过来，服务就开始干活了。

完整流程可以拆成六步：

1. 根据 payload 里的项目 ID 和 MR IID，用 GitLab API 拉取最新 diff，以及 MR 的标题、描述、作者、变更文件列表。
2. 过滤无意义文件。lock 文件、生成的 proto 文件、前端构建产物、图片资源这些投喂给模型纯属浪费 token，直接跳过。
3. 对 diff 做切块。超过一定行数的 diff 按文件拆分，再按 hunk 拆分，并尽量把切块边界对齐到"完整函数"级别。
4. 组装 prompt。把 diff、上下文片段、项目规范摘要一起塞给模型。
5. 调用本地模型，拿到 JSON 输出，解析成结构化的审查意见。
6. 把意见按严重级别排序，通过 GitLab API 发一条评论，甚至可以把每条意见挂到对应代码行上。

这里有个关键设计是触发策略。我没有让每个 MR 的每一次 push 都触发审查，那样噪声太大。给服务加了两条规则：diff 相对上一次没有变化就不审；一个 MR 在短时间内反复 push，只有最后一次会触发完整审查。另外在 MR 准备合并之前，人工点一下"触发最终审查"，确保合并前拿到最新一轮意见。这样既覆盖了完整链路，又不会让模型被高频事件打爆。

3.2 提示词怎么写，才能让模型输出能直接用的结果

提示词是这套系统里性价比最高的优化点。我在前两周反复调了很多版本，最后沉淀出一个稳定模板。核心要点有三个：明确角色、明确输出格式、明确边界。

下面是我在用的精简版提示词，以英文为例，纯英文对代码类模型的理解通常更稳定：

You are a senior code reviewer with 15 years of experience. Review the following code diff and provide feedback. Focus on: - correctness bugs, race conditions, null/undefined handling - security issues (auth bypass, injection, hardcoded secrets) - performance problems (unnecessary loops, N+1 queries) - API design and backwards compatibility Output a JSON array with items: {"file": "...", "line": <number>, "severity": "high|medium|low", "title": "<short title>", "suggestion": "<specific suggestion>"} Rules: - Do NOT report pure style issues unless they affect readability seriously. - Do NOT invent issues that do not exist. If the code looks fine, output []. - For every finding, cite the exact line number from the diff. - Be concise. No explanation outside the JSON. Diff: <diff content>

注意里面特意写了一句话：如果代码没问题，就输出空数组。这个约束很重要。因为生成模型有个天然毛病，就是"宁可多说也不能漏说"，容易把没问题的代码硬挑出刺来。明确允许它输出空结果，可以显著降低误报率。我实测这样改之后，低优先级噪声几乎少了一半。

还有一个叫"输出格式约束"。JSON 输出比自然语言好解析太多，可以直接绑定到 GitLab 评论。第一次跑的时候我没指定格式，模型洋洋洒洒写了一大段，又得写正则去拆，体验很差。加了这个约束后，解析链路稳定多了。如果模型偶尔输出不合法 JSON，服务层可以加一个"解析失败就重试一次，并把 temperature 调低"的逻辑兜底。

3.3 上下文增强：只给 diff 让 AI 审查等于盲人摸象

只把 diff 扔给模型的做法，坚持不了几天就会暴露问题。模型经常不知道某个函数原本是干嘛的，很容易把调用处合理的写法误判成 bug。典型场景在 Go 项目里特别多：一个函数返回指针，AI 看到判断空指针就标记为高危，但实际上调用方在上层已经做了空值保护，这个判断是冗余但安全的。

解决办法是给模型增强上下文。我做了三步：

第一步，把 git log 里该文件最近几次提交信息一起带上。提交信息往往含"为什么改这里"的语义，模型理解了演进意图之后，误报会明显下降。第二步，用轻量脚本把 diff 中出现的函数定义、关键类型定义所在位置的代码抽出来，截取函数体前后各几十行，作为上下文片段接在 diff 的后面。第三步，如果改动涉及对外接口，把接口定义或者 Swagger 片段一并带上。

这样做的代价是 token 变多，但换来的是审查结果更可信。对本地部署的模型来说，token 成本本来就可控，关键还是性能和安全。如果单条 hunk 的上下文超过模型窗口，我会优先保留被修改函数附近的内容，放弃文件其他部分。这个优先级取舍，实际效果比重试十次都要好。

4. 落地效果：数据说话，审查覆盖率与准确率提升如何

4.1 接入 30 天，几个关键指标到底变了多少

我拿自己团队的数据给大家做个参考。团队规模 15 人左右，前后端一体，代码量中等，平均每周产生 30 到 40 个 MR。接入 AI 审查之后跑了 30 天，几个关键指标的变化如下：

数字本身有噪声，每个团队情况也不一样，但趋势是很清楚的：合并阻塞时间大幅缩短，低级错误被提前拦截。这里特别要说一下，审查周期下降不仅仅是 AI 跑得快，而是因为 AI 先把问题列表整理好了，人的 review 时间不再需要从头到尾扫一遍，工作时间被压缩了，等待时间自然就没了。

我个人的体感是，现在打开一个 MR，AI 的评论通常已经出现在评论区。它挑出来的边界问题里，大部分时候确实值得让人多看一眼。这让我从"逐行读代码找问题"变成"判断 AI 找到的问题里哪几个真的需要处理"，这个转变就是效率翻倍的来源。

4.2 一个真实 PR 案例：AI 在哪儿比人先看出了问题

分享一个刚接入不久时的真实案例。我们有个后端服务改了"分页查询"接口，改动是把原本全量返回的列表改成分页，前端传 page 和 pageSize，后端用 LIMIT 和 OFFSET 实现。人 review 第一眼看上去，逻辑很顺，参数校验也做了，看不出大问题。

AI 给的评论里有这样一条：

{ "file": "internal/api/users.go", "line": 148, "severity": "high", "title": "OFFSET 分页在大偏移量下性能有隐患", "suggestion": "数据量上来之后，OFFSET 500000 这类查询会逐步退化成全表扫描，建议改用基于游标的分页，或至少限制最大页码。" }

这一条提醒得非常在点。直接改成分页，功能确实没错，但业务数据量还在涨，涨到几十万条之后，OFFSET 越深查询越慢。这个风险如果等线上接口变慢再回头排查，代价就大了。后来我们把分页改成了"索引加游标"方案，上线后表现稳定。

人类 reviewer 当时为什么没看出来？因为人看代码时习惯先验证"功能对不对"，很少会在 review 阶段去推演一条查询在数据量涨上去之后的性能曲线。模型恰恰很擅长这种"不是错但可能爆"的推算。这种穷举式检查，就是初筛器最大的价值。

4.3 踩坑实录：四个最常见的问题和我的修复方案

第一坑，diff 没做切块。第一次接入时我以为把整个 diff 塞进去就行，结果遇到一个 3000 多行的 MR，模型上下文直接爆掉，服务抛错。后来加了切块逻辑，按文件、按 hunk 分批跑，再汇总。切块的边界要小心，一个函数被拦腰切开，模型会看不懂中间逻辑，所以代码里专门做了括号匹配，把切块边界对齐到完整函数级别。

第二坑，AI 噪声严重伤害了信任。第 3 周的时候，团队里有人说"AI 标了一堆没用的，我懒得看了"。这是很危险的信号，一旦大家开始无视 AI 的评论，这套系统就等于白做了。解决方式很直接：把提示词里的风格检查进一步弱化，加了一条规则——高优先级意见必须给出具体修复代码，否则自动降级。这样每人收到的评论大概少了 50%，但留下来的高优先级意见基本都值得处理，团队的信任又回来了。

第三坑，并发调模型时 GPU 显存不够。最开始用默认参数部署 7B 模型，8G 显存的卡一遇到并发就 OOM。后来给服务加了信号量，限制同时只有 2 个请求进入模型，其余排队。高峰期最多就是排队，不会把整台机器打挂。如果条件允许，还可以用 vLLM 这类推理框架开启 continuous batching，吞吐提升很明显，不过对部署环境有点要求。

第四坑，模型重复审同一个文件。MR 更新几次，diff 也变了几次，没有去重逻辑的话，每次更新都会产生一堆重复评论。我给服务加了基于"文件路径 + diff hash"的缓存，diff 变化超过 20% 才触发重新审查。这样大部分小改动不会重复刷评论，每轮评论都对应最新有效的变更。

5. 常见问题与避坑清单

5.1 常见问题速查表：现象、原因、处理方向

这段时间被问到最多的问题，我整理成了一张速查表，方便大家直接用：

另外补充一个比较隐蔽的问题：如果你用商业 SaaS 接入，找客服往往只能解决接入问题，很难帮你优化模型效果。自建方案里这些坑只要你愿意花时间调试，都能找到明确答案。这也是我倾向自建的隐性理由——问题不在别人手里。

5.2 落地前先看这五条经验

最后几条经验送给准备动手做的人。

第一，从一开始就约定清晰边界。AI 是审查助理，不是合并门禁。我们团队明确写了一条规范：AI 的评论只是建议，合并条件仍然是至少一位人类 reviewer 加 CI 通过。这样既避免 AI 误杀正确代码，也避免有人拿 AI 意见当挡箭牌，推卸自己的判断责任。

第二，对 AI 输出做二次过滤。纯靠模型自然会产生大量零散意见，程序要做一次加过滤：低优先级意见按类型合并同类项，一类最多列 3 条；高优先级意见必须带具体修复方案才能放行。这套规则看着不起眼，但对评论区的可读性影响巨大。

第三，先积累一份"已知问题清单"再调提示词。把过去半年线上事故和回滚原因归类，比如空指针、并发写共享数据未加锁、密码硬编码、SQL 拼接注入风险、接口未做兼容处理。把这些类型直接写进提示词，并配一条样例说明。模型知道你要什么样的输出，质量会明显上一个台阶。

第四，换模型版本之前一定要做回归测试。每次换新模型，我都拿固定的一批历史 MR 跑一遍，比对结果。不是越新的模型越强，有些新模型为了"听话"，反而会把没问题的代码过度解读，噪声一下就上去了。用固定数据集评估，比凭感觉换模型靠谱得多。

第五，脱敏是底线。虽然本地部署已经挡住了大多数数据外流风险，但模型本身会从投喂内容里学习，不要把真实的生产密钥、token、连接串当测试数据。系统里要加一道脱敏层，在把 diff 交给模型前，把 password、apiKey、连接串里的值全部替换成占位符。这一点没有任何商量余地。

我在实际使用这套系统几个月后最大的体会是，AI 辅助审查并不会让代码审查这件事从团队里消失，它改变的是人的投入方式。以前我花大量时间做最简单也最累的扫雷工作，现在这部分被模型接走了，我能把节省下来的精力放到真正的设计评估和逻辑推演上。代码审查的深度不但没有下降，反而因为前期噪声减少了，人的关注点更集中了。

如果让我再给一条最实在的建议，那就是别急着上整套复杂方案。先选一个仓库，用最简单的方式把流程串起来，哪怕先让自己一个人用起来。你会很快发现，最多一周你就习惯了"先让 AI 扫一遍再说"。代码审查这件事，等所有人都有空再来深入，往往等于永远做不深。不如先把重复劳动交给工具，让人的注意力留在真正需要思考的地方。