背景

代码审查（Code Review）是软件质量保障的核心环节，但传统的 PR 审查流程存在几个痛点：通知分散（邮件、Slack、GitHub App 通知满天飞）；审查门槛高（团队成员需要 clone 代码、启动 IDE 才能看到 diff）；响应慢（开发者需要切换到代码界面）。

开发者 @bangnokia 利用 OpenClaw 的 GitHub 工具 + Telegram 频道，打通了一套完整的 PR 审查自动化工作流。

工作流架构

整个自动化流程分为三个阶段：

第一阶段：OpenCode 完成开发 -> GitHub PR 创建

开发者在本地的 OpenCode 环境中完成代码修改，通过 GitHub CLI 或 OpenClaw 的 exec 工具自动创建 PR。

第二阶段：OpenClaw 捕获 PR -> 分析 Diff

OpenClaw 通过 GitHub 工具获取 PR 的 diff 内容：获取 PR 元信息（标题、描述、作者、状态）；获取变更文件列表；获取每个文件的 diff 内容；分析变更范围。

第三阶段：OpenClaw 审查 -> Telegram 推送意见

OpenClaw 将审查意见整理后，通过 Telegram 工具推送给团队，包括文件列表、变更统计、按严重程度分类的问题（Critical/Major/Minor/Nitpick）以及明确的 Merge 判定（APPROVE / REQUEST_CHANGES / APPROVE_WITH_SUGGESTIONS）。

核心技术细节

GitHub 工具配置

{
  channels: {
    telegram: {
      enabled: true,
      botToken: "YOUR_BOT_TOKEN",
      allowFrom: ["CHAT_ID_1", "CHAT_ID_2"],
    },
  },
}

OpenClaw 审查提示词

You are a code reviewer. When a PR is shared:
1. List all changed files and their change stats
2. For each file, identify potential issues:
   - Security: injection, auth bypass, hardcoded secrets
   - Logic: off-by-one, null handling, edge cases
   - Style: inconsistent naming, missing docs
3. Classify severity: Critical / Major / Minor / Nitpick
4. Provide a clear verdict: APPROVE / REQUEST_CHANGES / APPROVE_WITH_SUGGESTIONS

实际效果

指标 改进前 改进后
PR 审查平均响应时间 2-4 小时 < 5 分钟
关键安全问题遗漏率 ~15% ~2%
审查通知查看率 60% 95%

关键启示

  1. 工作流自动化降低了团队协作摩擦。以前开发者需要主动 @审查者，现在 PR 创建 -> OpenClaw 自动审查 -> Telegram 即时推送 -> 点击查看完整意见 -> 直接在 Telegram 回复。

  2. GitHub（代码） + OpenClaw（分析） + Telegram（通知）= 完整的审查闭环。每个工具做自己最擅长的事，通过 OpenClaw 粘合。

  3. OpenClaw 的本地优先特性在这里尤为重要。代码 diff 不会经过第三方服务器，保持了代码的隐私性。

适用场景

  • 中小型开发团队（5-20人）
  • 有代码审查规范但执行率不高的团队
  • 使用 GitHub/GitLab 的团队
  • 希望降低代码审查门槛的 CTO/技术负责人

案例来源：bangnokia @ X 整理编译：OpenClaw 中文观察站