程序员 AI 工具实战：OpenClaw + Claude Code 24小时自动修 Bug

凌晨3点47分，PagerDuty 的刺耳警报把我从睡梦中拽了出来。

又是那个老问题——用户下单时支付回调超时。我眯着眼睛打开笔记本，SSH 连上服务器，翻看日志，定位 Bug，写修复，跑测试，提交 PR。等一切搞定，天已经亮了。这种 on-call 的痛苦，做过后端的同学都懂。

但说实话，这种 Bug 根本不值得我凌晨起床。它是典型的”已知问题类型”——网络超时后重试机制没写好。修复也很简单：加个指数退避，捕获异常，记录日志。这种重复性的工作，为什么不能让 AI 代劳？

Railway - 现代化的部署平台，告别繁琐运维，让代码分钟级上线

立即开始 →推广

后来我搭了一套 OpenClaw + Claude Code 的混合工作流。OpenClaw 24小时盯着 Sentry，发现 Bug 自动派单；Claude Code 接单后拉分支、修代码、跑测试、提交 PR；我早上醒来只看到一封邮件：“已自动修复 3 个问题，请审查 PR。“

OpenClaw vs Claude Code——不是竞争，是互补

很多人问我：OpenClaw 和 Claude Code 到底用哪个？

说实话，这俩根本不是竞争关系。它们的定位完全不同，组合起来才是王炸。

OpenClaw 是 24/7 待命的”个人 AI 管家”。它常驻后台，能接 webhook、能监控各种数据源、能在你睡觉的时候继续干活。官方对它的定义是 “persistent personal AI”——持久化的个人 AI。它不擅长写复杂代码，但擅长”看着”事情发生，然后触发相应的动作。

Claude Code 是专业的”AI 程序员”。它不懂怎么监控你的服务器，但让它看代码、改 Bug、重构逻辑，那是它的强项。它能深度理解代码库，知道哪里该改、怎么改才安全。

你看，这俩完美互补：一个负责”看”，一个负责”干”。

我在 OpenClaw Directory 上看到一个叫 “Sentry → Auto-Debug → Open PR” 的配方，简直就是为这种场景设计的。它的思路是：

1. Sentry 监控到错误，触发 webhook
2. OpenClaw 接收告警，分析堆栈信息
3. OpenClaw 派生子代理，调用 Claude Code 修复
4. Claude Code 生成修复代码，跑测试
5. 测试通过后，自动打开 GitHub PR

整个流程完全自动，不需要人工介入。我在 Substack 上看到有人分享使用体验，说这套配置让他实现了”overnight code review with no human in the loop until the PR is ready”——晚上出 Bug，早上看 PR。

架构设计——混合工作流的核心组件

要理解这套工作流，你得先搞清楚 OpenClaw 的”子代理”机制。

OpenClaw 本身是个”大管家”。它负责监听各种事件（webhook、定时任务、消息通知），但具体的执行可以派给”子代理”去做。子代理是临时创建的、专注于特定任务的 AI 实例。

打个比方：OpenClaw 是项目经理，Claude Code 是程序员。项目经理接到需求（Sentry 告警），分析后派给程序员（子代理），程序员干活，干完汇报。

整体架构长这样：

┌─────────────────────────────────────────────────────────────┐
│                         外部世界                            │
│  ┌──────────┐  ┌──────────┐  ┌─────────────────────────┐   │
│  │  Sentry  │  │  GitHub  │  │  Slack/Discord/Telegram │   │
│  └────┬─────┘  └────▲─────┘  └──────────▲──────────────┘   │
└───────┼─────────────┼───────────────────┼──────────────────┘
        │             │                   │
        │ webhook     │ create PR         │ notify
        │             │                   │
┌───────▼─────────────┴───────────────────┴──────────────────┐
│                      OpenClaw Gateway                        │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              OpenClaw 主代理（监控者）                │  │
│  │  • 24小时监听 Sentry webhook                         │  │
│  │  • 分析错误类型和严重程度                            │  │
│  │  • 决策：自动修复 / 人工介入 / 忽略                  │  │
│  └─────────────────────┬────────────────────────────────┘  │
│                        │ spawn                             │
│                        ▼                                   │
│  ┌──────────────────────────────────────────────────────┐  │
│  │            Claude Code 子代理（执行者）               │  │
│  │  • 拉取最新代码                                      │  │
│  │  • 分析 Bug 根因                                     │  │
│  │  • 编写修复代码                                      │  │
│  │  • 运行测试验证                                      │  │
│  │  • 推送分支并创建 PR                                 │  │
│  └──────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────┘

