AI 评审的规则集：通用大模型为什么容易漏

2026-07-28

数据截至 2026-07，价格与限额以各官网为准。

把 git diff 整段贴给通用大模型让它”帮我评审一下”，漏检的主要原因通常不是模型能力不足，而是这套做法缺了一层确定性的东西：哪些文件该看、看的时候对照哪些已知缺陷形态、意见最后落到哪一行。专门的 AI 评审工具和”手搓 prompt 评审”之间的真实差距，多半在这层脚手架上，而不在背后换了哪个模型。

常见的误解是：评审质量约等于模型强度，只要把模型从便宜的换成旗舰的，漏的自然就少了。实际用过一段时间的人会发现，换模型能改善措辞和推理深度，但那几类反复漏掉的问题——空指针、并发共享状态、拼接出来的 SQL——漏的位置往往还是老地方。因为这些问题不是”想不到”，是”没往那儿看”。

一、通用模型读 diff，先天缺的是变更之外的信息

diff 这个格式的本质是”改动行 + 少量上下文行”。对人来说这没问题，因为评审者脑子里装着这个仓库的其他部分；对一个只拿到 diff 的模型来说，它看到的世界就到上下文行为止。

举几个具体场景就明白了：

新增一行 user.getProfile().getName()，diff 里看不出 getProfile() 在哪些分支下会返回 null，模型只能靠命名猜。
往一个已有的成员变量里写值，diff 里看不出这个类的实例是不是单例、是不是被多个线程共享，线程安全问题就这么滑过去。
改了一个拼字符串的方法，diff 里看不出这个字符串最终被谁执行——是日志还是 SQL，决定了它是无害还是注入。

所以”漏”的第一层原因是信息不够，不是判断力不够。给它更强的模型，它依然看不到 diff 之外的东西。要补，只能靠工具层去主动取上下文，或者靠一份规则把”遇到这种形态就该去查什么”固化下来。

二、位置漂移和覆盖不全是两种不同的失败

自己写 prompt 做评审的人，大概率都撞见过这两类问题，但很多人把它们混为一谈：

位置漂移：模型说得对，但指错行。它告诉你”第 47 行有空指针风险”，你翻过去发现 47 行是个 import。这类失败特别消耗信任——一次指错，评审者下次就不看行号了，直接全文重读，工具的省时价值当场归零。

覆盖不全：改动有 12 个文件，模型认真评了前 3 个，后面的一笔带过。这种失败更隐蔽，因为输出看起来是完整的一份报告，你不逐个文件核对根本发现不了它跳过了什么。

这两类问题的成因不一样。位置漂移是输出格式与源码坐标之间没有校验环节，模型是”复述”行号而不是”计算”行号；覆盖不全是长上下文里的注意力分配问题，加上没有一个外部的清单在盯着”还剩哪些文件没评”。

阿里开源的 open-code-review 在仓库自述里明确把这两点列为它要解决的目标，做法是确定性流水线（文件筛选、规则匹配）加 LLM Agent 动态决策的两段式架构，并且有一个独立的评论定位模块负责把意见钉到具体行上。需要说明的是，这是项目仓库自己的描述，效果如何还得看你在自己代码库上的实测。

三、规则集的作用，是把”看什么”从模型的自由发挥里抽出来

理解了上面两类失败，规则集要干什么就清楚了：它不负责判断对错，它负责保证”该看的都看了”。

open-code-review 的仓库自述提到它带一套经过微调的内置规则集，覆盖 NPE（空指针）、线程安全、XSS、SQL 注入这四类。为什么偏偏是这几类值得先做成规则？共同点是它们在代码里有相对稳定的形态特征：

空指针有明确的触发形态——链式调用、可空返回值未判空、集合取值后直接用。
线程安全有明确的可疑对象——共享可变状态、非原子的读改写、错误的锁粒度。
XSS 和 SQL 注入有明确的数据流起点和终点——外部输入进来，未经处理进入渲染或执行。

