Open Code Review落地实战：5步给你的GitHub仓库配上AI代码审查

为什么要用AI做代码审查？

人工Code Review是软件开发中最耗时但最重要的环节之一。一个大PR可能涉及几十个文件的改动，评审者需要在上下文切换中逐行检查——既累又容易漏。

阿里开源的Open Code Review就是来解决这个问题的。它不会替代人工审查，但能在人工审查之前自动发现80%的低级错误和潜在bug，让评审者把精力集中在架构和业务逻辑上。

Step 1：安装

# 下载最新release
wget https://github.com/alibaba/open-code-review/releases/latest/download/ocr-linux-amd64.tar.gz
tar -xzf ocr-linux-amd64.tar.gz
sudo mv ocr /usr/local/bin/

# 验证安装
ocr --version

Step 2：配置LLM后端

Open Code Review支持多种AI后端。推荐使用OpenAI兼容API（成本最低）：

# 创建配置文件
mkdir -p ~/.ocr
cat > ~/.ocr/config.yaml << 'EOF'
llm:
  provider: openai
  api_key: "${OPENAI_API_KEY}"
  model: gpt-4o-mini
  endpoint: https://api.openai.com/v1

rules:
  security: true      # SQL注入、XSS等安全检查
  performance: true   # N+1查询、不必要循环
  style: true         # 命名规范、代码风格
  logic: true         # 空指针、边界条件
EOF

你也可以用本地模型来降低API成本：将provider改为`ollama`，model改为`qwen2.5-coder:7b`，Open Code Review会自动走本地推理。

Step 3：配置GitHub Actions

在你的仓库根目录创建 `.github/workflows/code-review.yml`：

name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Install OCR
        run: |
          wget -q https://github.com/alibaba/open-code-review/releases/latest/download/ocr-linux-amd64.tar.gz
          tar -xzf ocr-linux-amd64.tar.gz
          sudo mv ocr /usr/local/bin/

      - name: Run AI Review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          ocr review \
            --repo ${{ github.repository }} \
            --pr ${{ github.event.pull_request.number }} \
            --format github-comment

提交这个文件后，每次有人提交PR，Open Code Review就会自动运行。

Step 4：解读审查结果

AI审查完成后，你会在PR页面看到类似这样的评论：

🤖 AI Code Review | ocr

📁 src/api/user_handler.go:45
⚠️ 潜在的空指针引用
在调用 `user.Profile.Name` 之前，未检查 `user.Profile` 是否为 nil。
建议添加 nil 检查：
  if user.Profile != nil {
      name = user.Profile.Name
  }

📁 src/api/user_handler.go:78
💡 性能优化建议
该循环内的数据库查询可以批量处理。当前 N+1 查询模式：
  for _, id := range ids {
      db.Find(&user, id)  # 每次循环都查询一次
  }
建议改用：
  db.Where("id IN ?", ids).Find(&users)

每条建议都精确到代码行，带具体修复方案，评审者可以直接点击”Add suggestion to batch”一键采纳。

Step 5：自定义审查规则

如果你的团队有自己的编码规范，Open Code Review支持自定义规则：

# 创建自定义规则文件
cat > ~/.ocr/rules/custom.yaml << 'EOF'
rules:
  - id: no-console-log
    pattern: "console\\.log\\("
    message: "生产代码中不要使用 console.log，请使用结构化日志"
    severity: warning
    languages: [javascript, typescript]
  
  - id: require-error-handling
    pattern: "await\\s+\\w+\\("
    context: "try"
    message: "异步调用必须包裹在 try-catch 中"
    severity: error
    languages: [javascript, typescript]
EOF

# 使用时指定规则文件
ocr review --rules-dir ~/.ocr/rules/

生产环境最佳实践

在实际落地中，有几个经验值得分享：

1. 不要完全替代人工审查： AI会误报，也会漏报。把它看作”自动化第一轮筛查”，最终合并决定权始终在人类手上

2. 从小范围开始： 先在1-2个非核心仓库试用一周，团队熟悉了AI的”风格”后再推广

3. 定期回顾误报率： 如果某个规则频繁误报，直接关掉比”忍受噪音”更好——审查者的信任才是最重要的资产

4. 结合传统Linter： AI审查和ESLint/Pylint并不冲突——Open Code Review的确定性管道本身就集成了传统检查

**核心思路：** Open Code Review的”混合架构”是关键——确定性管道（规则检查）不花API费用，只有真正需要语义理解的复杂场景才调用LLM。阿里内部的实测数据显示，这种架构将每PR的AI审查成本控制在$0.05以内。

进阶玩法：自定义AI审查策略

当你的团队对AI审查越来越依赖时，可以根据项目类型制定不同的审查策略。这里分享一个针对”安全敏感项目”的增强配置：

# security-enhanced.yaml
provider: openai
model: gpt-4o  # 安全项目用更强的模型

rules:
  security: strict     # 严格模式：所有SQL查询必须参数化
  performance: true
  style: false         # 安全项目不纠结风格
  logic: true

security_policy:
  sql_injection: error       # SQL注入直接阻断
  hardcoded_secret: error    # 硬编码密钥直接阻断
  xss: warn
  path_traversal: error

然后在你的CI/CD流程中根据分支选择不同的审查策略：

# 主分支合并 → 严格审查
if [ "$GITHUB_BASE_REF" = "main" ]; then
    ocr review --config security-enhanced.yaml
else
    ocr review  # 默认配置
fi

**核心思路：** 不是所有代码都需要同等级别的审查。将审查策略与开发流程深度绑定——热修复走快速通道、主分支走全量审查、实验性分支可以只做安全检查——才能让AI审查真正融入工作流而不是成为负担。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn