一、AI生成的代码越来越多，但谁来审？
2026年6月，一个标志性事件震动了开源圈——Ladybird浏览器项目宣布停止接受公开代码贡献。
原因很直白：AI PR 太多了。每天几十个 AI 生成的 Pull Request 涌进来，维护者根本审不过来。审不过来的 PR，比没有 PR 更危险。
这不是 Ladybird 一家的问题。在阿里巴巴内部，AI 代码审查评论的占比已经达到了80%。真人参与实际审查的比例大幅萎缩。当一个组织里 8 成代码审查意见都是 AI 生成的——你怎么确保它不是在"自己审自己的代码"？
问题比这更严重。
阿里内部团队发现，用通用 Agent（比如 Claude Code + 一个 Review Skill）做代码审查，会系统性出现三个结构性问题：
第一，覆盖不全。变更集一大，Agent 就开始选择性审查——挑几个看起来重要的文件应付一下，剩下的直接跳过。你根本不知道它跳过了什么。
第二，位置漂移。Agent 说"第 42 行有问题"，你点过去，第 42 行是个空行。实际问题在第 38 行。在长文件里这种行号偏移尤其严重——你花在"找问题"上的时间，比"修问题"还多。
第三，质量不稳定。今天写个 Skill 提示词效果不错，改了两个字，审查质量断崖式下跌。纯自然语言驱动的流程，几乎没法系统化调试。
根源是同一个：纯语言驱动的架构，天生缺乏对审查过程的硬约束。Agent 该审哪些文件、评论该标在哪一行、什么类型的问题该报——这些不应该全是 LLM 的"自由发挥"。
面对这个问题，阿里没有选择"优化一下 Prompt"。他们从底层架构入手，做了一套确定性工程 × Agent 混合架构的方案。在内部跑了整整两年，服务了数万名开发者，识别了数百万个代码缺陷。
2026 年 5 月，他们把整套方案开源了——Open Code Review，GitHub 14,500+ Stars，登顶 Hacker News 首页（258 points），引发 270+ 条技术讨论。
这不是又一个"LLM 套壳工具"。这是在阿里体量下真刀真枪跑了两年的工程决策。
二、核心洞察：不是Agent不够聪明，是让Agent"什么都干"本身就是错的
用通用Agent做代码审查，本质上犯了什么错？
你把一个语言模型当成了一个审查工程师。但语言模型擅长的是理解意图、动态推理、自由生成——它不是为"精确、可重复、可审计"的工程任务设计的。
阿里的解法很朴素：把"不能出错"的部分交给工程代码，把"需要判断力"的部分交给Agent。
整个架构被拆成两个部分：
确定性工程——守边界的
这块负责代码审查流程中必须精确、不可失误的环节，全由工程逻辑保证，不交给LLM去"猜"：
精确文件筛选。哪些文件该审、哪些该过滤（比如lock文件、生成代码、第三方库），由工程逻辑决定，不是靠LLM判断。该看的改动一个不漏，不该看的不浪费Token。这从源头解决了"覆盖不全"——文件清单是算出来的，不是模型猜出来的。
智能文件打包。关联文件自动归并成一个审查单元。比如message_en.properties和message_zh.properties这对国际化资源文件，会被打包到一起审。每个包作为独立的子Agent运行，上下文隔离。这是一种分治策略——在超大变更集上天然稳定，而且支持并发审查。
精细化规则匹配。针对不同文件特征，自动匹配对应的审查规则。Java文件看NPE和线程安全，XML mapper文件看SQL注入，前端文件看XSS。基于模板引擎的规则匹配行为稳定、可预期——规则命中与否是确定性的，不随提示词波动。
外挂定位与反思模块。独立的"评论定位"模块确保行号准确；"评论反思"模块对生成内容做二次校验。这两个模块不是Prompt里的一句话，而是独立的工程组件。
Agent——做判断的
Agent的精力集中在它真正擅长的两件事上：
场景化调优的提示词。针对代码审查深度优化的提示词模板——不是"请帮我review以下代码"这种一句话，而是一整套经过实战验证的审查框架。
场景化调优的工具集。这个最有意思——工具集不是拍脑袋选的，而是从阿里内部大量生产数据的工具调用轨迹中蒸馏出来的。分析维度包括：调用频率分布、单一工具的重复调用率、新工具对整体调用链的影响。最终沉淀出一套专门为代码审查场景打造的工具集，比通用Agent的"万能工具箱"更稳定、更可预期。
这套分工的逻辑很清楚：能用代码确定性解决的，就别让模型去赌；模型该出力的地方（读上下文、判断意图、动态决策），就给它最聚焦的输入和最趁手的工具。
三、Benchmark说话：F1超Claude Code，Token只要1/9
说架构容易，拿数据难。Open Code Review放了一份真刀真枪的基准测试。
先看测试规模：
- 50个热门开源仓库
- 200个真实Pull Request
- 10种编程语言
- 80+位资深工程师交叉标注验证
- 1,505个标注缺陷作为Ground Truth
这个规模在代码审查评测里，是下了本钱的。
再看结果：
| 指标 | 含义 | vs Claude Code |
|---|---|---|
| Precision（精确率） | 报的问题中真实缺陷的比例 | 显著更高（更少误报） |
| F1 | 精确率与召回率调和平均 | 显著更高 |
| Avg Token | 每次审查消耗Token数 | 仅约1/9 |
| Avg Time | 每次审查耗时 | 更快 |
但有一个指标故意压低了：Recall（召回率）。Open Code Review的召回率低于通用Agent——这是刻意的设计取舍。阿里的逻辑是：宁可少报，不要噪音。
这个取舍对不对？社区有争议。有人在HN上拿第三方benchmark（codereview.withmartian.com）跑了10个PR子集，召回率约74%、精确率约12%、F1约20——不太好看。但也有人指出，这个benchmark本身对"golden issue"的标注就很主观，不同评审工程师对"什么算缺陷"判断不同。
关键不在于某个benchmark上的某次跑分。关键在于设计哲学：阿里选择优化Precision而非Recall，是因为误报不是免费午餐——开发者必须逐条看完才能知道哪些是假的，这直接消耗时间。如果AI报的大部分都是假问题，团队迟早会开始无视它。
就像Security Scanner：如果你每天收到500条告警，其中480条是误报——你不会更安全，你会直接关掉它。
为了支撑这套评测体系，南京大学与阿里巴巴TRE联合推出了AACR-Bench——一个专门为代码审查场景设计的评测基准。它不像传统benchmark那样直接拿原始PR评论当Ground Truth，而是采用"AI辅助 + 人类专家校验"的标注流水线，问题覆盖率比传统数据集提升了285%。它支持10种编程语言，提供完整的仓库级依赖上下文。这是把"怎么衡量一个AI代码审查工具好不好"这件事，本身做成了一个学术级工程。
四、不只是又一个Tool——这是"Agent不该什么都做"的宣言
Open Code Review为什么能两周冲到Trending #2？不只是因为阿里背书，更是因为它回答的问题太关键了。
过去半年，AI编程工具链的竞争主线很清晰：先是卷"谁能写得更好"，然后卷"谁能写得更少"，现在开始卷"谁能审得更准"。
从Ponytail（代码-54%）到caveman（Token-65%）到i-have-adhd（改输出风格），本质上都是在做"让Agent更聚焦"这件事。但Open Code Review迈出了一大步：它不是在优化Agent的能力边界，而是重新定义了Agent和工程代码的责任边界。
"确定性工程 × Agent混合"不是一个技术选型，而是一个工程哲学。它的潜台词是：不要把LLM当成银弹。LLM该做动态推理的部分让它做，该做确定性保证的部分用代码做。越是需要精确性、可重复性、可审计性的场景，这种混合架构就越必要。
这个哲学会影响的不只是代码审查。想象一下这些场景：
- CI/CD中的安全扫描。规则匹配用确定性引擎（已知的CVE模式），动态推理用Agent（新型攻击向量）。
- 合规审查。法规条款匹配用确定性模板，业务逻辑合理性用Agent。
- 数据库迁移审查。Schema变更影响范围用确定性图算法，业务语义正确性用Agent。
Open Code Review本身，本质上是一个专用Agent Harness的参考实现。它证明了一个重要命题：为特定场景定制的专用Agent，可以在效果和成本上同时碾压通用Agent。
这也是为什么它选择CLI形态而不是Skill形态。Skill把审查当成Agent的"一个子任务"——文件筛选、规则匹配、行号定位全部交给LLM自由发挥。CLI把这些环节外置为独立的工程模块，Agent只负责推理。这不是技术选型的差异，是架构哲学的分歧。
五、对我们的启示
回到开头那个场景：你让Claude Code做代码审查，它"偷懒"跳过了关键文件。
这个问题的答案，不是换一个更好的模型，或者写一个更精妙的Prompt。答案是：不要把审查这件事，100%交给一个你不知道它会不会"偷懒"的系统。
阿里这两年的实践证明了几个关键结论：
第一，专用Agent > 通用Agent（在具体场景）。同样的底层模型，Open Code Review的F1和Precision反超Claude Code，Token消耗只有1/9。不是因为模型更好，是因为把确定性工程做对了。
第二，"做减法"正在成为AI工程的主旋律。从colibri（1300行C跑744B模型）、ds4（12000行C跑284B模型）、到Open Code Review（把Agent的职责范围缩小到"只做判断"），AI基础设施正在从"让模型做更多"转向"让模型做更少，但做得更好"。
第三，代码审查是AI对工程质量的"最后一道防线"。当AI每天生成数千行代码、AI PR数量急剧上升、真人审查能力严重不足的时候——一个可靠的AI代码审查工具，是从"氛围编程"走向"工程级AI编程"的关键基础设施。
最后我想说一件事。
Open Code Review的README第一句话是：“Battle-tested at Alibaba’s scale.“这句话的分量不在于"Alibaba”，而在于"battle-tested”——经过两年实战，数万开发者的日常使用，数百万缺陷的检出。
这不只是一个Tool的发布。这是阿里在告诉你：我们试过了，纯Agent方案做不好代码审查。混合架构才是正路。
如果你在用AI编程工具，如果你的团队正在被"AI写的代码越来越多、真人审不过来了"这件事困扰——试试npm install -g @alibaba-group/open-code-review，然后跑ocr review。
让工程做工程擅长的事，让AI做AI擅长的事。这才是AI时代的工程智慧。
Open Code Review — 阿里内部AI代码审查工具，服务数万开发者两年，检出数百万缺陷。2026年5月开源，GitHub 14,500+ Stars。确定性工程 × Agent混合架构，F1超Claude Code，Token仅1/9。Apache 2.0协议。
本文首发于「圈圈的AI工程笔记」
