GitHub 趋势 · 第 70 期
阿里开源的 AI 代码审查工具，把「输的那个指标」写在了 README 里
#GitHub趋势#AI代码审查#阿里开源
先给结论：这个项目最值得读的不是功能表，是官方自己划的那条边界 —— 它明说 Recall（召回率）低于通用 Agent，并把这件事解释成一次有意的取舍：宁可少报，也不要噪声。一个工具敢把输的指标写进第一段，比它宣称赢了多少项更值得信。
用通用 Agent 做代码审查，官方总结了三个反复出现的毛病：变更集一大就挑文件审、位置漂移（报出来的问题对不上真实行号）、质量随提示词波动。它给的根因只有一句：纯语言驱动的架构，对审查过程没有硬约束。
它是什么
Open Code Review（命令是 ocr）是阿里开源的 AI 代码审查 CLI。它原本是阿里内部官方的 AI 代码审查助手，按 README 的说法已经运行两年、服务过数万名开发者、识别出数百万个代码缺陷，在被大规模验证之后孵化成了开源项目。用 Go 写，Apache-2.0，仓库 2026 年 5 月建，到抓取时 22,376 star。
工作机制是读 Git diff，把改动过的文件交给一个带工具调用能力的 Agent。这个 Agent 能读完整文件、搜代码库、翻其他改动文件补上下文，最后产出带行号定位的结构化审查意见。除了审 diff，还有 ocr scan 做整文件扫描 —— 用来审那些没有有意义 diff 的目录，比如第一次接手一个陌生代码库。
核心设计：确定性工程 + Agent 的分工
它的核心主张是把「不能出错的步骤」从模型手里拿走，交给工程逻辑；模型只负责真正需要动态判断的部分。两边具体分到哪些活，README 写得很清楚：
| 环节 | 由谁负责 | 做法 |
|---|---|---|
| 选文件 | 工程逻辑 | 确定哪些文件必须审、哪些过滤掉，保证不漏重要改动 |
| 文件分组 | 工程逻辑 | 相关文件合成一个审查单元（如中英 properties 捆在一起），每个单元跑独立子 Agent，天然支持并发 |
| 规则匹配 | 工程逻辑 | 按文件特征匹配规则，走模板引擎而不是语言提示 |
| 定位与反思 | 工程逻辑 | 独立的评论定位模块 + 评论反思模块 |
| 提示词 | Agent | 为代码审查专门调过的模板，同时压低 token 消耗 |
| 工具集 | Agent | 从生产数据的工具调用轨迹里蒸馏出来的专用工具集 |
效果那一段，官方给了两个方向的数字：同等底层模型下，Precision 与 F1 明显更高、token 约为通用 Agent 的 1/9、耗时更短；同时 Recall 低于通用 Agent。基准口径是 50 个热门开源仓库、200 个真实 PR、10 种编程语言，由 80+ 位资深工程师交叉校验出 1,505 条标注。
它给「用 AI 写代码」立了 8 条规矩
仓库根目录有一份 AGENTS.md（4,702 字节），它不是介绍项目的，是给「要改这个仓库」的人立的规矩。八条，每条都是硬要求，没有一句「建议」：
- ▪开 issue 或 PR 时就要披露你用了 AI/LLM，以及用了什么工具和模型
- ▪你要理解 AI 写出来的每一行代码，知道它做了什么
- ▪维护者问你改动原因时，回答的实质内容必须来自你自己的理解 —— AI 只能用来翻译或润色措辞，不能替你生成答案
- ▪PR 里不该出现 AI generated -> fixed -> fixed -> fixed 这种反复循环，那说明你没审 AI 的代码，只是让它一次次救火
- ▪主动请任何人 review 之前，你要自己先审过全部 AI 生成的内容
- ▪不得把 commit 归功于 AI，包括 Assisted-by、Co-developed-by 这类 trailer
- ▪别写超长 commit message，重要信息放 PR 描述里
- ▪以上任何一条你不愿做或做不到，请直接关掉你的 issue 或 PR
第 6 条值得单独拎出来：modular 在同一件事上的要求正好相反 —— 那边要求给 AI 辅助的提交打上 Assisted-by: AI 标签，这边禁止出现任何把功劳归给 AI 的 trailer。同一种 trailer，两家大厂给出完全相反的规则：一家要你标出来，一家要你别标。
还有一条不常见的 CI 门槛写在同一份文件里：make english-check 会拦下源码里任何非 ASCII 字母 —— 汉字、假名、谚文、西里尔字母都拦，连德语变音符甚至全角标点都不放过，一个全角冒号或全角括号也会被拦下，只有符号和 emoji 放行。翻译有各自的家（README.<locale>.md、文档站的 locale 目录、i18n 表），那些目录不在扫描范围内；个别例外要在行尾挂一个 allow-non-english: <reason> 标记说明理由。一个中文公司的项目，把「源码里不准出现一个汉字」做成了 CI 检查。
顺带一个体量上的细节：五个 README 语言版本里，俄语版 19,260 字节最长，日语 15,918、韩语 13,531、英文 12,829，简体中文版 12,397 字节是最短的那一版。而 AGENTS.md 里有一条硬规则 —— 改 README.md 必须同步四个本地化版本。
另外根目录同时摆了 .agents/、.claude/、.claude-plugin/ 三套入口，而 CLAUDE.md 只有 11 字节，全文就一行 @AGENTS.md。也就是说这个仓库没给 Claude 单独写说明，只是把上层入口指回同一份文件 —— 4,702 字节的 AGENTS.md 是正身，11 字节的 CLAUDE.md 是路牌。
上手
前置条件只有一条：Git >= 2.41。安装走 npm，装完命令是 ocr。
# 安装（主通道是 npm） npm install -g @alibaba-group/open-code-review # 配模型：必须先配，除非走下面的 delegation 模式 ocr config provider ocr config model # 审工作区里已暂存 / 未暂存 / 未跟踪的全部改动 ocr review # 按分支区间审（审 feature-branch 从 main 分叉之后的所有改动） ocr review --from main --to feature-branch # 只审一个 commit ocr review --commit abc123 # 中断之后接着审 ocr session list ocr review --from main --to feature-branch --resume <session-id>
另外三条路：整文件扫描、给宿主 Agent 用的 JSON 输出、以及不用配 LLM 的 delegation 模式。
# 整文件扫描：不需要 git 历史 ocr scan ocr scan --path internal/agent # 输出 JSON，推荐给宿主的 AI agent 读 ocr review --format json --output result.json # delegation 模式：让宿主 Agent 自己审，OCR 只负责选文件和解析规则，不需要 OCR 的 key ocr delegate preview ocr delegate rule src/main.go src/handler.go
我的判断
适合谁：CI 里需要一个稳定、低噪声的增量审查环节的团队；已经有自建模型端点、不想再为 review 单独烧一笔 token 的团队；以及想让 Agent 复用自己工作流的场景 —— delegation 模式不需要配 OCR 的 key，等于把选哪些文件、套哪些规则这两件工程活外包出去，推理仍然跑在你自己的宿主 Agent 里。
不适合谁：指望它顶掉人工 review 兜底的人。官方自己写了 Recall 低于通用 Agent，它优化的目标是报出来的得是真问题，而不是一个都别漏。要的是覆盖率而不是信噪比，那它的取舍方向正好和你相反。另外 Git 版本低于 2.41 的环境直接出局。
坑：① 版本别只信一个端点。抓取时 /releases/latest 返回 v1.11.9，而 /tags 的第一项已经是 v1.12.0，两个端点不一致，判版本要看 tag 列表。
② 效果数字全在图片里。50 个仓库、200 个 PR、1,505 条标注这些口径写在正文，但 F1、Precision、Recall、平均耗时、平均 token 五个指标的数值全在一张 PNG 里 —— 正文里能读到的只有一个约 1/9 token 的概述，没有一行可核的表格数字。
③ 对比对象是自己挑的。所谓通用 Agent 那一档，以及这个基准本身，都出自项目自己，不是第三方评测；开头那句服务过数万名开发者、识别出数百万个代码缺陷，同样是内部数字，外部无从核实。
④ 发行产物的体量容易低估。最新一版挂了六个平台二进制，每个 53–58 MB，合计约 332.8 MB，是仓库自身体积（51,535 KB）的约 6.3 倍。
⑤ star 涨得快，长期跟的人少。22,376 star 对 66 个 watcher（约 0.3%）、158 个未关 issue。装之前建议先按你的语言和 CI 平台搜一遍 issue 关键词。
仓库：github.com/alibaba/open-code-review ｜ 官网：open-codereview.ai
Star：22,376（REST API 实测）／ 22,677（Trending Go 日榜同期快照）｜ 今日 +115
Fork：1,665 ｜ Watcher：66 ｜ 未关 issue：158
许可：Apache-2.0（仓库根 LICENSE 11,356 字节，标准全文，无附加条款）
主要语言：Go ｜ 仓库体积：51,535 KB ｜ 默认分支：main ｜ archived：false ｜ 维护者类型：Organization
创建：2026-05-18 ｜ 最近推送：2026-09-11
最新 release：v1.11.9（2026-09-11 发布，6 个平台二进制 + sha256sum.txt）；tag 列表首位：v1.12.0
数据来源：GitHub Trending 官方页面 + GitHub REST API ｜ 抓取时间：2026-09-13 (GMT+8)
你们团队现在用 AI 审 PR 吗？是把 diff 直接丢给通用 Agent，还是接了这种专用工具？
还有一个更实际的问题：如果一个工具明确告诉你「我召回率不如通用 Agent，但我只在有把握的时候才报」，你会把它放进 CI 的必过项，还是只当一份参考？
下期预告：分语言榜继续零新面孔的话，兑现欠了两期的「把模型塞进小设备与边缘」主题族横向合集；一旦出现高动量新面孔，就回到单项目精读。
#GitHub趋势#AI代码审查#开源工具