用 OpenClaw 搭建自动化代码审查工作流

69次阅读

用 OpenClaw 搭建自动化代码审查工作流

还在手动检查 PR、写审查意见？OpenClaw 的 GitHub 技能让你自动监控代码变更、生成审查报告、甚至派 AI 代理直接修复问题。本文带你搭建一套无人值守的代码审查流水线。

01 为什么需要自动化代码审查？

传统代码审查的痛点：

OpenClaw 的解决方案：

  • 🤖 自动监控 — 实时跟踪 PR 状态、CI 结果

  • 📝 智能审查 — AI 分析代码变更，生成审查意见

  • 🔧 自动修复 — 对简单问题直接派代理修复

  • 📊 审查报告 — 汇总统计，可视化代码质量

02 环境准备

安装 GitHub CLI

# macOS
brew install gh

# Linux
sudo apt install gh

# 验证安装
gh --version

登录 GitHub

# 交互式登录
gh auth login

# 验证状态
gh auth status

配置 OpenClaw

在 ~/.openclaw/openclaw.json 中添加 GitHub Token：

{
  "skills": {
    "entries": {
      "gh-issues": {"apiKey": "ghp_xxxxxxxxxxxx"}
    }
  }
}

💡 获取 Token： GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)

03 基础操作：查询 PR 和 Issue

查看 PR 列表 

# 列出 openclaw 仓库的所有 PR
gh pr list --repo openclaw/openclaw

# 过滤状态
gh pr list --repo openclaw/openclaw --state open

# JSON 输出（方便脚本处理）gh pr list --repo openclaw/openclaw --json number,title,author,state

查看 PR 详情 

# 查看特定 PR
gh pr view 123 --repo openclaw/openclaw

# 查看 CI 检查结果
gh pr checks 123 --repo openclaw/openclaw

查看 Issue

# 列出所有 open 的 issue
gh issue list --repo openclaw/openclaw --state open

# 按标签过滤
gh issue list --repo openclaw/openclaw --label bug

# 查看详情
gh issue view 456 --repo openclaw/openclaw

04 实战演示

案例 1：批量审查 PR

场景： 周末堆积了 10 个 PR，需要快速了解状态

操作：

# 获取所有 open PR 的摘要
gh pr list --repo openclaw/openclaw \
  --json number,title,author,additions,deletions,mergeable \
  --jq '.[] | "[\(.number)] \(.title) by @\(.author.login) | +\(.additions)/-\(.deletions) | \(.mergeable)"'

输出示例：

[145] feat: add WebSocket support by @alice | +523/-89 | MERGEABLE
[144] fix: memory leak in parser by @bob | +45/-12 | MERGEABLE
[143] docs: update API reference by @carol | +234/-56 | CONFLICTING

快速决策： – ✅ MERGEABLE — 可以直接合并 – ⚠️ CONFLICTING — 需要解决冲突 – 🔄 CHECKS FAILING — CI 未通过

案例 2：自动监控 CI 状态

场景： 合并前确认所有检查通过 

# 查看 PR 的 CI 状态
gh pr checks 145 --repo openclaw/openclaw

输出示例：

Some checks are still pending
build (ubuntu-latest)   pending  —
test (node-18)          pass     2m
lint                    pass     1m
codecov                 pending  —

自动化脚本：

#!/bin/bash
# wait-for-ci.sh

PR_NUMBER=$1
REPO="openclaw/openclaw"

echo " 等待 PR #$PR_NUMBER 的 CI 完成..."

while true; do
  STATUS=$(gh pr checks $PR_NUMBER --repo $REPO --json state --jq '.[0].state')

  if ["$STATUS" = "SUCCESS"]; then
    echo "✅ CI 通过！可以合并 "
    gh pr merge $PR_NUMBER --squash --repo $REPO
    break
  elif ["$STATUS" = "FAILURE"]; then
    echo "❌ CI 失败，请检查日志 "
    gh run list --repo $REPO --limit 5
    break
  fi

  echo "⏳ 检查中... $(date)"
  sleep 60
done

案例 3：自动修复 Issue（gh-issues 技能）

gh-issues 是 OpenClaw 的高级技能，可以：– 自动 fetch issue – 派 AI 代理分析并修复 – 自动创建 PR – 监控审查意见并继续修复

基础用法：

# 查看帮助
/gh-issues --help

# 处理前 5 个 bug
/gh-issues openclaw/openclaw --label bug --limit 5

# 只处理分配给当前用户的
/gh-issues openclaw/openclaw --assignee @me

# 持续监控模式（每 5 分钟检查一次）/gh-issues openclaw/openclaw --label bug --watch --interval 5

实战：自动修复内存泄漏 bug

假设有个 issue #42：‘Fix memory leak in parser’

# 启动自动修复
/gh-issues openclaw/openclaw --label bug --limit 1 --yes

OpenClaw 会自动：

  1. Fetch issue — 获取 #42 的详情

  2. 派子代理 — 启动 Coding Agent 分析代码

  3. 定位问题 — 搜索 parser 相关代码

  4. 实施修复 — 修改代码，添加测试

  5. 创建分支 — git checkout -b fix/issue-42

  6. 提交代码 — git commit -m "fix: memory leak in parser"

  7. 推送分支 — git push origin fix/issue-42

  8. 创建 PR — 自动填写 PR 描述，关联 issue

PR 描述自动生成：

## Summary
修复 parser 中的内存泄漏问题

## Changes
- 在 parse() 函数中添加资源释放逻辑
- 修复了循环引用导致的内存无法回收
- 添加单元测试验证修复效果

## Testing
- 运行 `npm test`，全部通过
- 使用 heapdump 验证内存泄漏已解决

