Claude Code + GitHub：从提 Issue 到合并 PR，全自动开发流水线这样搭

发表于 更新于 分类于 阅读次数： 本文字数： 5.6k 阅读时长 ≈ 5 分钟

cover

想象这样一个场景。

有人在你的 GitHub 仓库里提了一个 Bug Issue。你还没打开电脑，AI 已经读完了 Issue、分析了代码、创建了分支、写好了修复、跑通了测试、提了 PR、还自动做完了 Code Review。

你打开电脑，看到的是一个等待合并的 PR。点一下 Merge，完事。

这不是科幻。这是 2026 年，Claude Code + GitHub Actions 已经可以实现的全自动开发流水线。

今天这篇文章，我来手把手拆解这条流水线的每个环节，给你可以直接复制粘贴的配置文件。

整体架构：一条 AI 驱动的开发流水线

先看全貌。这条流水线有 5 个自动化环节，覆盖了从 Issue 到合并的完整生命周期：

1
2
3
4
5
6
7
8
9
Issue 提交 → AI 自动修复并提 PR
     ↓
PR 创建 → AI 自动 Code Review
     ↓
Review 通过 → AI 自动生成测试
     ↓
代码合并 → AI 自动生成 Release Notes
     ↓
本地开发 → Hooks 自动检查质量

每个环节都有对应的 GitHub Actions Workflow 或 Claude Code Hook。下面逐一拆解。

第一步：安装 Claude GitHub App

所有自动化的基础，是让 Claude 能访问你的仓库。

  1. 打开 github.com/apps/claude，安装 Claude GitHub App
  2. 选择要授权的仓库
  3. 在仓库的 Settings → Secrets 中添加 ANTHROPIC_API_KEY

安装完成后，你就可以在 Issue 和 PR 的评论里 @claude 来触发 AI 操作了。

第二步：Issue 自动转 PR

这是整条流水线最惊艳的环节。有人提了 Issue，Claude 自动读取、分析、修复、提 PR。

创建 .github/workflows/issue-to-pr.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
name: Issue to PR
on:
  issues:
    types: [labeled]

jobs:
  auto-fix:
    if: github.event.label.name == 'claude-fix'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Read issue #${{ github.event.issue.number }}.
            Analyze the codebase, create a fix, and open a PR.
            Follow the project's CLAUDE.md conventions.
          allowed_tools: "Bash,Read,Write,Edit"

工作流程：

  1. 有人提 Issue
  2. 你（或机器人）给 Issue 打上 claude-fix 标签
  3. Claude 自动创建分支、写代码、跑测试、提交 PR

一位工程师在 Medium 上分享了实际体验：

“一个小修复、小重构、小功能——我们只需要在 Issue 里 @claude 加一句清晰的描述。Claude 自动拉分支、改代码、跑测试、提 PR。全程不需要任何开发者 pull 代码或切换分支。”

第三步：PR 自动 Code Review

每个 PR 都应该被认真审查。但现实是，人类审查者时间有限，很多 PR 只是被快速浏览一下就 Approve 了。

Claude Code 的自动 Review 可以解决这个问题。

创建 .github/workflows/claude-review.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review this PR on 5 dimensions:
            1. Design - Is the approach sound?
            2. Readability - Is the code clear?
            3. Performance - Any bottlenecks?
            4. Security - Any vulnerabilities?
            5. Testability - Are changes tested?

            Post findings as inline comments
            on specific lines.
          allowed_tools: >-
            Bash(gh pr diff:*),
            Bash(gh pr comment:*),
            Bash(gh pr view:*)

关键细节：allowed_tools 的安全限制。

注意 allowed_tools 这行。它把 Claude 的权限限制在”读取 diff + 发评论”，不允许执行任意 Shell 命令、写文件或访问 Secrets。这是安全的关键防线。

Anthropic 官方博客公布了一个数据：Code Review 在内部使用中，小于 50 行的 PR，31% 被发现有问题，平均每个 PR 发现 0.5 个问题。而**误报率不到 1%**。

更高级的方案是 Anthropic 官方的 Code Review 插件，它会派出 5 个专门的 AI 代理并行审查，每个发现都有 0-100 的置信度评分。不过这是付费功能。上面的 GitHub Action 方案是免费开源的，对大多数团队够用。

一个真实的成本参考：有开发者分享，使用 Opus 4.6 做了 200+ 个 PR 的自动审查，平均每个 PR 只花 $0.04，两个月总共 $19.50。

第四步：自动生成 PR 描述

很多 PR 的描述写着”fixed stuff”或者”update code”。这对审查者来说毫无用处。

用 Claude Code 自动生成 PR 描述，只需要在本地提 PR 时跑一行命令：

1
2
3
4
5
6
git diff main...HEAD | claude -p "Write a PR description for these changes. Include:
- Summary (2-3 sentences)
- What changed and why
- Testing done
- Breaking changes (if any)
Format as GitHub markdown."

或者把这个集成到 GitHub Actions 中，在 PR 创建时自动生成描述。

