OpenClaw
使用场景入门10 min

用 OpenClaw 自动化 GitHub PR 代码审查

手把手教你用 OpenClaw 搭建 AI 驱动的 PR 自动审查流程:GitHub 集成、PR Reviewer 代码分析、Conventional Commits 规范化提交,提升团队代码审查效率。

最近更新: 2026-03-31

所需 Skills

GitHub (gh)
推荐

通过 gh CLI 操作 GitHub(Issue/PR/仓库等)。

查看指南
PR Reviewer
推荐

自动化的 Pull Request 代码审查。

查看指南
Conventional Commits
推荐

生成/校验 Conventional Commits 提交信息。

查看指南

你将搭建什么

一条完整的 PR 自动审查流水线:

  1. 自动创建 PR — 根据 commit 历史,AI 生成规范的 PR 描述
  2. AI 代码审查 — 自动分析代码,发现 bug、安全漏洞和风格问题
  3. 提交规范化 — 强制使用 Conventional Commits 格式
  4. 可操作的反馈 — 直接在 PR 中留下行内审查评论

搭建完成后,每次开 PR 都会自动触发 AI 审查,无需人工干预。

为什么需要 AI 辅助代码审查

人工代码审查不可或缺,但在实际执行中存在明显瓶颈:

  • 审查质量不稳定 — 不同审查者关注点不同,有人看命名规范,有人看错误处理。哪些问题能被发现,取决于"今天谁来审"
  • 审查疲劳 — 看完几百行代码后注意力明显下降。研究表明持续审查超过 60 分钟后,效率大幅降低,关键 bug 往往藏在大段 diff 的末尾
  • 等待时间长 — 审查者有自己的开发任务,一个 PR 可能等几个小时甚至几天。这会阻塞提交者,催生"攒一堆再提"的大 PR,引发合并冲突
  • 扩展性差 — 团队越大,审查瓶颈越严重。资深开发者越来越多时间花在审查上,新成员又可能不够熟悉代码库

AI 审查不是要取代人工审查,而是处理那些系统性检查(安全模式、常见 bug、风格问题),让人工审查者集中精力在架构设计、业务逻辑上。可以理解为——在人看之前,先过一遍底线质量关。

前置条件

