工作流 📋 6 个步骤 第 546 / 548 篇

把 Claude Code 接进 GitHub Actions:PR 自动审查与 @claude 自动化

用 Anthropic 官方 claude-code-action@v1 把 Claude Code 接进 GitHub Actions:从安装 GitHub App、配置 ANTHROPIC_API_KEY secret、写 workflow,到 @claude 自动响应 issue/PR 与 PR 自动审查,含成本控制与权限红线。

2026.10.19· 6 分钟上手· 约 1776 字· 🤖 Claude Code / ⚙️ GitHub Actions

你已经用 Claude Code 在本地写代码、修 bug,但每次都要手动让它审 PR、改 issue,团队其他人根本用不上。把 Claude Code 接进 GitHub Actions 后,这件事就自动化了:PR 一打开就自动出审查意见,在 issue 或 PR 里 @claude 说一句它就动手干活,连 lint、测试都能自动跑。本教程用 Anthropic 官方维护的 claude-code-action@v1,从装 GitHub App、配密钥、写 workflow,到自动审查与成本控制,一步步跑通 CI 里的 AI 协作。

🤖 本教程适合:已经在本地用 Claude Code 的开发者或团队,想把 AI 审查、自动修 issue、跑测试这些活儿搬进 CI/CD,让整个仓库而非个人受益。需要一个 Anthropic API Key(或 Claude Pro/Max 计划的 OAuth Token)和一个 GitHub 仓库的管理员权限。

Step 1:先想清楚:接进 CI 后能省掉什么

1 它不是把本地 Claude Code 搬上云

claude-code-action 本质是在 GitHub 的 runner 上以无头模式跑一次 Claude Code 会话:你给它一段 prompt(或让它响应 @claude 评论),它读仓库、执行工具、把结果写成 PR 评论或提交回分支。关键收益有三块:审查自动发生(不靠个人记得叫 AI)、规则统一(CLAUDE.md 在 CI 里照样生效)、动作可审计(每次调用都在 PR 时间线留痕)。

本地用法:你手动开 Claude Code → 让它审 PR
CI 用法:PR 一开 → 自动跑 Claude Code 审查 → 评论贴回 PR
差别:后者不依赖「某人记得」,且全队同一套标准
💡 它和「AI 代码审查工具综述」里那些第三方服务不同:claude-code-action 直接复用你本地的 Claude Code 行为(同一个 CLAUDE.md、同一套工具白名单),迁移零成本。

Step 2:安装 GitHub App 并配置密钥

2 最快路线:/install-github-app

在 Claude Code 终端里运行 /install-github-app,会引导你安装官方 GitHub App、授权仓库、并自动生成 workflow 文件。装完后去仓库 Settings → Secrets and variables → Actions 里加一个密钥:名字 ANTHROPIC_API_KEY,值是你在 console.anthropic.com 拿到的 Key。Pro/Max 用户也可以换成 claude setup-token 生成的 CLAUDE_CODE_OAUTH_TOKEN,团队记账更干净。

1. 本地 Claude Code 终端执行:/install-github-app
2. 浏览器里给目标仓库装 GitHub App(需要管理员权限)
3. 仓库 Settings → Secrets → Actions → New repository secret
   名称:ANTHROPIC_API_KEY
   值:  sk-ant-xxxxxxxxxxxxxxxx
4. 权限要求:Contents / Issues / Pull requests 均 Read & Write

密钥红线:API Key 只进 GitHub Encrypted Secrets,绝不写进 workflow 文件或提交到仓库。fork 来的 PR 默认拿不到 secrets,要在 workflow 里加 if 判断跳过外部贡献者的运行,避免白跑或泄露。

Step 3:写第一个 workflow——PR 自动审查

3 在 .github/workflows 下放一个 yaml

新建 .github/workflows/claude-review.yml。它监听 pull_request 的 opened / synchronize / reopened 事件,拉全量 git 历史(fetch-depth: 0 让 Claude 看得到与 base 的 diff),然后调 action 出审查意见。prompt 里写清审查维度,claude_args 用 --max-turns 5 给迭代次数封顶,控制单次成本。

