阿里把内部用了两年的 AI 代码评审开源了：PR 提交前，先跑这一条命令

一、先说这是个什么东西阿里最近开源了一个代码评审工具叫open-code-review装完命令行里就一个ocr。它的来头值得说一句这不是一个新做的 demo而是阿里集团内部的官方 AI 代码评审助手内部跑了两年服务过数万开发者发现过数百万个代码缺陷。跑通了才拿出来开源。真正让我决定写它的是 README 里的一句反常话。它主动承认和 Claude Code 这类通用 Agent 相比我的召回率是低的。一个做代码评审的工具在首页写上我漏得比别人多。这句话背后藏着一个很清醒的判断——代码评审里误报的代价远高于漏报。一个天天喊狼来了的评审工具第三次就会被关掉而漏掉一个问题的工具至少你还会看它报出来的那些。这个取舍做过质量的人都懂。二、它能干什么先不谈架构直接说能力。以下都是它已经做到的。1. 三种评审范围随手就能跑# 工作区模式暂存 未暂存 未跟踪全审ocr review# 分支区间审 feature 分支从 main 分出去之后的所有改动ocr review--frommain--tofeature-branch# 单个 commitocr review--commitabc123工作区模式是我用得最多的——写完一段代码还没 commit直接跑一遍比等到提 PR 再发现问题便宜得多。2. 不只是看 diff还能整文件审计ocr scan# 扫整个仓库ocr scan--pathinternal/agent# 只扫某个目录或某几个文件这个模式和 diff 无关不需要 git 历史。什么时候用接手一个陌生模块、review 一段别人塞过来的代码、或者想给一个老目录做一次全面体检的时候。我自己觉得scan甚至比review更实用——日常 PR 有同事看着反而是那些没人给你写 diff 的历史代码最需要有人帮你过一遍。3. 评论能挂准位置这是它最硬的一条。很多 AI 评审工具报问题说得头头是道点进去行号对不上、或者挂在另一个文件上。评论一旦需要读者自己重新找位置价值立刻打对折——因为读者会先怀疑这条意见是不是幻觉。它的做法是模型从头到尾不碰行号。模型提交评论时给的是一段它认为有问题的代码原文工具再用滑动窗口算法去 diff 里匹配这段连续代码匹配上了才挂载。匹配不上还有一个专门的重定位任务兜底让模型逐字重新摘一遍代码。行号是算出来的不是模型编出来的。4. 会自己复核一遍砍掉站不住的评论评审跑完之后它还有一道反思环节拿这一组文件的 diff回头核对刚生成的每一条评论把能被 diff 证明是错的评论删掉。这个模块的判据设计得很讲究。它先把两种错误的代价摊开算留着一条错误评论代价是评审者多花几秒钟注意力。删掉一条正确评论代价是静默销毁一个真实发现——它永远到不了任何人手里而且没人知道它被丢了。所以规则是证据不够就放行。“可疑”“我无法验证”“价值不高”“换我我不会提”在它这里全都等于保留。还画了五类一票否决的红线不管模型多确定它是错的都不许删内存安全、并发、链接与声明一致性、行为或兼容性变更、函数收下却从不使用的参数。理由也写得明白这几类是删错代价最高、而模型自己的置信度最不可信的领域。在这几类上你不配自信。5. 规则可以按路径定制内置了54 条路径规则从 Java、Go、Rust、Python 到 Terraform、Solidity、Verilog 都有。连.m文件到底是 MATLAB 还是 Objective-C都专门做了内容嗅探来区分。你也可以给自己的项目加规则在项目根目录放一个.opencodereview/rule.json{rules:[{path:**/*Mapper.xml,rule:重点检查 SQL 注入风险、分页是否带 limit、字段是否与数据库实际定义一致,merge_system_rule:true}],include:[**/*.java,**/*.xml],exclude:[**/generated/**,**/*Test.java]}path决定哪个路径命中哪套规则include/exclude决定审哪些不审哪些。merge_system_rule: true表示在内置规则之外追加而不是替换。配完不确定有没有生效有个专门的调试命令ocr rules check src/main/resources/mapper/UserMapper.xml它会直接告诉你这个文件命中了哪套规则、规则来自哪一层项目 / 全局 / 内置、匹配的是哪个 pattern。6. 能接进你已经在用的 AI 编程工具它给 Claude Code、Codex、Cursor、Kimi Code、OpenCode 都做了插件装完之后是几个 review 斜杠命令或技能。它还自带 MCP Server可以往外扩展工具。也就是说你不用改工作流。原来怎么用 Claude Code 还怎么用只是在写完 → 提交之间多插一步。7. 能进 CI也有结果回放CI 侧支持 GitHub Actions、GitLab CI、GitFlic CI 和 Gerrit。另外有个挺好用的东西叫 Session Viewer在浏览器里回放某次评审会话逐条把评论标记成已修或忽略处理一条划掉一条。适合那种一次报了二十多条、需要慢慢消化的大评审。8. 一个省钱模式Delegationocr delegate preview这个模式下你不用给它配任何 API Key。它只负责它擅长的那部分——选哪些文件、套哪套规则然后把你自己的 AI 编程 Agent 当成执行者来跑评审。如果你本来就有 Claude Code / Cursor 的订阅这个模式等于零额外成本。三、实际怎么用六个场景说完了能力讲讲我在实际工作里会怎么用它。场景 1提 PR 之前本地先过一遍最朴素的用法也是我认为性价比最高的。cdyour-project ocr review我把它放在写完代码 → 自查 → commit之间。成本是几十秒到两三分钟收益是把那些低级但丢人的问题在别人看到之前拦下来空指针没判、边界条件漏了、异常吞掉了、改了接口没改调用方。这一步的价值不在于它有多聪明而在于它比人有耐心。人自查会跳过我刚写的这段肯定没问题的部分它不会。场景 2大改动用分支区间 断点续跑一个改了三四十个文件的分支一次跑完可能很久也可能中途断掉。这时候用# 分支区间评审ocr review--frommain--tofeature-branch# 看看有哪些没跑完的会话ocr session list# 接着上次跑已经审过的不重复烧 tokenocr review--frommain--tofeature-branch--resumesession-id--resume在大改动上是刚需。它内部会把每个文件的评审结果记进会话续跑时已经审过的直接复用。场景 3接手一个陌生模块这是我最推荐的用法。ocr scan--pathlegacy/payment你刚接手一块没人愿意碰的老代码没有文档原作者可能已经离职。这时候scan会把它当成一个整体来审不依赖任何 git 历史。它给出的不是这段代码写得烂而是具体到某一行的问题清单——这等于一份由机器生成的代码债清单。你可以直接拿它排优先级。场景 4给团队沉淀自己的评审规则每个团队的坑不一样。通用规则管不到我们这个项目的金额字段必须用 BigDecimal“所有对外接口必须带幂等键”。做法是在项目根目录放.opencodereview/rule.json见上一节的示例提交到仓库里团队所有人共享。一个实操建议不要一上来写一大套规则。先只写三到五条你最常在同僚评审里反复提的那几条跑一两周看看效果再慢慢加。规则写太多模型的注意力会被摊薄反而变钝。配完记得用ocr rules check 文件路径验证命中情况。场景 5接进 Claude Code / Cursor 的日常流程如果你已经在用 AI 编程工具最顺手的接法是装它的插件之后就变成一条斜杠命令。流程变成让 AI 写代码 → 自己过一遍 →ocr review→ 人工评审 → 提交注意这里的顺序AI 写的代码不要让同一个 AI 审。它的价值恰恰在于它是另一个视角、另一套约束。你自己用 Claude Code 写完再让它自查它只会告诉你我写得挺好。如果不想配额外的 API Key就用 Delegation 模式让它借用你现有的 Agent 来跑。场景 6接进 CI 当门禁——但建议先别卡流程CI 侧有现成的 GitHub Actions / GitLab CI / Gerrit 集成。但我的建议是先别当硬门禁。原因是它自己承认召回率偏低。把它设成不通过就禁止合并会有两个后果漏掉的问题照样进主干而报出来的问题里有一部分会被开发当成这工具又在瞎报。比较稳妥的做法是先跑成评论机器人——只提意见不卡流程。等团队对它的准确率有了共识再决定要不要升级成门禁。需要把结果交给别的程序处理时ocr review--formatjson--outputresult.json官方也推荐把结果导成 JSON 喂给 AI host agent让它接着处理。四、上手前要知道的几件事① 装和配npminstall-galibaba-group/open-code-review ocr config provider# 选供应商、填 API Keyocr config model# 选模型两条 config 命令都是交互式 UI配完会自动测连通性。② 需要 Git 2.41它依赖 Git 做 diff 生成、代码搜索和仓库操作。版本不够先升级。③ 别把它当成唯一的评审关卡它省 token官方数据约是通用 Agent 的九分之一同模型下精准率和 F1 更高、速度更快但召回率确实更低。定位是帮你漏得更少、吵得更少不是替你负责。④ 结果要能追踪如果一次报出十几条别试图在脑子里过。用 Session Viewer 打开逐条标记已修或忽略处理完一条划一条。五、最后我读完它的源码之后印象最深的不是架构设计是一段注释。那段注释在解释为什么这里不报错token 预算打满时它会停止调度后续任务但故意不把这次运行标记为失败——因为那是受控的覆盖率截断不是运行级失败一旦标成失败就会抢占第一个失败原因的名额把真正的运行级原因超时、被取消挤掉。半页注释解释的是一个不报错的地方。一个工程团队真正的水平不体现在主流程写得多漂亮而体现在他们有没有把这里曾经踩过什么坑写下来。而这次他们把两年、数万开发者、数百万缺陷换来的坑全都开源出来了。装上跑一遍。不行再卸。项目github.com/alibaba/open-code-review 文档open-codereview.ai/docs 许可Apache-2.0本文首发于个人公众号转载请注明出处。