open-code-review

open-code-review 快速入门：让代码评审先有明确范围

这是什么？适合谁？

Open Code Review 是 Alibaba 开源的代码审查 CLI，同时提供面向编码助手的插件和可调用技能。站内按 Skill 收录的是这套助手集成入口，而不是把整个项目误当作一段纯提示词。

它读取 Git 变更，通过确定性文件选择、规则匹配与模型 Agent 结合的方式输出评审意见；也能用 ocr scan 检查完整文件。普通模式需要单独配置模型，委托模式则交给宿主助手的模型执行。

适合希望在提交前预审代码、给现有编码助手增加审查流程的开发者。它不代替测试、静态分析、人工评审，也不保证找出所有问题。

项目方介绍了内部使用经历和基准结果。这些属于项目方声明，不能直接当作本站在你的代码、模型和语言上的效果保证。

核验日期：2026-10-19。操作依据为官方 README与插件说明。

准备工作

• Git 至少为 2.41；这是官方列出的前置条件。
• 使用 npm 安装路径时，准备 Node.js/npm 和可写的包安装目录。
• 建一个没有密钥、客户代码与私有配置的测试仓库。
• 普通模式准备模型服务与预算；委托模式确认宿主助手支持对应集成。
• 运行前保存当前改动，审查与自动修复分开授权。
• 软件使用 Apache-2.0 许可，模型费用与宿主订阅另算。

先在终端检查环境。

git --version
node --version
npm --version

如果版本或权限有问题，先修环境，不要把安装失败当成审查能力不足。

三步快速上手

第一步：安装 CLI，确认模型连接

npm install -g @alibaba-group/open-code-review
ocr --help
ocr config provider
ocr config model
ocr llm test

官方配置向导用于选择服务商、输入密钥与选择模型。不要把真实密钥写入示例代码、截图或版本库。

预期结果：ocr 命令可用，连接测试通过。仅安装包成功还不能执行需要模型的普通评审。

如果只打算使用委托模式，可以不为 OCR 单独配置模型，但宿主助手本身仍需有效模型与权限。

第二步：选择与你助手一致的集成

以 Claude Code 为例，在助手内执行以下官方插件命令，不是在普通 shell 中运行。

/plugin marketplace add alibaba/open-code-review
/plugin install open-code-review@open-code-review

对应入口包括 /open-code-review:review 与 /open-code-review:delegate-review。安装后先确认当前会话能够发现插件，再给测试任务。

Codex 用户按官方插件说明先添加 marketplace，进入 /plugins 安装并启用，再开始新任务；不要把 Claude Code 的斜杠命令照搬过去。

Cursor 与 Kimi Code 也有各自安装说明。平台支持不等于所有平台用同一个目录，见平台集成说明。

第三步：只评审一份可核对的小变更

进入你明确授权的测试项目。先看 Git 状态，再运行评审。

cd your-project
git status --short
ocr review --format json --output result.json

默认工作区评审涵盖暂存、未暂存与未跟踪改动。不要因为只想查一个文件，就假定其他工作区文件不会进入范围。

给宿主助手的首个任务可以这样写。

只评审当前测试仓库的改动，不修改文件，不提交、不推送。
每个问题给出文件、位置、触发条件和最小复现思路。
把确定缺陷与需要确认的疑问分开；找不到问题时不要编造。

成功判定：结果文件可读取，问题位置与实际源码一致，引用的变量与调用确实存在。没有意见只代表本轮未报告问题，不能理解成代码已安全。

初级用法

1. 提交前工作区预审

用 git status 确认范围，让 OCR 解释每条意见，再由开发者核实。先判断问题是否成立，再决定是否修复。

把输出保存到仓库外或明确的忽略目录；结果文件本身若变成未跟踪文件，下一轮可能改变评审输入。

2. 评审一个明确提交

ocr review --commit abc123

这里的 abc123 是占位示例，必须替换为测试仓库中真实提交。核对提交包含哪些文件，避免评价了错误版本。

3. 比较分支变更

ocr review --from main --to feature-branch

