用最小 JavaScript Demo 跑通 Alibaba Open Code Review 的完整流程

0 阅读

安装与配置基础环境

要跑通 Alibaba 的 Open Code Review(简称 OCR),第一步是安装 CLI 工具。通过 npm 全局安装即可:

文章配图

npm install -g @alibaba-group/open-code-review

安装完成后运行 ocr version 验证是否成功。接着需要配置大模型访问凭证,这是 OCR 执行代码分析的核心依赖。

使用 ocr config providerocr 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。这段新增代码故意保留了多个问题:

  1. SQL 字符串拼接,存在注入风险
  2. 未做权限校验
  3. db.query 未 await,可能未等待操作完成
  4. 无错误处理
  5. 无论删除是否成功都返回 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:生成最终审查意见

审查结果共两条:

  1. SQL 注入风险:指出 userId 直接拼接进 SQL 字符串,建议改用参数化查询
  2. 返回值失真:函数始终返回 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 函数生成了三条评论:

  1. SQL 注入风险(同前)
  2. 缺少异步错误处理:指出未 await db.query 且无 try-catch,建议改为 async 函数并处理异常
  3. 缺少权限校验:强调删除操作需验证调用者权限,建议增加 authUser 参数并检查 canDelete 权限

第三条评论明显受自定义规则中“权限校验缺失和删除类危险操作”的引导。这证明规则配置能有效调整 AI 的审查焦点,使其更贴合业务需求。

工具调用链路解析

OCR 的审查并非简单将 diff 丢给大模型,而是通过 Agent 式的多步工具调用完成:

  1. file_read_diff:读取 Git diff,确定变更范围
  2. file_read:加载文件全文,提供上下文
  3. file_find:查找同名或关联文件(如 test 文件)
  4. code_search:搜索关键词(如 db.queryDELETE FROM users),探索项目级模式
  5. code_comment:综合所有信息生成带行号的结构化评论

这种设计让 AI 能像人类开发者一样“主动探索”代码库,而非仅依赖输入片段。例如,通过 code_search 发现项目其他地方使用参数化查询,可强化对当前拼接 SQL 的批评力度。

总结与后续方向

通过这个最小 Demo,验证了 OCR 的核心能力:

  • 精准识别常见缺陷:如 SQL 注入、硬编码、异常处理缺失
  • 规则驱动审查重点:自定义规则可引导 AI 关注业务关键风险
  • 工程化友好:JSON 输出和工具链支持 CI/CD 集成

但需注意,AI 审查仍依赖上下文完整性。在缺乏权限系统或数据库封装的 Demo 中,某些问题(如权限校验)可能被忽略。因此,OCR 更适合作为人工审查的辅助工具,用于捕获低级错误和安全漏洞,而非完全替代人类判断。

下一步可深入源码,分析 ocr review 命令的实现逻辑,理解其如何协调 Git、规则引擎和 LLM 工具链完成审查任务。