Claude Code GitHub Actions 教程：自动审 PR 修 Bug（2026）

本地用 Claude Code 写代码已经很顺了，但它下班就停工——你睡觉的时候没人审 PR，同事提的 issue 也躺着不动。Claude Code GitHub Actions 解决的正是这件事：把 Claude Code 整个运行时搬进 GitHub Actions 跑起来，在任意 issue 或 PR 评论里 @claude，它就能读懂上下文、改代码、提交 PR；也可以配成每个 PR 一打开就自动跑一遍代码评审，在有问题的那几行直接留评论。这篇教程给出官方 v1 的完整配置、最容易抄错的版本差异，以及成本与安全上的实际边界。

它到底能干什么

这个 Action 建立在 Claude Agent SDK 之上，跑的是完整的 Claude Code 运行时，不是简单调一次 API。也就是说它在 CI 里同样能读整个仓库、跑命令、改多个文件，能力上限和你本地那个 Claude Code 是一致的。常见用法有四类：

• 自动代码评审——PR 打开或更新时自动触发，读 diff 并结合仓库上下文，在具体行上留评论，能顺着调用链发现跨文件的回归。
• 把 issue 变成 PR——在 issue 里写 @claude implement this feature based on the issue description，它读需求、写实现、开一个完整的 PR。
• PR 里直接改——评审时发现问题，直接回复 @claude fix the TypeError in the user dashboard component，它推一个 commit 上去。
• 定时任务——配 schedule 触发器，比如每天早上生成一份昨日提交与未决 issue 的摘要。

最快路径：一条命令装完

在本地项目的 Claude Code 终端里运行斜杠命令，它会交互式地帮你装 GitHub App、生成工作流文件、配置密钥：

/install-github-app

两个前提：你必须是该仓库的管理员（否则装不了 App、加不了 secret）；这条快捷路径只适用于直连 Claude API 的用户，走 Amazon Bedrock 或 Google Cloud 的要手动配。另外在 Claude Code v2.1.187 及以上版本里，装完 App 后可以选择「暂时跳过」只装 App，之后再运行一次该命令回来补工作流和密钥。

手动配置：三步

1. 1安装 Claude GitHub App 到你的仓库（github.com/apps/claude）。它需要三项仓库权限：Contents 读写（改文件）、Issues 读写（回 issue）、Pull requests 读写（建 PR 和推送改动）。
2. 2把 API 密钥加进仓库 Secrets，命名为 ANTHROPIC_API_KEY。路径是仓库 Settings → Secrets and variables → Actions。
3. 3在 .github/workflows/ 下新建工作流文件，内容参考下面的示例，或直接复制官方仓库 anthropics/claude-code-action 的 examples/claude.yml。

基础工作流：响应 @claude

最小可用的配置只有这么几行。它监听评论事件，看到 @claude 就动手：

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          # 省略 prompt，即为响应评论中的 @claude 提及

提交后，去任意 issue 或 PR 里发一条包含 @claude 的评论测试。注意是 @claude，不是 /claude——写错前缀是「Claude 没反应」最常见的原因。

进阶：每个 PR 自动跑代码评审

不想每次都手动 @，可以监听 pull_request 事件并直接给出 prompt。官方推荐的做法是装上 code-review 插件，复用它内置的评审 skill，而不是自己从零写一大段评审提示词：

name: Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"

types 里的 synchronize 表示 PR 有新提交时也重跑一次。如果嫌频繁，去掉它，只在 opened 时跑一次。另外定时任务也是同一个套路，换成 schedule 触发器即可：

name: Daily Report
on:
  schedule:
    - cron: "0 9 * * *"
jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Generate a summary of yesterday's commits and open issues"
          claude_args: "--model opus"

从 beta 升到 v1：中文教程最容易抄错的地方

这一节值得单独看。v1.0 引入了破坏性变更，而网上流传的大量中文教程还停留在 beta 写法——照抄会直接报参数不识别。核心变化是：把一堆零散的参数收敛成了 prompt 和 claude_args 两个口子，模式也不用手动指定了。

对照着看一眼前后差异就很清楚了。beta 写法：