官方说明该模式以分支分叉点为基础评审。先确认本地引用是否最新、目标分支是否正确；命令能跑不代表基线选对了。

高级玩法

1. 对无有意义 diff 的目录做全文件扫描

ocr scan --path internal/agent

将路径替换为真正授权的目录。首次不要扫描整仓，先看一个小模块的成本、耗时与意见质量，再扩大范围。

2. 用委托预览理解规则与文件选择

ocr delegate preview
ocr delegate rule src/main.go src/handler.go

后面的文件名也是示例，换成真实存在的文件。预览有助于看清 OCR 提供哪些上下文与规则，但不等于完整评审已经执行。

3. 恢复中断的评审

ocr session list
ocr review --from main --to feature-branch --resume <session-id>

尖括号内替换为真实会话 ID，不要原样粘贴进 shell。恢复前确认代码版本与原会话是否一致，发生重要变更时不要盲用旧结果。

常见踩坑

踩坑 1：有插件但找不到 ocr。

插件依赖本地 CLI。先在同一运行环境检查命令是否可发现，再检查 npm 全局安装目录与 PATH；不要连续重复安装插件。

踩坑 2：普通模式没有配置模型。

普通评审需要有效服务商与模型。运行 ocr llm test 核实连接；若采用委托模式，确认调用的是对应入口，而不是混用两套执行路径。

踩坑 3：把工作区模式理解成只读暂存区。

官方明确工作区模式包括未暂存和未跟踪文件。先检查 Git 状态，移除无关输入的方式由仓库规则决定，不能为了审查直接删除他人文件。

踩坑 4：看到精确行号就相信问题成立。

行号定位与缺陷判断是两件事。逐条核对触发条件、调用方和测试；尤其注意被假设为可空、并发或外部输入的值是否真满足条件。

踩坑 5：把评审指令顺手升级成自动修复。

助手集成可能支持修复类任务，但初次使用应只读。需要修复时先保存快照、限定文件，再跑测试和独立复核，不让审者自行提交上线。

以上排查由官方前置条件、工作区范围和执行模式推导，不是本站复现故障记录。

小技巧

1. 首轮用自己熟悉的小 diff，判断误报比只看报告长度更有效。
2. 保存模型、版本与基线提交，才有条件比较两轮结果。
3. JSON 输出便于做问题去重，但仍需保留位置和解释。
4. 先复现一条高置信缺陷，再考虑把审查接入持续集成。
5. 代码会送往哪个模型端点，要在审查前确认而不是事后补查。

常见问题 FAQ

Q1：这是独立工具，还是 Skill？

A：核心是 CLI，官方另外提供插件与可移植技能；两者需一起理解，见插件文档。

Q2：开源是否意味着审查完全免费？

A：不是。普通模式的模型 API、委托模式的宿主服务，以及 CI 资源都可能产生费用。项目许可证不包含这些服务。

Q3：不配置 OCR API key 能用吗？

A：官方委托模式允许宿主模型执行评审；普通模式仍要配置 OCR 的模型连接。是否适合你的助手取决于相应集成。

Q4：与 PR-Agent、CodeRabbit 怎么比较？

A：先确定你要本地命令行、助手内技能还是托管 PR 流程；查看PR-Agent与CodeRabbit的实际接入方式，不把某个项目的基准排名套到所有任务。

Q5：没有发现问题能直接合并吗？

A：不应据此跳过测试和人工责任边界。模型审查可能漏报，也可能误报；合并仍遵守原仓库的验收与审批规则。

继续学习

依次理解 ocr review 的 diff 范围、ocr scan 的全文件范围和 ocr delegate preview 的委托上下文，再读规则匹配与 CI 文档。把“选对文件、找对位置、问题成立”分成三项独立验收。

免责声明

本文基于官方文档和公开资料整理，AI辅助生成，MagicNetWorld 尚未完成独立实测。未安装插件、连接模型或复现项目方基准，实际召回率、误报率和成本需在你的代码上测量。

参考链接

• 官方仓库
• 助手插件与技能安装
• 官方文档
• GitHub 社区指标