44 · GitHub Actions：在 PR 里 @ 一下，让 Claude 自己干活

📚 系列导航：上一篇 43 Git 工作流教你怎么让 Claude 在本地帮你管分支、写提交、开 PR——那都是你坐在电脑前、它在你身边干。这一篇把它送上云端：配好之后，你在 GitHub 的 issue 或 PR 里打一句 @claude，它就自己跑起来分析代码、改东西、开 PR，全程不用你开电脑。这就是 Claude Code GitHub Actions（GitHub 自动化工作流平台）。

设想这么一个半夜十一点多的场景：你已经躺下了，团队群里弹出一条消息。

一个同事：「老 X 那个 PR 你看了吗？卡了一天了，明天要上线。」你：「我睡了，明天一早看。」他：「……明天一早就来不及了啊。」

这种时候，要是早给那个仓库配上了 Claude Code GitHub Actions，就能省下无数个这样的夜晚：那个 PR 还没等你醒，评论区里已经躺着一份 Claude 自动跑出来的 review——逐行标出了一个空指针风险和两处没处理的边界。同事直接照着改完合了。

说白了，前面四十多篇我们聊的 Claude Code，都得你人在、终端开着、你盯着它干。GitHub Actions 这一篇要解决的是另一件事：让它脱离你的电脑，住进 GitHub 的服务器里，靠一句 @claude 就能被喊起来干活。你出差、你睡觉、你在开会，它照样能接 issue、审 PR、改 bug。

看完这一篇，你会拿到：

一句话搞懂 Claude Code GitHub Actions 是什么、它和你本地用的 Claude Code 是什么关系
@claude 提及触发到底怎么回事——你在哪打、它怎么知道该不该响应
最小可跑的 workflow YAML 长什么样、每一行在干什么，照着抄就能用
三个最实用的用例：自动 code review、按 issue 自动改、定时任务
API key / 密钥怎么安全配进 GitHub，绝不能踩的那条红线
一个能照着走、给了预期结果的实战：5 分钟把它装进你自己的仓库并验证

01 先搞懂：它是「住进 GitHub 的 Claude Code」

先给结论：GitHub Actions 版的 Claude Code，就是把你本地那个 Claude Code，搬到 GitHub 的服务器上跑——触发它的不再是你敲终端，而是仓库里发生的事件（有人开 PR、有人评论、定时到点）。

你回想前面四十多篇，Claude Code 一直是这么个用法：你在自己机器上开个终端，敲 claude，然后跟它对话、看它改文件。它干活的前提是「你在场」——你得开着电脑、盯着它、随时批准它的操作。

GitHub Actions 把这个前提拿掉了。它的官方定义很直白：

Claude Code GitHub Actions 为您的 GitHub 工作流带来了 AI 驱动的自动化。只需在任何 PR 或 issue 中简单地提及 @claude，Claude 就可以分析您的代码、创建拉取请求、实现功能和修复错误——所有这些都遵循您项目的标准。

类比：给团队招了个不用睡觉的夜班同事。 你们组白天有人盯着代码，下班了、半夜了就没人了。现在你招了个夜班的——他不打卡、不需要工位、不要工资（只按用量付费），只要群里有人 @ 他一句「帮我看下这个 PR」「把这个 bug 修了」，他就接活、干完把结果贴回来。你睡你的，他干他的。GitHub Actions 版的 Claude 就是这么个夜班同事，只不过他住在 GitHub 的机房里。

这里有个关键点别搞混：它不是另一个新产品，底层就是 Claude Code。 官方说得明白——它建立在 Claude Agent SDK 之上（这个第 45 篇会讲），而且它干活时照样读你仓库根目录的 CLAUDE.md（第 18 篇讲过那份「项目说明书」）。也就是说，你之前给项目写的规矩、约定、风格指南，这个夜班同事全盘照收，跟你本地用的是同一套标准。

落到真实场景，配好之后你能干这些：

PR 开出来了，没人有空 review——让它自动审一遍，逐行标出问题
issue 描述清楚了，但你没空写代码——评论一句 @claude 把这个实现了，它直接开个 PR 把功能实现了
CI 挂了，半夜没人管——让它分析报错、尝试修复

