open-code-review：把确定性工程塞进 AI 代码审查的阿里开源 CLI

它解决的是通用代理审查的三个老毛病

通用代理做代码审查时，常见三个问题：大变更集上漏文件，行号飘移，质量随提示词波动。open-code-review 的 README 把这归因于纯语言驱动架构缺少硬约束。它把审查流程拆成确定性工程和代理两部分。确定性部分管文件选择、文件打包、规则匹配、评论定位和反思。代理部分只管动态决策和动态上下文检索。这个分工意味着，凡是不能错的地方，比如哪些文件该审、评论该贴在哪一行，都不交给模型自由发挥。结果是 Precision 和 F1 比通用代理高，但 Recall 低。这是设计上的取舍，不是缺陷。

确定性工程的具体机制：打包、匹配、定位

文件打包是其中一个关键设计。它把相关文件归成一个审查单元，比如 message_en.properties 和 message_zh.properties 会绑在一起。每个单元跑一个子代理，上下文隔离，支持并发。这对超大变更集很重要，因为单代理上下文会爆，而分而治之能保持稳定。规则匹配用模板引擎，不是纯语言引导。它根据文件特征匹配审查规则，把模型注意力集中在相关问题上，减少信息噪音。评论定位和反思是独立模块，一个负责把模型输出映射到准确行号，一个负责修正内容准确性。这些模块全部是确定性逻辑，不依赖模型。

代理部分：场景化提示词与工具集

代理不是通用工具包，而是为代码审查专门裁剪过的。README 提到，工具集是从大规模生产数据中的工具调用轨迹里提炼出来的，分析了调用频率分布、每个工具的重复率、新工具对调用链的影响。提示词模板也针对审查场景优化过，目的是减少 token 消耗。代理能读完整文件、搜索代码库、查看其他变更文件，所以它能做深层审查，不只是 diff 表面的反馈。但注意，这些能力都受确定性模块的约束，代理不能自己决定审哪些文件，只能决定怎么审。

安装与配置：npm 一条命令，但模型必须自己配

安装很简单，npm install -g @alibaba-group/open-code-review，装完就有 ocr 命令。前提是 Git 版本至少 2.41，因为工具依赖 Git 生成 diff、搜索代码和操作仓库。用之前必须配置 LLM，除非用 Delegation Mode。配置过程是交互式的：ocr config provider 选择内置供应商或自定义，ocr config model 为当前供应商选模型。没有模型端点就跑不起来，这一点和很多 AI 工具一样。README 没有给出具体模型列表，所以你得自己去看官方文档。

除了 diff 审查，还有 ocr scan 全文件审查

diff 审查只针对变更行，但 open-code-review 还提供 ocr scan，用来审查整个文件。这个功能针对的是没有有意义 diff 的场景，比如审计不熟悉的代码库，或者审查某个目录。它把整个文件交给代理，配合确定性规则做行级输出。这个功能的价值在于，它把工具从 CI 场景扩展到代码审计场景。但注意，全文件审查的 token 消耗会明显高于 diff 审查，因为输入变多了。README 没有给出具体数字，但这个逻辑是显然的。

基准数据：Precision 高，Recall 低，token 省 9 倍

README 引用了 AACR-Bench 基准，由 50 个热门开源仓库、200 个真实 PR、10 种语言构成，80 多名资深工程师标注了 1505 个真实问题。对比对象是 Claude Code 这类通用代理。结论是 open-code-review 在相同底层模型下，Precision 和 F1 显著更高，token 消耗只有约九分之一，审查速度更快。但 Recall 更低。这意味着它漏报更多，但报出来的问题更可能是真问题。对 CI 来说，低噪音比高召回更重要，因为误报会消耗工程师的注意力。但如果你指望它抓出所有漏洞，它会让你失望。

局限与替代方案：它不是安全扫描器

一个明显的局限是，它依赖 LLM 的推理能力，所以对模型质量敏感。如果你配的模型能力弱，Precision 和 Recall 都会下降。另一个局限是，确定性规则匹配依赖文件特征，如果文件类型不在规则覆盖范围内，代理可能得不到正确的规则引导。替代方案是通用代理，比如 Claude Code 加 Skills。README 明确指出通用代理在 Recall 上更高，但 Precision 和 F1 更低，token 消耗大 9 倍。所以选择在于你的优先级：如果你追求全面覆盖，通用代理更合适；如果你追求低噪音和低成本，open-code-review 更合适。

维护与许可证：Apache-2.0，但模型费用自担

项目许可证是 Apache-2.0，允许商用和修改，但你不应该把它当法律建议。维护方面，最近发布节奏是 v1.11.0、v1.10.2、v1.10.1，间隔一天左右，说明活跃。但没有证据表明有长期维护承诺。升级成本在于，每次版本更新可能改变规则匹配行为或代理工具集，你需要重新跑基准测试。另外，token 消耗是运行成本的主要部分，即使比通用代理省 9 倍，大规模使用仍然要花钱。模型端点由你自己配置，所以成本完全取决于你的使用量。

编辑结论

如果你的团队在 CI 里需要低噪音、行级定位准确的代码审查，并且能接受漏报率偏高，open-code-review 值得一试。它特别适合大变更集和需要并发审查的场景。但别把它当成安全扫描器或全量代码审计工具，它的召回率低于通用代理，规则匹配依赖文件特征，覆盖不了所有漏洞类型。部署前先确认三件事：Git 版本不低于 2.41，准备好可用的 LLM 端点，以及用你自己的代码库跑一遍 ocr scan，对比它报出的问题与人工审查结果，看噪音水平是否可接受。它的 Apache-2.0 许可证允许商用，但模型调用费用和 token 消耗需要你自己承担。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes