AI 编程工具越来越多，写代码的速度正在变快。
但另一个问题也随之出现：代码写得越快，Review 的压力越大。
之前我也vibe coding了一个开发管理和代码审核的系统，Agentic-DevOps / DevManager-Agent 项目，但主要目的还是管理开发，对于Review这一块一直没有太好的方向。
所以团队内Code Review 主要靠AI Agent + 人。
资深工程师看架构、看边界、看异常处理、看安全风险，也看那些“不一定会报错，但迟早会出事”的细节。
但实际用下来，经常会遇到几个问题：
- 输出质量不稳定，同样的代码换个提示词，结果差异很大
当我准备继续优化我自己的Agentic-DevOps / DevManager-Agent 项目时候，我看到阿里开放了Open Code Review工具。
真是来得早不如来得巧，就像现在很多人打趣现在的情况：只要我AI学得够慢，后面什么工具都会有的。
言归正传，刚才我们难以解决和正在优化的问题，也是 Open Code Review 想解决的问题。
这两天我仔细看了一下这个工具的具体说明，以及我自己本地测试下来，我想给大家推荐一下这个工具。
首先：Open Code Review 是什么？
Open Code Review 是阿里开源的一款 AI 驱动代码审查 CLI 工具。
它的前身是阿里集团内部官方 AI 代码审查助手。据项目 README 介绍，过去两年它已在阿里内部服务数万名开发者，识别了数百万个代码缺陷，经过大规模验证后开放给社区使用。它可以读取 Git diff，把变更文件交给具备工具调用能力的 Agent 分析，并生成行级精度的结构化审查意见。
简单说，它不是一个“把 diff 丢给大模型，然后等一段自然语言评价”的小脚本。
它更像是一套专门为 Code Review 场景设计过的 AI 审查流水线。
它解决的核心问题：让 AI Review 更稳定
Open Code Review 最有意思的地方，是它没有把所有事情都交给大模型。
它采用的是“确定性工程 × Agent”的混合架构。
哪些文件需要审查、哪些文件应该过滤、相关文件如何打包、规则如何匹配、评论位置如何校准，这些容易出错但必须稳定的环节，由工程逻辑来约束。
而 Agent 负责它更擅长的部分：理解代码上下文、检索相关文件、结合规则判断风险，并给出具体审查意见。
这套分工很关键。
因为 Code Review 不是闲聊。它要尽量少漏报，也要尽量少误报；它不仅要“看起来懂”，还要把问题定位到具体代码位置，让开发者能真正处理。
它能审什么？
Open Code Review 支持基于 Git diff 的变更审查，也支持用
这意味着它不仅适合日常 PR / MR Review，也适合下面这些场景：
- 在 CI/CD 中自动检查 Pull Request
- 在 Claude Code、Codex、Cursor 等编程 Agent 工作流里作为审查工具使用
项目内置了面向代码缺陷的规则集，仓库描述中提到了 NPE、线程安全、XSS、SQL 注入等典型风险类型。它也支持 OpenAI / Anthropic 兼容接口，团队可以接自己的模型服务或私有网关。
怎么开始使用？
如果只是本地体验，官方推荐通过 npm 安装：
npm install -g @alibaba-group/open-code-review
安装完成后，全局会有 OCR命令。
首次使用前，需要配置 LLM：
ocr config providerocr config modelocr llm test
然后进入项目目录，直接审查当前工作区变更：
也可以审查两个分支之间的差异：
ocr review --from main --to feature-branch
如果想扫描整个仓库或指定目录：
ocr scanocr scan --path internal/agent
CI 场景下，可以输出 JSON，方便流水线解析，建议大家使用这个方法，否则看起报告来很艰难：
ocr review \ --from ”origin/main” \ --to ”origin/feature-branch” \ --format json
为什么值得关注？
Open Code Review 值得关注，不只是因为它来自阿里的内部实践，也不只是因为它开源了。
更重要的是，它代表了 AI 工程工具的一个方向：从“通用 Agent 什么都做”，逐渐走向“工程系统负责约束，Agent 负责判断”。
在真实研发流程里，稳定性往往比炫技更重要。
Code Review 也是如此。一个 AI Review 工具，不能只会说“这段代码可能有问题”，它还要知道看哪些文件、用哪些规则、如何控制误报、如何定位到准确行号、如何在大变更里保持覆盖率。
Open Code Review 的设计思路，正是把这些工程问题认真拆开处理。
适合谁使用？
如果你是个人开发者，它可以作为提交前的自检工具，帮你在发 PR 前先扫掉一批低级问题。
如果你在团队里负责质量、效能或 DevOps，它可以接入 CI/CD，在 MR / PR 阶段自动生成审查建议。
如果你已经在使用 Codex、Claude Code、Cursor 这类编程 Agent，它也可以作为一个专门的 Review 能力补充，让 Agent 写完代码之后，再走一遍更聚焦的代码审查流程。
写在最后
AI 写代码正在变快，但软件工程不能只追求“写得快”。
真正决定交付质量的，仍然是那些看似朴素的环节：审查、测试、定位、反馈、修复。
Open Code Review 的价值就在这里：它不是让 AI 替代工程师，而是把 AI 放进一个更可控、更工程化的审查流程里，让代码审查变得更快、更准，也更适合进入真实团队的研发流水线。
如果你想更好的vibe coding，你就该认真考虑：如何用 AI 审代码。
效果如何？
Open Code Review 的前身已在阿里集团内部经过大规模生产环境验证，这组数据表明，Open Code Review 不仅具备大规模落地的工程能力，更在真实开发工作流中获得了一线工程师的广泛认可。
以下数据的前提为 CR 被合并到目标分支中：
目前官方已经对于真实场景的 CodeReview 基准测试进行了客观评估，该评测集从 50 个热门开源仓库中精选 200 个真实的 PullRequest，覆盖 10 种编程语言、多种问题类型与不同的变更规模，并由 80+ 位资深工程师交叉标注完成。评测对比了三类工具：Open Code Review（v1.3.1）、Claude Code（v2.1.169，/code-review）和 Codex（v0.140.0，/review），涵盖 Claude-4.6-Opus、Claude-4.8-Opus、GPT-5.5、Qwen3.7-Max、Deepseek-V4-Pro、GLM-5.1 共六款主流模型。
结论一：不同工具在准确率与召回率上各有所长
Open Code Review 的核心优势在于准确率：各模型的准确率在 25%–38% 之间，远高于 Claude Code 的 7%–16%。以 Claude-4.6-Opus 为例，OCR 产出 889 条评论、命中 301 个真实问题（准确率 33.90%），而 Claude Code 产出 5980 条评论、命中 435 个真实问题（准确率 7.23%）。更高的准确率意味着更低的噪声，工程师在处理评审结果时效率更高。然而，Claude Code 的核心优势在于召回率：CC + Claude-4.6-Opus 以 28.90% 的召回率位居所有组合之首，实际命中了 435 个真实问题——比 OCR 最优组合多发现了 134 个（增幅约 45%）。不仅如此，CC + Qwen3.7-Max（23.37%）和 CC + GLM-5.1（20.80%）的召回率同样超过了 OCR 的多数组合。对于安全审计等"宁可多查、不可遗漏"的场景，更高的召回率有着不可替代的价值。综合来看，Open Code Review 凭借 F1 指标领先（最优 25.10% vs Claude Code 最优 14.13%），在准确率和召回率之间取得了更均衡的表现；而 Claude Code 则在最大化问题覆盖方面更具优势，适合对遗漏风险容忍度低的场景。三类工具在资源消耗上呈现出明显的层次差异。Open Code Review 的平均 Token 消耗为 352K–743K，耗时 1–6 分钟，是三者中效率最高的选择。Claude Code 的 Token 消耗在 2,062K–5,664K 之间，耗时 5–14 分钟，资源开销显著更高，但更高的召回率使其在深度审查场景中仍具价值。Codex 的 Token 消耗（525K）和耗时（约 3 分钟）与 OCR 处于同一量级，且保持了 27.82% 的准确率，但 4.92% 的召回率使其仅能覆盖少量问题，更适合作为轻量级的快速扫描工具。一个值得关注的现象是，Claude-4.8-Opus 在两个工具上均表现出"更精确但更保守"的特征：它的准确率是所有组合中最高的（OCR 上 37.80%、CC 上 15.93%），但召回率明显低于 Claude-4.6-Opus（OCR 上 11.70% vs 20.00%、CC 上 12.70% vs 28.90%）。这说明模型的代际升级并不一定带来代码评审效果的全面提升 —— 更强的模型能力可能倾向于更严格的判断标准，从而在提升精度的同时牺牲了覆盖面。Open Code Review 评审一个由 Claude Code 从零构建的生产级项目：需求管理平台，功能包括：需求记录，需求分析，方案设计，版本发布，测试用例，RAG知识库等等，是我自己当初早期搭建的一个vibe coding项目，基本功能已经全部完成，达到了MVP上线的水准。可以看到：estimated cost: ~307 file(s), est. 9.4M input + 1.6M output ≈ 11.0M total tokens (rough; actual reported after run)已经给出预估的token总数：11M，还是可以接受的，不过这一块的统计已经消耗了我450K的token，，在我三次重新请求的结果下，token命中率始终保持在66.7%左右，说明这里的命中率确实不高。结果终于出来，总体的token消耗量看了一下，11.68M，基本和他预估的差不多，缓存命中率45%，虽然说比较低，但是可以看出确实在不同的区域进行了review，没有过多的重复上下文，不过对于这种同一个项目内多次grep，命中率这么低，我不做具体的评价，我们来看看结果。- 不是单点 lint，而是 10 大类横切：授权、并发（TOCTOU）、数据质量（embedding 维度漂移）、认证（JWT 信任）、迁移安全、错误吞噬、串行await、类型安全、Prompt 注入、硬编码。这种"全仓扫描 → 模式聚合"的做法比单文件 review 信息密度高一个量级。
- Top Issues 用"critical / data integrity / data quality / security / availability"打了标签，而不是平铺。
- 例：server/src/routes/agent.routes.ts 的/planning/dependencies 接受任意 reqIds 数组并缺 ACL；server/src/middleware/auth.ts缺 algorithms 白名单。这种粒度直接可执行。
- #1 改 (err as Error).message、#2 加 forwardRef、#6 改 data-inset={inset || undefined}、#9 pin JWT 算法、#10 用prisma.$transaction 包 find-then-create — 都是 1~5 行代码级别的手术刀。
- embedding 维度漂移、JWT 7 天信任窗口、Prisma 迁移 ACCESS EXCLUSIVE 锁、process.exit(1) 绕过 finally、permission cache key 只用userId 而不带 role+group。这些不是 grep 能找出来的，是要理解业务模型才能识别的。
不足之处，总的来说，最突出的一点就是，告诉了你问题在哪，但是怎么修没有讲解清楚。另外一些比较突出的就是没有优先级，先做哪个，再做哪个，没有考虑投入产出比，所有的问题也没有给出一个具体的修复完成后可达到量化标准。最重要的一点，从整体报告来看，他的查询BUG方式主要是grep方式，没有引入QA测试逻辑，所以后续还要根据报告进一步完整所有的不足之处。总的来说，能力确实很强，如果在git diff之间做代码review很适合，作为日常的代码管理足够，可以代替之前我们vibe coding的开发管理，并且能力更强，但是如果需要遍历整体的项目代码进行review，我觉得可以往两个方向开展：1：整体review代码，根据报告，再逐个人为review2：按照功能点和路径进行review，分散集中扫描导致的上下文超长，以及报告重点不突出的问题。但无论哪种方式，IDENTIFY→RUN→READ→VERIFY→THEN这个门控的逻辑还是需要守住。
粤ICP备14082021号
免费POC，
零成本试错
