用 OpenClaw 自动化 GitHub PR 代码审查
手把手教你用 OpenClaw 搭建 AI 驱动的 PR 自动审查流程:GitHub 集成、PR Reviewer 代码分析、Conventional Commits 规范化提交,提升团队代码审查效率。
最近更新: 2026-03-31
所需 Skills
你将搭建什么
一条完整的 PR 自动审查流水线:
- 自动创建 PR — 根据 commit 历史,AI 生成规范的 PR 描述
- AI 代码审查 — 自动分析代码,发现 bug、安全漏洞和风格问题
- 提交规范化 — 强制使用 Conventional Commits 格式
- 可操作的反馈 — 直接在 PR 中留下行内审查评论
搭建完成后,每次开 PR 都会自动触发 AI 审查,无需人工干预。
为什么需要 AI 辅助代码审查
人工代码审查不可或缺,但在实际执行中存在明显瓶颈:
- 审查质量不稳定 — 不同审查者关注点不同,有人看命名规范,有人看错误处理。哪些问题能被发现,取决于"今天谁来审"
- 审查疲劳 — 看完几百行代码后注意力明显下降。研究表明持续审查超过 60 分钟后,效率大幅降低,关键 bug 往往藏在大段 diff 的末尾
- 等待时间长 — 审查者有自己的开发任务,一个 PR 可能等几个小时甚至几天。这会阻塞提交者,催生"攒一堆再提"的大 PR,引发合并冲突
- 扩展性差 — 团队越大,审查瓶颈越严重。资深开发者越来越多时间花在审查上,新成员又可能不够熟悉代码库
AI 审查不是要取代人工审查,而是处理那些系统性检查(安全模式、常见 bug、风格问题),让人工审查者集中精力在架构设计、业务逻辑上。可以理解为——在人看之前,先过一遍底线质量关。
前置条件
开始之前,确保你已经:
- OpenClaw 已安装并配置好(快速上手指南)
- GitHub CLI(
gh)已安装并完成认证(gh auth login) - 一个 GitHub 仓库 用于测试(个人项目即可)
- Node.js 18+
第 1 步:安装所需 Skills
按顺序安装三个 Skill:
# 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
验证安装:
clawhub list
三个 Skill 都应显示为 installed。
第 2 步:配置 GitHub 认证
GitHub Skill 需要一个具备以下权限的 Personal Access Token:
repo— 完整的仓库访问权限read:org— 读取组织成员信息(如果是组织仓库的话,可选)
如果你已经通过 gh auth login 完成认证,Skill 会自动使用现有凭据。否则:
# 查看当前认证状态 gh auth status # 如需登录 gh auth login
第 3 步:配置 PR Reviewer
PR Reviewer Skill 开箱即用,但你可以自定义行为:
# 查看默认配置 clawhub inspect pr-reviewer
核心配置项:
- 审查深度:
quick(快速扫描)或thorough(深度分析) - 关注领域:安全、性能、风格、bug,或全选
- 自动评论:是否直接在 PR 上发布评论
第 4 步:创建第一个自动审查 PR
用一个真实 PR 来测试整个工作流:
4.1 创建功能分支
git checkout -b feature/test-ai-review
4.2 写一些代码
在项目中修改一个文件。为了测试效果,可以故意引入一些常见问题,看审查器能否捕获:
异步调用缺少 await(异步 bug):
// Bug:异步调用缺少 await
function getUserData(userId) {
const response = fetch(`/api/users/${userId}`); // 缺少 await
return response.json(); // TypeError: response.json is not a function
}
SQL 注入漏洞:
# 安全问题:用户输入直接拼接到 SQL 查询中
def get_user(user_id):
query = f"SELECT * FROM users WHERE id = '{user_id}'" # SQL 注入风险
return db.execute(query)
硬编码密钥:
// 安全问题:API 密钥直接暴露在源码中
const stripe = require('stripe')('sk_live_abc123secretkey');
N+1 查询问题:
# 性能问题: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 帮你生成:
git add . # OpenClaw 自动生成符合 Conventional Commits 规范的提交信息 # 例如 "feat(api): add getUserData function for user data retrieval"
4.4 创建并审查 PR
# 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 项目中,审查器可以捕获不必要的重渲染:
// 性能问题:每次渲染都创建新的对象引用,导致子组件重渲染
function ParentComponent({ items }) {
return (
<ChildComponent
style={{ margin: 10 }} // 每次渲染都是新对象
onClick={() => doSomething()} // 每次渲染都是新函数
/>
);
}
团队级配置
在团队中共享审查配置:
- 将 Skill 配置导出到仓库中的
.openclaw/目录 - 提交到代码仓库
- 团队成员使用相同配置安装——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 创建工作流文件:
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 审查只在特定条件下运行,节省成本:
on:
pull_request:
types: [opened, synchronize]
paths-ignore:
- '*.md'
- 'docs/**'
- '.github/**'
或者要求添加标签后才触发审查:
- 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 平台。核心步骤:
- 安装
clawhub和pr-reviewerSkill - 将
OPENCLAW_API_KEY设为环境变量 - 传入 PR 编号和仓库信息
- 确保 CI Bot 对 Pull Request 有写权限
实际效果
使用这套工作流的团队通常会看到:
- PR 处理速度提升 40% — AI 先处理明显问题,减少人工审查压力
- 审查质量稳定 — 每个 PR 都经过相同标准的分析
- 提交历史更规范 — Conventional Commits 让变更日志自动化
- 生产环境 bug 更少 — AI 能捕获人工容易忽略的问题
常见问题排查
"GitHub CLI not found"
确保 gh 已安装并在 PATH 中:
# macOS brew install gh # Linux sudo apt install gh # Windows winget install GitHub.cli
PR 创建时提示"Permission denied"
检查 Token 权限:
gh auth status
确认包含 repo 权限。如有需要,重新认证:
gh auth login --scopes repo
PR Reviewer 没有评论
检查 Skill 安装和配置:
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 会根据条件自动匹配。这样关键变更能得到充分审查,低风险更新不会被拖慢。