阿里开源OpenCodeReview：AI代码评审，只用Claude Code九分之一token

阿里巴巴最新开源了一款叫OpenCodeReview的工具，定位是AI驱动的代码评审CLI。它把评审拆成两条线：一条是确定性的流水线，管文件挑选、打包和规则匹配；另一条是LLM智能体，负责动态分析代码。空指针异常、线程安全、XSS、SQL注入这些常见问题，它都能查。

OpenCodeReview用Go写，走Apache 2.0协议开源。它的思路是不让AI去拍板那些本来就能定下来的事，比如选哪些文件、调哪些工具、怎么根据diff核实评审意见。正因如此，整个评审过程被切成若干阶段，每个阶段的确定性程度不一样：选文件、打包、匹配规则交给确定性组件，代码分析才交给AI智能体。

据介绍，这套工具在阿里巴巴内部已经供数万名开发者用了两年，支持OpenAI和Anthropic的模型，可以审Git diff、分支，也能审整个文件。Shopify高级开发工程师Tom Rochette试用后评价：

这套架构瞄准的是智能体真实出错的情形：变更集一大，覆盖就容易缺漏，行号会偏移，提示词也稳不住。项目不光放出了公开基准，还坦白承认自己在召回率上不占优——同类工具里，愿意这么讲清楚的没几个。

阿里巴巴给出的数据是，在一项覆盖10种语言、200个PR的内部基准测试里，OpenCodeReview的精确率和F1分数都高于Claude Code，而token消耗大约只是后者的九分之一。Rochette也提出了提醒：

独立跑过的基准测试只有一回，成绩很难看：拿 10 个 Martian-benchmark PR 来测，精确率只有 12% 左右。维护方不认可这个数字，把原因归到工具调用出了异常上；问题后来是修了，可修完并没有再做过独立验证。另外，这个工具的召回率是故意压得比通用智能体低的。团队要是想尽量多地把缺陷挖出来，得先明白一点：这本来就不是它的设计目标。

在《OpenCodeReview与确定性红利》一文里，HCLTech前瞻部署工程负责人Daniel Vaughan就召回率上限和AACR-Bench的适用范围发出警示：

就算按最优配置来，召回率也只有 20%，换句话说，专家标出来的问题里，有 80% 根本查不出来。那套用来保住精确率的确定性任务分发机制，顺带也卡住了它往跨文件、架构层面深挖的能力。

社区早期反馈里，讨论阿里巴巴基准测试成绩的不多，关注点更多落在架构上，尤其是把文件选择、规则匹配和评审意见定位交给确定性逻辑这一做法。Vaughan这样总结：

OpenCodeReview 的贡献不在于使用性能更强的模型，而在于更好的 harness 框架。通过在文件调度中注入确定性、限制工具访问以及通过独立的反思器进行过滤，它以极小的 token 成本实现了 2.17 倍的审查质量提升。

OpenCodeReview既能本地跑，也能和GitHub、GitLab、Gerrit、VS Code、MCP对接，还支持接入Claude Code、Codex、Cursor这类代码智能体。