阿里 OpenCodeReview 做对了什么，不是 Prompt，而是审稿流水线

大家好，我是若风。

6 月 27 日晚上，我刷到阿里开源的 OpenCodeReview。

第一眼看数据，挺猛。

这个仓库 2026 年 5 月 18 日创建，到我抓取时已经有 9,441 stars、610 forks，主语言是 Go，最新 release 是 6 月 26 日的 v1.6.4，最新一次 push 是 6 月 27 日上午。

更有意思的是，它不是一个普通的「让 AI 帮你 review 代码」工具。

README 里讲得很直，OpenCodeReview 来自阿里内部官方 AI Code Review 助手，过去两年服务过数万名开发者，识别过数百万个代码缺陷。开源版现在做成了 CLI、VSCode 插件、Claude Code 插件、Codex 插件、Cursor 插件，还能接 CI/CD。

说真的，这个定位很容易让人误会。

你可能会想，Code Review 这事用 Claude Code 不就行了吗。把 diff 扔进去，让它挑问题，再让它给评论。

但 OpenCodeReview 真正想解决的，不是「LLM 会不会看代码」。

它解决的是另一个更痛的问题。

怎么让 LLM 的代码审查，稳定地进入真实研发流程。

先说结论

OpenCodeReview 的核心价值，不是把一个通用 Agent 包装成 review 命令，而是把 AI Code Review 拆成了一条确定性流水线。

文件怎么选，规则怎么匹配，diff 怎么分包，评论怎么定位，错误评论怎么过滤，这些不交给模型自由发挥。

模型只负责它擅长的部分，理解上下文、判断风险、生成解释。

这就是它最值得拆的地方。

我自己的判断是 4 个点。

坦率的讲，这不是一个 Prompt 项目。

它更像一个 AI Review Harness。

通用 Agent 做 Code Review，为什么会翻车

OpenCodeReview 的 README 里把通用 Agent 的问题拆成 3 个。

大改动里容易漏文件。

评论位置会漂。

质量会随着提示词微调上下波动。

这个判断我挺认同。因为 Code Review 和普通问答不一样，它不是模型写一段分析就结束了。它必须满足几个很硬的工程条件。

第一，覆盖范围不能丢。一个 PR 改了 20 个文件，模型不能只看它顺眼的 5 个。

第二，评论位置必须准。review 评论如果挂错行，开发者第一反应不是「谢谢提醒」，而是「这东西不靠谱」。

第三，噪音要低。Code Review 里最伤信任的不是漏一个小问题，而是连续报 10 个没必要的警告，让人开始本能忽略它。

你想想看，通用 Agent 天然喜欢自由探索。它会挑重点，会总结，会推理，也会被提示词细节影响。

这在写文档时可能是优点。

放到 Code Review 里，就变成风险。

所以 OpenCodeReview 的思路不是让 Agent 更自由，而是让它更受控。

这条流水线是怎么跑的

从实现看，internal/agent/agent.go 里 Agent.Run 的流程很清楚。

它先解析 diff，统计 changed files、insertions、deletions。然后把所有 diff 建成一个只读的 DiffMap，注入给 file_read_diff 工具。接着冻结工具注册表，过滤不该 review 的文件，再按文件并发派发 subtask。

单个文件里，又分成两段。

先是 plan phase。变更足够大时，模型会先做审查计划。默认模板里 PLAN_MODE_LINE_THRESHOLD 是 50，也就是说小变更可以跳过计划，大变更再多走一步。

然后是 main task loop。模型拿到当前文件 diff、同批次其他变更文件、匹配到的系统规则、可选业务背景、可选计划结果，再通过专用工具读取上下文和提交评论。

最后还有 review filter。它会把模型刚产出的评论再过一遍，只过滤掉那些仅凭当前 diff 就能确认错误的评论。

这里很妙。

它不是让第二个模型重新审一次。它只做一件很窄的事，事实核验。

这一窄，反而稳定。

最关键的细节，是评论定位

AI Code Review 里最容易被低估的细节，是定位。

一条评论内容再好，如果挂不到准确行号，体验就崩了。

OpenCodeReview 对这个问题下了不少功夫。code_comment 工具不让模型直接返回一个模糊位置，而是要求返回 existing_code，也就是评论对应的已存在代码片段。

然后程序再用动态滑动窗口去匹配 diff 里的连续行。

internal/diff/resolver.go 里也能看到这套思路。它会先从 diff hunk 里匹配新侧的 context 和 added lines，如果找不到，再回退到旧侧 context 和 deleted lines，最后还能扫描新文件内容做兜底。

这就是确定性工程的价值。

模型负责发现问题，程序负责把问题钉在代码上。

这两件事不能混在一起。

如果让模型自己报行号，它可能受上下文压缩、diff 格式、文件重排影响，数字看起来很像真的，实际却漂了。OpenCodeReview 让模型提供代码片段，再由程序做匹配，说到底是在把「定位」这件事从自然语言判断里拿出来。

说真的，这个设计比多写 500 字提示词更有用。

规则系统解决的是注意力问题

另一个硬细节，是规则匹配。

OpenCodeReview 内置了 system_rules.json，按路径匹配 review 规则。它覆盖了 17 类常见文件模式，比如 Java、Kotlin、Rust、C/C++、TypeScript/JavaScript、GitHub workflow、pom.xml、package.json、Cargo.toml、mapper XML、properties、YAML、JSON。

它还有 4 层优先级。

命令行 --rule 最高，其次是项目里的 .opencodereview/rule.json，再是用户全局 ~/.opencodereview/rule.json，最后才是内置系统规则。

这个东西解决的不是「规则多不多」。

它解决的是模型注意力。