开始之前,确保你已经:

  • OpenClaw 已安装并配置好(快速上手指南
  • GitHub CLIgh)已安装并完成认证(gh auth login
  • 一个 GitHub 仓库 用于测试(个人项目即可)
  • Node.js 18+

第 1 步:安装所需 Skills

按顺序安装三个 Skill:

bash
# 1. GitHub 集成(基础能力)
npx clawhub@latest install github

# 2. PR Reviewer(代码分析)
npx clawhub@latest install pr-reviewer

# 3. Conventional Commits(提交格式化)
npx clawhub@latest install conventional-commits

验证安装:

bash
clawhub list

三个 Skill 都应显示为 installed

第 2 步:配置 GitHub 认证

GitHub Skill 需要一个具备以下权限的 Personal Access Token:

  • repo — 完整的仓库访问权限
  • read:org — 读取组织成员信息(如果是组织仓库的话,可选)

如果你已经通过 gh auth login 完成认证,Skill 会自动使用现有凭据。否则:

bash
# 查看当前认证状态
gh auth status

# 如需登录
gh auth login

第 3 步:配置 PR Reviewer

PR Reviewer Skill 开箱即用,但你可以自定义行为:

bash
# 查看默认配置
clawhub inspect pr-reviewer

核心配置项:

  • 审查深度quick(快速扫描)或 thorough(深度分析)
  • 关注领域:安全、性能、风格、bug,或全选
  • 自动评论:是否直接在 PR 上发布评论

第 4 步:创建第一个自动审查 PR

用一个真实 PR 来测试整个工作流:

4.1 创建功能分支

bash
git checkout -b feature/test-ai-review

4.2 写一些代码

在项目中修改一个文件。为了测试效果,可以故意引入一些常见问题,看审查器能否捕获:

异步调用缺少 await(异步 bug):

javascript
// Bug:异步调用缺少 await
function getUserData(userId) {
  const response = fetch(`/api/users/${userId}`);  // 缺少 await
  return response.json();  // TypeError: response.json is not a function
}

SQL 注入漏洞:

python
# 安全问题:用户输入直接拼接到 SQL 查询中
def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = '{user_id}'"  # SQL 注入风险
    return db.execute(query)

硬编码密钥:

javascript
// 安全问题:API 密钥直接暴露在源码中
const stripe = require('stripe')('sk_live_abc123secretkey');

N+1 查询问题:

python
# 性能问题:N+1 查询——每个订单都触发一次数据库查询
def get_orders_with_items(user_id):
    orders = Order.objects.filter(user_id=user_id)
    for order in orders:
        order.items = OrderItem.objects.filter(order_id=order.id)  # N+1!
    return orders

4.3 使用 Conventional Commits 提交

不用手写提交信息,让 OpenClaw 帮你生成:

bash
git add .
# OpenClaw 自动生成符合 Conventional Commits 规范的提交信息
# 例如 "feat(api): add getUserData function for user data retrieval"

4.4 创建并审查 PR

bash
# OpenClaw 自动创建 PR 并生成 AI 描述
# PR Reviewer 随后自动分析 diff

几秒钟内,你会看到:

  • 一份格式规范的 PR 描述,自动总结了你的变更
  • 针对具体代码行的审查评论
  • 一条总结评论,包含整体评估和改进建议

审查评论示例:

🔒 安全问题 (第 14 行, auth.py):
  用户输入直接拼接到 SQL 查询字符串中,
  存在 SQL 注入攻击风险。
  建议修复:使用参数化查询。

  - query = f"SELECT * FROM users WHERE id = '{user_id}'"
  + query = "SELECT * FROM users WHERE id = %s"
  + return db.execute(query, (user_id,))

⚡ 性能问题 (第 8 行, orders.py):
  检测到 N+1 查询——OrderItem.objects.filter() 在循环内
  对每个 order 调用一次。请使用 select_related() 或
  prefetch_related() 将其合并为一次查询。

  - orders = Order.objects.filter(user_id=user_id)
  + orders = Order.objects.filter(user_id=user_id).prefetch_related('items')

🐛 Bug (第 3 行, api.js):
  fetch() 返回 Promise 但未使用 await。
  response.json() 会失败,因为 response 是一个
  pending 的 Promise,而不是 Response 对象。

  - const response = fetch(`/api/users/${userId}`);
  + const response = await fetch(`/api/users/${userId}`);

第 5 步:自定义审查工作流

安全优先审查

对安全敏感的仓库,可以让 PR Reviewer 重点检查安全问题:

  • SQL 注入模式
  • 硬编码的凭据或 API 密钥
  • 不安全的数据处理(未验证的输入、缺少过滤)
  • 依赖漏洞
  • 前端代码中的 XSS 漏洞
  • 不安全的反序列化模式

性能导向审查

对性能敏感的服务,让审查器聚焦性能模式。比如在 React 项目中,审查器可以捕获不必要的重渲染:

jsx
// 性能问题:每次渲染都创建新的对象引用,导致子组件重渲染
function ParentComponent({ items }) {
  return (
    <ChildComponent
      style={{ margin: 10 }}        // 每次渲染都是新对象
      onClick={() => doSomething()}  // 每次渲染都是新函数
    />
  );
}

团队级配置

在团队中共享审查配置:

  1. 将 Skill 配置导出到仓库中的 .openclaw/ 目录
  2. 提交到代码仓库
  3. 团队成员使用相同配置安装——Skill 会自动读取项目级配置

进阶:引导审查重点

你可以通过自然语言指令来调整 PR Reviewer 的审查方向。

按语言定制

运行审查时,告诉 Agent 重点关注什么:

  • Python:检查裸 except: 块、缺少类型注解、Django ORM N+1 查询
  • JavaScript/TypeScript:标记遗留的 console.log、异步调用缺少 await、硬编码密钥
  • Rust:标记生产代码中的 .unwrap(),建议使用正确的 Result 处理

按目录定制

对不同目录设置不同审查级别:

  • 核心业务逻辑src/core/)— 全面审查,覆盖安全、bug 和性能
  • 测试文件src/tests/)— 快速检查正确性
  • 文档docs/)— 轻量级风格审查
  • 脚本scripts/)— 聚焦安全和 bug

自定义规则

让审查器标记项目特定的反模式,比如:

  • API 路由中直接访问数据库而没有走 Repository 层
  • 页面组件缺少 Error Boundary
  • API 接口没有限流

集成到 CI/CD

要实现每个 PR 都自动审查,可以将 PR Reviewer 集成到 CI/CD 流水线中。

GitHub Actions

.github/workflows/ai-review.yml 创建工作流文件:

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

jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install OpenClaw and skills
        run: |
          npm install -g clawhub@latest
          clawhub install pr-reviewer

      - name: Run AI Review
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENCLAW_API_KEY: ${{ secrets.OPENCLAW_API_KEY }}
        run: |
          clawhub run pr-reviewer \
            --pr ${{ github.event.pull_request.number }} \
            --repo ${{ github.repository }} \
            --auto-comment

控制审查触发条件

限定 AI 审查只在特定条件下运行,节省成本:

yaml
on:
  pull_request:
    types: [opened, synchronize]
    paths-ignore:
      - '*.md'
      - 'docs/**'
      - '.github/**'

或者要求添加标签后才触发审查:

yaml
- name: Check for review label
  if: contains(github.event.pull_request.labels.*.name, 'ai-review')
  run: clawhub run pr-reviewer --pr ${{ github.event.pull_request.number }}

其他 CI 平台

同样的方式适用于任何支持 Node.js 的 CI 平台。核心步骤:

  1. 安装 clawhubpr-reviewer Skill
  2. OPENCLAW_API_KEY 设为环境变量
  3. 传入 PR 编号和仓库信息
  4. 确保 CI Bot 对 Pull Request 有写权限