第五步：本地 Hooks——提交前的最后防线

GitHub Actions 在远程运行，但有些检查越早越好。Claude Code 的 Hooks 系统让你在本地就能拦截问题。

Hooks 的本质是生命周期事件监听器。你配置一次，它就会在 Claude Code 的特定动作前后自动运行。

在 .claude/settings.json 中配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "npm test 2>&1 | tail -20",
        "async": false
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "echo '{\"decision\":\"block\",\"reason\":\"Dangerous command\"}' | jq -r '.decision' | grep -q 'block' && echo 'BLOCKED' || true",
        "async": false
      }
    ]
  }
}

PostToolUse Hook：每次 Claude 编辑文件后，自动运行测试。如果测试失败，Claude 能看到结果并自动修复。

PreToolUse Hook：在 Claude 执行 Shell 命令前进行拦截，可以阻止危险操作。

一位用了 Claude Code 六个月的开发者总结得很好：

“你手动检查的每一件事，都可以编码成一个 Hook。每编码一个 Hook，就少记一件事。”

第六步：CLAUDE.md——流水线的大脑

所有自动化的质量，取决于 Claude 对你项目的理解程度。而 CLAUDE.md 就是那份”理解说明书”。

在项目根目录创建 CLAUDE.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Project Context

## Architecture
- Backend: Go + gin framework
- Frontend: React + TypeScript
- Database: PostgreSQL

## Conventions
- All API endpoints follow RESTful naming
- Error handling uses custom AppError type
- Tests use table-driven test pattern

## CI/CD Context
When running in GitHub Actions:
- Do not modify configuration files
- Always create a new branch, never commit to main
- Format PR comments using GitHub-flavored Markdown
- Include file paths as clickable links

## Testing
- Run `make test` before any PR
- Coverage threshold: 80%
- Integration tests are in /tests/integration/

Claude Code 在每次会话开始时自动读取这个文件。它是 Claude 的”入职文档”——项目结构、编码规范、测试策略、CI/CD 规则，全在这里。

子目录也可以有自己的 CLAUDE.md。 比如 api/CLAUDE.md 定义 Express 中间件模式，web/CLAUDE.md 描述 React 组件结构。Claude 会根据当前操作的文件路径自动加载对应的上下文。

安全注意事项

把 AI 放进 CI/CD 流水线，安全必须放在第一位。

1. 严格限制权限

allowed_tools 是最重要的安全配置。只给 Claude 它需要的最小权限。Review 任务只需要读 diff 和发评论，不需要写文件或跑命令。

2. 不要在 CI 中使用 --dangerously-skip-permissions

这个 flag 跳过所有权限检查。在本地开发时有人会用它图方便，但绝对不要在 CI/CD 中使用。

3. 警惕 Prompt 注入

如果你的 Workflow 会读取 Issue 标题或 PR 描述作为 Prompt 的一部分，攻击者可以通过精心构造的 Issue 标题注入恶意指令。Cline 的 500 万用户事件就是这样发生的。

防范方法：

  • 限制 allowed_tools，不给 Bash 执行权限
  • 不要把用户输入直接插入 Prompt
  • 设置 --max-turns 限制执行轮数（5-10 轮足够大多数 Review）

4. CI 触发链保护

默认情况下，GitHub App 创建的 commit 不会触发新的 Actions。这是一个重要的安全特性——防止 AI 触发无限循环。如果你确实需要 CI 在 Claude 的 commit 上运行，使用 actions/create-github-app-token 来配置专门的触发权限。

实际效果如何？

一个来自企业级团队的真实反馈（Go + React + TypeScript + Terraform 技术栈）：

  • Code Review 堆积问题解决了：每个 PR 都能在提交后几分钟内得到结构化的反馈
  • CI 失败调试时间大幅减少：Claude 读 CI 日志、定位根因、直接修复或给出清晰解释
  • 新人上手速度加快：新成员可以直接在 Issue 或 PR 里问 Claude 问题，得到基于代码库上下文的回答
  • 开发者不用离开 GitHub：不需要切换到另一个 AI 工具，在 PR 评论里 @claude 就行

这条流水线的核心思想是：Hooks 在提交前拦截问题，Actions 在合并前拦截问题。双层防线，大幅减少到达生产环境的 Bug。

从哪开始？

如果你想尝试，建议按这个顺序：

  1. 先搭 PR 自动 Review——价值最大、配置最简单、风险最低
  2. 再加本地 Hooks——测试自动运行、格式自动检查
  3. 然后加 Issue 转 PR——从简单的 Bug 修复开始
  4. 最后加 Release Notes 和 Docs 自动更新——锦上添花

每一步都可以独立运行，不需要一次全搭完。

记住一句话：自动化的质量取决于 Prompt 的质量。 你给 Claude 的指令越清晰、CLAUDE.md 写得越详细，流水线的输出就越靠谱。

你的团队有在用 AI 做自动化 Code Review 吗？你们的 CI/CD 流水线里加了哪些 AI 环节？欢迎在评论区分享你的实践经验。