Fixes openclaw/openclaw#42

案例 4：处理 PR 审查意见

场景： Reviewer 提了修改意见，需要批量处理 

# 只处理审查意见（不处理新 issue）/gh-issues openclaw/openclaw --reviews-only

OpenClaw 会自动：

  1. 扫描所有 open PR — 查找有审查意见的

  2. 分析意见内容 — 判断哪些是 actionalbe 的

  3. 派修复代理 — 针对每条意见修改代码

  4. 回复 reviewer —‘已在 commit abc123 中修复’

支持的审查来源： – GitHub PR Review（inline comments）– PR 评论 – 嵌入在 PR body 的审查（如 Greptile）

05 进阶工作流

工作流 1：每日自动审查

目标： 每天早上自动检查昨日 PR，生成审查报告 

#!/bin/bash
# daily-review.sh

REPO="your-org/your-repo"
DATE=$(date -d "yesterday" +%Y-%m-%d)

echo "## 📊 昨日 PR 审查报告 ($DATE)"
echo ""

# 获取昨日创建的 PR
gh pr list --repo $REPO \
  --search "created:$DATE" \
  --json number,title,author,additions,deletions,mergeable \
  --jq '.[] | "- [#\(.number)] \(.title) by @\(.author.login) | \(.mergeable)"'

echo ""
echo "## 🔍 需要关注的 PR"

# 找出 CI 失败的
gh pr list --repo $REPO --state open | while read line; do
  PR_NUM=$(echo $line | awk '{print $1}')
  CHECKS=$(gh pr checks $PR_NUM --repo $REPO --json state --jq '.[0].state')
  if ["$CHECKS" = "FAILURE"]; then
    echo "- PR #$PR_NUM: CI 失败 "
  fi
done

配合 cron 定时运行：

# 每天早上 9 点执行
0 9 * * * /path/to/daily-review.sh | mail -s "PR Review Report" team@example.com

工作流 2：自动合并低风险 PR

场景： 文档更新、依赖升级等低风险 PR 自动合并 

#!/bin/bash
# auto-merge.sh

REPO="your-org/your-repo"

# 查找标记为 "auto-merge" 且 CI 通过的 PR
gh pr list --repo $REPO \
  --label "auto-merge" \
  --json number,title \
  --jq '.[].number' | while read pr; do

  STATUS=$(gh pr checks $pr --repo $REPO --json state --jq '.[0].state')

  if ["$STATUS" = "SUCCESS"]; then
    echo " 合并 PR #$pr"
    gh pr merge $pr --squash --repo $REPO
  else
    echo "PR #$pr CI 未通过，跳过 "
  fi
done

工作流 3：Fork 模式贡献开源

场景： 给开源项目提 PR，但没有写权限 

# 使用 --fork 参数
/gh-issues facebook/react --label "good first issue" \
  --fork your-username/react-fork \
  --limit 3

流程： 1. 从 facebook/react fetch issue 2. 在你的 fork（your-username/react-fork）创建分支 3. 修复代码并推送到 fork 4. 从 fork 向原仓库发起 PR

06 常见问题

Q1: gh-issues 提示‘GitHub authentication failed’

解决： 检查 Token 配置 

# 确认 GH_TOKEN 环境变量
echo $GH_TOKEN

# 或检查 OpenClaw 配置
cat ~/.openclaw/openclaw.json | jq '.skills.entries["gh-issues"].apiKey'

Q2: 子代理修复代码后没有创建 PR

排查： 1. 检查分支是否已推送：git branch -r | grep fix/issue- 2. 检查 Token 是否有创建 PR 权限 3. 查看子代理日志：process action:log sessionId:xxx

Q3: 如何处理复杂的 issue？

建议： – 复杂 issue 标记为‘needs-discussion’– 用 --limit 控制并发数，避免资源耗尽 – 对不确定的 issue，先用 --dry-run 查看详情

Q4: 审查意见太多怎么办？

策略：

# 分批处理
/gh-issues openclaw/openclaw --reviews-only --limit 5

# 只处理特定 reviewer 的意见（需手动筛选）

07 最佳实践

1. 标签管理

给 issue 打标签，方便分类处理：

2. 审查标准配置

在子代理 prompt 中明确审查标准：

 审查重点：1. 是否有单元测试覆盖
2. 是否遵循项目代码风格
3. 是否有潜在的安全问题
4. 性能影响评估

3. 监控和告警 

# 失败时发送通知
/gh-issues openclaw/openclaw --label bug \
  --notify-channel "-1001234567890"

4. 定期清理 

# 清理已合并的分支
gh api repos/openclaw/openclaw/branches | \
  jq -r '.[] | select(.name | startswith("fix/issue-")) | .name' | \
  while read branch; do
    # 检查对应 PR 是否已合并
    PR_NUM=$(echo $branch | sed 's/fix\\/issue-//')
    STATE=$(gh pr view $PR_NUM --repo openclaw/openclaw --json state --jq '.state')
    if ["$STATE" = "MERGED"]; then
      echo " 删除已合并分支: $branch"
      git push origin --delete $branch
    fi
  done

08 总结

下一步： – 尝试用 gh-issues 处理你项目的积压 issue – 配置 webhook 实现真正的实时触发 – 结合 Slack/ 飞书发送审查报告

本文是 OpenClaw 进阶技能系列第 2 篇，下一篇：《OpenClaw 批量生图实战：从 Prompt 到成品画廊》

#OpenClaw #GitHub #代码审查 #自动化 #DevOps

正文完
发表至： 技术
2026-06-02
 

近期文章

近期评论

您尚未收到任何评论。