实际效果

使用这套工作流的团队通常会看到:

  • PR 处理速度提升 40% — AI 先处理明显问题,减少人工审查压力
  • 审查质量稳定 — 每个 PR 都经过相同标准的分析
  • 提交历史更规范 — Conventional Commits 让变更日志自动化
  • 生产环境 bug 更少 — AI 能捕获人工容易忽略的问题

常见问题排查

"GitHub CLI not found"

确保 gh 已安装并在 PATH 中:

bash
# macOS
brew install gh

# Linux
sudo apt install gh

# Windows
winget install GitHub.cli

PR 创建时提示"Permission denied"

检查 Token 权限:

bash
gh auth status

确认包含 repo 权限。如有需要,重新认证:

bash
gh auth login --scopes repo

PR Reviewer 没有评论

检查 Skill 安装和配置:

bash
clawhub inspect pr-reviewer

确认你的 OpenClaw AI 提供者已配置且有可用额度。

常见问题

支持。GitHub Skill 基于 `gh` CLI,完全兼容 GitHub Enterprise Server 和 GitHub Enterprise Cloud。只需通过 `gh auth login --hostname github.yourcompany.com` 配置企业域名。认证完成后,所有 GitHub 相关的 Skill(包括 PR Reviewer)的使用方式与 github.com 完全一致,无需额外配置。

GitHub Skill 是 GitHub 专用的,但 PR Reviewer 和 Conventional Commits 可以配合任何 Git 平台使用。GitLab 用户可以安装 GitLab Skill,传入 Merge Request ID 替代 PR 编号。Bitbucket 同理。核心审查逻辑与平台无关,只有发布评论的集成层因平台而异。

AI 审查是人工审查的补充,而非替代。它擅长系统性检查——捕获安全漏洞、常见 bug 模式、风格违规和性能反模式,而且不会疲劳、不会遗漏。但它无法评估高层架构决策、业务逻辑正确性,或判断整体方案是否合理。最佳实践是让 AI 做第一轮扫描,处理机械性检查,让人工审查者专注于设计和意图。

成本取决于你使用的 AI 提供者和被审查的 diff 大小。一个典型的 PR 审查(分析约 500 行 diff)在大多数提供者上的费用约 $0.01-0.05。更大的 diff(1000+ 行)可能在 $0.10-0.15 左右。你可以通过对非关键路径设置 `quick` 审查深度,以及用路径过滤器跳过自动生成的文件、vendor 目录和文档来控制成本。

可以。PR Reviewer 支持灵活的文件模式配置。你可以按 glob 模式排除文件(如 `**/*.generated.ts`、`vendor/**`),限制只审查特定目录,或对不同路径设置不同审查深度。在 `.openclaw/pr-reviewer.yml` 中配置即可。大多数团队会排除自动生成的文件、lock 文件和 vendor 依赖,让审查聚焦在团队实际编写的代码上。

PR Reviewer 会将大 diff 拆分成逻辑块分别分析。对于超过 1000 行的 PR,会优先审查高风险文件——涉及认证、数据库查询、API 接口和安全敏感逻辑的文件会以最大深度审查,测试和配置变更则用轻量级审查。你也可以配置一个行数阈值,超过时自动提醒作者将 PR 拆分成更小的可审查单元。

支持所有主流编程语言,包括 JavaScript、TypeScript、Python、Go、Rust、Java、C#、Ruby、PHP 等。审查器自动应用语言特定的规则——比如在 Rust 中检查 `unwrap()` 误用,在 JavaScript 异步代码中检查缺少的 `await`。你也可以在配置文件中为每种语言定义自定义规则。审查器根据文件扩展名检测语言,无需手动设置。

AI 审查和 Linter 解决的问题互补,可以很好地配合。Linter 强制执行确定性规则(格式、import 顺序、未使用的变量),AI 审查捕获语义层面的问题(逻辑 bug、安全模式、性能问题),这些是规则工具无法检测的。在 CI 中,先跑 Linter 处理格式问题,再跑 AI 审查做深度分析。PR Reviewer 知道常见的 Linter 规则,会避免重复反馈相同问题。

OpenClaw 会跟踪仓库随时间的审查指标。运行 `clawhub stats pr-reviewer` 可以查看按类别分类的问题统计、合并前解决了多少、以及代码库中的常见模式。这有助于识别反复出现的问题——比如 SQL 注入警告频繁出现,说明需要加强团队培训或改进 ORM 抽象。你可以将指标导出为 JSON 格式,集成到看板或团队报告工具中。

可以。你可以定义审查模板,根据 PR 标签、分支命名规范或变更文件路径应用不同规则。例如,`hotfix/*` 分支使用安全优先的最大深度审查,`docs/*` 分支仅做轻量风格检查。在 `.openclaw/pr-reviewer.yml` 的 `templates` 字段中定义模板,PR Reviewer 会根据条件自动匹配。这样关键变更能得到充分审查,低风险更新不会被拖慢。

相关场景