open-code-review 上手：ocr 命令怎么用

2026-07-28

数据截至 2026-07，各项目能力以官方文档当前版本为准。

open-code-review 的上手门槛比大多数人预期的低：一条 npm 全局安装，两条交互式配置命令选好模型供应商，进项目目录敲 ocr review 就能拿到带行级定位的评审意见；真正需要花时间想清楚的不是怎么装，而是它的四种评审模式分别对应什么场景，以及仓库自述的那些性能数字该信到什么程度。

一个常见的误解是把它当成”又一个套壳 AI 聊天助手”——以为无非是把 diff 拼进 prompt 发给大模型，然后拿回一段散文式的评语。从公开的架构描述看不是这么回事：它是确定性流水线加 LLM Agent 两段结合的结构，文件筛选和规则匹配这类可以写死的活儿由确定性代码做，需要理解语义的判断才交给 agent，最后输出的是结构化、带行级定位的意见，而不是一坨自由文本。这个区别决定了它更像一件能进 CI 的工程工具，而不是一个聊天窗口。

另外先解决一个必然会遇到的困惑：它的命令名是 ocr，跟光学字符识别那个 OCR 完全没关系，只是 open-code-review 三个词首字母的缩写。如果你机器上恰好装过别的叫 ocr 的东西，安装后先确认一下 which ocr 指向哪儿，免得敲半天命令报的是另一个程序的错。

一、安装：一条命令，装的是全局 CLI

它以 npm 包的形式分发，安装命令是：

npm install -g @alibaba-group/open-code-review

注意包名带 @alibaba-group/ 这个 scope，不要按直觉去装一个叫 open-code-review 的裸包名。装的是全局包（-g），因为它的定位是命令行工具，你需要在任意项目目录下直接敲 ocr，而不是每个项目里装一份本地依赖。

装完之后先验证一下命令是否可用再往下走。如果提示找不到命令，通常是 npm 的全局 bin 目录不在 PATH 里，这是 Node 环境的老问题，跟这个工具本身无关——用 nvm 之类的版本管理器时尤其容易碰上，切换 Node 版本后全局包是跟着版本走的，换了版本就得重装。

二、配置：两条 config 命令，全程交互式

安装完不能直接评审，因为它自己不带模型，得先告诉它用谁的模型。配置分两步：

ocr config provider          # 选 LLM 供应商
ocr config model             # 选模型

这两条都是交互式的，会引导你选供应商、填 API key，并且自动做一次连通性测试。这个自动测试其实挺省事——大部分工具是等你真正跑任务时才暴露 key 填错、端点不通这类问题，报的错还未必指向根因；配置阶段就先打一次通，把”配置问题”和”评审逻辑问题”在时间上分开，排查起来清爽得多。

供应商这块，项目仓库说明它兼容 OpenAI 与 Anthropic 两种格式。这里说的是接口格式而不是具体厂商——只要某个服务对外提供的是这两种格式之一的兼容端点，理论上都能接进来，这也是目前国内不少模型服务的通行做法。至于具体支持哪些模型名、哪个模型跑评审效果更好，仓库并没有给出清单，这篇也不替它编，你在 ocr config model 的交互列表里看到什么就是什么，以官方文档当前版本为准。

配置完成后进入项目目录，最基础的一条命令是：

cd your-project
ocr review                   # 评审已暂存/未暂存的改动

它评审的是当前工作区的改动，也就是你正准备提交的那批东西。这是日常用得最多的一条——写完一个功能、git add 之后、真正 commit 之前跑一遍，属于最自然的插入点。

三、四种评审模式，分别对应四种场景

除了裸 ocr review，仓库还给出了三种模式，加起来一共四种。别都试一遍就随便挑一个用，它们的适用场景差别很明确：

ocr review                                    # 评审当前工作区改动
ocr review --from main --to feature-branch    # 分支对比
ocr scan --path internal/agent                # 整文件审计
ocr delegate preview                          # 由 AI agent 执行评审

第一种，裸 ocr review：提交前的自查。改动范围小、上下文你自己最清楚，跑一遍主要是抓那些自己盯久了看不见的问题。

第二种，--from / --to 分支对比：这是接近真实 code review 的用法。你要合一个 feature 分支回主干，想先知道这一整条分支相对主干引入了什么风险，就用它。跟裸 review 的区别在于范围——裸 review 只看未提交的改动，分支对比看的是两个 ref 之间的全部差异，包括你几天前已经 commit 掉的那些。做 MR 之前先自己跑一遍，比让同事在评论区帮你抓低级问题要体面。

第三种，ocr scan --path：注意这条不是看 diff，是整文件审计。前两种模式的输入都是变更，只审你动过的地方；scan 输入的是路径，把该路径下的文件整体过一遍。这个区别很关键：接手一份别人写的老代码、或者想给某个核心模块做一次专项体检时，diff 模式是使不上劲的——因为你压根没改动它，diff 是空的。scan 就是为这类场景准备的。代价也很直白：整文件送审比 diff 送审的 token 消耗高得多，别对着整个仓库根目录一把梭，按模块分批扫。

第四种，ocr delegate preview：由 AI agent 来执行评审流程，而不是走固定的评审管线。这条属于更放手的用法，agent 的自主度更高，相应地结果的可预期性也更低一些。建议先把前三种用熟、对它产出的意见质量有基本判断之后再碰这一条，否则你很难分辨”这条意见不靠谱”是模型的问题还是模式选错了。

上手顺序上，我的建议是：先用裸 review 跑几次小改动建立手感，再上 --from/--to 接进你的分支流程，等确实有老代码体检需求了再用 scan，delegate 放到最后。

四、接进 CI：明确支持四个平台

