1. 先聊聊为什么纯LLM撑不起代码审查代码评审这件事我干了有年头了带团队那会儿最头疼的从来不是写代码而是review PR。凌晨三点看到一个带着明显空指针风险的分支被merge进主干这种事儿发生过不止一次。所以当圈子里开始聊AI代码审查我第一时间就去试了最朴素的方案把diff整段丢给LLM让它“看看有没有问题”。结论很真实——能用但不敢信。纯LLM方案有三个绕不过去的死穴。第一个是幻觉。模型很可能振振有词地指出“第42行存在空指针解引用”而那行代码实际上是个shutdown钩子根本没有对象调用。更麻烦的是它引用的行号经常对不上号diff是变更内容行号是原文件的行号两者之间隔着一道映射关系模型往往在这个映射上翻车。第二个死穴是上下文窗口与仓库规模的根本矛盾。一个中型PR动辄改几千行牵涉十几个文件把全部diff塞进上下文既超预算又抓不住重点。第三个死穴是结果不可复现。同一个PR换一个模型、调一次温度甚至什么都不变重跑一遍输出都不一致。代码审查本质上是质量门禁门禁最怕的就是判断标准漂移。这不是模型能力不够而是选型错了。LLM擅长语义理解和模式识别但不擅长精确计算、全局索引和确定性规则执行。代码审查恰好是“精确模糊”的混合场景diff解析、lint规则命中、语法错误这类东西需要精确匹配而“这段逻辑有没有边界问题”“这个异步调用是否可能造成竞态”则依赖语义理解。单纯用LLM包办一切等于让一个语文老师去核对账本——字都能认账一定对不平。于是问题就变成了能不能把“精确”的部分先用确定性手段做完再把“模糊”的部分交给LLMopen-code-review这个项目的设计思路给我的启发正在于此。它没有试图做一个“全知全能的Agent”而是用一条确定性流水线把代码审查的前半程固化成标准工序再把结构化产物喂给LLM Agent去做推理与建议生成。整套思路说白了就是确定性工具干脏活累活LLM干动脑子的活中间用规整的数据格式衔接谁也不越界。这套架构对我们团队的意义很大。手里有七八个存量仓库历史债务一堆PR里一半是业务逻辑改动一半是补测试、重构和依赖升级。人工review既要盯历史包袱又要看新逻辑疲惫之下很容易漏掉深层问题。搭完这套混合架构之后AI先跑一遍“体力活”把低级的风格、边界、重复代码问题筛掉剩下真正需要人判断的部分再由LLM给出带推理链的分析评审者只需要重点复核AI标出的高置信度问题。实际体验下来这等于把评审从“全程阅读”变成了“抽查复核”省下来的时间相当可观。1.1 确定性流水线到底解决什么问题一句话确定性流水线负责把代码变更“翻译”成LLM能高质量理解的结构化数据并且顺带解决一批压根不需要AI参与的问题。它在代码审查里承担的角色类似生产流水线上的定位夹具——每个工件到工位之前已经被固定好姿态机器人才不会抓瞎。具体来说流水线要处理四类脏活。第一是diff解析从VCS里拿到原始diff解析成hunk粒度的结构化数据保留变更文件路径、变更行号、上下文快照。第二是静态分析注入跑ESLint、Ruff、go vet这类确定性工具把命中的规则、严重级别、报错行整理成标准化entry。第三是依赖关系分析通过AST解析变更文件的import关系确定哪些符号、哪些文件与本次变更相关。第四是历史检索在仓库历史PR里检索相似改动、相似报错形成“此类问题已知的处理方式”参考集。这四类输出凑到一起就是LLM Agent的“全套案卷”。1.2 LLM Agent在这里的定位LLM Agent不是空手接diff而是基于流水线给出的“案卷”做推理。它的任务分三个层次。第一层是分类与解释把静态规则的告警翻译成人话说明为什么这样写会出事。第二层是发现流水线“看不见”的问题比如并发逻辑里的竞态、异常吞掉后的状态不一致、多文件之间互相矛盾的假设。第三层是生成修复建议甚至完整补丁。这里有一条重要的架构纪律Agent的输出必须经过确定性校验才能进最终报告。Agent说“第102行有副作用”流水线要先验证102行确实存在且指向预期符号验证通过才标记为高置信度否则一律降级为“疑似”。这套“AI提报、机器核实”的闭环正是open-code-review这类混合架构最值钱的资产也是我建议任何想自己搭AI审查平台的人优先搬走的模块。2. 混合架构的整体设计与数据流转如果让我用一个词形容这套架构的特点就是“各司其职”。整条流水线发端于一个webhook事件止于一份带置信度评分和修复建议的评审报告。任何一个环节出问题都有一条明确的回退路径不会因为LLM抽风导致整条链路雪崩。数据流转大致是这样PR open或synchronize事件触发流水线先做基础检票拿到PR元数据、目标分支、变更文件列表然后进入diff解析阶段把原始diff拆成hunk对象接着并行跑静态分析器和AST分析器再组装上下文包随后LLM Agent评审之后是结果校验最后聚合去重写回代码平台的评论区或Check Run。听起来流程很长但每个环节的输入输出都是明确Schema的JSON两边互不猜测。这一点怎么强调都不过分确定性极强的那部分跟Agent合作的前提就是结构化契约——如果AI上游给的是free textAgent给出的也必然是free text工程化就无从谈起。2.1 上下文包的组装策略最偷懒的做法是把整个PR的diff一股脑塞给LLM这也是我最开始犯的错误。open-code-review的处理方式更有意思先给变更文件打分排序只把高价值的文件完整带上低价值文件只带hunk摘要。文件价值怎么评我用三个指标加权改动行数、文件在import依赖图里的被依赖次数、文件自身的变更频率。经常变的文件往往承载核心业务被依赖次数多的文件一旦改错影响面大这两类文件天然值得投入更多token。三个权重先用启发式跑完两周根据误报率回调慢慢就能摸到适合自己仓库的配比。上下文包最终的形态是一个JSON数组每个元素对应一个文件包含文件路径、语言、变更类型新增/修改/删除、hunk列表带上下文行、相关符号定义、命中的静态规则。这样做的好处是LLM不用在混乱的纯文本diff里做“阅读理解”而是直接处理已经剔除噪声的结构化数据。实测下来输出JSON的结构稳定性明显提高引用行号时也不再那么随心所欲。注意上下文包是整套系统的信息基础宁可多带一点相关符号的引用点也不要为了省token砍掉边界情况。LLM在信息不全时倾向于“脑补”而“脑补”出来的审查意见比没有更危险。2.2 为什么确定性层要做“初审报告”这可能是整套架构里最反直觉的部分流水线不只做数据整理它还要先生成一份“基础评审报告”把静态分析结果按严重度和文件聚合成初步结论。LLM Agent在此基础上工作而不是从零开始评审。这个设计是刻意的。静态分析器对风格、死代码、危险API的识别能力和一致性远强于LLM让LLM重新读一遍lint输出纯属浪费token还容易把Agent的注意力带偏。所以流水线先把确定性工具的结果打包成“已核实问题清单”LLM只需要在这张清单之上做总结和补充去挖掘流水线发现不了的深层次缺陷。这个分工避免了两层之间的大量重复劳动也让每一层都只干自己擅长的事情。环节确定性工具主责LLM Agent主责diff提取与行号映射是否语法错误与风格问题是否边界条件与错误处理缺失否是并发、竞态、状态一致性否是修复补丁生成否是报告位置定位与行号校验是否表格里每一行都是一条职责红线。越过红线的代价我后面讲踩坑的时候会具体说这里先记住结论确定性层做不好LLM层一定跑偏。3. 确定性流水线的实现细节与参数设计这一段是全文最“干”的部分我按实际模块展开每个模块都给出能直接抄的参数与步骤。这些细节来自我自己的工程实践不一定是最优解但一定是经过生产环境验证过的可行解。3.1 diff解析与hunk分片处理的入口是git diff产物。这里有几个坑要重点说。第一不要直接拿原始diff文本当解析原文。需要按文件分隔、按hunk分隔并且保留 -a,b c,d 里的行号范围。这个范围是后面所有行号校验的依据。第二上下文行的选择直接影响Agent的理解质量。我试过默认3行上下文经常会丢掉变量声明导致Agent看不懂某个变量从哪来调到7行左右漏信息最少代价是token费用上涨。这里可以根据语言微调——函数式风格的代码返回逻辑往往依赖上面的变量定义上下文行要稍微放宽声明式风格的配置文件3行其实就够。第三处理rename和binary文件时直接跳过并打标记。不然diff解析器很容易把二进制内容误当文本把上下文包撑爆还会产出毫无意义的审查建议。解析之后的hunk对象我建议保持四个字段{ oldStart: 102, oldEnd: 125, newStart: 110, newEnd: 134, changedLines: [110, 111, 112, 118, 121], context: ...变更行前后的原始代码快照... }LLM拿到这个JSON之后可以精确地引用“变更后的121行”而不是像纯文本diff里那样报出对不上的行号。这个结构化行号引用在后续的结果校验和评论定位上非常关键几乎决定了报告的准确性上限。3.2 静态分析工具链的接入不同语言要接不同工具不要指望一套ESLint走天下。我这里梳理了一个最小可用清单JavaScript/TypeScriptESLint加TypeScript ESLint插件打开recommended配置按需增补几条团队自定义规则。PythonRuff。比Flake8快两个数量级规则覆盖面够还能直接做import排序检查。Gogo vet加golangci-lint前者查编译器级别的隐患后者补风格和复杂度检查。基础设施代码TFLint查Terraform的合法性和最佳实践。接入时不需要做额外加工跑一遍命令把结果转成统一Schema即可。上报项至少包含ruleId、severity、message、文件路径、行号。后面LLM层要用这些字段去解释告警schema不统一会让Agent的prompt写得非常痛苦。静态分析的结果需要跟diff的hunk做一次交叉过滤只有落在变更范围内的告警才进入“本次PR引入的问题”清单否则作为存量问题存到另一个队列防止Agent被历史债务刷屏。这个过滤规则看似简单实则是大幅度提升报告信噪比的关键。我见过不少团队第一步就栽在这里AI报告里一半内容是陈年老债开发者看两篇就再也不信任这个工具了。3.3 AST符号索引与相关代码定位这个模块决定了LLM对跨文件问题的理解上限。在静态分析之外我用各语言的AST解析器构建一个变更符号索引解析变更文件提取被修改的函数、类、变量名再到全仓库的AST索引里查这些符号被谁引用、调用点在哪里。这样“修改了A函数”这个事实就会被扩展成一个带引用方列表的上下文LLM才有机会发现“调用了A的那几个地方可能会受影响”。举个例子后端只改了用户认证函数的返回逻辑但没有同步改调用方的判空逻辑。纯diff视角下这个问题完全不透明但有了符号索引Agent能看到三个文件里的七处调用点自然就能意识到有一处调用点还在拿旧结构取数据。这种发现能力是“把diff丢给LLM”的做法永远做不到的。实际字段结构可以做成一个relatedSymbols数组{ symbol: authenticate, definedIn: auth/service.ts, referencedBy: [api/user.ts, api/admin.ts, worker/session.ts], callSites: [api/user.ts:34, api/admin.ts:21] }这个信息不需要全量构建维护一份增量索引就行。首次构建一次全仓cache之后只更新变更文件涉及的符号。对中小仓库来说一次全量构建几秒钟就能完成完全在可接受范围内。4. LLM Agent层的工作流设计到了LLM这一层真正的难题不是模型选型而是怎么约束模型只在确定性事实的基础上推理。模型选型反而简单主流商用模型和开源模型都能跑这个工作流差异主要体现在输出JSON的稳定性和指令遵循能力上建议用自己仓库的PR做一个小批量评测再定。4.1 多Agent角色分工我参考open-code-review的设计把Agent拆成三个角色reviewer、critic、patcher。reviewer负责提出主要发现输出severity、location、rationale、suggestioncritic专门对reviewer的发现进行反驳检查证据链是否成立有没有误伤patcher负责把已被critic认可的发现转成具体补丁。三个角色可以串行也可以reviewer与critic并行跑两轮再合并。这个角色拆分的理由很朴素让同一个模型既提问题又自我检查效果远不如让它先提、再让另一个实例专门挑刺。模型在“提出”和“反驳”两种思维模式下切换容易出现自洽性陷阱——为了维护上一轮观点而忽略新证据。拆成两个实例之后critic的目标函数变成了“找出reviewer的错误”反而能更干净地搜索漏洞。这也是LLM Agent工作流里少数几个有明确收益的角色拆分方案。4.2 抑制幻觉与“舔狗”效应的prompt设计prompt设计有几个要点直接影响报告质量。第一所有location相关的陈述必须引用结构化字段。提示词里明确写“引用lineNumbers字段中的具体值禁止推测行号”并且要求模型在引用位置时同时给出该位置的上下文行方便后续校验器核对。第二明确告诉模型当证据不足时允许输出insufficient_information。这个看似示弱的选项实际效果反而更强——它把模型从“必须找点问题出来”的压力里解放出来硬凑的建议少了真正有价值的发现反而更多。实测下来允许模型“认怂”之后整体报告的误报率下降了接近一半。第三“舔狗”效应是另一个坑。模型在拿不准的时候倾向于挑一些不痛不痒的小毛病来显得自己认真比如“建议变量名更语义化”之类。这类建议不是错但价值很低还会淹没真正的风险点。我的处理办法是要求reviewer把所有发现按severity排序并且强制输出一个highest_risk_analysis字段里面必须回答“这段代码如果跑在极端输入下会发生什么”。高风险的强制问题会逼模型把注意力集中在最危险的地方。4.3 置信度打分与证据链校验模型输出之后不能直接信任。我加了一层“证据校验器”拿LLM输出的JSON去比对确定性层的数据。校验三个东西行号是否存在且确实落在变更范围内。引用的symbol是否在AST索引里真实存在。引用的静态规则ID是否确实命中了对应文件。三项全过置信度记为high有一项不过降为medium并附带说明两项以上不过直接标为suspicious默认折叠不发给开发者。这套机制的本意不是完全信任校验器而是让低可靠性反馈沉底高价值反馈浮上来。工程师每天要看的信息太多了报告的排序方式决定了他们会先处理什么、忽略什么。置信度打分还可以叠加一个严重度矩阵。高严重度至少要同时满足两个条件涉及数据或状态一致性的潜在风险以及修复成本不太高。单一条件满足只给medium。这个校准规则能过滤掉很大一部分“听起来很吓人但实际无关紧要”的报告项。5. 从原型到准生产的踩坑实录这段写实际运行中遇到的典型问题按“现象-排查-解决”的结构来每一条的教训都值不少加班时间。5.1 幻觉行号把报告可信度拉崩早期最严重的问题第一版直接把LLM的评论写回GitHub评论区结果有一条高严重度评论指向根本不存在的行号开发者在评论区里花了不少时间才确认这是误报后续对AI报告的态度急转直下。排查下来问题出在两个地方。LLM在生成评论时脱离了结构化行号字段自己“脑补”了一个位置后端又没有对评论做校验就直接POST。解决方案分两层先把LLM的输出JSON改成强制引用lineNumbers字段但这只治标模型不遵守规则时任何prompt都救不了第二层是加评论前校验步骤行号不在变更范围内就给降级校验不通过就不允许生成高严重度标签。两层都用上之后这个坑才算填平。核心教训任何LLM输出在落地之前都必须有一道确定性闸门不能把模型的自我约束当作可靠保障。5.2 重复建议与严重度通胀上线第二天报告里出现了五六条“建议提取公共函数”的重复建议分布在不同文件里看起来像是发现了同类问题的多处实例实际上就是同一个模式被反复重复只是换了文件名和行号。我在聚合层加了去重逻辑按语义相似度做一次聚类只保留最核心的一条并把涉及的文件列表作为附件挂到这条报告后面。另外加了严重度校准规则同一模式触发多个文件的问题只把风险最集中、最能说明问题的那一条标为high其余统一降级。这样处理之后报告的条目数少了一大截信息密度却反而更高。5.3 成本与延迟的平衡刚开始全量跑所有模型调用时一个大型PR的token消耗接近10万单次成本4块多延迟三分钟。这个成本和速度对高频PR提交的团队来说很难接受。优化分三步走。第一低价值文件的上下文只保留hunk摘要不再带完整文件内容。第二静态分析命中极多文件时先让规则引擎按权重截断只让LLM处理最高优先级的Top 15个文件剩余文件只保留规则命中条目。第三reviewer和critic的并发调用从串行改成并行两个模型同时跑最后再做聚合。最终成本降到原来的40%左右p95延迟控制在40秒以内。对大多数团队的PR节奏来说这个延迟是完全可以接受的——毕竟人工review通常要等半天才能等来第一句评论。6. 团队落地与效果复盘架构跑通只是第一步真正难的是让团队接受AI的评审意见。这里我聊聊度量体系和团队引导经验这两块直接决定系统能不能从“玩具”变成“基建”。6.1 落地效果与度量体系建议至少盯四个指标PR处理时长从触发到报告产出加人工复核完成、误报率开发者标记为无效反馈的比例、高危问题发现数评审者确认需要修复的条数、修复采纳率AI建议被真正merge的比例。只盯报告产出速度没有意义要看它是否真正减少了漏检、提高了评审效率。我们团队跑了两个月后的实测数据供参考平均每个PR的报告产出时间从人工review的4小时缩短到15分钟人工只需要复核高危项高置信度问题中有超过60%被开发者接受并修复误报率稳定在10%以下主要误报集中在并发场景的过度担忧。这里要说明一下代码审查没有统一的行业benchmark每支团队代码风格和业务复杂度差异很大最好以自己仓库的历史数据做基线对比改进幅度才有意义。6.2 让团队相信AI评审的三个技巧第一先灰度到低风险仓库。挑一个工具链成熟、测试覆盖足的内部库跑上一周把报告质量调到靠谱再扩展到核心业务。直接拿核心仓库试点一旦报告质量问题频出AI审查这顶帽子扣上就很难摘掉。第二开放人工标记通道。开发者在评论里把误报标记掉这些标记要回灌成校验器的排除规则形成正反馈。给每一条AI报告设置“有用/无用”的反馈按钮这个数据的价值比token成本贵得多积累三个月之后过滤规则会变得非常精准。第三报告必须给出修复补丁。只报问题的AI是站着说话不腰疼能一键应用补丁的AI才是工程师愿意用的工具。patcher角色在这个阶段的价值就体现出来了——哪怕补丁只能覆盖一半的情况也值得生成工程师改起来比自己从零写快得多。提示灰度期间不要设置任何自动门禁让AI报告只作为建议存在。等误报率稳定在阈值以下再考虑接入CI门禁让高置信度问题阻塞merge。一上来就设门禁团队抵触情绪会非常大。整个系统跑顺之后我最深的体会是AI代码审查最大的敌人不是模型能力不足而是“什么都想交给模型”。open-code-review这套混合架构真正解决的事情是给模型划清了边界能用工具算清楚的绝不让模型猜测需要模型思考的给它最干净的数据。如果你也想在自己团队搭一套我的建议是不要一上来就追求全自动、全覆盖先把diff解析、静态分析、行号校验这三块确定性地基打牢LLM Agent再弱都翻不了车。后面有机会再聊聊这套系统怎么跟CI门禁联动、怎么把评审历史变成模型微调的反馈数据集那又是一个新的故事。这篇就先到这里该拿你仓库里最脏的那个PR试试水了。
混合架构下的LLM代码审查：确定性流水线与Agent的协同实践
1. 先聊聊为什么纯LLM撑不起代码审查代码评审这件事我干了有年头了带团队那会儿最头疼的从来不是写代码而是review PR。凌晨三点看到一个带着明显空指针风险的分支被merge进主干这种事儿发生过不止一次。所以当圈子里开始聊AI代码审查我第一时间就去试了最朴素的方案把diff整段丢给LLM让它“看看有没有问题”。结论很真实——能用但不敢信。纯LLM方案有三个绕不过去的死穴。第一个是幻觉。模型很可能振振有词地指出“第42行存在空指针解引用”而那行代码实际上是个shutdown钩子根本没有对象调用。更麻烦的是它引用的行号经常对不上号diff是变更内容行号是原文件的行号两者之间隔着一道映射关系模型往往在这个映射上翻车。第二个死穴是上下文窗口与仓库规模的根本矛盾。一个中型PR动辄改几千行牵涉十几个文件把全部diff塞进上下文既超预算又抓不住重点。第三个死穴是结果不可复现。同一个PR换一个模型、调一次温度甚至什么都不变重跑一遍输出都不一致。代码审查本质上是质量门禁门禁最怕的就是判断标准漂移。这不是模型能力不够而是选型错了。LLM擅长语义理解和模式识别但不擅长精确计算、全局索引和确定性规则执行。代码审查恰好是“精确模糊”的混合场景diff解析、lint规则命中、语法错误这类东西需要精确匹配而“这段逻辑有没有边界问题”“这个异步调用是否可能造成竞态”则依赖语义理解。单纯用LLM包办一切等于让一个语文老师去核对账本——字都能认账一定对不平。于是问题就变成了能不能把“精确”的部分先用确定性手段做完再把“模糊”的部分交给LLMopen-code-review这个项目的设计思路给我的启发正在于此。它没有试图做一个“全知全能的Agent”而是用一条确定性流水线把代码审查的前半程固化成标准工序再把结构化产物喂给LLM Agent去做推理与建议生成。整套思路说白了就是确定性工具干脏活累活LLM干动脑子的活中间用规整的数据格式衔接谁也不越界。这套架构对我们团队的意义很大。手里有七八个存量仓库历史债务一堆PR里一半是业务逻辑改动一半是补测试、重构和依赖升级。人工review既要盯历史包袱又要看新逻辑疲惫之下很容易漏掉深层问题。搭完这套混合架构之后AI先跑一遍“体力活”把低级的风格、边界、重复代码问题筛掉剩下真正需要人判断的部分再由LLM给出带推理链的分析评审者只需要重点复核AI标出的高置信度问题。实际体验下来这等于把评审从“全程阅读”变成了“抽查复核”省下来的时间相当可观。1.1 确定性流水线到底解决什么问题一句话确定性流水线负责把代码变更“翻译”成LLM能高质量理解的结构化数据并且顺带解决一批压根不需要AI参与的问题。它在代码审查里承担的角色类似生产流水线上的定位夹具——每个工件到工位之前已经被固定好姿态机器人才不会抓瞎。具体来说流水线要处理四类脏活。第一是diff解析从VCS里拿到原始diff解析成hunk粒度的结构化数据保留变更文件路径、变更行号、上下文快照。第二是静态分析注入跑ESLint、Ruff、go vet这类确定性工具把命中的规则、严重级别、报错行整理成标准化entry。第三是依赖关系分析通过AST解析变更文件的import关系确定哪些符号、哪些文件与本次变更相关。第四是历史检索在仓库历史PR里检索相似改动、相似报错形成“此类问题已知的处理方式”参考集。这四类输出凑到一起就是LLM Agent的“全套案卷”。1.2 LLM Agent在这里的定位LLM Agent不是空手接diff而是基于流水线给出的“案卷”做推理。它的任务分三个层次。第一层是分类与解释把静态规则的告警翻译成人话说明为什么这样写会出事。第二层是发现流水线“看不见”的问题比如并发逻辑里的竞态、异常吞掉后的状态不一致、多文件之间互相矛盾的假设。第三层是生成修复建议甚至完整补丁。这里有一条重要的架构纪律Agent的输出必须经过确定性校验才能进最终报告。Agent说“第102行有副作用”流水线要先验证102行确实存在且指向预期符号验证通过才标记为高置信度否则一律降级为“疑似”。这套“AI提报、机器核实”的闭环正是open-code-review这类混合架构最值钱的资产也是我建议任何想自己搭AI审查平台的人优先搬走的模块。2. 混合架构的整体设计与数据流转如果让我用一个词形容这套架构的特点就是“各司其职”。整条流水线发端于一个webhook事件止于一份带置信度评分和修复建议的评审报告。任何一个环节出问题都有一条明确的回退路径不会因为LLM抽风导致整条链路雪崩。数据流转大致是这样PR open或synchronize事件触发流水线先做基础检票拿到PR元数据、目标分支、变更文件列表然后进入diff解析阶段把原始diff拆成hunk对象接着并行跑静态分析器和AST分析器再组装上下文包随后LLM Agent评审之后是结果校验最后聚合去重写回代码平台的评论区或Check Run。听起来流程很长但每个环节的输入输出都是明确Schema的JSON两边互不猜测。这一点怎么强调都不过分确定性极强的那部分跟Agent合作的前提就是结构化契约——如果AI上游给的是free textAgent给出的也必然是free text工程化就无从谈起。2.1 上下文包的组装策略最偷懒的做法是把整个PR的diff一股脑塞给LLM这也是我最开始犯的错误。open-code-review的处理方式更有意思先给变更文件打分排序只把高价值的文件完整带上低价值文件只带hunk摘要。文件价值怎么评我用三个指标加权改动行数、文件在import依赖图里的被依赖次数、文件自身的变更频率。经常变的文件往往承载核心业务被依赖次数多的文件一旦改错影响面大这两类文件天然值得投入更多token。三个权重先用启发式跑完两周根据误报率回调慢慢就能摸到适合自己仓库的配比。上下文包最终的形态是一个JSON数组每个元素对应一个文件包含文件路径、语言、变更类型新增/修改/删除、hunk列表带上下文行、相关符号定义、命中的静态规则。这样做的好处是LLM不用在混乱的纯文本diff里做“阅读理解”而是直接处理已经剔除噪声的结构化数据。实测下来输出JSON的结构稳定性明显提高引用行号时也不再那么随心所欲。注意上下文包是整套系统的信息基础宁可多带一点相关符号的引用点也不要为了省token砍掉边界情况。LLM在信息不全时倾向于“脑补”而“脑补”出来的审查意见比没有更危险。2.2 为什么确定性层要做“初审报告”这可能是整套架构里最反直觉的部分流水线不只做数据整理它还要先生成一份“基础评审报告”把静态分析结果按严重度和文件聚合成初步结论。LLM Agent在此基础上工作而不是从零开始评审。这个设计是刻意的。静态分析器对风格、死代码、危险API的识别能力和一致性远强于LLM让LLM重新读一遍lint输出纯属浪费token还容易把Agent的注意力带偏。所以流水线先把确定性工具的结果打包成“已核实问题清单”LLM只需要在这张清单之上做总结和补充去挖掘流水线发现不了的深层次缺陷。这个分工避免了两层之间的大量重复劳动也让每一层都只干自己擅长的事情。环节确定性工具主责LLM Agent主责diff提取与行号映射是否语法错误与风格问题是否边界条件与错误处理缺失否是并发、竞态、状态一致性否是修复补丁生成否是报告位置定位与行号校验是否表格里每一行都是一条职责红线。越过红线的代价我后面讲踩坑的时候会具体说这里先记住结论确定性层做不好LLM层一定跑偏。3. 确定性流水线的实现细节与参数设计这一段是全文最“干”的部分我按实际模块展开每个模块都给出能直接抄的参数与步骤。这些细节来自我自己的工程实践不一定是最优解但一定是经过生产环境验证过的可行解。3.1 diff解析与hunk分片处理的入口是git diff产物。这里有几个坑要重点说。第一不要直接拿原始diff文本当解析原文。需要按文件分隔、按hunk分隔并且保留 -a,b c,d 里的行号范围。这个范围是后面所有行号校验的依据。第二上下文行的选择直接影响Agent的理解质量。我试过默认3行上下文经常会丢掉变量声明导致Agent看不懂某个变量从哪来调到7行左右漏信息最少代价是token费用上涨。这里可以根据语言微调——函数式风格的代码返回逻辑往往依赖上面的变量定义上下文行要稍微放宽声明式风格的配置文件3行其实就够。第三处理rename和binary文件时直接跳过并打标记。不然diff解析器很容易把二进制内容误当文本把上下文包撑爆还会产出毫无意义的审查建议。解析之后的hunk对象我建议保持四个字段{ oldStart: 102, oldEnd: 125, newStart: 110, newEnd: 134, changedLines: [110, 111, 112, 118, 121], context: ...变更行前后的原始代码快照... }LLM拿到这个JSON之后可以精确地引用“变更后的121行”而不是像纯文本diff里那样报出对不上的行号。这个结构化行号引用在后续的结果校验和评论定位上非常关键几乎决定了报告的准确性上限。3.2 静态分析工具链的接入不同语言要接不同工具不要指望一套ESLint走天下。我这里梳理了一个最小可用清单JavaScript/TypeScriptESLint加TypeScript ESLint插件打开recommended配置按需增补几条团队自定义规则。PythonRuff。比Flake8快两个数量级规则覆盖面够还能直接做import排序检查。Gogo vet加golangci-lint前者查编译器级别的隐患后者补风格和复杂度检查。基础设施代码TFLint查Terraform的合法性和最佳实践。接入时不需要做额外加工跑一遍命令把结果转成统一Schema即可。上报项至少包含ruleId、severity、message、文件路径、行号。后面LLM层要用这些字段去解释告警schema不统一会让Agent的prompt写得非常痛苦。静态分析的结果需要跟diff的hunk做一次交叉过滤只有落在变更范围内的告警才进入“本次PR引入的问题”清单否则作为存量问题存到另一个队列防止Agent被历史债务刷屏。这个过滤规则看似简单实则是大幅度提升报告信噪比的关键。我见过不少团队第一步就栽在这里AI报告里一半内容是陈年老债开发者看两篇就再也不信任这个工具了。3.3 AST符号索引与相关代码定位这个模块决定了LLM对跨文件问题的理解上限。在静态分析之外我用各语言的AST解析器构建一个变更符号索引解析变更文件提取被修改的函数、类、变量名再到全仓库的AST索引里查这些符号被谁引用、调用点在哪里。这样“修改了A函数”这个事实就会被扩展成一个带引用方列表的上下文LLM才有机会发现“调用了A的那几个地方可能会受影响”。举个例子后端只改了用户认证函数的返回逻辑但没有同步改调用方的判空逻辑。纯diff视角下这个问题完全不透明但有了符号索引Agent能看到三个文件里的七处调用点自然就能意识到有一处调用点还在拿旧结构取数据。这种发现能力是“把diff丢给LLM”的做法永远做不到的。实际字段结构可以做成一个relatedSymbols数组{ symbol: authenticate, definedIn: auth/service.ts, referencedBy: [api/user.ts, api/admin.ts, worker/session.ts], callSites: [api/user.ts:34, api/admin.ts:21] }这个信息不需要全量构建维护一份增量索引就行。首次构建一次全仓cache之后只更新变更文件涉及的符号。对中小仓库来说一次全量构建几秒钟就能完成完全在可接受范围内。4. LLM Agent层的工作流设计到了LLM这一层真正的难题不是模型选型而是怎么约束模型只在确定性事实的基础上推理。模型选型反而简单主流商用模型和开源模型都能跑这个工作流差异主要体现在输出JSON的稳定性和指令遵循能力上建议用自己仓库的PR做一个小批量评测再定。4.1 多Agent角色分工我参考open-code-review的设计把Agent拆成三个角色reviewer、critic、patcher。reviewer负责提出主要发现输出severity、location、rationale、suggestioncritic专门对reviewer的发现进行反驳检查证据链是否成立有没有误伤patcher负责把已被critic认可的发现转成具体补丁。三个角色可以串行也可以reviewer与critic并行跑两轮再合并。这个角色拆分的理由很朴素让同一个模型既提问题又自我检查效果远不如让它先提、再让另一个实例专门挑刺。模型在“提出”和“反驳”两种思维模式下切换容易出现自洽性陷阱——为了维护上一轮观点而忽略新证据。拆成两个实例之后critic的目标函数变成了“找出reviewer的错误”反而能更干净地搜索漏洞。这也是LLM Agent工作流里少数几个有明确收益的角色拆分方案。4.2 抑制幻觉与“舔狗”效应的prompt设计prompt设计有几个要点直接影响报告质量。第一所有location相关的陈述必须引用结构化字段。提示词里明确写“引用lineNumbers字段中的具体值禁止推测行号”并且要求模型在引用位置时同时给出该位置的上下文行方便后续校验器核对。第二明确告诉模型当证据不足时允许输出insufficient_information。这个看似示弱的选项实际效果反而更强——它把模型从“必须找点问题出来”的压力里解放出来硬凑的建议少了真正有价值的发现反而更多。实测下来允许模型“认怂”之后整体报告的误报率下降了接近一半。第三“舔狗”效应是另一个坑。模型在拿不准的时候倾向于挑一些不痛不痒的小毛病来显得自己认真比如“建议变量名更语义化”之类。这类建议不是错但价值很低还会淹没真正的风险点。我的处理办法是要求reviewer把所有发现按severity排序并且强制输出一个highest_risk_analysis字段里面必须回答“这段代码如果跑在极端输入下会发生什么”。高风险的强制问题会逼模型把注意力集中在最危险的地方。4.3 置信度打分与证据链校验模型输出之后不能直接信任。我加了一层“证据校验器”拿LLM输出的JSON去比对确定性层的数据。校验三个东西行号是否存在且确实落在变更范围内。引用的symbol是否在AST索引里真实存在。引用的静态规则ID是否确实命中了对应文件。三项全过置信度记为high有一项不过降为medium并附带说明两项以上不过直接标为suspicious默认折叠不发给开发者。这套机制的本意不是完全信任校验器而是让低可靠性反馈沉底高价值反馈浮上来。工程师每天要看的信息太多了报告的排序方式决定了他们会先处理什么、忽略什么。置信度打分还可以叠加一个严重度矩阵。高严重度至少要同时满足两个条件涉及数据或状态一致性的潜在风险以及修复成本不太高。单一条件满足只给medium。这个校准规则能过滤掉很大一部分“听起来很吓人但实际无关紧要”的报告项。5. 从原型到准生产的踩坑实录这段写实际运行中遇到的典型问题按“现象-排查-解决”的结构来每一条的教训都值不少加班时间。5.1 幻觉行号把报告可信度拉崩早期最严重的问题第一版直接把LLM的评论写回GitHub评论区结果有一条高严重度评论指向根本不存在的行号开发者在评论区里花了不少时间才确认这是误报后续对AI报告的态度急转直下。排查下来问题出在两个地方。LLM在生成评论时脱离了结构化行号字段自己“脑补”了一个位置后端又没有对评论做校验就直接POST。解决方案分两层先把LLM的输出JSON改成强制引用lineNumbers字段但这只治标模型不遵守规则时任何prompt都救不了第二层是加评论前校验步骤行号不在变更范围内就给降级校验不通过就不允许生成高严重度标签。两层都用上之后这个坑才算填平。核心教训任何LLM输出在落地之前都必须有一道确定性闸门不能把模型的自我约束当作可靠保障。5.2 重复建议与严重度通胀上线第二天报告里出现了五六条“建议提取公共函数”的重复建议分布在不同文件里看起来像是发现了同类问题的多处实例实际上就是同一个模式被反复重复只是换了文件名和行号。我在聚合层加了去重逻辑按语义相似度做一次聚类只保留最核心的一条并把涉及的文件列表作为附件挂到这条报告后面。另外加了严重度校准规则同一模式触发多个文件的问题只把风险最集中、最能说明问题的那一条标为high其余统一降级。这样处理之后报告的条目数少了一大截信息密度却反而更高。5.3 成本与延迟的平衡刚开始全量跑所有模型调用时一个大型PR的token消耗接近10万单次成本4块多延迟三分钟。这个成本和速度对高频PR提交的团队来说很难接受。优化分三步走。第一低价值文件的上下文只保留hunk摘要不再带完整文件内容。第二静态分析命中极多文件时先让规则引擎按权重截断只让LLM处理最高优先级的Top 15个文件剩余文件只保留规则命中条目。第三reviewer和critic的并发调用从串行改成并行两个模型同时跑最后再做聚合。最终成本降到原来的40%左右p95延迟控制在40秒以内。对大多数团队的PR节奏来说这个延迟是完全可以接受的——毕竟人工review通常要等半天才能等来第一句评论。6. 团队落地与效果复盘架构跑通只是第一步真正难的是让团队接受AI的评审意见。这里我聊聊度量体系和团队引导经验这两块直接决定系统能不能从“玩具”变成“基建”。6.1 落地效果与度量体系建议至少盯四个指标PR处理时长从触发到报告产出加人工复核完成、误报率开发者标记为无效反馈的比例、高危问题发现数评审者确认需要修复的条数、修复采纳率AI建议被真正merge的比例。只盯报告产出速度没有意义要看它是否真正减少了漏检、提高了评审效率。我们团队跑了两个月后的实测数据供参考平均每个PR的报告产出时间从人工review的4小时缩短到15分钟人工只需要复核高危项高置信度问题中有超过60%被开发者接受并修复误报率稳定在10%以下主要误报集中在并发场景的过度担忧。这里要说明一下代码审查没有统一的行业benchmark每支团队代码风格和业务复杂度差异很大最好以自己仓库的历史数据做基线对比改进幅度才有意义。6.2 让团队相信AI评审的三个技巧第一先灰度到低风险仓库。挑一个工具链成熟、测试覆盖足的内部库跑上一周把报告质量调到靠谱再扩展到核心业务。直接拿核心仓库试点一旦报告质量问题频出AI审查这顶帽子扣上就很难摘掉。第二开放人工标记通道。开发者在评论里把误报标记掉这些标记要回灌成校验器的排除规则形成正反馈。给每一条AI报告设置“有用/无用”的反馈按钮这个数据的价值比token成本贵得多积累三个月之后过滤规则会变得非常精准。第三报告必须给出修复补丁。只报问题的AI是站着说话不腰疼能一键应用补丁的AI才是工程师愿意用的工具。patcher角色在这个阶段的价值就体现出来了——哪怕补丁只能覆盖一半的情况也值得生成工程师改起来比自己从零写快得多。提示灰度期间不要设置任何自动门禁让AI报告只作为建议存在。等误报率稳定在阈值以下再考虑接入CI门禁让高置信度问题阻塞merge。一上来就设门禁团队抵触情绪会非常大。整个系统跑顺之后我最深的体会是AI代码审查最大的敌人不是模型能力不足而是“什么都想交给模型”。open-code-review这套混合架构真正解决的事情是给模型划清了边界能用工具算清楚的绝不让模型猜测需要模型思考的给它最干净的数据。如果你也想在自己团队搭一套我的建议是不要一上来就追求全自动、全覆盖先把diff解析、静态分析、行号校验这三块确定性地基打牢LLM Agent再弱都翻不了车。后面有机会再聊聊这套系统怎么跟CI门禁联动、怎么把评审历史变成模型微调的反馈数据集那又是一个新的故事。这篇就先到这里该拿你仓库里最脏的那个PR试试水了。