💡 一句话总结：GitHub Actions 版 Claude Code 就是搬进 GitHub 服务器、靠仓库事件触发的 Claude Code；它不用你在场，照样读你的 CLAUDE.md、守你的项目标准，像个不用睡觉的夜班同事。

02 `@claude` 提及：你怎么喊它，它怎么知道该不该来

最核心的用法——在 issue 或 PR 的评论里 @ 它一句，它就动。这一节把这件事拆透：你在哪打、打什么、它凭什么响应。

类比：在群里 @ 一个值班同事派活。 你们团队群里，平时聊天刷屏，但只要你 @ 了那个值班的，加一句具体要求，他就知道「这条是叫我的」，然后接活去办。@claude 一模一样——它平时不插话，你不 @ 它，它当没看见；你一 @ 它，它就把这条评论当成派给自己的任务。

具体在哪打？官方给的几个地方，都是你日常会用的：

PR 的评论区（issue comment）
PR 代码行上的 review 评论（pull request review comment）
issue 的正文或评论

打什么内容？就跟你给真人同事派活一样，说人话、说具体。比如这几句：

text

@claude 按这个 issue 的描述把功能实现了
@claude 这个接口的用户认证该怎么做
@claude 把用户面板组件里那个 TypeError 修了

分别是「按这个 issue 的描述把功能实现了」「这个接口的用户认证该怎么做」「把用户面板组件里那个 TypeError 修了」。它会自动分析上下文——读 issue、读相关代码、读你的 CLAUDE.md——然后做出对应的响应：能直接改的就开 PR，是提问就回答。

这里接上第 15 篇那条铁律——指令越具体，它越不跑偏。你在群里跟真人说「这个 PR 看一下」和「这个 PR 重点查一下并发安全和 SQL 注入」，得到的结果天差地别。@claude 也一样，含糊一句「看看」它只能泛泛扫，点名「查 SQL 注入漏洞」它就往那个方向使劲。

有个新手最容易踩的坑，官方专门在故障排除里点了名：

确认评论包含 @claude（不是 /claude）。

很常见的一幕：配好之后兴冲冲在 PR 里打了句 /claude review this，等了五分钟没动静，以为是密钥配错了，翻来覆去查了半天。最后发现是把 @ 打成了斜杠——/claude 是你本地终端里的斜杠命令（第 36 篇那套），在 GitHub 评论里它谁也不是。云端触发认的是 @claude（@ 符号），不是斜杠。 记死这一条，能帮你省下半小时排查。

	本地终端（前 43 篇）	GitHub Actions（这一篇）
谁来触发	你敲 `claude` 启动、对话	仓库事件（评论、开 PR、定时）
怎么喊它干活	直接说话、`/` 斜杠命令	评论里 `@claude`（@ 符号！）
你要在场吗	要，全程盯着	不用，它在云端自己跑
跑在哪	你自己的机器	GitHub 托管的 runner
批准谁来点	你逐步批准	按 workflow 预设的权限，无人值守

💡 一句话总结：在 issue / PR 评论里 @claude + 一句具体要求就能喊它干活；它自动读上下文和 CLAUDE.md 后响应；千万别打成 /claude——云端认的是 @ 符号，不是斜杠。

03 装上它：一条命令的「自动安装」最省事

@claude 能响应的前提，是你得先把这套东西装进仓库——装三样：一个 GitHub App（让 Claude 有权限读写你的仓库）、一个密钥（你的 API key）、一个 workflow 文件（告诉 GitHub 什么时候该把 Claude 喊起来）。

听着麻烦，但官方给了条「一键装」的捷径。最省事的办法：在你本地的 Claude Code 终端里，跑一条命令。

bash

/install-github-app

注意——这条 /install-github-app 是在你本地 claude 会话里敲的斜杠命令（对，就是第 36 篇那套斜杠命令，跟上一节说的云端 @claude 是两码事，别又搞混了）。它会拉起一个引导流程，官方说它会带你走完：

此命令将指导您完成 GitHub 应用和所需密钥的设置。

具体就是帮你把三件事一次办了：装好 GitHub App、把 ANTHROPIC_API_KEY 密钥配进仓库、把示例 workflow 文件丢进 .github/workflows/。跟着提示点几下就行。

