📌 评测对象：alibaba/open-code-review | 星数：28,651 · Fork 2,051（2026-09-16）| 协议：Apache-2.0 | 语言：Go（CLI）| 创建：2026-05-18 · 4 个月 | 今日 GitHub Trending +2,756（连续霸榜）| 前身：阿里集团内部官方 AI 审查助手（两年、数万开发者、数百万缺陷）
一句话定位："通用 agent 审代码像请了个聪明但不守规矩的实习生——会漏文件、行号对不上、心情还影响发挥；Open Code Review 把'绝不能出错'的环节全部焊死在工程管道里，LLM 只做它擅长的动态决策。" Open Code Review（命令 ocr）是阿里 Aone 团队把内部跑了两年、服务数万开发者、识别数百万缺陷的官方 AI 审查助手开源出来的产物：读 Git diff → 按规则把变更文件智能打包 → 分发给带工具能力的 LLM 子代理 → 输出行级精确评论。2026 年 5 月中开仓，4 个月 28.6k 星，今日仍以 +2,756 的增量霸着 Trending 榜首。
站内昨天刚写过同题材的shadcn/lint教程：1.7k星agent-first设计系统linter——shadcn 的思路是"写 agent 能验证的规则"，OCR 则是"把规则匹配本身做成确定性管道"，两者互为镜像，一起读更能看懂 2026 年代码质量工具的设计共识：别让 LLM 全权决定过程。
| 维度 | 评分 | 说明 |
|---|---|---|
| 理念与定位 | 9.5 | "确定性工程×Agent混合"是对纯语言驱动架构缺乏硬约束的正面回答，2026年agent工具里最清醒的分工哲学之一 |
| 工程含金量 | 9.0 | 智能文件打包（分治+子代理隔离上下文+并发）、模板引擎规则匹配、独立定位/反思模块，每个组件都有明确存在理由 |
| 实证效果 | 9.5 | AACR-Bench（50仓/200真实PR/10语言/1,505个工程师标注真值问题）开放在HuggingFace；同模型下Precision/F1超Claude Code、token约1/9 |
| 安全与规则 | 8.5 | 内置NPE/线程安全/XSS/SQL注入多语言规则集，OpenSSF Best Practices Gold；Recall刻意偏低需知情 |
| 上手成本 | 9.0 | npm -g一条装、ocr config交互式配provider（自动测连通）、ocr review开审；委托模式连API key都不用配 |
| 文档质量 | 9.0 | 官网docs体系覆盖安装/CLI/规则/配置/MCP/CI-CD/Viewer/Telemetry/FAQ，英中日韩俄五语README |
| 生态与扩展 | 9.0 | 五大编码agent插件（Claude Code/Codex/Cursor/OpenCode/QCA）+四种CI（Actions/GitLab/GitFlic/Gerrit）+MCP+Session Viewer+OpenTelemetry |
| 社区与维护 | 8.5 | 4个月28.6k星（日均230+）、2,051 fork，最新push就在今天，阿里Aone出品内部两年生产验证背书 |
README 对通用 agent（如 Claude Code + Skills）审代码的三大痛点诊断相当扎心：覆盖不全（大 changeset 会偷工减料只审部分文件）、位置漂移（报告的问题对不上真实代码位置，行号/文件引用偏移）、质量不稳（自然语言驱动的 Skills 难调试，prompt 稍改质量就波动）。根因是纯语言驱动架构对审查过程缺乏硬约束。OCR 的解法是双轨分工：
| 层 | 负责 | 具体机制 |
|---|---|---|
| 确定性工程（硬约束） | 精确文件选择 | 哪些文件必审、哪些该过滤——工程逻辑保证，绝不漏审 |
| 智能文件打包 | 相关文件打包成审查单元（如 message_en.properties 与 message_zh.properties），每 bundle 一个隔离子代理——分治策略在超大 changeset 上稳定，天然支持并发 | |
| 细粒度规则匹配 | 模板引擎按文件特征匹配审查规则，模型注意力聚焦、源头消除噪声——比纯语言规则引导更可预测 | |
| 定位与反思模块 | 独立的评论定位与反思模块，系统性提升 AI 反馈的位置与内容准确性 | |
| LLM Agent（动态决策） | 场景化 prompt | 为代码审查深度优化的模板，提效果同时降 token |
| 场景化工具集 | 从大规模生产环境的工具调用轨迹蒸馏（调用频率分布/重复率/新工具对调用链的影响），比通用 agent 工具箱更稳 |
这个分工和 shadcn/lint 的"agent-first linter"殊途同归（见shadcn/lint教程），也与站内评测过的编码代理生态一脉相承——工具要"能被 agent 验证"，审查要"能被工程约束"，见Pi深度评测里的 harness 哲学对比。
代码审查工具很少给可复现的基准，OCR 给了一套完整的：基于 50 个流行开源仓库、200 个真实 PR、10 种编程语言构建，由 80+ 位高级工程师交叉验证、标注 1,505 个真值问题，数据集（Alibaba-Aone/aacr-bench）开放在 HuggingFace。
| 指标 | 衡量什么 | 为什么重要 |
|---|---|---|
| F1 | Precision与Recall的调和平均 | 审查质量最佳单一数字 |
| Precision | 报告的问题里真实缺陷的比例 | 更高=更少误报要人工分拣 |
| Recall | 真实缺陷被发现的比例 | 更高=更少漏网之鱼 |
| Avg Time | 单次审查墙钟时间 | CI流水线延迟敏感 |
| Avg Token | 单次审查token消耗 | 直接影响API成本 |
核心结论：对比通用 agent（Claude Code），同一底层模型下 Precision 与 F1 显著更高，token 消耗仅约 1/9，审查更快；Recall 更低是官方明示的刻意权衡——precision over noise，把误报压到最低。1/9 的 token 意味着什么？按站内Tokentab用量仪表盘教程里的成本视角，团队级部署时这就是预算数字的直接改写；想进一步在多家提供商间做模型路由省成本，可以配合My Free Code多提供商网关教程里的思路。
# 前提：Git >= 2.41
npm install -g @alibaba-group/open-code-review # 装出 ocr 命令
ocr config provider # 交互式选内置/自定义 LLM 提供商，自动测连通
ocr config model # 为当前提供商选模型
cd your-project
ocr review # 工作区模式：staged+unstaged+untracked 全审
ocr review --from main --to feature-branch # 分支范围（merge-base）
ocr review --commit abc123 # 单提交
ocr review --resume <session-id> # 恢复中断的审查
ocr scan # 全文件扫描（陌生代码库审计/无diff目录）
ocr scan --path internal/agent # 扫指定目录
ocr review --format json --output result.json # 结构化输出（给 AI 宿主代理）
ocr delegate preview # 委托模式：编码代理用自己的 LLM 审查
ocr delegate rule src/main.go src/handler.go上手体验：交互式配置引导做得细致（provider 选择 → key 填写 → 连通性测试一条龙），ocr review 对工作区变更的抓取覆盖 staged/unstaged/untracked 三态，比多数只看 staged 的工具周全。真实成本：软件 $0（Apache-2.0），LLM 费用走自配 key，token 效率是基准实测的强项；委托模式下直接复用编码代理已有的 LLM，零额外配置。
1. Recall 刻意偏低。基准里 Recall 低于通用 agent 是设计选择——误报少了，但确实会漏一些真问题。把它当"高精度第一道闸"而不是"唯一审查者"，与人工审查和 CI 静态分析并存才是正确姿势。
2. 强依赖 Git >= 2.41。diff 生成、代码搜索、仓库操作都压在 Git 上，老仓库环境要先升级。
3. 4 个月 28.6k 星的另一面。163 个 open issues、成长速度快于社区消化速度是常态，生产引入建议先在预发分支跑一段时间。
| 方案 | 哲学 | 适合 |
|---|---|---|
| Open Code Review | 确定性管道×LLM混合，precision优先，token极省 | 团队CI门禁、高误报敏感、大规模changeset |
| 通用agent直接审（Claude Code等） | 全语言驱动，灵活但无过程硬约束 | 个人快速过一遍小diff，不介意漏审误报 |
| 传统静态分析（SonarQube等） | 纯规则无LLM，零误报成本但召回语义能力弱 | 合规强要求的存量代码基线 |
推荐：要在 CI 里加一道高精度 AI 审查闸门的团队（四 CI 集成开箱即用，1/9 token 把批量审查的成本打下来）；用 Claude Code/Codex/Cursor 又想要专门化审查能力的开发者（插件即装）；审计陌生代码库的人（ocr scan 全文件模式）。不建议：追求"一个漏网之鱼都不许有"的场景（Recall 权衡在此）；没有 Git 2.41+ 的陈旧环境。
综合评分 8.9/10：这是站内评测过的代码质量类工具里罕见的"既给架构又给基准还给数据集"的三好生——混合架构直击通用 agent 的结构性缺陷，AACR-Bench 把"效果"从营销话术变成可复现实验，阿里两年内部生产验证给了它别的开源新秀没有的 battle-tested 底气。扣分在 Recall 的刻意取舍、快速成长期的 issues 积压，以及 Git 版本硬依赖。当 2026 年的 LLM 应用都在往"更多 agent 自由度"卷的时候，它反着来——先约束，后智能——这本身就该进教科书。
alibaba/open-code-review（28.6k星，Apache-2.0，Go，npm包@alibaba-group/open-code-review，命令ocr）是阿里集团内部官方AI代码审查助手孵化的开源项目：读Git diff，把变更文件发给带工具能力的LLM agent，生成行级精确的审查评论，另提供ocr scan全文件扫描。区别在于混合架构：文件选择、文件打包、规则匹配、评论定位等必须不出错的环节全部用确定性工程保证，agent只负责动态决策——解决通用agent审代码的覆盖不全、位置漂移、质量不稳定三大痛点。AACR-Bench实测同一底层模型下Precision和F1显著高于Claude Code，token消耗仅约1/9。
确定性工程负责硬约束：精确文件选择（不漏审）、智能文件打包（相关文件如中英文资源文件打成一个bundle，每bundle一个隔离子代理，分治+并发）、模板引擎规则匹配（按文件特征聚焦注意力）、独立的评论定位与反思模块（提升位置和内容准确性）。Agent负责动态决策：场景化调优的prompt模板和从大规模生产工具调用轨迹蒸馏的工具集。Recall低于通用agent是官方明示的刻意权衡——宁缺毋滥，把误报（noise）压到最低，减少人工分拣负担。
前提是Git >= 2.41（diff生成、代码搜索、仓库操作依赖它）。三步：npm install -g @alibaba-group/open-code-review装出ocr命令；ocr config provider交互式选择内置或自定义LLM提供商并填API key（自动测试连通性）；ocr config model选模型后即可ocr review开审。支持工作区模式（staged/unstaged/untracked全部变更）、分支范围（--from main --to feature-branch）、单提交（--commit）、中断恢复（--resume）和全文件扫描（ocr scan）。
能。委托模式（Delegation Mode，ocr delegate）下你的编码agent（Claude Code/Codex/Cursor/OpenCode等已装插件的）用它自己的LLM执行审查，OCR只负责文件选择与规则解析——无需配置OCR API key。默认模式则由OCR用你配置的LLM跑审查（OpenAI与Anthropic兼容端点均可）。
可以。CI/CD官方支持GitHub Actions、GitLab CI、GitFlic CI和Gerrit四种集成；编码agent侧提供Claude Code（review斜杠命令插件）、Codex（可调用review技能）、Cursor（便携review技能）、OpenCode（原生工具+斜杠命令）、QCA Forward五个插件，另有skill兼容agent通用的便携技能。还支持ocr review --format json --output result.json输出结构化结果给宿主agent、MCP Server扩展外部工具、Session Viewer浏览器回放审查会话、OpenTelemetry可观测性。