26k Star，又一大厂的 AI 代码审查神器开源了！

今年五月的时候，阿里把一个内部工具开源了，叫 Open Code Review，听名字就知道是干什么的，用 AI 做代码审查。这个工具不是开源的时候才做出来的，它在阿里集团内部已经跑了两年，是内部的官方代码审查助手，官方说法是几万名开发者用过，识别出来的代码缺陷有数百万个。 现在用 AI 写代码的人越来越多了，写得也快，但代码多了以后审查就跟不上，让同事帮忙看吧，大家都很忙，顾不上那么细。让 Claude Code 这类通用助手顺便审一下，我用着总觉得差点意思。 这篇我们就来聊聊这个工具。 它和直接把代码丢给 AI 有什么区别 先说下我平时遇到的情况，拿 Codex 这类助手配上一段提示词去审代码，用一段时间下来，会发现几个挺烦人的问题。 改动一多它就容易漏，一堆文件摆在那，它只挑其中一部分看，没看的那些到底有没有问题，没人知道。报出来的问题位置也经常对不上，它说某一行有空指针风险，我点过去一看，那一行是空的。还有就是结果不太稳定，提示词稍微动一动，审出来的东西就变样了，这次能发现的问题，下次再审可能就漏了。 Open Code Review 的做法不太一样，它的思路大概是，能用工程代码保证正确的环节，就不交给模型去决定。哪些文件要审、文件怎么分组、每种文件套什么规则、评论落在哪一行，这些都是程序做的。模型在里面负责的事情其实不多，就是看代码，然后判断有没有问题。 它能干什么 审改动：ocr review 平时用得最多的应该就是这条命令了，在项目目录下跑 ocr review，它会把暂存的、没暂存的、还没跟踪的改动都审一遍。想审某个分支相对主分支的改动，就用 ocr review --from main --to feature-branch。只想看某一个提交的话，ocr review --commit abc123。 另外有个参数我自己挺喜欢的，--background，举个例子，这次改动是为了实现手机号登录验证，把这句话带上，模型就能分出来哪些是你故意这么写的，哪些是真的有问题，误报会少不少。 全量扫描：ocr scan review 是用来审改动的，scan 不太一样，它审的是完整文件，不依赖 Git 历史。什么时候用呢，比如刚接手一个不熟悉的项目，或者想把某个核心目录整体检查一遍，ocr scan --path 目录名 就行，不是 Git 仓库的目录也能扫。 扫之前可以先用 ocr scan --preview 看看它会处理哪些文件，这一步不调模型，不花 token。仓库比较大、担心花太多钱的话，还能用 --max-tokens-budget 设个上限。 评论能落到具体的代码行 定位这件事我觉得值得单独说一下。它没有让模型自己去报行号，因为模型对数字本来就不敏感，报的经常不准。 它换了个办法，让模型把有问题的那段代码片段给出来，然后程序拿着这个片段去 diff 里找准确位置，找不到就扫一遍全文件，再不行才让模型重新定位一次。这样一层层处理下来，内部版本评论位置的准确率超过了 97%。 自带规则库，也能加自己团队的规矩 工具里面内置了一套规则，按语言和文件类型分的。Java 文件重点查空指针、线程安全这些，前端文件查 XSS，MyBatis 的 XML 查 SQL 注入，开箱就有，不用自己配。 团队如果有自己的要求，可以在仓库里放一个 .opencodereview/rule.json，比如规定金额计算必须用 BigDecimal，对外接口必须加鉴权注解之类的。项目规则、个人规则、命令行临时规则之间有四层优先级，哪条会覆盖哪条，文档里都写清楚了。 可以接进 Claude Code、Codex 这些编码助手 平时就在用 Claude Code 或者 Codex 写代码的话，可以把 OCR 装成插件，在对话里直接调起审查。还有一种委托模式，OCR 只负责挑文件和匹配规则，真正审查的动作交给你自己的编码助手去做，这样连模型 key 都不用单独配了。 能挂到 CI 流水线上 官方给了 GitHub Actions 和 GitLab CI 的现成例子，配上 --format json --audience agent 这两个参数，输出的就是标准 JSON，CI 脚本拿去直接解析就行，每次 PR 都能自动过一遍。 有个网页界面回看审查记录 跑 ocr viewer 会在本地起一个网页，能看到之前的审查会话，处理掉的评论标记成已修复或者忽略就可以，下次不用从头再看一遍。 快速开始 安装很简单，就一条命令： npm install -g @alibaba-group/open-code-review 装完全局就有 ocr 命令了，有一点提前说下，它依赖 Git 做 diff 和代码搜索，Git 版本要 2.41 以上，机器上 Git 太老的话记得先升一下。 装完接着配模型，跑 ocr config provider，它有个交互式的界面，里面内置了不少供应商，国内的阿里云百炼直接可选，把 key 填进去它会自己测一下连通性。配完用 ocr llm test 确认没问题就行了。 然后就是进到项目里跑 ocr review，等它出结果。第一次用的话，我建议先跑 ocr review --preview，看看它选了哪些文件、过滤掉了哪些，心里有个数再正式审。 效果到底怎么样 这个项目开源四个多月了，现在 Star 过了两万六，在 GitHub Trending 上也待过好几天。官方那边放了一些数据，内部版本在阿里集团的月活用户有两万，累计跑了 370 万次真实评审，用户采纳率超过 30%。 开源版他们还专门建了一个评测集，从 50 个热门开源仓库里挑了 200 个真实 PR，覆盖 10 种语言，找了 80 多位资深工程师来标注，一共标出 1505 个问题。测下来的结果是，在同样的底层模型下，OCR 的准确率和 F1 都比通用助手高不少，token 消耗只有通用助手的大概九分之一，速度也更快。 有一点得说清楚，它的召回率比通用助手要低，也就是说会有一些问题没被发现。这是官方刻意做的取舍，宁愿少报几个，也不想拿一堆误报来烦人。日常审 PR 我觉得这个取舍没什么问题，但如果是安全审计这种不能漏的场景，光靠它不够，还得搭配别的工具一起用。 官方基准测试结果 最后说两句 这个工具我觉得最有价值的地方，是它把审查这件事的流程固定住了。比如文件要一个不漏地审完，评论的位置得准确，每次用的规则得是一样的，这些听起来都是很基础的事情，但通用助手恰恰容易在这些地方出问题，阿里这波相当于是把内部踩了两年的坑，打包一起开源出来了。 现在 AI 生成的代码越来越多，审查这个环节靠人去盯，肯定是盯不住的。OCR 当然也有它自己的问题，召回率摆在那里，不能指望它兜住所有事。但能让每个 PR 都先被稳定地过一遍，我觉得就挺值得装来用用了，感兴趣的可以去仓库看看。 开源地址 https://github.com/alibaba/open-code-review