你请一位聪明助手检查装修，却只说“整套房子看看”。他可能认真检查了厨房，却漏掉卫生间；也可能指出墙角有裂缝，却把房间号写错。通用 AI 做代码审查时，也会遇到类似问题：改动一多，容易漏看文件、标错位置，提示词稍有变化，结果也跟着波动。
阿里巴巴开源的 Open Code Review，想解决的正是这类不稳定。它不是一个什么都能做的通用自主 Agent，而是一款 AI 代码审查 CLI 工具——CLI 即命令行界面，开发者可以在终端、本地脚本或持续集成流程中调用它。项目源自阿里内部的官方 AI 代码审查助手。以下规模数据和性能结论均来自阿里项目仓库及其论文，尚无第三方评测佐证。
先把流程管住，再让模型判断
代码审查，是在代码合并前检查缺陷、安全风险和可维护性问题。日常审查通常从 Git diff 开始。Git diff 会列出两个版本之间新增、删除或修改的代码行，让审查者把注意力放在本次变化上。
Open Code Review 读取这些差异，再通过具备工具调用能力的 Agent，把相关代码交给用户配置的大语言模型（LLM）分析，最后生成精确到代码行的结构化意见。模型不只看眼前几行：它还能读取完整文件、搜索代码库，并检查本次提交涉及的其他文件。若项目没有有效的 diff，ocr scan 还可以直接审查完整文件、目录或整个代码库。
它的关键不是简单地“让模型多想一会儿”，而是把任务拆成两类。确定性工程规则负责不能出错的流程：准确选择文件、过滤无关内容、把相关文件组成一组，并为不同文件匹配对应的审查规则。LLM Agent 则负责需要理解语义的部分，例如判断一段改动的意图，以及决定何时查询更多上下文。
这像给审查员一张明确的检查清单和固定巡检路线。路线由程序保证，审查员不用自己猜先看哪里；遇到具体问题时，再发挥判断力。项目还会把大型改动拆成多个相互隔离的审查单元，可并行处理，避免上下文越堆越大。
为什么还要安排一次“唱反调”
模型生成一条听起来合理的意见，并不代表它真的站得住脚。据 OpenCodeReview 论文介绍，系统还设置了独立的定位与反思环节。其中负责过滤意见的模型只能看到代码差异，看不到前一阶段搜索到的材料，并以证伪为目标重新检查评论。
这种隔离很重要。如果复核者沿用生成者的全部思路，两者可能一起强化同一个错误判断。让第二个环节只凭原始改动核验，相当于要求它重新回答：“这条意见单靠代码证据能成立吗？”
少报一点，但尽量别乱报
项目方用 AACR-Bench 做了测试。这个基准包含来自 50 个热门开源仓库的 200 个真实 Pull Request——也就是准备合并进项目的一组代码改动——覆盖 10 种编程语言，共有 1,505 个标注问题，并由 80 多名资深工程师交叉验证。
在相同底层模型下，项目方称 Open Code Review 的 Precision 和 F1 显著高于 Claude Code 等通用 Agent，Token 消耗约为后者的九分之一，审查也更快。Token 是模型处理文本时使用的基本计量单位，通常直接影响调用成本。
这里要分清三个指标。Precision（精确率）看“工具报出的问题里，有多少是真的”，越高意味着工程师越少被误报打扰。Recall（召回率）看“实际存在的问题里，工具找到了多少”。F1 则综合两者。Open Code Review 的 Recall 更低，项目方明确称这是主动取舍：宁可少报一些，也希望报出来的意见更可信。论文另称，其方案可节省 5 至 15 倍 Token。
值得看的不只是又一个代码 Agent
这个项目提供了一种更务实的分工：规则负责稳定、可重复的流程，模型负责理解意图和补充上下文。它没有把所有控制权都交给自然语言提示，而是用工程约束限制模型的活动范围。对于需要进入日常工作流的 AI 工具，这种“先缩小自由，再利用智能”的思路，比单纯增加工具和提示词更值得关注。
阿里称，这套工具过去两年服务了数万名开发者，并识别出数百万个代码缺陷。不过“缺陷”也可能包含告警或候选问题，现有材料没有说明其中多少经过确认并最终修复。
局限与未知
- 性能结论来自项目方自测。材料没有给出完整结果表、所用模型、Claude Code 配置、Token 统计口径或显著性检验，不能视为独立验证。
- 更高精确率以较低召回率为代价。它适合减少噪声，却可能让更多真实问题漏过，实际取舍仍取决于团队需求。
- 项目没有披露内部规模数据的可核验明细；现有材料也未提供具体开源日期、许可证和版本号。