工具真正产生价值通常不是在你本地手敲的时候，而是接进流水线之后自动跑。仓库列出的集成对象是四个：GitHub Actions、GitLab CI、GitFlic CI、Gerrit。

这个清单值得逐个看一眼。GitHub Actions 和 GitLab CI 是最主流的两个，覆盖了绝大多数团队；Gerrit 的出现说明它认真考虑过传统企业内部的代码评审流程——Gerrit 在国内一些中大型公司和硬件、通信行业里仍然是主力，而这类环境恰恰是”评审积压、reviewer 时间不够”最严重的地方；GitFlic 则相对小众。

清单之外的平台（比如自建的其他代码托管系统）仓库没有列，不代表一定接不了——它本质是个 CLI，任何能跑 shell 命令的流水线理论上都能调起来，只是官方现成的集成模板得你自己补。具体每个平台怎么配、需要哪些权限和环境变量，以官方文档当前版本为准，别照抄别处的教程片段。

接进 CI 之前有件事要先想清楚：评审意见是拿来阻断合并的，还是仅作参考的。一上来就设成不通过就卡住合并，大概率会被团队骂——任何 AI 评审工具都会有误报，误报直接卡流水线是最快消耗团队耐心的做法。先让它以评论的形式出现，观察一两周，统计一下多少条意见真的被采纳，再决定要不要收紧。

五、仓库自述的那些数字，该怎么看

这一节可能是全文最需要冷静的部分。项目仓库列了几条差异点，我原样转述，但都标明这是项目仓库自己的说法：

混合架构：确定性流水线加 LLM Agent，仓库称这个结构可以消除通用 agent 常见的”位置漂移”与”覆盖不全”两类问题。
定位精度：有独立的评论定位模块，负责把意见准确挂到对应行上。
内置规则集：仓库称经过微调，覆盖 NPE、线程安全、XSS、SQL 注入这几类问题。
使用规模：仓库称在阿里内部经”数万开发者”使用，累计发现过”数百万个代码缺陷”。
token 消耗：仓库称在精度更高的同时，token 消耗约为 Claude Code 的九分之一。

最后这条最容易被断章取义地传播，所以专门说一句：这是项目自己的基准口径，没有第三方复现过。它测的是什么任务集、怎么定义”同等精度”、对比时两边分别用的什么模型，公开信息里都没有交代。这不是说它一定不实，而是说这类数字不能当成客观事实来引用，更不能拿它推出”open-code-review 比 Claude Code 强”这种结论——两者的定位本来就不同，一个是专用评审工具，一个是通用编码 agent，把通用工具在专用任务上的消耗拿来做分母，本身就不是一个公平的比较框架。

同样的态度也适用于”数万开发者""数百万缺陷”这两条。内部使用规模能说明它经受过真实工程环境的打磨，这是有价值的信息；但”发现过多少缺陷”这个口径里，一条被开发者点了”忽略”的误报算不算”发现”，外部无从得知。

放到整个 AI 评审工具赛道来看，同类产品还有 GitHub 的 Copilot code review、CodeRabbit 等等。想比较的话，只比公开可查的机制差异（是否开源、许可证、支持哪些代码平台、模型是否可自选、计费方式），别比效果——各家都没有可交叉验证的公开基准，谁的宣传页都不能当裁判。像 Copilot code review 那边的成本结构可以参考Copilot 代码评审的计费怎么算，那是能查到明确规则的部分。

六、局限和使用建议

诚实地说几条：

它不能替代人工评审。 AI 评审擅长的是有明确模式的问题——空指针、注入风险、并发访问共享状态这类。而真正需要 reviewer 的地方往往是”这个抽象层次对不对""这个改动跟三个月后的规划冲不冲突”，这些依赖的是项目背景知识，任何只看 diff 的工具都给不出答案。合理的期待是：它把机械的那一层过滤掉，让人把注意力留给判断题。

内置规则集的覆盖有偏向。 从仓库点名的 NPE、线程安全、XSS、SQL 注入看，重心明显偏后端服务类代码。如果你的项目是前端为主、或者是数据科学脚本，能吃到的规则红利可能没那么多，实际效果需要你自己跑几轮才知道。

它要花 token，成本得自己扛。 它自己不带模型，用的是你配的供应商，评审量上去之后账单是实打实的。尤其 scan 模式，整文件送审的消耗跟 diff 模式不是一个量级，接 CI 之前先在本地估一下单次消耗，再乘以团队每天的合并次数，心里有个数。

star 数不等于成熟度。 截至 2026-07-28，GitHub 页面显示这个项目有约 15,000 star、约 1,000 fork，当天 Trending 榜上的增量是 979。热度确实高，但热度只说明关注度，不说明它在你的技术栈上好不好用。开源项目怎么评估更靠谱，可以看开源项目选型的判断方法。

小结

第一，装它只需要 npm install -g @alibaba-group/open-code-review，命令名是 ocr，跟光学字符识别无关。第二，配置就两条命令 ocr config provider 和 ocr config model，交互式引导并自动测连通性，供应商侧兼容 OpenAI 与 Anthropic 两种接口格式。第三，四种模式各有场景：日常提交自查用 ocr review，合并前用 --from/--to 做分支对比，给老模块体检用 ocr scan --path，ocr delegate preview 放到最后再碰。第四，CI 侧官方列出的是 GitHub Actions、GitLab CI、GitFlic CI、Gerrit 四个，接进去时建议先只发评论、别急着卡合并。第五，仓库自述的 token 消耗、使用规模等数字都是厂商口径、无第三方复现，可以作为参考，但不适合拿来做工具之间的高下判断——真要选型，自己在真实仓库上跑两周比看任何宣传都可靠。