【GitHub】阿里开源 AI 代码审查工具:38k Star,Token 只花九分之一

阿里把内部用了两年的 AI 代码审查助手开源了，两周 38k Star。建议先收藏，往下看它怎么把 Token 只花到九分之一。

项目名 alibaba/open-code-review，装完只有一个命令 ocr。它读 Git diff，把变更文件交给一个可配置的模型，再由带工具调用能力的 agent 生成行级审查意见。

其实关键在「带工具」这三个字。它读的不只是那几行改动，agent 可以调出完整文件、在整个代码库里搜索、把其他变更文件也翻一遍。

这就是它跟「让大模型总结一下 diff」的区别。

官方说它在阿里内部跑了两年、服务过数万名开发者、识别出数百万个缺陷。配上它两个月从 25.7k 涨到 38k 的曲线，这话我信一半。

如果你用 Claude Code 加 Skill 审过代码，大概率踩过这三件事。

纯语言驱动的架构，对审查过程没有任何硬约束。这是能力问题，换更强的模型也救不回来。

这套工具的核心主张是把流程切成两半。文件选哪些、哪些该打包在一起、用哪条规则、评论落在哪一行，交给确定性工程逻辑。

理解代码、推理上下文、判断有没有问题，才交给 agent。

说实话，文件打包这一手挺妙。message_en.properties 和 message_zh.properties 会被塞进同一个审查单元，每个单元跑一个独立子 agent、上下文隔离。分治之后，超大 changeset 也稳得住，还天然支持并发。

至于哪些文件能进这个流程，要过六道门。

过完六道门还有两道收尾。单个文件的 diff 超过上下文预算的 80% 会被判为 too_large，新路径是 /dev/null 的标记为 deleted。

规则写在 JSON 里，四层优先级从高到低。

上面那层文件不存在就静默跳过，不算错。系统层永远在，所以总能解析出一条规则。

include 的作用是绕过内置的测试文件排除，没匹配上的文件照样走常规检查。匹配用的 glob 支持 ** 和花括号展开，且大小写不敏感。

内置规则是一整套按语言和文件类型分的提示词库，从 java.md、go.md、python.md 一直铺到 MyBatis mapper、FreeMarker 模板、Solidity 和 Terraform。仓库描述里那四个缺陷类型只是概括。

改完规则不放心，用 ocr rules check src/main/java/Example.java 看哪一层赢了。

前置只要 Git 2.41 和 Node 18。内置二十多个 provider，阿里百炼、火山方舟、DeepSeek、Kimi、智谱、MiniMax、小米 mimo 都在，Anthropic、OpenAI、Gemini 和 Bedrock 也有。

要审分支用 --from main --to feature-branch，审单次提交用 --commit abc123，没有 diff 就 ocr scan 扫整库。--format json --audience agent 是喂给 CI 的，接上 GitHub Actions 或 GitLab CI 就能在 PR 里贴行级评论。

安全意识强一点的话，密钥可以完全不落盘。api_key_cmd 支持从 1Password 或系统钥匙串运行时取值，优先级是静态 key、命令、环境变量。

嫌麻烦还有委托模式，让 Claude Code、Cursor 这些现成 agent 用自己的模型跑审查，OCR 只管选文件和定规则，一个 API Key 都不用配。

官方 benchmark 叫 AACR-Bench，50 个开源仓库、200 个真实 PR、10 种语言，80 多位资深工程师标注出 1505 个真实缺陷。同模型对比下它 Precision 和 F1 更高，token 约九分之一，速度更快。

得说清楚，基准是项目方自己搭的，目前没看到第三方复现。官方还主动承认 Recall 更低。它宁可少报，也不制造噪音，这个取舍对每天要处理几十条评论的人来说反而是好事。

issue 1454 是 9 月 19 日提的。有团队升级到 v1.12.7 后发现，全仓库所有 PR 的审查都在 15 到 25 秒内结束，输出「没有选中任何文件」。

退出码 0，CI 一路绿灯，评论一条都没发。上一个版本同样的仓库要跑 25 到 30 分钟。

问题出在一个把 **/test_*.py 加进默认排除的 PR 上。合并之后，只改测试文件的 PR 就被静默跳过。绿灯让「发布坏了」和「审过了没问题」完全没法区分。

报告者只能把版本 pin 回旧版，还建议零选中时该报错退出。维护者的回复是 "I don't see the point of this."

issue 1440 更微妙。项目的安全保证文档写着 API Key 只从环境变量读取、永不写入配置文件，实际 CLI 会把 key 存进 ~/.opencodereview/config.json。

报告者自己定性为文档准确性问题，但两个文件对不上这件事足以误导做安全评审的人。已经有人提交补丁把配置权限收紧到 0600。

顺带一个细节，issue 1454 的报告标注了 AI 辅助静态分析，修 bug 的 PR 作者写着「用 Claude Code 实现，我逐行看过」。一个审 AI 代码的工具，收的 bug 和吃的补丁都是 AI 产出的。

如果你的 PR 经常排队等人工 review，或者团队里没人愿意看别人的代码，这套东西值得花半小时试一次。先跑一次 --preview，比直接跑审查更能说明它靠不靠谱。

#AI代码审查 #开源 #阿里巴巴 #CodeReview #程序员 #效率工具 #AI编程 #每天一个开源项目

 { 感谢阅读 }

如果本文对您有帮助，欢迎 “点赞“，点“推荐”