有形态特征，就能用确定性的方式先把候选位置捞出来，再交给模型做具体判断。这跟”你自己看着办”是两种工作方式：前者的召回率由规则保底，后者的召回率完全取决于模型这一次的注意力落在哪。

反过来说，规则集也不是万能的。业务逻辑错误、需求理解偏差、接口语义不一致这些问题没有稳定形态，规则捞不出来，只能靠模型的理解力，也就仍然会漏。这是规则集这条路的天然边界，不要指望它把评审这件事整个包下来。

四、两段式架构的实际含义

“确定性流水线 + LLM Agent”这个说法听起来抽象，落到运行时其实是分工问题：

确定性的那一段做的是不需要智能的事——按扩展名和路径规则筛掉不需要评审的文件（生成代码、锁文件、测试快照），把改动按规则匹配打上标签，把行号坐标算准。这些事用代码写死，结果每次都一样，不会因为模型温度参数飘一下就变了。

LLM Agent 那一段做的是需要智能的事——在候选位置上判断这次改动到底有没有问题、严重程度如何、怎么改。这一段本来就有不确定性，也接受它有不确定性。

这个分工的好处是把不确定性关进了小笼子。评审报告的”骨架”（评了哪些文件、每条意见挂在哪一行）是确定的，可复现的；变化的只是意见内容本身。对比之下，纯 prompt 方案里骨架和内容都在飘，你连”这次和上次为什么不一样”都很难归因。

如果你现在就是拿 prompt 在做评审，不换工具也能借这个思路改：把”列出本次改动涉及的所有文件”作为第一步单独跑一遍，拿到清单后再按文件逐个送评，最后用清单核对有没有遗漏。这样至少把覆盖不全这一类失败压下去了。

五、上手 open-code-review 的最小路径

安装：

npm install -g @alibaba-group/open-code-review

配置和第一次评审：

ocr config provider          # 选 LLM 供应商
ocr config model             # 选模型
cd your-project
ocr review                   # 评审已暂存/未暂存的改动

交互式配置会引导你选供应商、填 API key，并自动做一次连通性测试，这一步能省掉不少”配好了但跑不通”的排查时间。

其他几种评审模式：

ocr review --from main --to feature-branch    # 分支对比
ocr scan --path internal/agent                # 整文件审计
ocr delegate preview                          # 由 AI agent 执行评审

关于模型供应商，仓库自述兼容 OpenAI 与 Anthropic 两种接口格式；具体支持哪些模型名以官方文档当前版本为准，别照抄旧教程里的模型名。

CI 集成方面，仓库列出的是 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 四种。如果你的团队用的是别的平台，就得自己把 CLI 包进流水线脚本，不要默认它开箱支持。

六、厂商自述的数字，该怎么读

这个项目仓库里有几个数字流传得比较广，值得单独说清楚它们的性质。

仓库自述提到，它在阿里内部经”数万开发者”使用、发现过”数百万个代码缺陷”；还有一条基准口径称，在更高精度的同时，token 消耗约为 Claude Code 的 1/9。

这三条都是项目仓库自己的口径，没有第三方复现。规模类数字（多少开发者、多少缺陷）属于内部统计，外部无从验证；1/9 这个比值更需要谨慎，因为 token 消耗高度依赖测试用什么仓库、什么改动规模、什么模型、评审深度设成多少，换一组条件结果可能完全不同。

我的建议是：把这些数字当作”项目方认为自己在这个方向上有优势”的信号，而不是当作选型依据。真要比，只能比公开可查的机制差异——是不是有独立定位模块、是不是带内置规则集、支持哪些 CI 平台、协议是什么。至于效果谁强，AI 评审这个赛道目前没有任何一家有可交叉验证的公开基准，谁说自己更准都只是自述。

想横向了解开源项目该怎么评估，可以看开源项目选型方法。

七、成本这一层容易被忽略

AI 评审跑在 CI 上，是按次触发的，量比想象中大。两条路径的账单结构不一样：

