
这是「Claude Code 通关手册」系列的第 9 篇,共 10 篇。Level 4(高级篇)收官。这篇讲完,你的 Claude Code 自动化体系就完整了。
Claude Code 通关手册(一):Cursor 用户转 Claude Code,第一天我就后悔了——后悔没早点用
Claude Code 通关手册(二):权限系统搞明白,效率直接翻倍
Claude Code 通关手册(三):99%的人不知道的效率秘诀,CLAUDE.md 深度实战
Claude Code 通关手册(四):3 个自定义命令,让你的 Claude Code 快到飞起
Claude Code 通关手册(五):子代理系统——给你的 AI 配一个"专家团队"
Claude Code 通关手册(六):MCP 协议完全指南,Claude Code 最被低估的能力
Claude Code 通关手册(七):打造 AI 自动化流水线,Hooks、Skills、Plugins 实战
Claude Code 通关手册(八):你还在跟 AI 聊天?高手早就用代码驱动了
从今天起,你的每个 PR 提交后就会收到一份 AI 代码审查报告——类型安全、性能隐患、安全风险、Next.js 最佳实践,全部自动检查。不用人盯着,不会遗漏,永不请假。
这不是概念演示,这是你读完本文就能配好的东西。
但光有云端自动化还不够。本地开发时,Claude 大刀阔斧改了 20 个文件结果改错了怎么办?Claude 执行了一个不该跑的命令怎么办?
所以这篇把三个东西放在一起讲——GitHub Actions(云端自动化)、检查点(本地后悔药)、沙箱(安全围栏)。三块拼图补齐,你的 Claude Code 就既能自主工作,又不会失控。
最简单的方式是在 Claude Code 终端里直接跑:
/install-github-app
这个命令会引导你完成 GitHub App 安装和 Secret 配置。跟着提示走就行,大概 5 分钟搞定。
如果你更喜欢手动配置,往下看。
第一步:安装 Claude GitHub App
访问 https://github.com/apps/claude ,把 App 安装到你的仓库。需要的权限:Contents(读写)、Issues(读写)、Pull requests(读写)。
第二步:添加 API Key
进入仓库的 Settings → Secrets and variables → Actions → New repository secret,添加 ANTHROPIC_API_KEY。
第三步:创建 Workflow 文件
把下面的文件放到 .github/workflows/claude.yml:
name: ClaudeCode
on:
issue_comment:
types:[created]
pull_request_review_comment:
types:[created]
issues:
types:[opened,assigned]
pull_request:
types:[opened,synchronize]
permissions:
contents:read
pull-requests:write
issues:write
jobs:
claude:
if:|
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'issues' && contains(github.event.issue.body, '@claude')) ||
github.event_name == 'pull_request'
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}}
这个配置覆盖了两种触发方式:自动触发(每次 PR 创建或更新时)和 @claude 触发(在 issue 或 PR 评论中 @claude)。
上面是通用配置。对于 DevPulse 这样的 Next.js 项目,我们加一个专门的审查 Workflow:
# .github/workflows/claude-review.yml
name:ClaudePRReview
on:
pull_request:
types:[opened,synchronize]
permissions:
contents:read
pull-requests:write
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:|
审查这个 PR 的代码变更。你是一个 Next.js 14 + TypeScript 项目的资深审查员。
逐文件检查以下维度:
1.TypeScript类型安全:有没有any、类型断言是否合理
2.Next.js最佳实践:Server/ClientComponent划分是否正确、数据获取方式是否合适
3.性能问题:有没有不必要的re-render、大列表是否有优化
4.安全风险:有没有XSS隐患、敏感信息泄露
对每个问题标注严重程度(🔴必须修复/🟡建议改进/🟢可选优化),
并给出具体的修改建议和代码示例。
最后给一个整体评分(1-10)和一句话总结。
claude_args:"--max-turns 5 --model sonnet"
合并到 main 分支后,每次有人提 PR,Claude 就会自动审查并把结果作为 PR 评论发出来。
除了自动审查,你还可以在任何 PR 或 Issue 的评论里 @claude 跟它对话:
@claude 这个 API 路由有没有 SQL 注入风险?
@claude 帮我把这个 issue 描述的功能实现一下,完了提个 PR
没错——Claude 不只能审查,还能直接写代码并创建 PR。不过自动创建 PR 需要把权限改为 contents: write,建议先从只读审查开始,熟悉之后再开放写权限。
GitHub Actions 里跑 Claude 有两个成本:Actions 运行时间 + API Token 消耗。几个建议:
--max-turns——限制 Agent 循环次数,防止跑飞# 加在 jobs 同级
concurrency:
group: claude-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: true
这样同一个 PR 短时间内多次 push 只会跑最新那次,取消之前的。
云端自动化解决了。回到本地开发——当你让 Claude 大刀阔斧改代码时,如果改错了怎么办?
Claude Code 会在每次文件编辑前自动创建检查点。你不用做任何配置,它默认就在工作。
就像一个极度勤快的助理,每次动手前都先拍一张快照——"改之前是这样的,您看看,改错了随时回来"。
方式 1:Esc × 2(最快)
连按两次 Esc 键,立即弹出回退菜单。这是日常最常用的方式——Claude 刚改完你觉得不对,两下 Esc 就回去了。
方式 2:/rewind 命令
/rewind
弹出一个可滚动的列表,显示本次会话中你的每一条提示词。选择要回退到的那条,然后选择回退策略。
方式 3:/checkpoints 命令
/checkpoints
列出所有检查点和 ID,可以精确跳转到某个检查点:
/rewind checkpoint_a3f8d2
选中一个检查点后,你有三个选择:
┌──────────────────────────────────────────────────────────┐
│ 三种回退策略 │
├──────────────────┬───────────────────────────────────────┤
│ 策略 │ 效果 │
├──────────────────┼───────────────────────────────────────┤
│ 恢复代码和对话 │ 代码回退 + 对话回退 │
│ (Restore code │ = 彻底回到那个时间点 │
│ and conversation)│ 适合:改错了,整个方向不对 │
├──────────────────┼───────────────────────────────────────┤
│ 恢复对话 │ 只回退对话,保留当前代码 │
│ (Restore │ = 清理上下文但保留代码成果 │
│ conversation) │ 适合:代码改对了,但对话太长想精简 │
├──────────────────┼───────────────────────────────────────┤
│ 从此处总结 │ 从这个点开始压缩后续对话 │
│ (Summarize │ = 保留早期上下文,压缩后面的 │
│ from here) │ 适合:调试跑偏了很久想回正轨 │
└──────────────────┴───────────────────────────────────────┘
检查点不是版本控制的替代品。它们的关系是互补的:
检查点 = "本地撤销"
→ 秒级回退,会话级别
→ 适合快速试错和回退
→ 会话结束后逐渐消失
Git = "永久历史"
→ commit 级别的版本管理
→ 适合长期历史和协作
→ 永久保存
最佳实践:
1. 让 Claude 大胆改 → 检查点保底
2. 改好了确认没问题 → git commit 存档
3. 改错了 → Esc×2 回退,重新来
检查点只追踪 Claude 编辑工具的文件操作。以下操作不在追踪范围内:
rm、mv、cp)——这些是永久操作所以如果 Claude 通过 bash 删了文件,检查点救不了你。这也是为什么第 7 篇的 PreToolUse Hook(拦截危险命令)很重要——它在检查点之前就防住了问题。
你有没有过这种经历——Claude 要执行一个 npm 命令,弹出权限确认,你看了一眼点"允许"。又弹一个,又点。再弹一个,继续点。到第十个的时候你已经不看内容直接点了。
这就是"权限疲劳"——确认太多等于没有确认。
沙箱解决的就是这个问题:用 OS 级别的隔离代替频繁的权限弹窗。在安全边界内的操作自动放行,超出边界的操作直接拦截。
在 Claude Code 交互模式中:
/sandbox
一个命令启用。启用后,Claude 在沙箱边界内的 bash 命令不再弹出权限确认——既更安全,又更顺畅。
沙箱提供文件系统和网络两层隔离:
┌──────────────────────────────────────────────────────────┐
│ 沙箱的两层隔离 │
├──────────────────────────────────────────────────────────┤
│ │
│ 文件系统隔离 │
│ ┌───────────────────────────────────────────┐ │
│ │ 可写入:当前工作目录及子目录 │ ← 默认 │
│ │ 可读取:整个系统(除显式拒绝的路径) │ │
│ │ 被拦截:工作目录外的写入操作 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ Claude 可以读你的项目文件、修改项目代码, │
│ 但不能碰 ~/.bashrc、~/.ssh/、/usr/local/bin │
│ 或任何项目目录之外的东西。 │
│ │
│ 网络隔离 │
│ ┌───────────────────────────────────────────┐ │
│ │ 默认:限制网络访问到明确允许的域名 │ │
│ │ npm/yarn 等包管理器的域名自动允许 │ │
│ │ 其他出站请求需要显式配置 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ 技术实现: │
│ macOS → Seatbelt(苹果的沙箱框架) │
│ Linux → bubblewrap(容器级隔离) │
│ 这是操作系统内核级别的隔离,不是靠"信任" │
│ │
└──────────────────────────────────────────────────────────┘
沙箱和权限系统(第 2 篇讲的 permissions)是两个独立的安全层:
没有沙箱时,权限系统的 deny 规则只对 Claude 的内置工具生效——如果 Claude 通过 bash 命令访问文件,deny 规则管不到。开启沙箱后,同样的限制在 OS 层面强制执行,bash 命令也被管住了。
// .claude/settings.json 中的沙箱相关配置
{
"permissions": {
"deny": [
"Read ~/.ssh/**",
"Read ~/.aws/**",
"Edit ~/.bashrc",
"Edit ~/.zshrc"
]
}
}
启用 /sandbox 后,这些 deny 规则从"工具级别"升级为"OS 级别"——真正的铜墙铁壁。
实际效果:开启沙箱后,权限确认弹窗减少约 80%。大部分操作在安全边界内自动放行,你只需要在真正越界时做决策。
前面三个系统(GitHub Actions 在云端、检查点在本地、沙箱管安全)到位后,你可以放心地让 Claude 执行更长时间、更大范围的任务了。
第 5 篇讲过子代理最多 7 个并行。在自主运行场景下,这意味着你可以说:
对 src/components/ 下的所有组件做一次全面审查:
代码质量、安全扫描、测试覆盖率检查,同时进行
Claude 会把任务分配给多个子代理并行执行,然后汇总结果。你只需要等一份汇总报告。
Claude Code 支持后台任务(Background Tasks)——比如在 Claude 工作时保持 dev server 运行:
启动 npm run dev,然后帮我修复首页的布局问题
Claude 会在后台启动 dev server,同时在前台改代码,改完后可能还会在浏览器里验证效果。
长时间无人值守运行时,你的安全配置尤其重要。这里是一个推荐的策略组合:
┌──────────────────────────────────────────────────────────┐
│ 无人值守安全策略 │
├──────────────────────────────────────────────────────────┤
│ │
│ ✅ 必须开启 │
│ ├── /sandbox(OS 级隔离) │
│ ├── 检查点(自动存档,改错可回退) │
│ └── Git 分支(在新分支上操作,不碰 main) │
│ │
│ ✅ 建议配置 │
│ ├── PreToolUse Hook 拦截危险命令 │
│ ├── 敏感文件保护 Hook │
│ └── --max-turns 设上限(防止无限循环) │
│ │
│ ✅ 监控方式 │
│ ├── Notification Hook → 桌面通知 │
│ │ (Claude 需要你介入时提醒你) │
│ ├── Stop Hook → 记录日志 │
│ │ (每次 Claude 完成任务时记录做了什么) │
│ └── 回来后先 git diff 看看改了哪些文件 │
│ │
│ 口诀:分支隔离 + 沙箱围栏 + 检查点兜底 │
│ 三道防线,安心放手 │
│ │
└──────────────────────────────────────────────────────────┘
三个核心收获:
第一,GitHub Actions 让 Claude 住进你的 CI/CD——每次 PR 自动审查,@claude 随时交互。用 anthropics/claude-code-action@v1,配合自定义 prompt 定制审查标准。记得设 --max-turns 和 concurrency 控制成本。
第二,检查点是你的"后悔药"——Claude 每次编辑前自动存档,Esc×2 秒回退。三种回退策略(代码+对话、仅对话、从此总结)覆盖不同场景。但 bash 命令不在追踪范围内,所以 Hook 拦截依然重要。
第三,沙箱用 OS 级隔离取代权限疲劳—— /sandbox 一键启用,文件系统和网络双层隔离,权限弹窗减少约 80%。和权限系统形成双层防护:权限管工具,沙箱管命令。
三块拼图补齐:GitHub Actions 管云端自动化,检查点管本地回退,沙箱管安全边界。 Claude Code 从此既能自主工作,又不会失控。
回顾 Level 4(高级篇)两篇文章的完整检查清单:
claude -p)写过自动化脚本query() 函数执行过任务全部打勾?Level 4 通关。你已经掌握了 Claude Code 从本地开发到云端自动化的完整链路。
第 10 篇(终篇):Claude Code 通关手册(十)—— 从个人利器到团队基建
到目前为止,所有内容都聚焦在"你一个人怎么用好 Claude Code"。但如果你是技术负责人,你需要考虑的是:怎么让整个团队都用好它?
CLAUDE.md 怎么写才能让所有人遵循同样的标准?权限配置怎么设才能既安全又不碍事?子代理和 Skills 怎么通过 Plugin 分发给团队?新人怎么快速上手?
终篇会把前 9 篇的所有知识汇总成一个可落地的团队方案——从个人的 Claude Code 能力,升级为整个团队的 AI 开发基建。
今日话题
你打算在哪个项目里第一个配上 Claude Code GitHub Action?效果如何?评论区分享你的体验——是惊喜还是翻车,都值得聊聊。
如果这篇文章帮你补齐了自动化的最后一块拼图,欢迎点赞、在看、转发三连——帮更多人实现"AI 驱动的 CI/CD"。
关注「前端达人」,终篇即将到来,我们下篇见。