关键点在于：OpenClaw 不直接改代码。它只做”决策”和”协调”，真正的代码修改交给 Claude Code 子代理。这样既保证了安全性（OpenClaw 有权限控制），又保证了修复质量（Claude Code 专业对口）。

数据流向是这样的：

1. Sentry webhook → OpenClaw（错误事件、堆栈信息、环境数据）
2. OpenClaw → Claude Code 子代理（修复指令、上下文信息）
3. Claude Code 子代理 → GitHub（修复代码、PR 描述）
4. GitHub → OpenClaw（PR 状态、CI 结果）
5. OpenClaw → Slack（通知人类审查）

OpenClaw 的状态管理能力在这里很重要。它可以记录每个 Bug 的处理状态：“已接收”、“分析中”、“修复中”、“待审查”、“已合并”。这样即使流程中断，也能从断点恢复。

实战配置——从监控到自动提交 PR

好，概念讲完了，来看具体怎么配置。

第一步：Sentry 配置 webhook

阿里云 - 开发者上云首选，轻量服务器专享 8.5 折优惠，助力项目快速上线

领取 8.5 折优惠 →推广

登录 Sentry，进入项目设置 → Integrations → Webhooks。添加你的 OpenClaw webhook URL：

https://your-openclaw-gateway.com/hooks/sentry?sessionKey=bug-fix-pipeline

然后在 Alert Rules 里创建一条规则：当 error count > 5 in 5 minutes 时，触发 webhook。

第二步：OpenClaw 配置监控代理

在 OpenClaw 里创建一个专门的 agent 来处理 Sentry 事件。配置文件大概长这样：

name: sentry-bug-monitor
hooks:
  sentry:
    path: /hooks/sentry
    defaultSessionKey: bug-fix-pipeline

steps:
  - id: parse-error
    command: json.parse stdin
    description: "解析 Sentry 的错误数据"

  - id: classify
    command: llm-task "分析错误类型和严重程度"
    args:
      error: $parse-error.stacktrace
      message: $parse-error.message
    schema: error-classification.json

  - id: decision
    command: state.set "action" $classify.recommended_action

  - id: auto-fix
    command: subagent.spawn
    args:
      type: claude-code
      task: "修复 Bug: ${parse-error.title}"
      context: $parse-error
      repo: $parse-error.project.repo
    condition: $classify.severity == "medium" && $classify.auto_fixable == true

  - id: notify-human
    command: slack.send "#alerts"
    args:
      message: "发现严重错误，需要人工介入: ${parse-error.url}"
    condition: $classify.severity == "critical"

这里有几个关键点：

• classify 步骤用 LLM 分析错误类型，判断是否适合自动修复
• decision 根据严重程度分流：中等优先级且可自动修复的走 Claude Code，严重的通知人工
• subagent.spawn 是派生子代理的指令，这里指定了 type 为 claude-code

第三步：Claude Code 子代理配置

子代理的任务是具体的代码修复。OpenClaw 会把上下文传递给它，包括错误堆栈、相关代码文件、环境信息。

子代理的工作流程：

# 1. 拉取最新代码
git clone $REPO_URL /tmp/fix-workspace
cd /tmp/fix-workspace

# 2. 创建修复分支
git checkout -b auto-fix/$ERROR_ID

# 3. 分析问题（Claude Code 介入）
claude-code --context $ERROR_CONTEXT --prompt "分析这个 Bug 的根因"

# 4. 编写修复
claude-code --prompt "编写修复代码，确保包含测试"

# 5. 运行测试
npm test

# 6. 提交并推送
git add .
git commit -m "fix: auto-fix for $ERROR_TITLE [skip ci]"
git push origin auto-fix/$ERROR_ID

# 7. 创建 PR
gh pr create --title "Auto-fix: $ERROR_TITLE" --body "..."

Claude Code 在这里的核心价值是”代码理解”。它不只是根据错误堆栈盲目修改，而是会：

• 读取相关代码文件，理解业务逻辑
• 分析错误传播路径，找到真正的根因
• 编写符合项目代码风格的修复
• 生成单元测试验证修复效果

第四步：GitHub PR 自动化

PR 创建后，OpenClaw 会继续监听 GitHub 的 webhook：

- id: watch-pr
  command: github.watch-pr $auto-fix.pr_number

- id: ci-status
  command: poll "github.checks $auto-fix.pr_number"
  until: $ci-status.completed == true
  timeout: 30m

- id: notify-review
  command: slack.send "#dev"
  args:
    message: |
      自动修复 PR 已就绪: ${auto-fix.pr_url}
      CI 状态: ${ci-status.conclusion}
      请审查后合并