不过有两个硬门槛得先满足，官方用 Note 框特意强调过：

您必须是仓库管理员才能安装 GitHub 应用并添加密钥
此快速启动方法仅适用于直接 Claude API 用户。如果您使用 Amazon Bedrock 或 Google Vertex AI，请参阅相应部分。

翻成人话：第一，你得是这个仓库的管理员（admin 权限），不然装不了 App、加不了密钥——这是 GitHub 的权限要求，不是 Claude 卡你。第二，这条捷径只服务「直接用 Claude API」的人；如果你们公司是走 AWS Bedrock 或 Google Vertex AI 那套云基础设施（第 05 篇提过的第三方模型路子），得走手动配置，这一篇末尾会点到。

那 GitHub App 装上之后要哪些权限？官方列得很清楚，就三项，而且都是读写：

Contents：读写（用来改仓库文件）
Issues：读写（用来响应 issue）
Pull requests：读写（用来创建 PR 和推送更改）

类比：给夜班同事发一张能进哪些门的工牌。 这三项权限就是工牌上印的门禁——能进「代码库」改文件、能进「issue 区」回话、能进「PR 区」开单子推代码。你不给他工牌，他站在门口啥也干不了；给多了又不安全。这三项是它干活的最小必需，官方默认请求的也正是这三项。

如果 /install-github-app 跑失败了（比如你网络不通、或者权限没对上），也能纯手动来：去 https://github.com/apps/claude 装 App、去仓库 Settings 里加密钥、从官方仓库的 examples/claude.yml 复制 workflow 文件。但能用 /install-github-app 就别手动——两种都走下来，自动那条省心太多，手动那次光找 examples 文件在哪就得翻好几分钟。

这套东西需要访问 GitHub 和 Claude 的服务器，国内网络如果不通，装 App、跑 workflow 那几步可能卡住，先开「魔法上网」再试。

💡 一句话总结：装它最省事的办法是本地 claude 里跑 /install-github-app，它一条龙帮你装 App、配密钥、放 workflow；前提是你得是仓库管理员且走直接 Claude API；给的工牌就三项读写权限——Contents、Issues、Pull requests。

04 workflow YAML：给夜班同事排的那张「值班表」

装好之后，真正决定「什么事发生时该把 Claude 喊起来」的，是那个 workflow 文件——一个躺在 .github/workflows/ 目录下的 YAML。这一节我们把最小的那份拆开，逐行看懂。

类比：给夜班同事排的值班表。 workflow 文件就是这张表，上面写清楚两件事：什么情况下他要上班（触发条件）、上班了具体干什么（执行步骤）。没这张表，同事招来了也不知道何时该动、动了干啥。

先看官方给的最小一份「响应 @claude 评论」的 workflow：

yaml

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 }}
          # Responds to @claude mentions in comments

别被 YAML 吓到，它就四块，逐块翻译一遍你立刻懂：

第一块 name：这张值班表的名字，随便起，会显示在 GitHub 的 Actions 页面。

第二块 on（什么时候上班）：这是触发条件。这里写的是「issue 评论被创建」（issue_comment 的 created）和「PR 代码行评论被创建」（pull_request_review_comment 的 created）——也就是说，有人在 issue 或 PR 里发了条新评论，这张表就被激活。

第三块 jobs（干什么活）：这里定义一个叫 claude 的任务，runs-on: ubuntu-latest 是说「在 GitHub 提供的最新版 Ubuntu 机器上跑」——你的代码全程待在 GitHub 的 runner 上，这也是官方说的「默认安全」。

第四块 steps（具体步骤）：核心就一步——uses: anthropics/claude-code-action@v1，意思是「用 Anthropic 官方做的这个 action，版本 v1」。下面 with 里把 ANTHROPIC_API_KEY 密钥传进去（密钥怎么来下一节专门讲）。那行 # Responds to @claude mentions 是注释，提醒你这份配置的作用就是「响应评论里的 @claude」。

最妙的一点在这儿：这份配置里，你没看到任何地方写「只在评论包含 @claude 时才跑」。为啥不用写？因为 v1 版本会自动检测模式。官方原话：

