Open Code Review 实战：AI 写的代码怎么审查？从 Git 改动到一条可验证意见

AI 帮你写好了“关闭工单”接口：点一下按钮，状态变了，页面也没报错。

但换一个账号还能不能关？已经关闭的工单再提交一次，会发生什么？这些问题，往往要到代码准备合并时才被想起来。

阿里开源的 Open Code Review，就是这一步可以尝试的工具：读取 Git 改动，让配置好的模型结合上下文提出审查意见。对准备项目作品的开发者来说，我们可以把它用在一个很小的目标上：完成一次有记录、有验证的代码审查。

本文按已核对的仓库固定提交资料整理，未做本机效果与费用实测。

先看它能替你组织哪些工作

Open Code Review 是命令行工具。输入 Git 改动，输出带文件位置与行号的结构化审查意见；需要理解关联逻辑时，Agent 可以读取文件、搜索代码，而不只盯着眼前几行 diff。

它值得研究的设计，是把审查拆成两类工作：程序组织审查范围与规则，模型理解代码语义。 例如，中英文资源文件存在对应关系，README 用它们说明为什么有关联的文件需要放在一起看。

依据官方 README 原创绘制的简化分工图。

程序约束流程，不代表语义缺陷一定会被发现。

按使用场景，可以先区分三个入口：

你现在要做什么	对应入口
提交前检查本地改动	ocr review
检查指定提交	ocr review --commit 提交ID
接手项目，查看整个目录	ocr scan --path 目录路径

前两种围绕变更，第三种检查完整文件。初次尝试选一项小改动即可，报告更容易逐条核对；后续还可以通过项目的 Session Viewer 查看审查会话，或研究怎样接入 CI。

先准备一次“关闭工单”的改动

在运行前，把业务约定写下来：只有有权限的账号可以关闭工单；已经关闭的记录再次提交时，系统应怎样响应，也要有明确约定。

这里没有替你规定唯一正确的接口行为。关键是先有预期，再判断建议；否则模型说“应该允许”，你就改成允许，它说“应该拒绝”，你又改回去。

官方 README 要求 Git 2.41 或更新版本。使用 npm 安装，还需要准备 Node.js 与 npm 环境。先安装并配置模型服务：

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

官方仓库完整原图，展示服务选择菜单，并非本文运行截图；选项以安装版本为准。

如果你正在寻找模型 API 中转服务，可以了解 routefast.ai，具体模型与接入方式另行核对。

然后进入练习仓库，先检查改动范围，再运行一次审查并保存报告：

git status --short
ocr review --format json --output result.json

工作区模式会检查暂存、未暂存和未跟踪的改动。先整理无关文件；模型也可能读取理解问题所需的上下文，练习仓库中不要混入密钥或不宜发送的业务数据。

这条命令会发起审查并写出结果文件。后续直接围绕这一轮报告核对即可。这里使用独立 CLI 的模型配置路线；仓库另有使用宿主编程代理模型的委托模式，接入方式要分开看。

拿到意见，先验证一条

假设报告提出：“重复关闭可能导致重复写入处理记录。”下一步不是马上修改，而是构造两次相同请求，观察工单状态与处理记录。

这是本文设计的练习情境，不是声称工具已经找到了这个漏洞。如果代码已有去重处理，就把对应实现指出来；如果问题成立，再修改并用相同请求复测。

原创记录模板，所有结果留待实际运行后填写。

这条意见的状态	下一步留下什么
能复现	触发条件、修复与复测结果
不适用	业务约定或已有处理代码
暂时不能确认	缺少的上下文与待查问题

报告为空，不代表没有缺陷；报告很长，也不代表每条都成立。真正能体现能力的，是你如何区分这些情况。

最后，把这次审查放进项目说明

这一轮保留四样东西就够了：代码改动、原始报告、逐条判断，以及验证记录。

讲项目时，你就可以沿着“这次改了什么—检查到什么—为什么采纳或拒绝—怎样确认结果”展开。比起只说“项目接入了 AI”，这条过程更具体，也更容易被追问和复查。

如果还不熟悉分支、合并请求与代码审核，可以到 云栈社区 补 Git 与 GitLab 企业实战基础。

仓库采用 Apache-2.0 许可，模型服务另有使用条件。先把一条审查意见验证清楚，再逐步扩大使用范围。

项目与学习入口

• 开源地址：github.com/alibaba/open-code-review