📌 标签：#混合部署 #CLI #CI/CD #架构决策 #最佳实践
Claude Code 既可以在你的终端里本地运行，也可以放进 GitHub Actions、Jenkins 等 CI/CD 流水线中云端执行。这两种模式不是互斥的，而是互补的。聪明的团队会根据任务类型、数据敏感性、成本预算和响应速度，动态选择最合适的执行环境。这篇文章帮你理清决策逻辑，并给出一个可落地的混合部署框架。
1. 本地 CLI vs 云端 CI/CD：核心差异一览
| 数据位置 | 代码和密钥留在本地，不上传 | 代码被复制到 CI runner（通常是云厂商的临时实例） |
| 网络访问 | 可访问本地服务、内网、VPN | 通常只能访问公网，无法访问公司内网（除非自建 runner） |
| 交互性 | 可实时确认、打断、追问 | 全自动，无人值守 |
| 响应时间 | 即时 | 需要排队、启动 runner，通常 10-60 秒延迟 |
| 成本 | 仅 API token 费用 | token + CI runner 计算时间（部分平台免费额度有限） |
| 并发能力 | 单用户单任务 | 可大规模并发（受配额限制） |
| 审计合规 | 依赖个人记录 | 日志集中存储，便于审计 |
| 依赖环境 | 你的本地开发环境（可能不标准） | 标准化容器镜像，可复现 |
关键结论：本地 CLI 适合探索、调试、临时任务；云端 CI/CD 适合自动化、规模化、需要强制流程的任务。
2. 何时用本地 CLI？
2.1 场景一：探索性编码和原型开发
当你还不确定怎么写一个函数、不确定 API 用法时，在本地终端里快速问 Claude：
用 Rust 写一个并发安全的 LRU 缓存。
AI 生成代码，你立即运行测试、修改、迭代。本地响应快，不需要 commit 或 push。
2.2 场景二：处理敏感数据或私有代码
如果你的代码库有商业机密、个人隐私信息（如用户数据），你可能不愿意将它复制到云端的 CI runner 中（即使 GitHub 等厂商承诺数据隔离）。本地 CLI 确保所有代码和上下文只留在你的机器上，只有 API 调用发送到 Anthropic（且 API 默认不用数据训练）。
2.3 场景三：需要访问内网资源
如果你的项目依赖公司内部 npm 仓库、私有 Git 服务器、内网数据库，云端 CI runner 无法访问这些资源（除非搭建自托管 runner）。本地 CLI 可以直接利用你的 VPN 或网络代理。
2.4 场景四：交互式调试和故障排查
生产环境出了诡异 bug，你需要快速查看日志、单步调试、尝试修复。在本地终端里：
@error.log 结合 src/payment.js 分析为什么 Stripe webhook 验证失败。
AI 可以引导你检查环境变量、模拟请求，整个过程你可以随时打断或补充信息。
2.5 场景五：低成本原型验证
云端运行每次都要启动环境、拉取代码、安装依赖，消耗 runner 分钟数和 token。而本地 CLI 只需 token 费用，且你可以用免费额度或低成本测试新的提示词。
3. 何时用云端 CI/CD？
3.1 场景一：团队协作的标准化流程
例如：每次 PR 自动运行代码审查、自动生成文档、自动运行测试。云端 CI 保证了一致性：无论开发者用的是 Windows 还是 Mac，CI 环境总是 Ubuntu + Node 20，结果可复现。
3.2 场景二：大规模并发任务
你有 100 个仓库需要批量更新依赖。本地一台机器做太慢，云端可以启动 10 个并行 runner，每个处理 10 个仓库，总时间从 2 小时降到 10 分钟。
3.3 场景三：需要审计和合规记录
金融、医疗行业要求所有代码变更都有记录和可追溯性。云端 CI 的所有步骤（包括 Claude 的输入输出、环境变量、时间戳）都会保存在日志中，满足合规要求。
3.4 场景四：定时自动化任务
比如每周一凌晨自动升级所有依赖并提交 PR。云端 CI 可以通过 cron trigger 实现，不需要你半夜爬起来运行本地脚本。
3.5 场景五：无本地开发环境的情况
比如你只在线编辑代码（GitHub web）、或者你的开发机是 chromebook 无法安装 CLI。云端 CI 可以通过评论 @claude 或 webhook 触发。
4. 混合部署的黄金模式：本地 + 云端融合
现实中最有效的策略是混合部署：根据任务的敏感度、紧急程度和类型，自动路由到最佳执行环境。
4.1 架构示意
开发者
│
├─ 本地终端 (claude) → 实时响应、敏感数据、内网访问
│
└─ GitHub PR/Issue 评论 @claude → Webhook → 决策引擎
│
┌─────────────────────┼─────────────────────┐
↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 本地 │ │ 云端 │ │ 自托管 │
│ runner │ │ Actions │ │ runner │
└──────────┘ └──────────┘ └──────────┘
(内网、敏感) (常规任务) (合规但不在公云)
4.2 决策树
当收到 @claude 指令时，服务判断：
指令中是否包含敏感词（如 /secrets, /db）？
→ 是 → 路由到自托管 runner（公司内部）
指令是否要求访问内网（如 /internal-api）？
→ 是 → 路由到自托管 runner
指令类型是否为“探索/教育/简单问答”？
→ 是 → 可路由到低成本云端（甚至 Haiku 模型）
指令来自 release 分支或 main？
→ 是 → 必须使用云端（可审计）
其他情况 → 默认使用 GitHub 托管的 runner
4.3 自托管 runner 的混合模式
对于必须访问内网或处理敏感数据的任务，你可以在公司内部的机器上运行一个自托管的 GitHub Actions runner，它既能被 GitHub 触发，又能安全地访问内网资源。在该 runner 上安装 Claude Code，云端 webhook 触发它执行任务。这样既保留了 CI 的自动化，又满足了数据本地化要求。
# .github/workflows/claude-internal.yml
name: Claude Internal
on:
issue_comment:
types: [created]
jobs:
claude-sensitive:
runs-on: self–hosted # 你的内网机器
if: contains(github.event.comment.body, '/sensitive')
steps:
– uses: actions/checkout@v4
– run: |
claude –print "${{ github.event.comment.body }}" \\
–allowed-tools Read,Grep,Edit,Bash
5. 实践建议：如何选择与迁移
5.1 小团队 / 个人开发者
- 首选本地 CLI：成本低、灵活。每天 80% 的任务在本地完成。
- 云端辅助：只在需要自动化审查、定时任务时配置一个简单的 GitHub Actions（第 37 篇）。
5.2 中型团队（10-50 人）
- 本地 CLI 作为开发者工具：每个开发者自己安装，用于日常开发。
- 云端 CI 作为质量门禁：PR 自动审查、依赖升级 PR、文档生成等。
- 混合路由：使用 @claude 命令，敏感任务（如访问数据库）提示“请在本地执行，因为需要内网权限”。
5.3 大型企业（50+ 人，合规严）
- 本地 CLI 仅限于沙箱项目：普通开发者不允许直接访问生产密钥。
- 自托管 runner 为核心：所有 Claude 任务跑在公司内部的 Kubernetes 或虚拟机集群上，日志集中存储。
- 禁止公网 runner 访问生产环境：GitHub 托管的 runner 只能访问测试仓库。
5.4 从纯云端迁移到混合模式的信号
- 账单过高：每天几百次云端 CI 调用，token 和 runner 费用超出预期 → 将简单任务（如注释生成、格式检查）挪到本地 CLI。
- 数据泄露担忧：法务要求代码不得离开公司网络 → 搭建自托管 runner。
- 响应慢：开发者抱怨“审查评论要等 2 分钟” → 让本地 CLI 提供即时反馈，云端仅做深度分析。
6. 混合部署的挑战与解决方案
| 工具链不一致 | 使用 Docker 容器统一 Claude Code 版本和环境（本地也用相同镜像） |
| 状态不同步 | 本地和云端共用同一个 Git 仓库，云端自动拉取最新代码；本地手动 pull |
| 成本双计费 | 设置预算上限：本地使用自己的 API Key；云端使用团队共享 Key 并设置配额 |
| 权限管理复杂 | 通过 CLAUDE.md 区分环境：if: CI=true 时禁止某些危险操作 |
| 调试困难 | 在本地用 –print 模拟云端环境（设置相同的环境变量） |
7. 实战：在本地和云端共享同一套 Skill
你可以创建一个 Skill（第 18 篇），让它既能本地交互运行，也能在 CI 中非交互运行。
Skill 文件 .claude/skills/security-check.md：
—
name: security-check
description: 扫描代码中的常见安全漏洞
—
# 安全检查 Skill
## 执行
– 使用 `Grep` 搜索高危模式：eval、exec、SQL 拼接、硬编码密码。
– 输出 JSON 格式的报告。
## CI 模式检测
如果环境变量 `CI=true` 存在，则：
– 只输出报告，不询问修复。
– 报告格式必须是 JSON。
否则（本地模式）：
– 发现漏洞后，询问“是否自动修复？”
– 如果用户同意，使用 `Edit` 工具修复。
这样，同一个 Skill 在本地可以交互修复，在 CI 中只做只读扫描。
8. 成本优化：混合部署的财务模型
假设一个中型团队每天执行 200 次 Claude 任务：
| 每日 token 消耗 | 400K | 800K | 400K0.6 + 800K0.4 = 560K |
| 每日 API 成本 | $2.40 | $4.80 | $3.36 |
| CI runner 成本 | $0 | $5.00（GitHub 超额度） | $2.00 |
| 总成本 | $2.40 | $9.80 | $5.36 |
混合模式节省约 45% 成本，同时保留了自动化能力。
9. 下篇预告
混合部署让你在正确的地方使用 Claude Code。但如果你的企业有特殊的安全要求，连 GitHub 托管的 CI 都不能用，那么你必须自己搭建一套内部的代码审查服务。下一篇我们将深入 云端代码审查服务搭建：从PR自动评论到@claude交互 的企业内部版。
👉 下一篇： 云端代码审查服务搭建：从PR自动评论到@claude交互
思考题（自测理解）
本地是家，云端是办公室。聪明的工程师知道什么时候在家工作，什么时候去办公室。下一篇，我们将把办公室搬到自己的服务器上。