- uses: anthropics/claude-code-action@beta
  with:
    mode: "tag"
    direct_prompt: "Review this PR for security issues"
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    custom_instructions: "Follow our coding standards"
    max_turns: "10"
    model: "claude-sonnet-5"

v1 正确写法：

- uses: anthropics/claude-code-action@v1
  with:
    prompt: "Review this PR for security issues"
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    claude_args: |
      --append-system-prompt "Follow our coding standards"
      --max-turns 10
      --model claude-sonnet-5

参数速查：claude_args 能塞什么

Action 本身的参数很少，绝大部分定制都通过 claude_args 透传给 Claude Code CLI——也就是说，本地 CLI 支持的参数这里基本都能用。

claude_args 里最常用的几个：--max-turns 限制最大对话轮数（默认 10，是防跑飞的主要闸门）、--model 指定模型、--allowedTools 白名单限制可用工具、--mcp-config 挂 MCP 配置、--debug 开调试输出。

国内团队的三个现实问题

官方文档不会讲这些，但国内团队接入时基本都会撞上。

1. 1网络不是问题。Action 跑在 GitHub 托管的 runner 上（境外机器），由它去访问 Claude API，你本地能不能连通并不影响。真正的门槛是有一个可用的 Anthropic API 账号和余额。
2. 2企业环境可以走云厂商。如果公司有 AWS 或 GCP 资源，用 use_bedrock / use_vertex 配合 OIDC 联合身份，既解决计费主体问题，也不用在 GitHub 里存长期密钥——OIDC 签发的是临时凭证，比静态 AccessKey 安全得多。
3. 3想接国产模型没有官方方案。本地 Claude Code 靠 ANTHROPIC_BASE_URL 指向第三方网关（DeepSeek 的 /anthropic 端点、智谱 GLM 等）就能换模型，社区里也有人把同样的环境变量塞进 workflow 的 env 里，但这不是官方支持路径，兼容性和稳定性都要自己承担。想省钱更稳妥的做法是控制触发频率和 --max-turns，而不是硬换后端。

成本：两笔账要分开算

很多人接完发现账单比预期高，是因为只算了一边。实际上有两笔：

• 在 claude_args 里配好 --max-turns，防止它反复迭代烧 token。
• 给 job 设工作流级超时，避免任务失控一直跑。
• 用 GitHub 的 concurrency 控制限制并行运行数，防止一次推多个 commit 触发一堆重复评审。
• 自动评审的触发器慎用 synchronize——每推一次 commit 就重跑一遍，是账单飙升的头号原因。
• 把 CLAUDE.md 写得简洁聚焦，它每次都会进上下文。

让它更贴合你的项目

两个定制入口。一是仓库根目录的 CLAUDE.md——定义代码风格、评审标准、项目特定规则，Claude 在 CI 里同样遵守它，和你本地那套完全一致，这也是让评审意见「像自己人提的」的关键。二是工作流里的 prompt 参数，用来给不同工作流下不同的具体指令。

常见故障排查

• Claude 完全不响应 @claude：确认 GitHub App 装好了、工作流是启用状态、仓库 Secrets 里有 API 密钥，以及评论里写的确实是 @claude 而不是 /claude。
• Claude 提交的 commit 不触发 CI：确保用的是 GitHub App（官方 App 或你自建的），而不是默认的 Actions 用户——Actions 用户的提交默认不会再触发其它工作流；同时检查工作流触发事件和 App 权限。
• 鉴权报错：确认密钥有效且额度充足；走 Bedrock / Vertex 的检查 OIDC 配置和 secret 命名是否与工作流里引用的一致。
• 参数不被识别：八成是抄了 beta 时代的配置，对照上面的迁移表改成 v1 写法。

把 AI 从「本地帮你敲代码的工具」变成「常驻在流水线里的一个成员」，是 AI 编程从个人提效走向团队工程化的关键一步。真正难的不是配好这个 YAML，而是想清楚哪些环节该交给它、哪些必须留给人，以及怎么用 CLAUDE.md 把团队规范沉淀成 AI 也能遵守的约定。想系统掌握这整套 AI 工程化协作方法，欢迎来 IMAI 看看我们的体系化实战课程。