你让一个通用 Agent 同时记住 Java NPE、SQL 注入、线程安全、前端 XSS、GitHub Actions 权限、properties 国际化，它当然会散。OpenCodeReview 先用工程逻辑判断当前文件是什么，再把对应规则塞给模型。

也就是说，模型不是带着一本厚厚的审查手册上场。

它每次只拿一页。

这会显著降低噪音。

它为什么要做 ocr scan

v1.6.0 里，OpenCodeReview 加了 ocr scan。

这个命令和 ocr review 不一样。review 看 diff，适合 PR 或 commit。scan 看整文件，适合审计陌生代码库、迁移前扫雷、或者没有 meaningful diff 的目录。

这一步很关键，因为它把 Code Review 从「提交前检查」扩展到了「代码库体检」。

但这里也有代价。

整文件扫描天然更耗 token，更容易重复报相似问题，所以它有 --max-tokens-budget、--batch、--no-plan、--no-dedup、--no-summary 这些参数。默认 batching 还能按语言或目录分批。

这个设计挺实在。

它没有假装全仓扫描永远便宜。它直接把成本预算暴露出来，让你先 --preview 看文件列表，再决定要不要花钱。

老实说，这才像能进 CI 的工具。

接入研发流程，比模型本身更重要

OpenCodeReview 的安装路径很多。

最简单是 npm。

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

如果在 CI 里跑，核心命令长这样。

ocr review \
  --from "origin/main" \
  --to "<commit_sha>" \
  --format json

它还支持 Claude Code、Codex、Cursor 的插件形态。比如 Codex 插件里最终还是跑本地 OCR CLI。

ocr review --audience agent

这个设计挺重要。它没有把自己绑定到某一个聊天客户端，而是把 CLI 做成核心，把插件、Skill、CI、VSCode 都当入口。

工具形态上，它很像在回答一个问题。

如果 AI Code Review 真的要进团队流程，它应该活在哪里？

答案不是只活在聊天窗口。

它要活在本地 CLI、IDE、CI、Agent 插件和 JSON 输出里。

benchmark 里藏着一个取舍

README 里有一段 benchmark 描述，我觉得比图片更重要。

它说这套评测来自 50 个热门开源仓库、200 个真实 PR、10 种编程语言，并由 80 多名资深工程师交叉验证，形成 1,505 个标注问题。

结论不是「全指标吊打通用 Agent」。

它明确承认，OpenCodeReview 相比 Claude Code 这类通用 Agent，Precision 和 F1 更高，token 大约只有九分之一，速度更快，但 Recall 更低。

这个取舍很诚实。

少报错，少花钱，少噪音。

代价是可能漏掉更多真实问题。

这其实很符合 Code Review 的生产场景。大多数团队不是缺一个能提出 100 条建议的 AI，而是缺一个能稳定提出 3 条靠谱建议的 AI。

你每天要合几十个 PR，低噪音比表演型聪明更重要。

当然，如果你在做安全敏感变更，低召回就会成为问题。ROADMAP 里也写了 H2 2026 计划做 Ultra Mode，用更多 token 和更长时间换更高召回。

这说明团队自己也知道边界在哪。

诚实的边界

OpenCodeReview 不是银弹。

第一，它仍然依赖外部 LLM。你可以接 OpenAI、Anthropic、Gemini、Bedrock、Azure OpenAI，也能接 OpenAI 或 Anthropic 协议兼容的私有网关，但它不打包自托管模型。README 和 ROADMAP 都讲得很清楚，OCR 连接模型，不负责托管模型。

第二，它默认偏 precision，不偏 recall。对日常 PR 很舒服，对高风险安全审查未必够。Ultra Mode 还在规划里，不是已经完成的能力。

第三，配置成本不低。Provider、API key、模型、规则文件、CI 参数、企业代理、额外 headers，这些都要配。对个人项目还好，对公司内网落地，真正难的是把环境打通。

第四，项目迭代很快，边界还在变化。最近几个开放 issue 里，有人问本地模型怎么 review，有人反馈 GitLab CI 报错，还有人提到 ocr review --commit 返回 0 files changed。PR 里也有标准 MCP 工具、CodeGraph 结构上下文、多模型 fallback 这些正在推进的方向。

第五，它明确不是自动修复工具。ROADMAP 的 Not Planned 写得很清楚，自动改代码必须有人审。它可以建议修复，但不应该替你把代码悄悄改掉。

这点我反而觉得加分。

Code Review 的价值不是让 AI 接管责任，而是把问题更早、更准、更低噪音地摆到人面前。

我真正学到的东西

OpenCodeReview 给我的启发，不是「阿里也做了一个 AI Code Review」。

而是 AI 工具开始从聊天能力，走向工程容器。

通用 Agent 会越来越强，这个趋势不用怀疑。但越是进入真实研发流程，越不能只靠模型自己记得该怎么做。文件范围、规则优先级、上下文工具、并发策略、token 预算、定位算法、过滤器、CI 输出，这些东西都得被写成程序。

模型负责不确定性。

程序负责确定性。

这两者合在一起，才像能长期用的工具。

我一直觉得，AI Code Review 最大的挑战不是让模型说出更多建议，而是让开发者愿意每天看它的建议。

愿意看的前提，是它少废话，少误报，挂得准，能解释，还能接进你已经在用的流程。

OpenCodeReview 这条路，正好踩在这个点上。

写在最后。

如果你只是想偶尔让 Claude 帮你看一段 diff，通用 Agent 已经够用了。

但如果你想把 AI Code Review 放进团队工作流里，OpenCodeReview 这种「确定性工程 × Agent」的混合架构，才是更值得研究的方向。

不是因为它更炫。

而是因为它更像工程。