name: Claude Code Review
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            审查这个 PR:1) 逻辑错误与空值处理 2) 安全隐患
            (SQL 注入、鉴权缺失、敏感信息泄露)3) 性能与
            风格是否违反 CLAUDE.md。按 High/Medium/Low 标注严重度。
          claude_args: |
            --max-turns 5
🔑 fetch-depth: 0 很重要:它给 Claude 完整历史,否则它只能看到单条 diff,上下文不够。评论长度有上限,超长时先截断再贴,别让一次 PR 评论撑爆。

Step 4:用 @claude 让它在评论里直接干活

4 监听评论触发,自动派发任务

再建一个 workflow 监听 issue_comment 与 pull_request_review_comment 的 created 事件,只要评论里包含 @claude 就触发。这样团队成员在任意 PR 或 issue 里写「@claude 修复 auth.ts 里的 failing test」就能让它开干并开新 PR。v1 不再需要显式写 mode,action 会根据触发类型和 prompt 自动判断是响应模式还是自主执行模式。

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]
jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

从 beta 迁移的坑:旧版字段 direct_prompt 要改成 prompt,max_turns 要从顶层挪到 claude_args 下的 --max-turns。漏改会导致任务静默失败,PR 上什么评论都不出现——多半是 secrets.GITHUB_TOKEN 权限不够或字段名没改对。

Step 5:成本控制与权限红线

5 用 max-turns 与 allowed_tools 兜底

CI 里的调用按用量计费,和你的交互式会话分开算。给每个 job 设 --max-turns 上限(比如 5~10),避免单次 PR 把整月预算烧光;用 allowed_tools 收紧它能用的工具(只给 Read/Bash 做审查,需要它改文件时再加 Write/Edit)。fork PR 场景务必加 if 跳过,防止外部贡献者的评论触发消耗。

# 审查类:只读,不给写权限
allowed_tools: "Read,Grep,Glob,Bash"

# 自动修 lint 类:需要写回
allowed_tools: "Read,Write,Edit,Bash"

# 统一封顶迭代次数
claude_args: |
  --max-turns 8
💡 用 Haiku 这类便宜模型做浅层风格审查、用 Sonnet 做深度逻辑审查,按任务分档最划算。把项目规则写进 CLAUDE.md 一次,CI 每次都自动遵循,比在 prompt 里重复写更稳。

Step 6:让它在 push 时自动修 lint 或跑测试

6 自主提交也要收住范围

把触发事件换成 push,并给 action 一个明确的「只修格式/lint,不改逻辑」的 prompt,加上 contents: write 权限,Claude 就能把修复直接提交回分支。注意:这类自主提交风险更高,务必把 prompt 边界写死,并在仓库保护分支规则上要求 PR 评审,别让自动提交直接进 main。

on:
  push:
    branches: [main, dev]
jobs:
  auto-fix:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            运行 linter,修掉可自动修复的格式/lint 问题并提交,
            提交信息 "fix: auto-fix lint"。只改格式,不改任何逻辑。
          allowed_tools: "Read,Write,Edit,Bash"
          claude_args: |
            --max-turns 6

红线:自主提交(能写回分支)的 job 必须和「只评论不提交」的审查 job 分开,且写回类只用在你信任的分支与明确受限的 prompt 上。生产分支建议保留人工评审关卡,不要让 agent 自动合并。

常见问题速查

现象原因与处理
PR 上没出现审查评论多半是 GITHUB_TOKEN 权限不足或字段名仍是旧版 direct_prompt,改成 prompt 并在 workflow 显式写 permissions
fork 来的 PR 触发失败GitHub 默认不给 fork 工作流暴露 secrets,加 if 判断 head.repo 是否是本仓库再跑
单次运行太贵缩小审查范围(只看改动文件)、降 max-turns、浅层审查换便宜模型
Claude 不按项目规范确认仓库根目录有 CLAUDE.md,CI 会自动读取;把规则写进 CLAUDE.md 而非只写 prompt
← 返回教程中心