阿里 Open Code Review：确定性工程与 LLM 混合驱动的代码审查工具

开源AI开发者工具代码审查

OpenCodeReview 核心指标

阿里巴巴在 2026 年 6 月开源了一款名为 Open Code Review（简称 OCR）的 AI 代码审查工具。这不是又一个套壳 ChatGPT 的代码审查 demo，而是阿里集团内部跑了两年、服务数万开发者、识别数百万代码缺陷之后才孵化的生产级工具。截至 7 月 26 日，该项目在 GitHub 上获得了超过 12,900 个 star，Apache 2.0 开源协议。

核心问题：通用 Agent 做代码审查的三大痛点

如果你用过 Claude Code 配合 Skills 做代码审查，大概率遇到过这些问题：

覆盖不全——变更集一大，Agent 就会"偷懒"，只选择性地审查部分文件，跳过其他文件。在真实项目中，一个 PR 可能涉及几十个文件变更，通用 Agent 很难保证全部覆盖。

位置漂移——Agent 报告的问题与实际代码位置对不上，行号偏移、文件引用错误是家常便饭。开发者收到审查意见后，第一件事往往变成找问题对应的代码到底在哪里。

效果不稳定——基于自然语言的 Skills 难以调试，提示词改一个字，审查质量就可能大幅波动。同一份代码跑两次审查，结果可能差异巨大。

阿里团队在 HN（Hacker News）讨论帖中解释了开源动机：他们注意到社区里很多人要么花钱买类似的工具，要么用 Skills 让 AI 做代码审查。Skills 作为 sub-agent 确实是一种优雅的方式，能减少上下文污染，但它继承了通用 Agent 的固有限制——难以调试、难以评估、难以调优。因此他们选择用 Go 重写内部工具，做成独立 CLI 开源。

架构设计：确定性工程 × Agent 混合驱动

OCR 的核心设计理念是将"确定性工程"和"LLM Agent"结合，各司其职。

确定性工程——硬约束层

对于审查流程中"绝对不能出错"的环节，由工程逻辑而非语言模型来保证正确性：

精准文件筛选——明确哪些文件需要审查、哪些应该过滤。先做一轮筛选，确保重要的改动不会被遗漏。

智能文件打包——将关联文件归并为同一审查单元。比如 message_en.properties 和 message_zh.properties 会被打包在一起审查。每个文件包作为独立的 sub-agent 运行，上下文隔离，这是一种分治策略，在超大变更集下表现更稳定，同时天然支持并发。

精细化规则匹配——基于模板引擎，针对每个文件的特征匹配对应的审查规则，让模型聚焦在相关问题上。相比纯自然语言的规则引导，模板匹配的行为更稳定、结果更可预期。

外挂定位与反思模块——独立的评论定位模块和评论反思模块，分别提升 AI 反馈的位置准确性和内容准确性。这两个模块在 Agent 流程之外，作为确定性步骤对结果做二次校验。

Agent——动态决策层

Agent 的能力集中用在它真正擅长的地方：动态决策和上下文召回。

场景化提示词——针对代码审查场景深度优化提示词模板，在提升效果的同时降低 token 消耗。

场景化工具集——基于大规模生产数据中工具调用轨迹的分析（调用频率分布、重复调用率、新增工具对调用链路的影响等维度），从通用 Agent 工具集中裁剪出了一套代码审查专属工具集。

Benchmark：1/9 的 token 成本怎么来的

OCR 团队构建了一个真实场景的代码审查基准测试：从 50 个热门开源仓库中精选 200 个真实 PR，覆盖 10 种编程语言，由 80 多位资深工程师交叉标注，共计 1,505 个标注缺陷。

Benchmark 对比

测试在相同底层模型下对比了 Open Code Review、Claude Code 和 Codex 三种工具。结果一目了然：

模型工具F1PrecisionRecall平均耗时平均 Token
Claude-4.6-OpusOpen Code Review25.10%33.90% (301/889)20.00% (301/1505)1m23s385K
Claude-4.6-OpusClaude Code11.57%7.23% (435/5980)28.90% (435/1505)13m6s5,664K
GPT-5.5Open Code Review21.00%32.10% (234/728)15.50% (234/1505)2m51s422K
GPT-5.5Codex8.36%27.82% (74/266)4.92% (74/1505)2m58s525K

以 Claude-4.6-Opus 为例，OCR 消耗 385K token，Claude Code 消耗 5,664K token，后者是前者的 14.7 倍。README 中声称的"约 1/9 的 token"是基于 1,000 个 PR 的大规模平均值。

F1 分数的差异更为显著。同一模型 Claude-4.6-Opus，通过 OCR 运行的 F1 为 25.10%，通过 Claude Code 直接运行只有 11.57%——精确率（Precision）从 7.23% 提升到 33.90%。这意味着 Claude Code 直接审查会产生大量误报（5,980 条评论中只有 435 条有效），而 OCR 的确定性工程层把误报率压了下去。

