它和「把 diff 丢给模型」有什么不同
多数 AI 评审工具的做法是把 diff 拼成一段提示词交给模型，让模型一次性给出意见。OpenCodeReview 把这条链路拆开：文件选择、上下文打包、规则匹配、以及拿评审意见去和 diff 做校验，这些都能确定性完成，交给流水线执行；只有代码分析交给带工具调用能力的 LLM 智能体。
这个分工带来的直接差别是上下文。智能体在评审时可以读完整文件、检索代码库、查看其它改动文件来补全因果，输出的意见带行号定位，而不是笼统的 diff 感想。对改动跨越多个文件、或者只看 diff 看不出意图的场景，这个差别很明显。
安装与配置
安装走 npm 全局包，装完 ocr 命令就全局可用：
- npm install -g @alibaba-group/open-code-review；
- ocr config provider：选择内置模型提供方，或添加自建端点；
- ocr config model：为当前提供方挑一个模型；
- 配置界面会引导完成 API Key 与模型选择，并自动做一次连通性测试。
如果暂时不想接模型端点，仓库说明里还提到一种委托模式（Delegation Mode），可以先不配模型跑通流程。对团队来说，第一天更值得做的不是挑最强模型，而是把评审口径定下来：哪些问题必须报、哪些噪音要压掉。
跑第一轮评审与整库扫描
进入项目目录后直接对当前 diff 发起评审即可，输出是按行定位的意见列表。另一种用法是 ocr scan，它不看 diff、针对整个文件或目录做扫描，适合接手一个没有近期改动、但需要审计的存量代码库。
内置规则集覆盖空指针、线程安全、XSS、SQL 注入这类常见缺陷，并根据文件语言选择规则。规则命中的问题与模型判断的问题在输出里是可区分的——这条边界很重要，因为规则命中是确定性的，可以拿来做门禁；模型意见需要先验证稳定性。
接入 CI 与编辑器
- 仓库说明列出的集成面包括 GitHub、GitLab、Gerrit、VS Code、MCP，以及 Claude Code、Codex、Cursor 这类编码智能体；
- 放在提交前或合并前的检查里跑一遍，把它当作第一道筛子，人工只需要处理筛出来的条目；
- 如果要用 MCP 把它接进智能体工作流，注意评审本身会消耗模型调用额度，跑在 hook 里时要设好触发条件，避免每次小改动都全量评审。
哪些意见能当门禁
判断标准只有一条：能不能稳定复现。做法是同一份 diff 连续跑两次，把两次都出现的意见列为候选门禁项，只出现一次的先当提醒。规则命中一般天然稳定，模型意见则需要按这个方式筛一遍。
另外一个容易被忽略的成本是规则维护。内置规则解决的是通用缺陷，而真正造成事故的往往是你们自己的业务约束——比如某类字段不允许直接落库、某个开关不允许默认开启。这类问题得靠人写成规则，收益也主要来自这里。
要让 AI 评审真正省人力，前提不是模型更强，而是把「哪些意见必须拦住合并」变成可复现的规则。