阿里开源的 open-code-review：为什么代码审查要给 LLM 上一条确定性管线
上周在 GitHub 上又刷到一个 AI 代码审查工具，阿里开源的，叫 open-code-review。
说实话第一反应是划走。这类东西太多了。
但看到一行数据停下了：阿里内部两万多个开发者在用，跑过一百万次以上的审查任务，采纳率超过 30%。而且——token 消耗只有"通用 Agent + Skills"那套做法的五分之一。
采纳率 30% 是什么概念。你让一个 AI 挑代码毛病，它提十条，有三条你真照着改了。做过代码审查的人知道，这个数字不算低。
中文世界里"怎么装怎么用"已经被写烂了，阿里云、掘金、CSDN 一大堆教程。我想讲的是另一件事：为什么这工具敢把"确定性管线"四个字写进架构里，而不是像大部分 AI review 工具那样，把 diff 一股脑丢给大模型，让它自己看着办。
这背后有个我认同的工程判断。教学夹着它一起讲。
先说你大概率踩过的坑
你打开 Claude Code，或者随便哪个通用 agent，说"帮我 review 这个 PR"。三种事经常发生。
一是它偷懒。PR 改了 40 个文件，它挑几个看了看就开始总结，剩下的当没看见——上下文塞不下，模型自己做了取舍，你还不知道它舍了哪些。
二是行号对不上。它说"第 87 行有空指针风险"，你翻过去，第 87 行是个注释。它把位置记串了，甚至引用了根本不存在的代码。
三是今天一个样、明天一个样。提示词改一个字，审查重点就飘了。纯自然语言驱动的审查逻辑，没法调试，也没法保证两次结果一致。
这三件事，恰恰是代码审查最不能容忍的。审查这活的价值在于"稳"——同样的问题，这次抓得到，下次也得抓得到。
大模型天生不稳。
五分钟装好
open-code-review 的装法很常规。
npm install -g @alibaba-group/open-code-review装完全局多一个 ocr 命令。第一次用要配一下模型：
ocr config provider # 选大模型服务商
ocr config model # 选具体模型会弹一个交互界面，填 API key、测连通性。不想走交互也行，直接给环境变量：
export OCR_LLM_URL="你的模型端点"
export OCR_LLM_TOKEN="你的密钥"
export OCR_LLM_MODEL="你选的模型"一个细节值得说：代码在你本地跑，不出私有环境。它把 diff 和必要的上下文发给你自己配的模型端点，仓库不上传到任何第三方。企业里这条往往是"能不能用"的前提。
三种审查姿势
装好之后，审查有几种姿势，对应你实际的工作场景。
看工作区当前改动（暂存、未暂存、未跟踪的都算）：
ocr review只看已暂存的：
ocr review --staged对比两个分支——提 PR 前最常用的：
ocr review --from main --to feature-branch盯单个提交：
ocr review --commit abc123review 到一半断了不用重来，会话能续：
ocr session list
ocr review --from main --to feature-branch --resume <session-id>如果不是审查改动，而是想把老代码整体扫一遍找存量问题：
ocr scan
ocr scan --path internal/agent内置的规则集是细粒度的——空指针、线程安全、XSS、SQL 注入这些，都有针对性的检测，而不是笼统地问模型"这段代码有没有问题"。
为什么要给 LLM 上一条管线
现在说回开头那个判断。
open-code-review 的架构，一句话概括：能确定的事交给代码，不能确定的事才交给模型。
那些"绝对不能出错"的环节，它用确定性的流水线兜住。
哪些文件要审、哪些不用（自动生成的、无关的直接过滤掉），这不该让模型猜，用规则筛。
大 PR 怎么拆，它做"智能打包"：把相关的文件分成一组一组，每组派一个独立的子 agent 去看，彼此不干扰上下文。这就堵住了前面说的"偷懒漏文件"。
行号定位单独有个模块管，再加一个反思环节复核，把行级评论的准确度顶到接近 100%。前面说的"行号漂移"，从架构上被摁住了。
规则匹配用模板引擎，按语言匹配那些已知的坏味道，先把噪音降下来，再让模型上。
模型干什么？干它真正擅长的那部分：读懂语义。拿到已经筛好、打包好、定位好的输入之后，它才开始理解这段逻辑想干嘛——调 file_read 看完整文件，用 code_search 找全局相关代码，做深层判断。
分工很清楚。
确定性管线负责"下限"：保证覆盖不漏、位置不错、结果能复现。LLM 负责"上限"：在干净的输入上做人干不过来的语义理解。
这也是它 token 只花五分之一的原因。不是模型更省，是没让模型去干那些本该规则干的脏活。你把 40 个文件的原始 diff 整个塞给大模型，光让它自己分辨"哪些该看"，就烧掉一大把 token，还容易分神。规则先把这步做完，模型只拿到它该看的，自然又快又准。
当然，这套东西也不是没代价。规则得有人维护，语言得一个个适配，冷门场景可能没覆盖。工程化的东西都这样，省了模型的力气，得有人在别处补上。
接进流水线
单机手动跑一次爽，但代码审查真正的价值在自动化里。
它能接 GitHub Actions、GitLab CI、Gerrit 这些，PR 一提就自动审，结果贴回 PR。审查结果能导成结构化的 JSON，方便你自己写闸门——比如"有高危问题就卡住合并"。
还有个我挺喜欢的模式，叫 delegate（委托）。如果你已经在用 Claude Code、Codex 或者 Cursor，可以不单独配模型，让 open-code-review 借用你手头这个 coding agent 去审：
ocr delegate preview
ocr delegate rule src/main.go src/handler.go它还给 Claude Code 出了个插件，装上就是几个 slash 命令，在你写代码的地方直接调。对已经吃 AI 编码的团队，这个接入成本几乎为零。
别指望它替你把关
最后几个坑，说在前面。
它不替代人审。它擅长的是那些有明确模式的问题——空指针、注入、并发。业务逻辑对不对、这个抽象合不合理、这个改动会不会坑到三个月后的自己，这些还得人看。把它当成"帮你先过一遍、把脏活累活干掉的初审"，别当终审。
delegate 模式省心，但受制于你那个 agent 的水平；自己配模型端点更可控。企业里我更倾向后者，代码不出门这条太重要。
还有，采纳率 30% 反过来说，就是七成提示你不会照做。别指望它句句金玉良言。审查工具的意义从来不是"永远对"，是"稳定地帮你多抓住那三成"。
纯提示词那套，模型强一点结果就好一点，模型飘一天结果就烂一天，你控制不了。
给它上一条确定性的管线，等于给一个聪明但爱走神的实习生配了个较真的流程。
聪明还是那个聪明。只是这回，它不敢漏文件了。