不过 OCR 的召回率（Recall）低于通用 Agent，这是设计上的刻意取舍。在代码审查场景中，误报比漏报更致命——大量假阳性会让开发者对审查结果产生"狼来了"效应，最终忽略所有反馈。OCR 选择用更高的精确率换取更低的噪声。

HN 讨论中，有开发者用第三方基准测试验证了这一取舍：在 10 个 PR 上跑 OCR，召回率约 74%（找到了大量真实问题），但精确率只有约 12%（大量误报）。OCR 团队回应称测试版本中有一个关键工具调用的异常影响了整体性能，已在后续版本修复。另一位开发者指出，召回率和精确率的取舍没有标准答案，取决于团队文化：有些组织优先找到所有问题（高召回），有些组织优先减少噪声（高精确率）。

使用方式

安装

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

安装后全局可用 ocr 命令。支持 npm、安装脚本、GitHub Release 二进制、源码构建四种安装方式。

配置 LLM

bash
ocr config provider    # 选择供应商（内置 OpenAI/Anthropic 等，或自定义）
ocr config model       # 选择模型

OCR 本身不绑定任何模型供应商，兼容 OpenAI 和 Anthropic 协议。你可以用 Claude、GPT、GLM、Qwen、DeepSeek 等任何兼容 API 的模型。

审查命令

bash
# 工作区模式——审查所有暂存和未暂存的变更
ocr review

# 分支范围——比较两个分支
ocr review --from main --to feature-branch

# 单个 commit
ocr review --commit abc123

# 全量文件扫描——审查整个文件，不依赖 git diff
ocr scan
ocr scan --path internal/agent

# 恢复中断的审查
ocr session list
ocr review --from main --to feature-branch --resume <session-id>

委托模式

如果你已经在用 Claude Code 或 Codex 等 AI 编程助手，OCR 提供了委托模式：OCR 负责文件选择和规则解析，审查本身交给你的编程 Agent 用自己的 LLM 执行。OCR 侧不需要配置任何模型端点。

bash
ocr delegate preview
ocr delegate rule src/main.go src/handler.go

CI/CD 集成

OCR 支持 GitHub Actions、GitLab CI、GitFlic CI 和 Gerrit 集成，可以作为 CI 流水线中的自动化审查步骤运行。

编程 Agent 集成

OCR 可以作为 Claude Code 插件、Codex Skill 或 Cursor 插件安装，直接在编程助手中调用：

bash
# Claude Code 插件
/plugin install alibaba/open-code-review

# Codex Skill
npx skills add alibaba/open-code-review --skill open-code-review

# Cursor 插件
cursor-plugin marketplace add alibaba/open-code-review

安装后在编程助手中可以直接用自然语言调用：@Open Code Review review my current changes。

内置规则集

OCR 预置了阿里内部大规模生产环境中打磨的审查规则集，覆盖以下高危类别：

  • NPE（空指针异常）——Java/Kotlin 中的最高频运行时错误
  • 线程安全——并发场景下的竞态条件、死锁风险
  • XSS（跨站脚本）——前端输入验证缺失
  • SQL 注入——拼接 SQL 语句导致的安全漏洞

规则通过模板引擎与文件特征匹配，而非依赖模型自由判断。比如检测 SQL 注入时，确定性工程层会先识别出所有包含 SQL 拼接的代码段，再交给模型做具体分析。这种分层设计确保了规则覆盖的稳定性。

值得关注的细节

14 种语言支持——Java、TypeScript、Go、Python、Kotlin、C++、C 等主流语言，以及 JavaScript、Rust、PHP、Ruby、Swift、Scala 等。

OpenSSF Silver 认证——通过了 Open Source Security Foundation 的最佳实践评估，这在同类 AI 工具中比较少见。

会话回放——ocr session 命令可以查看历史审查记录，支持在浏览器中回放完整的审查过程（包括 Agent 的工具调用链路），方便调试和回溯。

OpenTelemetry 集成——支持遥测输出，可以接入可观测性平台监控审查质量。

适用场景

OCR 适合需要将 AI 代码审查系统化接入开发流程的团队：

  1. CI 流水线自动化审查——每次 PR 自动触发审查，精确到行的反馈直接出现在 PR comment 中
  2. 大型代码库审计——ocr scan 审查整个仓库或目录，适合接手陌生代码库时快速识别高危区域
  3. 编程 Agent 协作——通过委托模式与 Claude Code、Codex、Cursor 配合，让编程助手在编码时获得代码审查能力

对于个人开发者的小项目，直接在 Claude Code 里问一句"帮我 review 一下这段代码"也能用。OCR 的价值在规模化的团队场景中体现得更明显——当你需要在数百个 PR 上保持一致的审查质量时，确定性的工程约束比自然语言驱动更可靠。

GitHub: https://github.com/alibaba/open-code-review