三个月前，我去了一趟技术支持群，看到一个做了三年 Code Review 工具的朋友在群里吐槽：“我们用大模型接了一套代码审查助手，前期效果很惊艳，用久了问题却越来越多。同一个模型，让它查算法逻辑问题表现不错，可让它审前端样式、SQL 索引这种跟算法八竿子打不着的改动，经常答非所问。最难受的是，它经常把一些团队自己的约定当成错误报出来，我一UNit时间大半都花在过滤无效告警上了。”
这段话让我特别有共鸣，因为我们团队在半年前上线多模型智能代码审查系统时，也被“单一模型覆盖所有代码审查场景”这个看似省事儿的思路坑得不轻。经过一段时间的挣扎、重构和验证，我们最终放弃了“用一个大而全的模型包打天下”的路线，改成了一套“多模型协同、按任务路由、分角色审查”的架构。
这篇文章就把我们这大半年在智能代码审查方向上的实践、踩坑和思考完整写出来。里面会涉及多模型路由设计、Prompt 分配、上下文裁剪、意见冲突处理、成本控制和效果评估这些环节。如果你正准备给团队或公司的代码评审流程接入大模型能力，或者你已经在用单模型但总觉得“哪里不对”，这篇文章的内容应该能让你少走不少弯路。
1. 单模型做全量代码审查，为什么总在关键问题上掉链子
很多团队接入大模型做代码审查，第一反应都是找一个综合能力最强的模型，把所有代码变更都丢给它，觉得“模型强就够了”。在十几个 PR 的小体量验证阶段，这种方案确实能给人一种“整挺好”的错觉——基础语法问题能查，明显的空指针能查，变量命名不规范也能给个提醒。
但一旦把审查范围扩大到不同语言、不同业务模块、不同代码改动类型，问题会变得很具体。
1.1 不同代码审查任务对模型能力的要求是冲突的
注意，我说的是“冲突”，不只是“不同”。代码审查场景看起来只有一个——看代码写得好不好——但实际拆开，它包含至少四类差异很大的任务：静态规范检查、逻辑正确性分析、并发和性能隐患识别、业务语义合规判断。
这四类任务对模型的要求完全不一样。静态规范检查需要的是极强的规则记忆能力和对团队自定义规范的精准理解；逻辑正确性分析需要的是长上下文推理和小范围状态跟踪；并发与性能隐患识别需要模型对底层运行机制有大量的、精确的先验知识；而业务语义合规判断则更偏“这个改法是否符合业务预期”这类跟代码上下文强相关的任务。
一个模型如果想同时做好这四件事，往往意味着它在任何一个方向上都无法做到极致。拿一个综合能力很强的大模型做实验，它在处理一段复杂的并发代码时可能给出不错的建议，但你马上丢给它一段普通业务代码，让它判断异常处理是否合理，它的输出就可能开始泛化、使用模板式的话术，甚至出现互相矛盾的审查意见。
比如我们团队早期拿单一通用模型跑一份“订单超时关单逻辑”的变更代码，模型能准确说出“这里应该加乐观锁”，但同一个模型同一个上下文，让它审同一个 Diff 里一段简单的金额格式化工具函数，它会一本正经地建议“把 double 换成 BigDecimal”——理由是“浮点数精度有问题”。可那段函数入参本身就是数据库里算好的 decimal 字符串，改成 BigDecimal 属于纯噪音建议，根本没有任何收益，还会干扰真正有价值的信息。
1.2 审查意见的风格漂移，比技术错误更难接受
比模型技术层面犯错更头痛的，是它的风格漂移问题。这类问题在单模型长周期使用中几乎一定会出现，主要体现在两个方向。
第一个方向是审查结论的“倾向漂移”。同一个模型，如果使用的人比较多，对话上下文复杂，它的输出分布会随着输入顺序和上下文长度产生明显波动。比如某个模型在上下文较短时偏向保守，只会报“这个问题考虑一下”；但上下文一旦接近模型窗口上限，它又开始对很多原本不属于严重问题的代码给出 High severity 的评价。这种漂移很容易误导开发者的判断优先级。
第二个方向是审查内容的“时效偏差”。一些通用模型的知识截断日期以后发生了变化的框架用法、函数签名、最佳实践，模型并不会自动更新。如果团队在代码审查中某个阶段只依赖单一模型，这个模型对某个已经被废弃的 API 仍然保持着“这是最佳实践”的错误判断，那么你得到的不是审查，而是持续性的反向指导。
1.3 我们早期的“单模型增强尝试”为什么失败了
最开始，我们也尝试给单个模型加一堆前置规则，比如先调用静态分析工具生成 AST 告警，然后拼到 Prompt 里让模型结合规则再判断。但这样做产生了一个新的问题——上下文变长之后，模型对 Prompt 后半部分的规则内容“记忆”越来越弱，尤其当 diff 本身超过一千行时，模型经常忽略静态分析工具给出的关键告警。
我当时印象很深的一个案例是：我们接入了一个 SQL 静态扫描结果作为 Prompt 上下文，让模型复核一条慢查询问题。结果模型不仅没有结合 EXPLAIN 结果给出优化建议，反而引用了上下文里的字段名，编了一版并不存在的执行计划分析。单模型由于自身能力边界和注意力机制的限制，很难真正把“规则+代码+解释”三层信息同时用好。
到这一步我们基本确定：想用一个大模型解决代码审查的所有问题，至少在目前阶段是不现实的。与其跟单模型的缺陷较劲，不如换一个思路——既然代码审查本身就可以拆成不同工种，那我们为什么不能用多个模型来分别扮演这些工种？
2. 多模型代码审查团队的具体架构：角色分工与路由中枢
把多个模型组合起来，并不是简单地在代码里写几个 if 分支，然后把不同 diff 分别发给不同模型这么粗糙。要让多模型真正产生“1+1>2”的效果，需要设计一套清晰的架构和分工逻辑。
我们最终采用的是“一名主审 + 两名专项审查员 + 一名最终意见整合者”的模拟团队结构。这个结构不一定适用所有团队，但设计思路是共通的：让每个模型只做自己最擅长的一个环节，然后通过一个规则化或者半规则化的路由层去调度它们。
2.1 四个角色如何分工，为什么这样分
主审模型我们选择了上下文能力强、综合理解能力扎实的商用大模型（内部代号 Captain），它负责做全局性的代码变更理解，输出的是“这段代码改了什么、业务含义是什么、整体逻辑链路是否完整”。它不需要做一个字一个字挑错，只需要在宏观层面判断变更是否引入架构级问题。
专项审查模型则按审查对象拆成两路：一路负责静态规范与细粒度代码风格（我们选了本地部署的代码专用模型，并且微调过团队规范），另一路负责运行时问题与安全/性能隐患（我们选了擅长逻辑推理与安全模式识别的模型，比如近两年在代码任务评测上表现不错的新一代模型）。这两路模型并不对所有文件都跑，它们的路由规则是严格按文件类型、改动性质、关键词触发的。
最后还有一个意见整合模型，它不是独立的第三方大模型，而是我们基于摘要模型构建的一层聚合器。主审和专项审查的结果会汇入这一层，做去重、分级、过滤和语义重排。
为什么需要意见整合者，而不是直接把两个模型的意见拼在一起？因为不同模型对同一个问题的表述是完全不一致的。有的模型会直接说“这里存在 NPE 风险”，但另一个模型可能用五十个字描述同一个上下文，如果不做一层聚合，开发者看到的结果会非常碎片化。我们试过直接拼接，开发者反馈“信息太密，不知道改哪个”。
2.2 路由中枢：每一类代码改动到底该由谁来看
多模型系统的核心是路由中枢。我们写了一个轻量的规则引擎，按照 MR 的元数据、改动文件类型、函数关键字和变更量级，自动分配任务。
下面这个表是我们最终线上跑的路由规则简化版：
| 代码变更特征 | 主审(Captain) | 规范专项模型 | 运行时专项模型 |
|---|---|---|---|
| 后端 Java 接口实现，改动量 < 300 行 | 是 | 是 | 是 |
| 纯前端样式/文案调整 | 是 | 是 | 否 |
| SQL 脚本或数据迁移 | 否 | 是 | 是 |
| YAML/JSON/配置文件 | 只读，不审逻辑 | 是 | 否 |
| 涉及 Redis/消息队列/异步任务 | 是 | 否 | 是 |
| diff 大于 1000 行 | 否，先做文件级拆分 | 分批 | 分批 |
这套路由规则看起来朴素，但它解决了一个最关键的问题——不浪费。不同模型的计算成本和推理延迟完全不一样，如果所有变更都跑三个模型，成本会翻三倍，延迟也会从几十秒涨到两三分钟。路由之后，我们的 API 调用成本大约节约了 60%。
2.3 让每个专职模型只看到它该看的部分
很多团队的误区是，给了多个模型却没有给它们划分上下文。路由做完了，同一个 diff 文本还是原封不动地同时发给三个模型。在代码审查场景里，这样做其实会稀释专职模型的优势——它虽然是你选出来的“规范审模型”，但看到的上下文里可能 80% 是跟规范无关的逻辑重构，这会影响它的注意力分配。
我们给每个专项模型设计了不同的系统提示和上下文策略。对规范专项模型，我们会把“本次变更涉及的文件之前是否有历史告警”也放进上下文；对运行时专项模型，我们会额外注入它对应技术栈的检查清单；而主审模型的输入则做了降噪处理，直接过滤掉纯粹格式调整的文件差异块。
用系统提示词大致长这样（这里以运行时专项模型为例）——
你是一名资深后端运行时审查员。你只关注与并发安全、事务边界、连接池、缓存一致性和异常吞没相关的问题。面对代码变更，请忽略纯格式或代码风格问题，那些将由另一位同事负责。你的输出必须按“风险描述 / 触发条件 / 最小修复建议 / 严重程度”四段式组织。如果你不确定触发条件，请明确写出“不确定”，不要猜测。别看它简单，这套系统提示词在生产环境里带来的效果提升比换一个更大的模型还明显。因为多模型系统的价值根本不在于“把多个模型分别跑一遍再贴在一起”，而在于让每个模型都能在自己的舒适区里，用最稳定的方式输出最符合它角色定位的意见。
3. 多模型协作中的真正难点：意见冲突、上下文孤岛和成本飞涨
架构设计完，模型也接上了，前两周我们一度觉得“稳了”。但在后面一个月里，连续暴露了三个问题，每一个都足以让这个系统退回单模型时代。
3.1 意见冲突：主审说改，专项模型说不用改，听谁的
第一个我们遇到的问题是跨模型意见冲突。代码审查里很多问题不是非黑即白的，比如对“是否需要把状态机抽成单独类”这类重构问题的判断，主审模型和运行时专项模型经常给出完全相反的结论。有一次，主审模型认为“订单状态流转逻辑太复杂，建议抽象成独立状态机类”，但运行时专项模型却指出“当前状态字段已经落库，引入状态机框架会造成存量数据迁移风险，不建议在本次需求中做”。
如果我们把两条意见直接并列推给开发者，开发者一定会觉得这系统“精神分裂”。我们一开始试图用规则来裁决，比如“如果意见冲突，以运行时专项模型为准”，但很快发现这个规则过于粗暴——因为有些冲突是语义层面的，并不是严重性层面的。
最后我们采用的方案是引入一层“归类标记”。意见整合者不会强行抹掉任何一方的意见，但它会把冲突标记出来，同时生成一小段“冲突说明”：指出两个模型冲突的核心争议点是什么、双方各自依赖哪些事实、建议开发者重点确认哪个环节。这样一来，冲突本身反而变成了有价值的信息，因为它帮开发者定位到了最容易踩坑的算法决策点。
3.2 上下文孤岛：合并了模型意见，却丢失了跨文件依赖
第二个问题比意见冲突更隐蔽，我们内部叫它“上下文孤岛”。多模型分工以后，每个模型默认只拿到自己负责的那部分代码。这会导致一个很严重的情况：某个文件里的 BUG 本身不在这份文件里，而是由另一个文件的改动引起的。如果一个专职模型只看自己分配的文件，它根本发现不了这类 BUG。
举一个真实出现过的例子。我们后端有一个用户积分发放的 MR，A 文件修改了积分规则计算，B 文件修改了积分入账的异步消息体。主审模型两份都看了，指出 “B 文件拿到的积分值字段从 int 改成了 long”，但规范专项模型只看了 A 文件，它没有这个上下文，于是把 A 文件里一个专门针对金额精度做得 long 类型比较的代码段判成了“可疑语法”。单看 A 文件这段确实有些绕，但结合 B 文件的改动，这个写法恰恰是正确的，是为了避免下游消息体溢出做的适配。
解决这个问题的方式，是我们给路由中枢加了一个“跨文件影响传播层”：所有文件级分析完成后，会有一个传播阶段，将每一份文件的输出摘要（仅摘要，不是原始代码）广播给其他相关文件的分析上下文。这样每个专职模型在最终输出前会多一步“关联文件摘要核对”，有效缓解了上下文孤岛问题。
3.3 成本飞涨：模型一多，token 消耗就成了大头
多模型系统最直接的代价就是成本。虽然路由已经把计算量降下来了，但相比单模型方案，开销仍然是成倍增长的。而且这里有一个很反直觉的地方：
成本涨幅最大的不是推理本身，而是每个模型之间共享的“上下文重复发送”。一份 500 行的 diff，三个模型各看一遍，输入 token 天然是三倍。我们试过把共享上下文放到提示词里压缩，但压缩会损失关键信息，比如函数命名信息。
后来我们做了两个优化。第一，对进入路由的文件做差异化裁剪——比如纯前端改动就不会带着整个后端 service 类的旧代码；第二，对模型的审查结果引入“缓存复用”：如果一段代码刚被主审模型完整分析过，而规范专项模型也需要做类似分析，我们会把主审的摘要直接注入专属模型，让它只做增量判断，而不是从头开始把整份 diff 重新读一遍。
我们统计过一个月的 API 账单，经过裁剪和增量复用后，多模型系统的单 MR 平均 token 消耗从约 68K 降到了 41K，审查效果没有下降。成本仍然是单模型的 1.8 倍左右，但这 1.8 倍换来的是有效告警率接近翻倍，从商业角度看这笔账很划算。
4. 给多模型审查团队建立的评估闭环：没有它一切优化都是盲人摸象
其实我们在多模型系统上线大概三周后就发现了前面说的各种问题。之所以能准确判断“这些问题让系统变差了多少”，是靠提前搭好了一套评估闭环。如果你不准备做评估集，只凭开发者的主观反馈去调整多模型路由，你极大概率会从一个坑跳到另一个坑。
4.1 我们如何构建小规模的代码审查评估集
代码审查效果的评估，跟模型在通用 benchmark 上的评估完全不是一回事。通用的 HumanEval、MBPP 只能说明模型能不能写算法题，跟“在团队的真实 MR 里能不能给出可执行的意见”完全是两个维度。所以我们做了一套“内部评审基准集”，从历史已合入的 MR 里抽取了 128 份代表不同改动类型的记录。
每条评估样本包含三个部分：原始 MR 的变更描述和完整 diff；至少两名资深工程师人工标注的“真实缺陷”清单（包括轻微、中等、严重三个级别）；以及团队当时实际讨论结论和终版代码改法。
线下评估的时候，我们会让多模型系统完整跑一遍这 128 份样本，然后跟人工标注做比对。评测指标我们主要看四个：单 MR 有效意见数、严重缺陷召回率、无效意见率、轻微问题加权准确率。不追求计算复杂指标，够用就行。
当时做的对比结果很有意思。单模型方案的综合有效意见率大约是 41%，也就是每 10 条自动审查意见里有 6 条左右是不需要开发者真正处理的；而我们第一版多模型路由方案有效意见率提升到了 68%，但严重缺陷召回率跟单模型差距不大，说明很多高风险问题在路由阶段就被“漏”了——这也暴露了单纯做分工不解决核心问题的事实。
4.2 让多模型团队持续改进的回归机制
有了评估集，我们就把模型升级变成了一个“可回归”的过程，而不是一个凭感觉拍板的事。具体做法很朴素：每周四晚上触发一次全量回归测试，跑 128 份样本，输出一份跟历史结果对比的指标变化报告。
添加新模型或者切换路由策略时，我们要求必须同时满足两个硬指标才允许合入：严重缺陷召回率不低于当前线上版本；无效意见率不得高于当前线上版本两个百分点以上。
这个过程关键作用不是找最优模型，而是防止“优化了一个指标却劣化了另一个指标”的情况发生。最典型的例子：我们曾经尝试把一个上下文窗口更大的模型换到主审位置，结果严重缺陷召回率微幅提升，但无效意见率从 31% 升到了 39%，系统整体体验反而变差了。有回归机制兜底，我们就没有让这个版本上线。
4.3 分级输出，把注意力留给真正需要改的代码
评估集还帮助我们重新设计了意见的呈现逻辑。前面说过，多模型系统天然会比其他方案产生更多意见，开发者如果不管三七二十一全看，体验一定很差。
最终我们按评估中发现的“意见可行动性”把所有审查意见分成了三个层级：
| 层级 | 含义 | 示例 |
|---|---|---|
| P0 必须处理 | 不修复会直接引发线上故障或数据错误 | 事务注解失效、并发更新覆盖、未处理唯一键冲突 |
| P1 建议修改 | 不影响功能但会在特定条件下成为隐患 | 资源未关闭路径、缺少必要的空值检查、状态流转缺失分支 |
| P2 可选优化 | 属于最佳实践、团队规范、可读性层面 | 魔法数字抽取常量、函数命名不达意、重复代码抽取 |
三个层级分别采用不同的展示和推送策略。P0 意见直接推送给作者和 CR 负责人，P1 在 MR 页面评论区内联展示，P2 折叠到次要区域，并且默认不产生通知。上线这个分级机制后，开发者对审查系统的反馈从“意见太多、干扰严重”变成了“至少 P0 是真的值得看的”。
后来我们又统计了三个月的线上数据，这套多模型系统每月处理约 1800 个 MR，P0 级别发现的真实问题稳定在 37~52 个之间，有效意见率保持在 70% 左右。跟单模型时代相比，最明显的变化不是模型变强了，而是整个系统不再只依赖某一次大模型的超常发挥，而是靠结构性分工保证了每一条意见的质量下限。
5. 如果可以重来，我会在项目第一天就做这几件事
写到这里，整个多模型智能代码审查系统的骨干内容基本讲完了。最后说几条我自己沉淀下来的经验和教训吧，尤其是“如果让我重新来一次，我会从第一天就开始做什么，而不是后来返工补课”的部分。
第一，尽早定义“有效意见”的标注口径。代码审查类系统的效果，是一个很模糊的概念。没有标注口径之前，团队里每个人都觉得“系统有时候有用，有时候没用”，但是没有数字去衡量。后来我们统一把“有效”定义为：开发者看完之后对代码做出至少一行实际修改，或者确认了一个真实风险并补充了测试。这个定义不一定完美，但它让所有人对系统的评估有了一个共同语言。
第二，不要把路由规则和模型绑定得太死。代码模型领域变化极快，过几个月可能就出现一个新的开源模型，在某类专项任务上能力飙升。如果路由规则是硬编码的“Java 一律发 A 模型、Python 一律发 B 模型”，你升级模型的时候会很不灵活。我们后来的做法是把“模型能力描述”也写进路由配置里，每次升级模型只改配置，不需要改核心代码。
第三，上下文重复发送问题一定要从第一天就控制。如果一开始就不在意 token 结构和上下文裁剪，后面接入的模型越多，累计浪费越大。最好在管线设计之初就把“同一份代码只能完整进入一个模型的推理上下文一次，其他模型只接收摘要和差异信息”写进设计约束，这会让你省掉很大一部分成本优化的返工。
第四，如果团队人力很紧，优先级顺序应该是“可靠的路由 + 评估集”大于“细分模型调优”。因为路由和评估集能保证系统的下限稳定，而细分模型调优只是锦上添花。我们早期花了不少精力去微调某个专项模型的 Prompt，试图让它更符合团队风格，但后来发现，对代码审查体验影响最大的其实是“该这个模型做的事，它做得纯粹而稳定”，而不是让它学会处理各种边角场景。
代码审查这个事，核心从来不是“选一个最强模型”，而是“把任务拆到一个模型能稳定输出的颗粒度，再让它们各司其职”。多模型不是目的，稳定才是。如果你也刚好在搭建类似系统，把这几个方向想清楚，应该能比我少走不少弯路。
