用最小 JavaScript Demo 跑通 Alibaba Open Code Review 的完整流程
安装与配置基础环境
要跑通 Alibaba 的 Open Code Review(简称 OCR),第一步是安装 CLI 工具。通过 npm 全局安装即可:

npm install -g @alibaba-group/open-code-review安装完成后运行 ocr version 验证是否成功。接着需要配置大模型访问凭证,这是 OCR 执行代码分析的核心依赖。
使用 ocr config provider 和 ocr config model 分别设置 LLM 提供商(如阿里云百炼、OpenRouter 等)和具体模型(如 Qwen-Max)。配置完毕后,执行 ocr llm test 测试连接是否正常。只有这一步通过,后续的代码审查才能真正调用大模型进行推理。
创建最小可运行的 JavaScript Demo
为了验证 OCR 的能力,我们手动创建一个极简项目。初始化 Git 仓库后,在 src/user.js 中写入一段包含多个典型问题的代码:
getUserName未检查 user 是否为空login函数硬编码密码 "123456"buildUserQuery使用字符串拼接 SQL,存在注入风险fetchUser缺少异常处理且直接访问response.data.name
提交这个初始版本作为基线。此时 Git 仓库干净,后续的变更将被 OCR 视为待审查的 diff。
制造一次待审查的代码变更
在不提交新 commit 的前提下,向 user.js 新增一个 deleteUser 函数:
function deleteUser(db, userId) {
db.query("DELETE FROM users WHERE id = " + userId);
return true;
}同时将其加入 module.exports。这段新增代码故意保留了多个问题:
- SQL 字符串拼接,存在注入风险
- 未做权限校验
db.query未 await,可能未等待操作完成- 无错误处理
- 无论删除是否成功都返回
true
执行 git diff 可看到实际变更内容:新增函数体 + 修改导出列表。OCR 将基于这个未提交的 diff 进行审查。
预览审查范围
正式审查前,先用 ocr review --preview 查看 OCR 识别到的变更文件:
Preview: 1 file(s) changed | +7 -1
Will review (1):
[M] src/user.js +7 -1输出表明 OCR 正确识别了 src/user.js 的 7 行新增和 1 行删除(因导出项末尾加逗号导致的行替换)。这一步能避免误审无关文件(如 node_modules 或构建产物),节省 token 并提高准确性。
执行首次代码审查
运行 ocr review 后,终端日志显示 OCR 跳过了 plan phase(因变更小于 50 行阈值),直接进入工具调用阶段。整个过程调用了多个内置工具:
file_read:读取user.js全文及指定行范围,获取上下文file_find:根据文件名查找相关文件code_search:搜索db.query相关代码,判断项目中是否有统一数据库封装code_comment:生成最终审查意见
审查结果共两条:
- SQL 注入风险:指出
userId直接拼接进 SQL 字符串,建议改用参数化查询 - 返回值失真:函数始终返回
true,掩盖了数据库操作的真实结果
这两条反馈准确命中了代码中的关键缺陷,尤其是 SQL 注入属于高危安全问题。但 OCR 未提及“缺少权限校验”,可能因 Demo 缺乏用户身份或权限系统上下文。
保存结构化审查结果
通过 ocr review --format json > ocr-review-result.json 可将结果导出为 JSON。该格式包含三部分核心信息:
- summary:审查文件数、评论数、token 消耗、耗时等统计
- tool_calls:各类工具的调用次数(如 file_read 3 次、code_search 2 次)
- comments:每条评论的文件路径、行号范围及具体内容
JSON 输出便于后续工程化集成,例如在 CI/CD 中自动解析严重问题、生成 PR 评论或纳入质量报告。
配置自定义审查规则
默认规则偏通用,而项目往往有特定关注点。在 .opencodereview/rule.json 中添加自定义规则:
{
"rules": [
{
"path": "**/*.js",
"rule": "重点检查 SQL 注入、硬编码密钥、空值异常、异步错误处理、权限校验缺失和删除类危险操作。",
"merge_system_rule": true
}
],
"exclude": ["**/node_modules/**", "**/dist/**"]
}使用 ocr rules check src/user.js 验证规则命中情况,确认自定义规则已生效且与系统规则合并。
自定义规则生效后的审查效果
重新执行 ocr review(此时工作区包含 rule.json 和之前的 JSON 结果文件,故审查 3 个文件),针对 deleteUser 函数生成了三条评论:
- SQL 注入风险(同前)
- 缺少异步错误处理:指出未 await
db.query且无 try-catch,建议改为 async 函数并处理异常 - 缺少权限校验:强调删除操作需验证调用者权限,建议增加
authUser参数并检查canDelete权限
第三条评论明显受自定义规则中“权限校验缺失和删除类危险操作”的引导。这证明规则配置能有效调整 AI 的审查焦点,使其更贴合业务需求。
工具调用链路解析
OCR 的审查并非简单将 diff 丢给大模型,而是通过 Agent 式的多步工具调用完成:
- file_read_diff:读取 Git diff,确定变更范围
- file_read:加载文件全文,提供上下文
- file_find:查找同名或关联文件(如 test 文件)
- code_search:搜索关键词(如
db.query或DELETE FROM users),探索项目级模式 - code_comment:综合所有信息生成带行号的结构化评论
这种设计让 AI 能像人类开发者一样“主动探索”代码库,而非仅依赖输入片段。例如,通过 code_search 发现项目其他地方使用参数化查询,可强化对当前拼接 SQL 的批评力度。
总结与后续方向
通过这个最小 Demo,验证了 OCR 的核心能力:
- 精准识别常见缺陷:如 SQL 注入、硬编码、异常处理缺失
- 规则驱动审查重点:自定义规则可引导 AI 关注业务关键风险
- 工程化友好:JSON 输出和工具链支持 CI/CD 集成
但需注意,AI 审查仍依赖上下文完整性。在缺乏权限系统或数据库封装的 Demo 中,某些问题(如权限校验)可能被忽略。因此,OCR 更适合作为人工审查的辅助工具,用于捕获低级错误和安全漏洞,而非完全替代人类判断。
下一步可深入源码,分析 ocr review 命令的实现逻辑,理解其如何协调 Git、规则引擎和 LLM 工具链完成审查任务。