这样你就收到了一条 Slack 消息，包含 PR 链接和 CI 结果。你点进去审查代码，没问题就合并。整个过程中，你完全不需要手动拉代码、写修复、跑测试。

进阶技巧——让工作流更智能

基础配置跑起来后，你可以加一些进阶功能让它更好用。

Bug 分级处理

不是所有 Bug 都值得自动修复。我在 classify 步骤加了个简单的规则引擎：

• P0（Critical）：系统宕机、数据丢失 → 立即通知人工
• P1（High）：核心功能不可用 → 通知 + 尝试自动修复（人工确认后提交）
• P2（Medium）：非核心功能异常 → 全自动修复
• P3（Low）：边缘 case、优化建议 → 记录到 backlog，每周批量处理

人工检查点

有些修复虽然技术上是正确的，但业务上可能有问题。我加了一个 approval 步骤：

- id: propose-fix
  command: claude-code.generate-fix

- id: human-approval
  command: slack.interactive
  args:
    message: "AI 建议以下修复，是否批准提交？"
    buttons: ["批准", "拒绝", "需要修改"]
  timeout: 4h

- id: submit-if-approved
  command: github.create-pr
  condition: $human-approval.choice == "批准"

这样对于敏感操作，AI 不会自作主张。

失败重试和回滚

Claude Code 也不是每次都能修好。如果测试失败，可以自动重试：

- id: fix-attempt
  loop: 3
  sub-lobster: claude-code-fix
  break-on: $fix-attempt.tests_passed

- id: escalate-if-failed
  command: slack.send "#dev-escalation"
  condition: !$fix-attempt.tests_passed

如果三次都失败，就通知人工接手。

多仓库支持

我们公司有十几个微服务，每个都有独立仓库。OpenClaw 可以配置多个项目映射：

projects:
  payment-service:
    repo: github.com/acme/payment
    sentry_project: payment-api
    auto_fix: true

  user-service:
    repo: github.com/acme/users
    sentry_project: user-api
    auto_fix: false  # 这个暂时不开自动修复

这样一套 OpenClaw 实例可以服务多个项目。

效果评估与注意事项

这套系统我跑了三个月，数据是这样的：

Vultr - 高性能 NVMe 云服务器，32 个全球节点可选，支持一键部署 Docker

查看定价 →推广

• 总捕获 Bug：127 个
• 自动修复成功：89 个（70%）
• 修复后测试通过：78 个（61%）
• 人工审查后合并：72 个（57%）

也就是说，接近六成的 Bug 完全不需要我动手，早上看看 PR 点一下合并就行。

时间节省更明显。以前一个典型 Bug 的处理流程：发现（平均 2 小时）→ 定位（30 分钟）→ 修复（30 分钟）→ 测试（20 分钟）→ 提交 PR（10 分钟）。总共 4.5 小时。

现在：发现（实时）→ AI 修复（10 分钟）→ 人工审查（5 分钟）。从 4.5 小时缩短到 15 分钟。

但说实话，这套系统也有局限：

适用场景：

• 已知问题类型的重复 Bug（如空指针、边界条件、API 超时）
• 有明确堆栈信息的运行时错误
• 代码库结构清晰、测试覆盖良好的项目

不适用场景：

• 架构设计层面的问题（需要人类决策）
• 需要跨多个系统协调的复杂 Bug
• 没有测试覆盖的遗留代码（AI 改完你不敢合）

风险控制：

• 永远不要给 AI 生产环境写权限
• 所有自动修复必须通过 PR，走正常审查流程
• 保留完整的审计日志，知道 AI 改了什么
• 定期检查 AI 的修复质量，调整模型 prompt

总结

说了这么多，OpenClaw + Claude Code 的混合工作流，本质上是把”监控”和”修复”这两个环节自动化了。OpenClaw 做它不擅长但必要的事情（24小时盯着），Claude Code 做它擅长的事情（写代码）。两者结合，实现了一个”永不疲倦的初级程序员”——能干活，但需要你把关。

这套配置的核心价值不是”替代程序员”，而是消除重复性工作，让你把精力集中在真正需要人类智慧的地方。

如果你也在为 on-call 痛苦，或者团队经常被重复 Bug 困扰，我建议试试这套方案。从最简单的场景开始——比如自动修复特定的错误类型——然后逐步扩展。

未来的编程工作流，大概率就是这种”人类决策 + AI 执行”的模式。早点拥抱它，早点下班。

10 分钟阅读 · 发布于: 2026年2月27日 · 修改于: 2026年3月3日

Easton

AI与智能