先说个我自己的经历。2024年年初我刚接触AI代码审查这个概念的时候第一反应是直接用ChatGPT看diff不就行了。于是我写了套脚本每次PR把git diff的文本抽出来拼上一段请帮我找bug的提示词扔给大模型。头几次跑完确实能找出点问题但到了第四周就发现了严重的问题同样一个错误在三个PR里报了三种不同的说法加了新文件之后旧文件的审查结果莫名其妙变了模型还会一本正经地在不存在的代码行上指出问题。那时我才真正意识到把LLM直接摊开在diff上是走不通的。后来我陆续接触了open-code-review这个开源项目里面把AI代码审查拆成了两段一段是确定性的代码流水线一段是LLM Agent的推理链路中间的接口是结构化的审查上下文。这个思路比把diff丢给GPT要靠谱得多。这篇文章我就想完整拆一下这个混合架构聊清楚哪些环节适合用程序做死哪些环节必须交给模型推理以及这两者是怎么粘起来的。内容适合正在搞AI工程化、想把AI Agent接入CI流程、或者准备自建代码审查工具的团队参考。1. 先踩一遍LLM裸审的坑为什么纯提示词审查站不住脚任何人在做AI代码审查的第一个版本时都会走上同一条路把diff当纯文本喂给LLM希望能直接得到就是这个文件、这几行、这个问题的审查结果。这个方案demo阶段确实惊艳但一旦进入工程化它的问题会像冰山一样接连浮出来。1.1 直接把diff喂给LLM会发生什么我最早那套脚本的Prompt结构大致长这样You are a senior code reviewer. Review the following diff and report bugs: diff_text看起来没有任何问题甚至很多商业化工具的第一版也是这么做的。但实际跑下来第一批问题很快出现了。第一是diff文本的上下文缺失。diff里只会出现被修改的行和相邻几行一个函数在diff里可能只有三行但函数体本身有80行那模型看到的这三行只是无根之木根本不知道这个改动在完整逻辑里的位置。我曾经遇到过这样一个案例PR里改了一个工具的输入参数默认值diff文本只显示一行变化模型给出的结论是该参数会影响函数内部行为建议谨慎。这句结论对任何改动都成立等于没说。后来我把完整函数体拼进去模型才提示这个默认值变更会影响外部模块对返回值的期待值。这就是典型的diff文本视角太窄问题。第二是提示词漂移。同一个检查空指针的需求我在第一次提问时写的描述是检查是否有潜在的空指针解引用跑了200个PR之后稍微调整成了查找可能出现的NPE看起来是同一个意思但模型给出的结果分布完全不同。这不是模型不稳定而是LLM对提示词的每一个词都敏感尤其当审查规则没有结构化沉淀、只存在于自然语言描述里时规则的一致性根本保证不了。第三是token消耗爆炸。一个200行左右的文件diff文本一般在6-8K token。一个大型PR涉及20个文件光把diff拼出来就快20K token了再加上系统提示词、审查规则描述、历史对话一轮审查轻松烧掉40K以上token。如果每个PR跑两轮一个月下来成本完全不可控。我做过一个粗略统计单次审查的API成本大约在3-6美元之间用的是当时的商用模型价格对一个中型团队来说这经费很快会让主管问一句这钱花得值吗1.2 从一次误报事故看LLM审查的幻觉边界比成本和稳定性更致命的是幻觉。纯文本模式下代码审查里常见的幻觉形式有这几种行号幻觉模型给出第42行存在风险但diff里根本没有第42行。变量幻觉模型认定某个变量可能为null但这个变量实际在更早的代码里已经被判空处理了模型没看到。语义幻觉模型把两个同名函数当成同一个函数基于错误的符号绑定给出结论。我印象最深的一次事故是这样的我们有个PR改了某个Redis连接池的初始化逻辑模型审查后给出了一条高优意见——该改动会遗漏连接池的异常关闭建议添加defer。事实是这个改动只是重新调整了参数顺序连接池的关闭逻辑在另一个地方由框架统一管理根本不需要defer。但由于模型在diff里看不到框架的自动回收机制它基于看到资源创建就必须看到资源释放的通用直觉产生了这条错误判断。当时这条误报还自动评论在PR下面团队成员看完直接对AI审查失去了信任。这件事给我的教训是LLM的推理范围不能超过它能看到的信息边界。如果模型看不到完整的调用链、看不到相关的初始化逻辑、看不到历史代码约定它的判断本质上就是基于统计规律的猜测而不是审查。1.3 工程化要解决的三个核心矛盾踩了这么多坑之后我把问题归纳成了三个矛盾这也是后来引入混合架构的直接原因第一个矛盾叫信息完整性与成本不可兼得。想让LLM做出准确判断就要给它更多上下文完整文件、调用关系、全局定义但上下文越多成本越高审查速度也越慢。如果不给上下文模型就只能在信息残缺的状态下瞎猜。第二个矛盾叫规则一致性 vs 自然语言的灵活。代码审查里大量规则是确定性的——不能使用不安全的反序列化函数没用的import必须要删变量命名必须符合项目规范。这些规则用LLM去判断每次结果都可能在边缘地带摇摆但用静态分析程序去判断1000次都是同一个结果。反过来也有一些问题比如这个接口的设计是否考虑了未来的扩展这个改动会不会影响正在运行的任务必须靠模型的语义理解能力这是规则程序做不了的。第三个矛盾叫体验层面的权威性。一旦LLM审查结果直接展示给开发者误报带来的信任打击是灾难性的。开发者看到一条明显错误的审查意见时他不会想这是AI能力有限他会想AI完全不靠谱——这个印象一旦形成后续所有审查结果都会被无视。所以工程化的关键不只是结果准确还要能筛选出哪些结果可以展示、哪些结果必须先过滤掉。这三个矛盾里面全部交给LLM和全部交给规则都是死路只有混合架构能让两边各发挥其长处。open-code-review的架构思路本质上是把审确定性检测和断语义推理拆开再通过一个中间的上下文协议把它们缝合起来。2. 确定性流水线和LLM Agent的整体分工谁负责看得准谁负责看得懂open-code-review这种混合架构我理解下来其实就一句话能算的坚决不算算不了才让LLM上。这里的算指通过解析、匹配、聚类、对比等确定性手段得出结果算不了指的是必须依靠语义理解、经验推断才能判断的问题。2.1 两条链路的职责边界我们先画一个大的分工图不涉及具体代码把每层的任务说清楚。确定性流水线处理的是任何一种静态分析工具都能精确回答的问题主要包括diff解析与变更定位准确知道改动了哪些文件、哪些函数、哪些行。AST级静态规则检测基于代码语法树的规则匹配比如禁止使用eval禁止硬编码密码函数嵌套层数过高。影响面分析通过符号表、调用关系图算出某个改动会影响哪些函数、哪些模块。历史聚类与去重把本次改动和历史上已经报告过的问题做相似度比对避免同一条问题反复出现在多个PR里。LLM Agent处理的是需要理解业务意图和上下文语义才能回答的问题主要包括改动意图推断从diff中的注释、命名、函数结构推断开发者想干什么。逻辑设计评审这个分支条件写反了吗这个异步操作有没有竞态风险这个错误处理路径是否完整架构层面建议改动是否符合项目的分层约定是否引入了不必要的耦合。两者之间不是先有鸡还是先有蛋的串行关系而是确定性流水线先产出结构化证据LLM Agent消费这些证据再产出推理结论的上下游关系。2.2 流水线的产物一份结构化的审查上下文为什么要强调结构化上下文因为LLM的推理质量完全取决于它拿到的病历是否完整、是否精确。我早期裸审失败的一个原因也在这里——我传递给模型的是一份无结构的diff文本它既是代码又是碎片既包含上下文又缺失上下文让模型自己去猜哪些行重要、哪些行是格式调整、哪些函数真正发生了变化。工程师会觉得这信息量足够了但对LLM来说无结构的信息等于低信噪比推理质量自然下降。open-code-review的做法是先由确定性流水线产出一份经过筛选与标注的审查上下文里面包含了每一个变更点的精确位置文件路径、函数名、行号区间每个变更点的变更类型标签新增逻辑、删除逻辑、命名调整、重构、格式修改关联的调用关系记录这个函数的调用方在哪些文件、哪些行已经匹配上的历史问题记录这份上下文的格式是标准化的可以当成一份JSON传给下游的Agent。LLM Agent要做的事情就变成了阅读一份结构化的病历然后针对性地回答问题而不是从一堆原始diff中大海捞针。这个设计带来的好处是确定性流水线先把噪声清理了一遍Agent的注意力可以集中在值得推理的地方。2.3 Agent的角色定位不是通才而是会读病历的专家LLM Agent这个词现在被用烂了什么场景都往上套。但在这个架构里Agent的角色定位非常清晰——它是一个受过训练的专科医生而不是一个全科神婆。它不需要去判断所有代码问题它只需要在被标记的变更点内根据病历结构化上下文和既往知识给出具体的诊断意见。这个角色定位有几个直接影响不需要一次性读完整仓库。Agent不需要理解整个项目的全貌它只需要理解这次变更涉及到的上下文。这就同时控制了token成本和推理速度。每个Agent只负责一个领域。你可以为不同的审查场景配置不同的Agent比如并发安全Agent错误处理Agent性能优化Agent每个Agent的System Prompt和工具调用范围都不同而不是让一个大而全的模型什么都干。Agent必须引用证据。Agent的任何一条审查意见必须引用确定性流水线给的证据锚点文件、行号、符号名。如果它给不出证据这条意见就不被接受要么丢弃要么降级为建议级别。换句大实话如果你希望LLM像人类资深工程师一样扫一眼全仓库就给出高质量评审那你既低估了工程化的复杂度又高估了当前LLM的上下文利用效率。工程化的正确姿势是把扫描全仓库这件事交给程序把对扫描结果的语义理解交给模型。3. 确定性流水线里的关键模块这些死功夫是AI审查的地基很多做AI代码审查的人花最多时间在调Prompt上却忽略了真正决定上限的是确定性流水线的质量。Prompt调得再好也弥补不了输入上下文的残缺但上下文构建得足够扎实即使模型差一点也能给出可用的判断。这一节我们把确定性流水线拆开看。3.1 diff解析的边界处理rename、format、chunkdiff解析是整个流水线的输入源头如果这一步出了问题后面全白搭。Git的diff输出本质上只是行级别的变化描述如果你直接把git diff的结果当事实用会遇到三个坑。第一个坑是rename检测。开发者把文件utils.py重命名为helper.pygit diff在默认配置下会显示删除utils.py新增helper.py如果流水线不做rename检测它会认为这是一个大变更触发全量审查而实际上代码一行没动。处理办法是调用git log --follow --name-status或者解析git diff --find-renames的结果把rename操作单独归类不进入深度审查。这个逻辑我在最开始完全没注意直到一个纯rename的PR触发了80条审查意见其中79条是这个文件是全新的建议全面检查这种废话。第二个坑是formatting-only变更。代码格式化工具prettier、black、gofmt会一次性改动大量行造成diff的假膨胀。如果不把这部分识别出来流水线会看到几千行的diff白白浪费token。一种常见的做法是先跑一次格式化工具生成一个格式化前和格式化后的diff如果这个diff和PR提交的diff基本一致就可以把这次变更标记为仅格式化跳过LLM审查只跑确定性规则。这个判断逻辑本身也是确定性的两个diff之间的相似度可以用行级匹配算法计算。第三个坑是chunk边界导致的上下文割裂。一个函数修改了5处git diff会生成多个hunk每个hunk只显示函数内的一小块。如果直接把这些chunk丢给后续模块AST分析会因为这些片段不完整而解析失败。所以diff解析模块不能只做行级别的split要做变更块到函数体的映射——也就是说要根据AST把每个hunk映射到它所属的函数、类、或者代码块然后把整个函数体该函数内的变更行作为一个分析单元。这一步是AST和diff的结合点也是整个流水线里最容易被忽视的难点。我给一个参考实现思路用tree-sitter或你语言对应的解析库把整个文件解析成AST然后遍历diff里的每个hunk通过行号定位到AST节点往上找到最近的函数定义节点把该节点作为变更单元。这个方案我实际用过处理大多数语言都没问题唯一要注意的是AST的end_line和diff的行号对齐——因为Git基于原始文件计算行号而AST基于解析后的文件计算行号中间如果有CRLF换行符或者文件编码问题行号会错位需要先统一换行符再解析。3.2 AST级静态规则能程序判断的决不浪费Token在这个架构里静态规则引擎承担了大量高确定性、高重复性的审查任务。它的存在不是为了替代LLM而是把LLM从低价值的重复劳动里解放出来。规则引擎的权重我会分成三层层级规则类型示例处理方式P0安全性硬规则禁止eval、禁止系统命令拼接、禁止硬编码密钥直接失败/直接报错P1代码质量软规则未使用的import、重复代码块、过大的函数体报告且可由配置决定是否阻塞MRP2风格类规则命名规范、缩进、import排序通常交给格式化工具不进审查链路这个分层很关键。如果你把P2级别的规则也丢给LLM去判断它每一条都可能因为描述不清而产生微小的不一致并且你还要承担token成本。反而用程序处理这些规则能得到100%一致的结果。规则实现上我强烈建议用基于AST的精确匹配而不是正则表达式。很多早期工具喜欢用正则找password xxx这种模式但正则无法理解作用域也无法判断这个赋值发生在配置文件里还是代码逻辑里。AST匹配可以精确到某个赋值表达式所属的代码块是否在try-catch内这个变量的声明是否在函数外部。这个能力正则给不了纯粹的文本diff更给不了。这里给一个PHP代码为例早期我们用eval做模板渲染规则引擎可以直接在AST上定位CallExpression的callee是否是eval如果是再判断参数是常量还是变量。如果参数是一个常量字符串说明是静态模板风险较低如果参数是外部输入比如从$_GET获取则直接报P0阻断。这类判断在AST语义下十分精确在正则或纯diff下则完全做不到。3.3 影响面分析把调用链变成审查线索LLM审查的一个致命弱点是它无法准确回答一个问题改了这个函数的签名谁会受到影响模型可能会基于常识猜测潜在影响但它没有办法保证覆盖全部调用方。而这个问题恰恰是确定性分析工具的强项。影响面分析要做的事情简单说就是建立整个代码库的符号表和调用关系图计算出当前变更会波及哪些函数、哪些模块、哪些测试。具体做法大致是这几步通过AST抽取项目中所有函数/类/方法的定义位置、参数列表、返回类型。扫描所有函数体内的调用表达式建立调用方 - 被调用方的索引。拿到变更列表后找出每一个变更的函数UE反向查询调用方生成一个受影响的调用链列表。把调用链信息结构化地放进审查上下文供Agent使用。这个数据的价值在哪我举一个实际例子。某次PR把getUserById(int $id)改成了getUserById(string $id, bool $includeDeleted false)如果只把diff给LLM模型大概会告诉你参数类型改变了注意调用方需要同步修改。但如果影响面分析已经算出这个函数有12个调用方其中3个调用了参数2Agent就能给出精确得多的话函数getUserById的定义变更影响以下12个调用方其中3个未传第二个参数默认值false可能不符合调用意图需要逐一确认。前者是一句正确的废话后者是能直接推送给开发者的有效建议。影响面分析还可以和测试选择联动如果有调用链信息我们可以确定性地算出受影响的测试文件有哪些直接推送MR构建任务只跑受影响测试加速CI。这也是这个架构里我最喜欢的一个连带红利。3.4 历史聚类与去重让LLM不重复报同一个问题没有做过长期运行的代码审查工具的人很难理解去重竟然是核心问题。你只要把一个AI审查工具接入CI跑上一周就会发现开发者的核心反馈不是你漏报了XX问题而是你怎么又报了同一个问题我上周不是刚修过吗或者你这问题报了三个月了又不是本次改动引入的为什么要我处理AI审查工具的舆论崩盘往往就是从重复报告历史问题开始的。解决思路也很直接做一个历史问题的向量存储每次流水线检测到一个问题或者Agent产出结论后先和历史库里的问题做相似度比对如果没有命中才继续进入后续链路如果命中了就把本次报告合并到已有历史记录里不再重复推送。在open-code-review的架构里这个模块应该放在确定性流水线这侧原因很简单Agent不擅长做精确的相似度对比它可能基于看起来差不多就判定两个问题相同。而向量检索比如用sentence-embedding把问题描述转成向量再用余弦相似度排序是确定性可复现的阈值可控也更适合自动化处理。我建议的相似度判断策略是问题类型AST规则ID 文件路径 代码片段embedding相似度。只有当这三者同时满足条件时才认为同一问题。单纯靠自然语言相似度会被变量命名不同但逻辑相同这类问题骗到但加上了AST规则ID和文件路径误判率会大幅降低。去重这个细节决定了AI审查工具能不能长期在团队里生存绝不能省。4. LLM Agent 的编排与上下文工程让模型在正确的问题上花合理的token确定性流水线把病历准备好了接下来就是LLM Agent登场。但如果Agent的设计有问题前面所有结构化工作都会被浪费掉。Agent这层的核心是问题拆解、工具控制、上下文预算管理。4.1 Agent 的规划器设计先分文件再分问题域Agent跑起来的第一步不是直接读代码而是规划。规划器的任务是把一个总的审查任务拆成一个可以并行执行的子任务列表。我的做法参考了open-code-review的分而治之思路根据确定性流水线的输出按变更单元分组。每个变更单元是一个独立的文件函数级别的单元。对每个变更单元再根据问题类型分域——这个变更单元涉及并发改动交给并发安全Agent涉及数据库查询交给SQL性能Agent普通逻辑改动交给通用代码审查Agent。子任务之间互相独立可以并行执行最后汇总结果。这个设计的目的有两个一是避免了一个Agent同时处理多类型问题时上下文串味二是提高了系统的可扩展性——如果你想新增一个安全审查维度只需新增一个Agent子任务不需要改动整体架构。实际执行时需要注意的一个坑是Agent之间的结果不能直接合并因为不同Agent基于不同子集信息做出判断可能出现结论互相矛盾的情况比如并发Agent说需要加锁而性能Agent说加锁会影响性能。所以在汇总阶段需要有一个冲突消解规则通常是把更高置信度或更高优先级的Agent结论作为最终结论。4.2 工具调用的边界Agent 能看什么不能做什么很多人做AI Agent会陷入一个误区把Agent的能力做得过大让它能改代码、能执行命令、能自动提PR。这在代码审查场景下非常危险。审查Agent的核心原则是可以看不能动。open-code-review对Agent的Tool设计我总结了几个允许和禁止允许的工具读取变更单元对应的源码片段read_file可以和区域行号绑定比如读取第40-80行读取调用链相关文件read_symbol_refs基于影响面分析的结果精准定位调用方执行检索ripgrep/keyword_search用于查找特定模式在项目中的分布读取历史审查记录query_previous_reviews避免重复报告禁止的工具或在生产环境中默认关闭写文件、改代码执行任意命令自动提交PR访问外部第三方API除非明确允许这里有一个非常重要的工程判断Agent的读也必须有边界。不能让它读取整个文件而应该是读取指定行号区间的代码因为全文件扫描会瞬间撑爆上下文窗口。这个约束需要在工具层做死而不能依赖Agent的自觉——也就是说工具函数接收的参数只有file_path和line_rangeAgent根本不具备传入读取全部的能力。这个经验更多是试错试出来的我早期给Agent提供了read_full_file工具结果Agent在任何一个变更单元上都倾向于把整个文件读一遍一个2000行的文件读几次之后上下文窗口就被占满了后续Agent开始忘记之前的推理审查质量断崖式下降。4.3 上下文窗口与性价比让模型在刀尖上跳舞LLM Agent在代码审查场景下的最大资源瓶颈是上下文窗口但更大的问题是上下文利用率。模型不可能对上下文里的每个词给予同等的注意力给得太多了反而会稀释真正重要的信息。所以上下文工程的本质是让重要的信息密度足够高。我在实践中总结出的上下文构建优先级如下变更单元的函数体最高优先级Agent要审查什么就先看什么。函数的关键注释和文档包括函数头注释、变更行的行内注释这能辅助Agent理解意图。函数签名和调用参数不展开完整实现给签名信息即可。调用链关键节点的摘要不是全量调用方源码而是每个调用方怎么调用这个函数的一行。项目约定文档可选如果项目有CONTRIBUTING.md或者特定风格指南可以抽取相关段落放入上下文。一个8K token的上下文窗口通常能塞下2-3个函数体注释签名的完整信息单元。如果一次PR涉及10个变更单元我们不能把它们都塞进一个Agent上下文里——那会导致每个单元分到的注意力太少。正确的做法是按变更单元分批每批只放2-3个单元分多轮执行最后汇总。有人可能会问分批执行为什么不会丢失全局视角这个问题问得好。答案是**全局视角由确定性流水线提供而不是由LLM上下文提供**。影响面分析已经算出了这次变更会影响哪些模块Agent不需要自己发现全局影响它只需要确认并解释流水线给出的影响。因此在分批执行的模式下Agent的局部判断依然是全局可靠的因为它基于的影响面事实是精确的。4.4 输出层设计把自由文本变成可执行的评审报告Agent的输出如果是一段自然语言点评那下游没法处理。所以必须设计一个结构化的输出协议——这正是从demo级AI走向工程级AI的分水岭。我给Agent规定的输出schema大致长这样{ review_id: rev_20250207_001, file_path: src/core/UserService.php, line_start: 128, line_end: 135, severity: high, category: logic_error, summary: 条件判断导致空用户信息被提前返回, description: 当 $user 为 null 且 $includeDeleted 为 true 时函数会在初始化缓存前直接返回导致后续调用方读取到空的缓存记录, suggestion: 将缓存初始化逻辑移动到条件判断之前或在返回前显式处理空用户场景, confidence: 0.87, evidence_refs: [ {type: homograph, file: src/core/UserService.php, line: 128}, {type: caller, file: src/controller/AdminController.php, line: 74} ] }注意几个细节line_start和line_end必须指向真实存在的代码行这是硬约束我甚至会在输出层做一个行号验证器如果Agent给的行号超出文件行数范围直接丢弃该条审查结果。severity的定级逻辑也不能完全信任模型。我的做法是Agent先给一个主观置信度它是如何确信这个问题的再经过一个确定性规则做等级校正。比如如果该问题涉及public API的改动等级自动上调一级如果是测试代码内部的逻辑等级自动下调一级。这种模型判断 规则校正的模式是减少误报最有效的手段。evidence_refs是杀手锏功能。它要求Agent把结论挂靠到具体的代码证据上没给出证据的审查意见会被降级为信息提示不会成为必须处理的评审项。这个机制直接解决了我在第一章提到的幻觉问题——幻觉往往出现在模型没有证据支撑的时候强制它给证据幻觉率会大幅下降。5. 确定性链路和Agent链路的缝合证据、置信度、复审闭环前两章把两条链路分别讲完了现在到了最关键的环节它们是怎么缝合起来的我理解混合架构的灵魂不在任何一条链路本身而在于中间的那道接口协议。5.1 证据链LLM 观点必须挂靠代码行号先说一个最硬的原则LLM的每一个审查观点都必须能挂靠到至少一条确定性证据上。什么是确定性证据可以是一个代码行号来自git diff可以是一个符号引用来自影响面分析也可以是一个AST节点来自规则引擎。总之它必须是程序能够准确验证的事实而不是模型脑补的印象。设计这个约束的直接原因是在早期裸审方案中模型可以随意说出第45行有问题但如果程序去检查第45行发现那根本不在本次diff的变更范围内那条意见就成为幽灵意见——它说得可能对也可能不对但开发者无法判断该不该信。有了证据必须可校验这个约束审查系统的鲁棒性就有了质的提升。不合规的评审结果会被过滤开发者看到的每一条意见理论上都能找到对应的代码位置。这就让AI审查从一个玄学工具变成了有据可查的工程工具。在实现层面我会在流水线的汇总模块中加一个证据校验器。它的逻辑非常简单遍历每一条Agent输出检查evidence_refs里的行号是否落在本次PR diff的变更区间内只要有一条证据不在区间内就把该条意见标记为参考建议并从必须处理列表移除。5.2 置信度分级与自动过滤不是所有Agent输出都值得直接展示给开发者。我的做法是把审查结果分四档每一档对应的处理策略完全不同置信度等级判定条件处理策略P0静态规则直接命中且属于禁止类规则直接阻合MR自动通知P1Agent给出高置信度 证据完整作为建议修改项默认展示由人工确认P2Agent给出中等置信度证据部分完整作为可讨论项折叠展示P3Agent给出低置信度 / 无明确证据仅进入日志不向开发者展示这个分级机制的最大价值是把模型的噪声留在了内部把有效的信号放大给开发者。开发者看到的不仅是AI给出的意见还看到了AI有多确定以及证据是什么信任感会显著提升。关于置信度的校准我补充一点经验模型的置信度数值和真实准确率往往不完全一致你需要定期做一次人工校准。方法很简单随机抽取100条审查结果让人类专家标注对/错/部分对然后用这个数据调阈值。比如模型置信度在0.9-1.0的结果人工判断准确率只有70%那么0.9这个阈值就不应该作为P1的进入门槛可能要上调到0.95。这个校准通常需要团队积累2-3个月的数据才能初见成效但一旦建立你对AI审查产出质量的判断就不再是感觉而是有数据支撑的。5.3 CI集成与增量执行的时机选择流水线搭好了怎么落到CI流程里里面也有细节。一个常见的错误是在每次push时都跑全量AI审查。成本高不说开发者也会被海量评论惹恼。更合理的策略是分多种触发时机Diff级执行每次push或commit时只跑确定性流水线做快速静态检查几秒内返回接在普通lint之后。PR级执行打开或更新PR时跑完整流水线确定性Agent产生结构化审查报告评论在PR上。这个级别的执行可以设定时间预算比如MR合并前必须执行完成。合并前闸口只把P0级意见作为必须解决的阻塞项。P1级意见作为建议不阻塞合并但会记录到技术债务看板。这里还有一个容易被忽视的设计点增量审查 vs 全量审查。一个长期运行的仓库之前积累了大量历史问题——如果每次PR都全量审查系统会反复报告那些历史遗留问题开发团队会觉得烦不胜烦。所以必须引入本次变更引入的新问题检测机制对于没有变化的代码区域不执行LLM Agent审查只有变更区域内的问题才被报告。这个机制在实现上并不复杂把变更文件变更行号作为过滤条件只分析落在这些行号区间的问题即可。另外补充一个性能优化的技巧Agent调度要做并行化。一个PR如果涉及10个变更单元那理想状态下应该起10个Agent并发跑注意上下文隔离最后集中汇总。我用Python asyncio并发调用模型API10个单元通常能压到90秒左右跑完一轮这个速度在CI里基本不会拖慢MR流程。如果做成串行执行一轮要跑10-15分钟开发者早就失去耐心了。6. 从Demo到生产落地open-code-review的工程实战最后一部分聊一聊真正把这套架构跑起来会遇到的坑和选择。我在这上面折腾了几个月很多经验都是拿真金白银换来的。6.1 最小可用配置从零把一个仓库接进来如果你在主仓库里还没有任何AI审查工具我建议按这个顺序接入而不是一上来就全量上第一步接diff解析 AST规则引擎。只跑确定性流水线不启用LLM Agent。这一步成本很低FastAPI/TypeScript/Python等生态里都有现成的库。跑上两周让团队适应每次MR有静态扫描结果。第二步接影响面分析 历史去重。先把上下文构建的基础打好确保后面Agent跑起来有病历可用。第三步接LLM Agent但只在草稿模式下运行。Agent的输出只进入内部Slack频道或日志不评论在PR上。团队可以观察一两周看意见类型、准确率、成本。第四步正式启用P1级评论保留P3级过滤。开始收集人工校准数据调优置信度阈值。这个渐进策略的核心价值是每一步都有可验证的收益而不是憋一个大招然后全部推翻。技术团队最容易犯的错误就是想一步到位。6.2 模型选型与私有化部署的取舍模型选型这个问题上没有万能答案取决于你的团队体量和成本承受力。我大体分三种情况小型团队5-10人直接用商用大模型的API选性价比高的中档模型不带最大参数的那个并把上下文窗口限制在8-16K。这类模型在普通代码审查场景下已经够用没必要上最贵的那档。中型团队10-50人可以考虑把确定性流水线完全本地化运行只把Agent推理的请求发送到云端大模型API。也就是程序判断全部留在本地只有语义推理部分出去。这个方案的月成本可控数据安全风险也能接受。大型团队有严格合规要求建议上私有化部署的开源权重模型。这里需要注意的坑是私有化模型的代码理解能力通常落后于商用模型一档所以必须更加依赖确定性流水线去做硬过滤把Agent的任务范围收窄到解释和确认而不是发现。不管选哪条路我强烈建议做一层模型无关的接口封装。把LLM调用抽象成统一的接口底层可以随时切换模型这样将来哪个模型的代码理解能力有突破你换起来就不用伤筋动骨。6.3 实测效果与数据审得准不准用数据说话我不会去声称任何通用的准确率因为不同代码库、不同开发水平、不同业务复杂度下结果差异极大。但我可以分享一套我自己的统计口径和典型的参考数据方便你建设自己的评估体系。我用的统计口径是这三个采纳率开发者真正接受并据此修改代码的比例。我观察到的基线是60%-75%如果低于50%说明你的Agent输出和团队实际标准之间存在系统性偏差需要调Prompt或调置信度阈值。误报率被人工标记为无效的审查意见占比。基线应该在15%以下。最开始时我跑出来是30%后来靠证据必须挂靠行号和置信度分级过滤压到了10%左右。漏报率不太好量化通常用人审小组抽查来评估我会定期抽取20%的PR让资深工程师补充Agent没提到的问题据此判断漏报模式。重要提醒这些数字不是为了证明AI比人强而是为了证明AI审查可以稳定地守住底线。我个人的真实体会是AI代码审查最靠得住的价值不在于发现复杂逻辑漏洞这种事模型偶尔能行但不稳定而在于每次都能稳定发现低级错误、安全隐患、规范违背。它像是团队里的自动化质检员不会疲劳不会漏检不会因为心情不好跳过某一个文件。真正代码气味级别的审查还是要靠人的经验。6.4 团队的落地节奏与心理建设工具链建设只是工程化的半边天团队接受度是另外半边。我见过太多优秀的技术方案死在开发者不信任、不愿意看、不愿意改上。几点实践建议把审查意见从命令改成问题。不要说这里必须改成xxx而是说这一行在什么条件下会导致xxx是否需要确认——降低开发者的防御心态。让资深工程师参与审查规则的制定。规则引擎里的每一条P0规则都需要经过团队里最资深的人确认而不是由工具链开发者自己定。否则规则会偏向工具维护者的偏好而非团队的工程标准。建立AI审查意见申诉通道。如果开发者认为某条意见是误报可以直接标注disagree这个反馈最终沉淀到校准数据里用来调整阈值和Prompt。这个过程本身就是在训练一套团队定制版的审查标准。别过度追求覆盖率。让AI审查覆盖安全问题低级错误规范符合就够了不需要覆盖架构合理性业务正确性——那不是当前LLM的强项硬上只会拉低信任度。6.5 后续可以扩展的方向这套混合架构跑顺之后还有几个方向我很看好一是审查规则的自动沉淀。当历史库中积累了足够多的人工确认过的问题后可以自动把它们抽象成新的静态规则——相当于一次LLM发现的问题未来用确定性规则去拦截。这是让系统成本越来越低的路径也是AI辅助工程化最有意思的部分。二是多语言仓库的支持。因为确定性流水线依赖AST每种语言都要单独适配解析器。但只要你把语言解析层抽象成接口新增语言的成本可以控制在接入一个tree-sitter parser 写语言特定的AST规则这个量级。三是从PR审查延伸到Issues和遗留代码。同样的上下文构建能力可以用在分析历史代码的风险等级上帮助团队做存量代码的技术债盘点。这块的价值可能比PR审查还大因为存量代码的问题密度通常远高于新代码而人工审计存量代码的成本更是高得惊人。我一直觉得AI代码审查这个词的最终形态不是一个更强大的LLM直接读代码而是程序把代码变成精确的结构化事实LLM在这些事实上做语义推理然后程序再校验推理结果。open-code-review的混合架构踩中的就是这个方向。照着这个思路去搭大概率不会走偏。