该 action 现在根据您的配置自动检测是在交互模式（响应 @claude 提及）还是自动化模式（立即使用提示运行）下运行。

说白了：你给了 prompt 参数，它就「自动化模式」——一触发立刻照着 prompt 干（下一节的 code review 就是这种）；你没给 prompt，它就「交互模式」——只在评论里出现 @claude 时才响应。这份最小配置没写 prompt，所以它自动进交互模式，乖乖等你 @。

⚠️ 这是从 beta 版升级过来的人最容易翻车的地方。老版本要手动写 mode: "tag"，还要用 direct_prompt；v1 把这些全砍了——mode 删掉（自动检测）、direct_prompt 改叫 prompt。如果你在网上抄到带 @beta、mode:、direct_prompt 的老配置，直接换成 v1 写法，别照抄。

那 --max-turns、--model 这些 CLI 参数（前面几篇见过的）往哪塞？官方给了个统一出口叫 claude_args——你本地能用的 Claude Code CLI 参数，基本都能从这儿传进去：

yaml

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    prompt: "Your instructions here"          # 可选：给它的指令
    claude_args: "--max-turns 5 --model claude-sonnet-4-6"  # 可选：CLI 参数

常用的几个 claude_args，官方列了这些：

参数	干什么	默认
`--max-turns`	最多来回几轮（防它没完没了烧钱）	10
`--model`	用哪个模型（如 `claude-opus-4-8`）	默认 Sonnet
`--allowedTools`	允许用哪些工具（逗号分隔）	—
`--mcp-config`	MCP 配置文件路径（第 22 篇那套）	—
`--debug`	开调试输出，排错时用	关

补一个官方明确写在文档里的事实：Claude Code GitHub Actions 默认用 Sonnet；想用 Opus 4.8，得在 claude_args 里加 --model claude-opus-4-8 显式指定。日常 review、改小 bug，Sonnet 完全够；真碰到要它啃大改动、做复杂推理，再换 Opus（模型怎么挑，第 30 篇那套「派活挑人」的逻辑在这儿照样成立）。

💡 一句话总结：workflow 就是给 Claude 排的值班表——on 定何时上班、steps 里 claude-code-action@v1 定干什么；v1 会自动检测模式（给 prompt 就自动跑、不给就等 @claude）；CLI 参数统一从 claude_args 塞进去。

05 三个真用得上的用例：自动审、自动改、定时跑

光会响应 @claude 还只是入门。这一节给你三份现成的 workflow，对应三种最高频的场景。每一份都标清「它解决什么、配置长啥样」。

用例一：每个 PR 自动 code review（不用 @，自动跑）

这是最常用的一个，也是开头那个半夜场景的主角。它不用任何人 @，只要有 PR 开出来或更新，Claude 就自动审一遍。

yaml

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 }}
          prompt: "Review this pull request for code quality, correctness, and security."
          claude_args: "--max-turns 5"

跟上一节那份比，差别就两处：触发条件换成了 pull_request 的 opened（PR 刚开）和 synchronize（PR 有新提交）；而且多给了一个 prompt。还记得上一节说的「给了 prompt 就自动化模式」吗？——正因为这里写了 prompt，它一触发就直接照着「审查代码质量、正确性和安全性」去干，不等任何人 @。每次有人推代码上来，它都自动过一遍，评论区里就躺好了反馈。

想要更省心、连 workflow 都不想写的「全托管」自动 review？Anthropic 还有个独立的 Code Review 服务（面向 Team / Enterprise 订阅），开关一开每个 PR 自动审、按严重程度标记、还能用 REVIEW.md 定制。本篇讲的是「在你自己的 CI 里跑 Claude」，那套托管服务是另一条路，这里点到为止。

用例二：按 issue 自动改（@claude 派活）

这个走的是上一节那份「响应 @claude」的最小 workflow，重点在你评论里怎么说。issue 描述写清楚后，在评论里：

text

@claude 按这个 issue 的描述把功能实现了