自己接 API 的工具（open-code-review 属于这类）：钱花在你自己配置的那个模型供应商上，按 token 计。变量是改动规模和评审深度，一个大重构 PR 可能顶得上几十个小改动。好处是账单透明，能自己控制模型档次。

平台自带的评审：以 GitHub Copilot code review 为例，仍在年付老计划上的 Pro / Pro+ 用户走 premium request 制，2026-06-01 起 code review 的模型倍率是 13，也就是每次 PR 或 IDE 里的代码评审扣 13 个 premium request；另外一个容易漏算的是，code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数。月付用户则已经迁到按用量计费的 AI Credits 制，计费口径不同。具体额度和当前政策以 GitHub 官方计费页为准，这块 2026 年变动比较频繁。

计费细节可以看Copilot 代码评审的成本怎么算。

实践上有个省钱做法：不要给所有 PR 都开全量评审。按路径规则区分——核心业务模块、涉及外部输入的接口层、并发相关的代码走完整评审；文案改动、配置调整、生成代码走跳过或轻量模式。这件事本来就该由确定性的文件筛选来做，也正好是前面说的那段流水线的价值所在。

八、把规则集变成你自己团队的

内置规则集覆盖的是通用缺陷形态，但每个团队真正反复出事的地方是不一样的。想把评审从”通用体检”变成”针对性复查”，可以试试这个顺序：

翻线上事故记录，把最近半年到一年的故障按根因归类，通常会发现前三类占了大半。
给每一类写出可识别的代码形态——不是”要注意并发安全”这种口号，而是”任何往静态 Map 里 put 的地方”这种能被搜到的特征。
先用最笨的方式验证：用 grep 或者静态检查工具在历史代码上跑一遍，看这条特征捞出来的东西里有多少是真问题。噪音太大就说明特征描述得不够具体，回去改。
确认有效之后再接进评审流程，作为 prompt 里的检查项或者工具支持的自定义规则。
定期回收：每季度看一次哪些规则从来没报出过真问题，该删就删。规则集膨胀是这套东西失效的主要方式——报得太多，人就全当没看见。

这个流程里最有价值的其实是第一步。多数团队没做过根因归类，凭印象觉得”我们主要是空指针问题”，翻完记录才发现真正的大头是配置错误或者上下游接口变更没同步。

九、诚实说局限

AI 评审现在能稳定提供的价值，是把一部分有形态特征的缺陷提前捞出来，以及给评审者提供一份”该看哪里”的导航。它现在做不到、短期也不该指望的事情有这么几件：

替代人工评审的判断。业务逻辑对不对、这个设计是不是引入了长期负担，这些问题模型给不出可靠答案，具体可以参考AI 写的代码能上生产吗里的讨论。
保证不漏。没有任何工具能给这个承诺，规则集只是把召回率的下限抬高一点。
零误报。误报率高到一定程度，团队会集体学会忽略它，这时工具的净收益是负的。上线初期要主动收集误报，宁可先关掉几条噪音大的规则。
跨仓库、跨服务的一致性检查。改了 A 服务的接口，B 服务没跟上——这类问题超出了单个 diff 的视野，目前主要还是靠契约测试和文档纪律，不是评审工具的强项。

另外提醒一句：把公司代码送进外部模型评审，涉及数据外发，这件事需要走内部合规而不是开发者自己决定，相关风险可以看AI 工具的数据安全风险。用自建或私有部署的模型能缓解，但要付出运维成本，这是个权衡。

小结

AI 代码评审漏检的主因，是通用模型只拿得到 diff 这点信息，加上没有外部清单盯着覆盖率和行号定位，所以换更强的模型收效有限。规则集的价值在于把”该看什么”固化下来，用确定性的筛选和匹配保住召回下限，把模型的不确定性限制在具体判断上。open-code-review 这类工具走的就是确定性流水线加 LLM Agent 的两段式路线，值得拿自己的仓库试一试，但仓库自述的那些性能与规模数字只能当信号看，各家都没有可交叉验证的公开基准。真正能拉开差距的动作，是从你自己团队的事故记录里长出一套小而准的规则，并且定期把不出活的规则删掉。