文章总结： 本文介绍阿里开源OpenCodeReview工具，其核心理念是让程序控制流程、模型做决策、人保留最终话语权。该工具通过筛选文件、按特点选择评审规则、子代理并行处理等方式提升AI代码审查精确率，但承认召回率较低。建议将其置于人工审核前做初步筛选，而非作为最终决定者。
综合评分： 82
文章分类： 安全工具,AI安全,安全开发,代码审计,解决方案
你的代码敢不敢让它审一遍？
原创
大菜
大菜
架构师修行之路
2026年9月20日 18:00
北京
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
人工智能写代码的速度越来越快，但是审代码并不一定就容易了。
一份看上去比较正规的风险提示，有可能是误报，需要查阅文件和调用关系来判断是否合理，提示越多并不一定就越容易。
阿里开源的OpenCodeReview就是想解决这个问题的——用人工智能来做代码审查，但是又不能让模型完全独立地去完成所有的审查工作。
它是采用Apache-2.0许可协议的一个命令行工具，命令名为“ocr”。
经过对Git差异进行分析之后，代理可以继续读取整个文件，并在代码库里查找相关信息，还可以查看其他被修改过的文件，最后给出带有具体位置信息的结构化的评估结果。
此外还存在一个叫做“ocr scan”的命令用来做整体性的检查，并非仅仅针对变动的部分进行审核。
把流程控制好之后再用模型去判断
把一份大的PR交给通用Agent，并且嘱咐它要认真查看、不能有丝毫疏漏，并不代表它已经看过所有的需要查看的内容。
OpenCodeReview 的做法是先把可以使用程序来确定的内容固定住。
首先筛选出文件，并把相关的文件打包成一个评审单元，比如中文和英文的资源文件可以放在一个单元里，让模型来比较它们。各个单元用上下文隔离开来的子代理来处理，并且支持并行。
根据文件的特点来选择相应的评审规则，即对SQL映射文件以及前端代码分别进行检查，并不需要带着一个庞大的检查列表。
模型会按需检索上下文，并对存在的问题做出判断；另外还有一个独立的定位和反思模块去改善评论的位置和内容的准确度。
我认为这样的分工要比“再写一段更有用的提示语”有趣得多。评判的标准不仅仅要看模型是否聪明，还要看它拿到了哪些文件、受到什么样的限制以及产生的结果是否经过二次审核。
但是工程限制并不等于全覆盖。官方的规定说明了过滤的方法：二进制文件、敏感路径、部分测试文件、不支持的文件扩展名等等可能会被忽略掉，过大差异也会被忽略掉。
接入之后可以先用 ocr review --preview 命令查看一下具体的审核范围，
特别是不能把规则中提到的 include 理解为白名单：它主要是为了避开一些默认被忽略的内容，并不表示只会对符合条件的文件进行检查，也不会替代敏感路径保护。
少报一些，为什么还会很有价值呢？
项目的 Readme 显示出内部使用的数量、npm 的下载量以及成本比较等信息，这些都是项目方公开的信息，并非本文所进行的实际测试；下载次数不能算作用户数量。
除了上面提到的数据之外，官方对于基准测试所作的说明也很重要：在同一底层模型下，相对于通用Agent而言，在精确率、F1值上有所提高的同时，也承认了召回率较低的情况。
精确率关注的是“报告出来的错误中真实的占多少比例”，而召回率则是要找出所有的实际存在的问题中有多少被发现了。两者并不相同。
官方AACR-Bench基准包含了50个开源仓库、200个真实PR、10种编程语言和1505个标注问题。排行榜是由项目方来评价的，并不能由此推断出该基准在你自己的业务代码中也会有同样的表现。
对于被误报淹没的团队来说，这样的选择似乎很吸引人，但是支付、权限、数据迁移等重要的更改不能因为“AI没有报告问题”而直接通过。少一些报警既可以是由于噪音少，也可以是没有发现故障。
所以我认为最好把它放在人工审核前面做一次初步筛选来确定需要验证的问题，而不能把其作为最终决定者。
拿一个熟悉的地方来试试看
官方规定 Git 的版本号不能小于 2.41，在电脑上已经安装了 npm 的情况下按照 Readme 进行安装即可：
npm install -g @alibaba-group/open-code-review
接着选择模型服务提供商以及模型：
ocr config provider
ocr config model
交互式界面会引导用户去选择服务提供商、输入API密钥以及选择模型，并进行一次网络连通性的检测。该工具可以使用内置的服务提供者或者自定义的端点，并不强制要求只能使用一个特定的模型。
进入到自己项目的文件夹之后，在命令行里输入以下命令：
ocr review
默认情况下会检查工作区里已经暂存和未暂存的状态以及没有被追踪到的更改，但是实际要包含哪些文件仍然受到过滤规则的影响。
想要进行比较的话，可以用官方提供的示例，并且把分支的名字改成自己想要的名字：
ocr review --from main --to feature-branch
这里所要比较的是目标分支从共同祖先分出后所发生的变化，并非是把两个分支的所有文件都进行对比。
可以继续往下走，并且可以把结果以json的形式保存下来：
ocr review --format json --output result.json
第一次可以挑选自己比较熟悉的项目，逐一核对结果，看看真正的问题是什么，误报要花费多长时间才能解决掉，这比看排名更能反映用户的真实感受。
有编码的Agent，不一定再配一套模型
还有一种比较实用的委托方式。
在该模式下，OpenCodeReview 负责文件的选择以及规则的解析工作，真正的审核则由宿主Agent的模型来完成。
OCR 方面不需要调用 LLM，也无需在OCR端额外配置模型API Key，依然按照原来的额度和使用规则进行操作，并不是免费审核。
跟让Agent调用ocr review不一样的是：后者的OCR仍旧会使用它所配置好的模型来完成审核工作。所以在选择接入方式的时候首先要明确是谁做推断，又是谁用了资源。
另外一个容易被忽视的地方是：开源CLI在本地运行，并不意味着相关的代码就不会离开电脑了。默认情况下，评审会把相关的代码发送到配置好的模型端点上。在公司项目接入之前，要先确定好端点、数据政策以及内部权限的要求。
最值得学习的地方应该是它所体现出来的克制精神——即让程序去控制流程、让模型来做决策、而人则拥有最后的话语权。
代码写得快了，但是信任不能用一键生成的方法来获得。
https://github.com/alibaba/open-code-review
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：架构师修行之路 大菜
大菜《你的代码敢不敢让它审一遍？》