它会读 issue 描述、读相关代码、读 CLAUDE.md，然后在一个新分支上把功能实现，并开一个 PR 供你审查。我给一个内部小工具加过一个导出 CSV 的功能，就是这么干的——issue 里把字段、格式写明白，@ 它一句，二十来分钟后 PR 就开好了，审完直接合，从头到尾没打开过编辑器。

修 bug 同理：

text

@claude 把用户面板组件里那个 TypeError 修了

它定位错误、改掉、更新分支或开新 PR。

用例三：定时任务（到点自己跑）

这个连「事件」都不需要，纯按时间触发——比如每天早上九点生成一份昨日提交和待办 issue 的汇总。

yaml

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"

on: schedule 配 cron: "0 9 * * *" 就是「每天 9 点（UTC）」跑一次，触发后照着 prompt 生成汇总。这种「无人值守、定时产出」的活，最适合丢给这个夜班同事。

三个用例，三种触发，横着对比一眼看清：

用例	触发方式	给 prompt 吗	是什么模式	典型场景
自动 review	`pull_request`（开/更新 PR）	给	自动化（自动跑）	每个 PR 自动审一遍
按 issue 改	`issue_comment`（评论 @claude）	不给	交互（等 @claude）	issue 转成代码、修 bug
定时任务	`schedule`（cron 到点）	给	自动化（自动跑）	每日报告、定期巡检

记住那条贯穿三者的主线：给 prompt = 它自动照着干；不给 prompt = 它等你 @claude。 想清楚你要哪种，就知道该不该写 prompt。

💡 一句话总结：三个最实用的用例——PR 自动 review（给 prompt，自动跑）、按 issue 自动改（不给 prompt，@claude 触发）、定时任务（cron + prompt，到点自动产出）；本质都是「触发方式 + 给不给 prompt」的组合。

06 密钥安全：那条绝不能踩的红线

到这儿你一定注意到了，前面每份 workflow 里都有这么一行：

yaml

anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

这一节专讲这一行背后的安全规矩——它是整篇里最不能马虎的地方。 第 04 篇我们配过本地的 ANTHROPIC_API_KEY，还说过「具体到 CI 的玩法第 44 篇再讲」，就是现在了。

先把官方那句加了红框的警告原封不动放这儿：

永远不要直接将 API 密钥提交到您的仓库。

为啥这是红线？因为 GitHub 仓库——尤其公开仓库——是全世界都能看的。 你要是图省事，把真实的 sk-ant-xxxx 直接写进 YAML 文件提交上去，等于把你的钱包密码贴在了公告栏上：有人扫到就能拿你的 key 疯狂调 API，账单全算你头上。这种事在 GitHub 上天天发生，扫密钥的爬虫一刻不停。

正确做法就一条：用 GitHub Secrets，绝不硬编码。 官方给的步骤很清楚：

将您的 API 密钥添加为名为 ANTHROPIC_API_KEY 的仓库密钥
在工作流中引用它：anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

类比：把钥匙锁进保险柜，YAML 里只留个取钥匙的暗号。 GitHub Secrets 就是仓库自带的保险柜——你把真实 key 锁进去，它加密存着、不会显示在任何日志或界面里。workflow 文件里你写的 ${{ secrets.ANTHROPIC_API_KEY }} 不是密钥本身，只是一句「去保险柜把那把叫 ANTHROPIC_API_KEY 的钥匙取出来用」的暗号。文件可以大大方方提交、公开，因为里面压根没有真东西。

怎么把 key 存进这个保险柜？手动的话：打开仓库的 Settings → Secrets and variables → Actions，点 New repository secret，名字填 ANTHROPIC_API_KEY，值填你的真实 key（从 Claude Console 拿，第 04 篇讲过）。如果你前面用了 /install-github-app，这一步它已经替你办好了。

这套和我们一路强调的安全主线是一脉相承的。第 21 篇讲过提示注入——有人往 issue、PR 评论里藏「写给 AI 看的恶意指令」骗 Claude 执行。云端这套尤其要警惕这一点：你的 Claude 现在会自动去读 issue 和 PR 评论的内容，而这些内容任何陌生人都能提交。所以官方的几条最佳实践，每一条都值得照做：

❌ 危险做法	✅ 安全做法
把真实 key 写进 YAML 提交	存进 GitHub Secrets，YAML 只引用
把权限开到最大图省事	只授必要的权限（Contents / Issues / PR 三项读写）
Claude 开的 PR 直接合	合并前自己审一遍
公开仓库随便让陌生人 @claude 派活	留意提示注入，敏感仓库收紧触发条件

最后一行的「合并前自己审一遍」值得专门强调——Claude 干得再好，它开的 PR 也只是「一个贡献者的提交」，不是免审金牌。官方原话：「在合并前审查 Claude 的建议」。一条值得守住的铁规矩是：云端 Claude 开的 PR，一律当成实习生交的活来审，绝不因为「是 AI 写的看着挺像样」就闭眼合。

💡 一句话总结：密钥红线就一条——绝不把真实 key 写进仓库，而是存进 GitHub Secrets（加密保险柜），YAML 里只用 ${{ secrets.ANTHROPIC_API_KEY }} 这个暗号引用；再配上「最小权限 + 合并前必审 + 警惕提示注入」三条，才算把云端这套用得稳。

07 动手：5 分钟把它装进你自己的仓库

光看不练等于没学。下面带你真正把它装进一个你自己的 GitHub 仓库并验证跑通。找一个你有管理员权限、且不重要的测试仓库练手（别拿生产仓库试），全程不依赖你已有的复杂环境。

前提：你得是这个仓库的管理员、走的是直接 Claude API（不是 Bedrock / Vertex）、本地装好了 Claude Code。这几步要连 GitHub 和 Claude 服务器，国内网络不通就先开「魔法上网」。

第一步：在本地 Claude Code 里跑安装命令

进到那个测试仓库的目录，启动 claude，然后敲：

text

/install-github-app

预期：它会拉起一个引导，通常会让你在浏览器里点开授权——给 Claude GitHub App 选仓库、确认那三项权限（Contents / Issues / Pull requests 读写），再引导你把 ANTHROPIC_API_KEY 配进仓库 Secrets。跟着提示一步步点完，看到它提示安装成功、workflow 文件已写入即可。

第二步：确认 workflow 文件到位

去你仓库里看一眼，应该多了个文件：

text

.github/workflows/claude.yml

预期：这个文件存在，内容大致就是第 04 节那份最小 workflow（on: issue_comment + claude-code-action@v1）。看到它 = 值班表已经排上了。 如果没有，说明上一步没走完，回去重跑 /install-github-app。

第三步：确认密钥进了保险柜

去仓库 Settings → Secrets and variables → Actions 看一眼。

预期：Repository secrets 列表里有一项 ANTHROPIC_API_KEY（只显示名字，值是加密的看不到）。看到这个名字 = 钥匙锁进保险柜了。

第四步：开个测试 issue，@ 它一句

在仓库里新建一个 issue，标题随便，正文里写一句具体的小任务，比如：

text

@claude 在 README 末尾加一行 "Hello from Claude Code GitHub Actions"，然后开个 PR

预期：

去仓库的 Actions 标签页，你会看到一个名为 Claude Code 的 workflow 正在运行（转圈）或已完成（绿勾）。
等一两分钟（它要在 runner 上启动、读仓库、干活），Claude 会在这个 issue 下回一条评论，并开出一个 PR——PR 里就是给 README 加的那一行。
看到这个自动开出来的 PR = 整条链路通了。

如果等了几分钟啥都没发生，按官方故障排除挨个查：评论是不是打成了 /claude（必须是 @claude）、App 是不是装好了、Secrets 里 key 在不在、Actions 是不是被禁用了。最常见的就是栽在 /claude 上，别重蹈覆辙。

第五步：审完再合（别闭眼合）

打开那个 PR，像审实习生的活一样看一眼 diff，确认它真就加了那一行、没动别的。确认无误再合。

跑通这五步，你就把「装 App → 配密钥 → 排值班表 → @ 它派活 → 它自动开 PR → 你审完合」这条完整链路亲手走了一遍。以后给任何仓库配，本质都是这套流程，无非换换 workflow 里的触发条件和 prompt。

💡 一句话总结：动手就五步——/install-github-app 装、看 claude.yml 到位、看 Secrets 里有 key、开 issue @claude 派个小任务、确认它自动开 PR 后审完再合；跑通这条链路，比记十条配置都顶用。

08 小结

这一篇我们把 Claude Code 送上了云端——从「你在场它才干」到「一句 @claude 它自己跑」，全靠 GitHub Actions 这套自动化。

把核心要点串起来回顾：

你要做的事	用什么	关键点
理解它是什么	住进 GitHub 的 Claude Code	仓库事件触发，不用你在场，照读 `CLAUDE.md`
喊它干活	评论里 `@claude` + 具体要求	认 @ 符号，不是 `/claude`
装上它	本地跑 `/install-github-app`	要管理员权限 + 直接 API；给三项读写工牌
配触发与行为	`.github/workflows/` 的 YAML	`on` 定何时、`claude_args` 传参；v1 自动检测模式
选用例	review / 按 issue 改 / 定时	给 prompt 自动跑，不给等 @claude
保护密钥	GitHub Secrets	绝不硬编码，YAML 只用 `${{ secrets.* }}` 引用

你现在应该能： 说清 GitHub Actions 版 Claude Code 和本地版的区别、在 PR / issue 里用 @claude 派活（还不会打成 /claude）、看懂并改一份最小 workflow YAML、按「自动 review / 按 issue 改 / 定时」三种需求挑对配置、把 API key 安全地锁进 GitHub Secrets，并亲手把这套装进自己的仓库验证跑通。这套云端自动化，是你让 Claude 从「桌上的助手」升级成「团队里 24 小时在岗的一员」的那一步。

配好 Actions 之后，就再没必要为「PR 没人 review」熬夜——夜班同事顶上了，你睡你的。

顺带一提：如果你们用的是 GitLab 而不是 GitHub，Claude 也有对应的 GitLab CI/CD 集成（目前是测试阶段），思路一模一样——在 .gitlab-ci.yml 里加个作业、配个掩码变量、@claude 触发。这一篇讲透了 GitHub 这条，GitLab 那条照着官方文档套就行。

下一篇 45「Agent SDK」——这一篇的 GitHub Actions，官方说它「建立在 Claude Agent SDK 之上」。换句话说，@claude 自动开 PR 这套能力，底层是一个能让你用代码把 Claude Code 嵌进任何程序的 SDK 在撑着。GitHub Actions 只是它最现成的一个封装。下一篇就掀开这层盖子：如果你想搞的自动化超出了 @claude 那几招——比如做个自己的 AI 客服、批量处理一万个文件、把 Claude 塞进你自家的后台系统，该怎么用代码直接驱动它？想想看：GitHub Actions 帮你把「触发」和「跑」都封装好了，可一旦你想自己定义「什么时候跑、跑完结果往哪送」，是不是就得往下挖一层了？

44 · GitHub Actions：在 PR 里 @ 一下，让 Claude 自己干活 ​

01 先搞懂：它是「住进 GitHub 的 Claude Code」 ​

02 @claude 提及：你怎么喊它，它怎么知道该不该来 ​

03 装上它：一条命令的「自动安装」最省事 ​

04 workflow YAML：给夜班同事排的那张「值班表」 ​

05 三个真用得上的用例：自动审、自动改、定时跑 ​

用例一：每个 PR 自动 code review（不用 @，自动跑） ​

用例二：按 issue 自动改（@claude 派活） ​

用例三：定时任务（到点自己跑） ​

06 密钥安全：那条绝不能踩的红线 ​

07 动手：5 分钟把它装进你自己的仓库 ​

08 小结 ​

44 · GitHub Actions：在 PR 里 @ 一下，让 Claude 自己干活

01 先搞懂：它是「住进 GitHub 的 Claude Code」

02 `@claude` 提及：你怎么喊它，它怎么知道该不该来

03 装上它：一条命令的「自动安装」最省事

04 workflow YAML：给夜班同事排的那张「值班表」

05 三个真用得上的用例：自动审、自动改、定时跑

用例一：每个 PR 自动 code review（不用 @，自动跑）

用例二：按 issue 自动改（@claude 派活）

用例三：定时任务（到点自己跑）

06 密钥安全：那条绝不能踩的红线

07 动手：5 分钟把它装进你自己的仓库

08 小结