高手进阶（二）：Claude Code Routines 完整指南：定时/API/GitHub 三种触发方式深度解析与 DeepSeek 替代方案

Routines 云端自动化——让 Claude Code 在关机后继续干活

Windows 10/11 · Claude Code v2.1.x (2026-05) · Anthropic API · 🔴 研究预览期 · 最后更新 2026-05-06

一、这篇教程解决什么问题

一句话定位：前面所有教程都在讲"你打开终端，给 Claude 下指令，它干活"。这篇讲的是反过来的——你关机睡觉，Claude 自己定时爬起来干活，干完了把结果放在一个分支里等你第二天审查。

阅读前提：

Claude Code CLI 已安装并能正常启动（参考《新手上路（二）》）
拥有 Anthropic 付费账号（Pro/Max/Team/Enterprise），并已开通 Claude Code on the web
了解 Git 基础操作（commit / branch / PR）
了解 MCP Connectors 的概念（参考《新手上路（四）》）
使用 Windows 10 或 Windows 11

DeepSeek 用户注意：Routines 运行在 Anthropic 云端基础设施上，仅限 Anthropic API 用户。本文正文完整覆盖 Routine 全部功能，第七节提供 DeepSeek 用户的本地等效替代方案（cron + /loop + 自建触发），建议通读正文理解设计思路后再看替代方案。

读完能得到什么：

一张三层调度体系对比表，一眼看清 Routines / Desktop 本地任务 / /loop 各自适用场景
掌握三种触发方式的完整配置：定时触发、API 触发、GitHub Webhook 触发
三个开箱即用的实战 Prompt 模板（Issue 自动分类 / CI 失败自动修 / 文档漂移检测）
理解无人审批模式下的 Prompt 写法精要——为什么必须精确到"完成标准是什么"
掌握配额体系（Pro 5次/天、Max 15次/天、Team/Enterprise 25次/天）和成本控制方法
理解安全边界：claude/ 分支策略、环境变量隔离、Token 权限范围
DeepSeek 用户可落地的本地替代方案（cron + /loop + webhook receiver）
5 个真实 Debug 场景的五段式排查

二、为什么需要云端代理：单机串行的天花板

在进入配置之前，先回答一个根本问题：为什么需要 Routines？

2.1 你现在的 Claude Code 工作流

打开终端 → 输入指令 → Claude 干活 → 等结果 → 审查 → 合并 → 循环

三个硬伤：

你在的时候Claude才干活：Claude 不会自己启动——凌晨的依赖扫描、早上的 Issue 分类，要么你起床干，要么不干
一次只能盯一件事：串行循环，不能同时审 5 个 PR、边改代码边盯测试
终端一关全没：/loop 和 cron 任务依赖终端进程存活，笔记本合上就死

2.2 Routine 的工作流

定义 Routine（Prompt + 仓库 + 触发器）→ 触发点火 → 云端 clone 仓库 →
Claude 全自动执行 → 结果推到 claude/ 分支 → 你审查合并

关键区别：Routine 在 Anthropic 云端基础设施上运行，clone 你的仓库，使用你配置的 MCP Connectors，执行完成后把结果推到 claude/ 前缀的专用分支。不依赖你的机器开机。

2.3 Claude Code 三层调度体系对比

这是理解 Routines 定位的全局视图：

维度	Routines（云端）	Desktop 本地定时任务	`/loop`（会话内循环）
运行位置	Anthropic 云端基础设施	你的机器	你的机器
需要机器开机	否	是	是
需要会话保持	否	否	是（终端关 = 任务死）
持久化	云端账号持久化	本地持久化	会话级（`--resume` 可恢复未过期任务）
文件访问	从 GitHub 全新 clone	本地文件系统	当前工作目录
MCP Connectors	每个 Routine 独立配置	继承配置文件	继承当前会话
权限审批	无（全自动执行）	可配置	继承当前会话
调度方式	定时/API/GitHub 事件	定时	定时/手动
最小间隔	1 小时	1 分钟	1 分钟
自动过期	否	否	7 天
触发器类型	Cron / HTTP POST / GitHub Events	Cron	Cron / 手动调用

一句话选型指南：

关机后也要跑的定时任务 → Routines（唯一选择）
需要本地文件访问的定时任务 → Desktop 本地任务
盯着一个部署、等一个构建结果 → /loop（临时轮询，最轻量）
外部系统需要触发 Claude 干活 → Routines API 触发（唯一选择）
GitHub 事件驱动（有人提 PR → 自动审查） → Routines GitHub 触发

三、三种触发方式详解

Routine 是一个保存的配置单元——包含 Prompt、关联仓库、云环境和 Connectors。触发器是点火方式，一个 Routine 可以同时绑定三种触发器。

创建 Routine 的三种路径：

路径	入口	能力
Web UI	`claude.ai/code/routines`	全功能：定时 + API + GitHub，环境变量管理
CLI	`/schedule`	仅定时触发，创建后可去 Web 补充其他触发器
Desktop App	侧边栏 → Routines → New Routine → Remote	与 Web UI 等价

用 CLI 创建第一个定时 Routine：

/schedule daily PR review at 9am

Claude 会走对话式配置流程：名称 → Prompt → 关联仓库 → 云环境 → 触发频率（本地时区自动转换）。创建后到 claude.ai/code/routines 可补充 API 或 GitHub 触发器。

3.2 定时触发（Scheduled）

适用场景：周期性、可预见的重复任务。

预设频率：每小时 / 每天 / 工作日（周一至周五） / 每周

自定义 Cron：从 CLI 用 /schedule update 设置标准 5 段式 cron 表达式。最小间隔 1 小时，子小时级表达式（如 */30 * * * *）会被拒绝。

时区处理：你在表单里输入的时间是你的本地时区。Routine 在云端自动转换为 UTC，保证在你设定的墙上时钟时间执行，与服务器所在位置无关。执行时间可能有几分钟的偏移（stagger），这是正常的负载均衡行为。

典型任务示例：

频率	任务	Prompt 概述
每工作日 9:00	Issue 自动分类	扫描昨晚新增 Issue → 按标签分类 → 分配负责人 → 发 Slack 汇总
每天 2:00	依赖更新检查	`npm outdated` / `pip list --outdated` → 分析 changelog → 草稿 PR
每周一 10:00	文档漂移检测	对比本周合并的 PR 与文档 → 标记文档中引用了已变更 API 的位置

3.3 API 触发

适用场景：外部系统需要"召唤"Claude 干活。监控系统告警、CI 失败、部署脚本——任何能发 HTTP POST 的系统都可以触发 Routine。

配置步骤：

在 Web UI 编辑 Routine → Add another trigger → 选择 API
保存后，系统生成专用 URL 和 Bearer Token
Token 只显示一次，立即存到密钥管理工具（环境变量、AWS Secrets Manager、1Password 等）
生成新 Token 会自动吊销旧 Token

调用示例——Datadog 告警触发 Claude 分析 trace：

curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxxxxxxxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521: /api/checkout error rate > 5%. Env: prod-us-east-1. Stack trace: ..."}'

响应：

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

返回的是一个会话 URL。打开它可以看到 Claude 正在执行的每一步：clone 仓库、读取日志、分析 trace、创建修复分支。你不必守在旁边，想看了就点进去。

text 字段的设计哲学：这个字段是自由格式字符串，不做解析。你传 JSON、纯文本、日志片段，Claude 都原样收到。关键是在 Prompt 里明确告诉 Claude "text 字段里是什么格式、你该怎么处理它"。这个字段最大 65,536 字符。

API 版本说明：/fire 端点标记为 experimental-cc-routine-2026-04-01 beta。这是 Anthropic 的带版本 beta header 机制——当 API 有破坏性变更时，会发布新的带日期 beta header，最近两个版本继续可用，给你迁移窗口。

必须的四个 HTTP Header：

Header	值	说明
`Authorization`	`Bearer sk-ant-oat01-...`	Routine 专属 Bearer Token（非 API Key）
`anthropic-beta`	`experimental-cc-routine-2026-04-01`	研究预览期必传
`anthropic-version`	`2023-06-01`	API 版本
`Content-Type`	`application/json`	有 body 时必传

GitHub Actions 中触发 Routine（CI 失败时自动呼叫 Claude）：

- if: failure()
  env:
    ROUTINE_FIRE_URL: ${{ secrets.ROUTINE_FIRE_URL }}
    ROUTINE_FIRE_TOKEN: ${{ secrets.ROUTINE_FIRE_TOKEN }}
  run: |
    curl -X POST "$ROUTINE_FIRE_URL" \
      -H "Authorization: Bearer $ROUTINE_FIRE_TOKEN" \
      -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
      -H "anthropic-version: 2023-06-01" \
      -H "Content-Type: application/json" \
      -d "{\"text\": \"CI failed: $GITHUB_WORKFLOW run $GITHUB_RUN_ID on $GITHUB_REF\"}"

3.4 GitHub Webhook 触发

适用场景：GitHub 仓库事件驱动。有人往 /auth 模块提 PR → 自动触发安全审查并评论；有人提 Issue → 自动分类标签。

前置条件（两个独立步骤）：

在 CLI 运行 /web-setup → 授权仓库 clone 权限
在 Web UI 配置 GitHub 触发器时 → 安装 Claude GitHub App（/web-setup 不会自动安装这个 App）

最常见的坑：只做了第 1 步，发现 GitHub 触发器不工作。两个步骤互不包含，必须都完成。

支持的事件类型（在 /routine 配置时可选）：

事件类别	具体事件
Pull Request	opened, closed, assigned, labeled, synchronized
Pull Request Review	submitted, edited, dismissed
Pull Request Review Comment	created, edited, deleted
Push	Commits pushed to a branch
Release	created, published, edited, deleted
Issues	opened, edited, closed, labeled
Issue Comment	created, edited, deleted
Check Run	created, requested, rerequested, completed
Check Suite	completed, requested
Workflow Run	started, completed
Workflow Job	queued, completed
Discussion	created, edited, answered
Discussion Comment	created, edited, deleted
Commit Comment	created
Merge Queue Entry	PR enters or leaves merge queue
Repository Dispatch	Custom `repository_dispatch` event

过滤器：可以按 base_branch、draft 状态、标签等过滤。只有全部过滤条件都匹配时才会触发。正确配置过滤器是控制配额消耗的关键——把 Routine 绑到 push 事件且不加过滤，活跃仓库可能在上午就耗尽一天的配额。

行为细节：

每个匹配事件启动一个独立新会话，事件间不共享状态
每个会话可以继续接收同一个 PR 的后续更新（评论、CI 结果），做出响应
研究预览期，GitHub 事件有每 Routine 每小时容量上限，超出的事件被丢弃
一小时最小间隔限制不适用于 GitHub 触发器——它按事件驱动，不受 cron 间隔约束

四、三个完整实战案例

4.1 案例一：Issue 自动分类 + 分配 + Slack 汇总

Routine 配置：

名称：nightly-issue-triage
触发器：定时（每工作日 8:00，Asia/Shanghai）
仓库：your-org/your-project
Connectors：GitHub（Issue 读写）、Slack（消息发送）
云环境：包含 SLACK_WEBHOOK_URL 的环境变量

Prompt 模板：

你是一个 Issue 分类助手。每天早上执行以下流程：

## 步骤
1. 用 GitHub connector 拉取昨天 18:00 至今所有新建 Issue
2. 对每个 Issue，按以下规则分类并打标签：
   - bug 报告（含报错、异常行为描述）→ label: bug
   - 功能请求（含"希望""建议""能否"）→ label: enhancement
   - 使用问题（含"怎么""如何""为什么"）→ label: question
   - 文档相关（含"文档""说明""示例"）→ label: documentation
3. 按以下规则分配负责人：
   - bug → 查看文件路径，用 git log 找最近修改该文件的人
   - enhancement → 分配给 @pm-lead
   - question → 分配给 @dev-support
4. 检测以下情况并标记为高优先级：
   - 标题含"崩溃""报错""500""502""panic""crash"
   - 正文含安全相关词汇
5. 生成 Slack 消息，发送到 #eng-standup 频道：

## Slack 消息格式
:robot_face: *今日 Issue 自动分类报告*（{日期}）
- 新增 Issue: {总数}
- :bug: Bug: {数量}（高优先级 {数量}）
- :sparkles: Enhancement: {数量}
- :question: Question: {数量}
- :book: Documentation: {数量}
详情链接: {GitHub issues URL}

## 完成标准
- 所有 Issue 都已打标签和分配负责人
- 高优先级 Issue 已在标题加 :rotating_light: emoji
- Slack 消息已成功发送

执行流程：Routine 定时点火 → Claude clone 仓库 → 通过 GitHub Connector 读取 Issue → 分析内容 → 打标签 → 分配 → 通过 Slack Connector 发送汇总消息

4.2 案例二：CI 失败自动分析 + 修复 PR

Routine 配置：

名称：ci-failure-autofix
触发器：API（CI pipeline 失败时 POST 调用）
仓库：your-org/your-project
Connectors：GitHub（PR 读写、文件写入）
云环境：包含 GITHUB_TOKEN（有写权限）

Prompt 模板：

你是一个 CI 故障自动分析和修复助手。text 字段包含失败的 CI 日志。

## 分析流程
1. 解析 text 字段，提取：
   - 失败的测试名称和行号
   - 错误类型（编译错误、测试断言失败、超时、lint 报错）
   - 涉及的源文件路径
2. 检查最近 24 小时内的 git log，找出可能引入错误的 commit
3. 按优先级处理：
   - 编译错误 → 读取报错文件和依赖 → 修复语法/类型问题
   - 测试断言失败 → 读取测试和被测代码 → 判断是代码 bug 还是测试需更新
   - 超时 → 分析是否可优化，或者只是 runner 波动（标记为 flaky）
   - lint 报错 → 直接修复
4. 将修复推送到 claude/auto-fix-ci-{run_id} 分支
5. 创建 Draft PR，描述修改内容和修复理由

## 不要做的事
- 不要修改 CI 配置文件（.github/workflows/）
- 不要修改 package.json / requirements.txt 等依赖声明文件
- 不要 force push
- 遇到不确定的修复，在 PR 描述中标注"⚠️ 不确定，请人工审查"

## 完成标准
- 修复分支已推送到 claude/ 前缀
- Draft PR 已创建，包含完整的修复说明

调用链：GitHub Actions workflow 失败 → if: failure() 触发 curl → POST 到 /fire 端点 → Claude 分析日志 → 修复 → 创建 Draft PR

4.3 案例三：文档与代码同步检测

Routine 配置：

名称：docs-drift-detector
触发器：定时（每周一 10:00）
仓库：your-org/docs + your-org/main-codebase（关联两个仓库）
Connectors：GitHub（PR 读写）

Prompt 模板：

你是文档漂移检测器。每周扫描一次主代码仓库中合并的 PR，检查对应文档是否需要更新。

## 扫描规则
1. 从主代码仓库拉取上周合并到 main 的所有 PR
2. 对每个 PR，提取：
   - 修改的函数/类/API 签名
   - 新增的 public API
   - 废弃（deprecated）的接口
   - 变更的环境变量或配置项
3. 在文档仓库中全文搜索这些 API 名称
4. 标记漂移：
   - 代码有但文档没有的 → "缺失文档"
   - 代码已改但文档描述未变 → "文档过时"
   - 代码已删除但文档仍有引用 → "幽灵文档"

## 输出
- 生成 docs-drift-report-{日期}.md，列出所有漂移项
- 如果漂移项 > 5，向 #docs 频道发送 Slack 提醒
- 对每个漂移项，创建独立的文档更新 Issue

## 完成标准
- 报告已推送到 claude/ 分支
- 每个严重漂移项（API 签名变更未更新文档）已创建 Issue

五、Prompt 写法精要：无人审批模式下的 Prompt 设计

Routine 执行时没有任何审批提示——没有人会点"Allow"按钮。这让 Prompt 的写法变得至关重要。

5.1 三条核心原则

原则一：明确"完成标准"，而非"做事方法"

❌ 差：检查代码质量
✅ 好：用 ESLint 扫描 src/ 目录，找出所有 error 级别的警告，
       对每个警告生成修复建议，输出为 markdown 表格列出文件路径+行号+建议

Routine 不像交互式会话可以追问"具体怎么检查？"。你必须一次性说清楚交付物是什么。

原则二：划定"不要做什么"比"要做什么"更重要

你不应该做的事：
- 不要修改 main 分支（你只能推到 claude/ 前缀分支）
- 不要修改 CI 配置（.github/workflows/*.yml）
- 不要 force push
- 不要在没有理解错误原因的情况下提交修复
- 遇到不确定的情况，标注"需要人工审查"而非猜测式修复

在无人值守模式下，负面约束往往比正面指令更能防止灾难。

原则三：给 Claude 足够的上下文，但不要超过它需要的

✅ 好：分析昨天下午 6 点到今天早上 9 点之间的新 Issue
✅ 好：使用 project/scripts/analyze_logs.py 解析日志文件，不要自己写正则
❌ 差：分析近期的 Issue（"近期"没有定义，Claude 会猜测）
❌ 差：把 README.md 全文贴在 Prompt 里（routine 执行时会 clone 仓库，可以直接读文件）

5.2 Prompt 模板结构

## 角色
你是一个 [具体角色描述]

## 触发时收到的信息
- text 字段包含：[格式说明]（仅 API 触发）
- 触发器类型：[schedule/api/github]

## 步骤
1. [步骤 1 + 使用的工具/Connector]
2. [步骤 2]
3. [步骤 3]

## 输出
[具体的交付物格式和存放位置]

## 不要做的事
- [约束 1]
- [约束 2]

## 完成标准
- [可验证的标准 1]
- [可验证的标准 2]

5.3 环境变量 vs Prompt：敏感信息放在哪里

永远不要在 Prompt 里写密钥。Prompt 在 Web UI 和 .claude/routines/ 文件中是明文可见的。API 密钥、Token、Webhook URL 等敏感信息放在云环境变量中：

# 正确做法
1. 在 claude.ai/code/environments 创建自定义环境
2. 添加环境变量：DATADOG_API_KEY=sk-xxxx, SLACK_WEBHOOK_URL=https://...
3. 在 Routine 配置中选择这个环境
4. Prompt 里写"使用环境变量中的 DATADOG_API_KEY"

# 错误做法
❌ Prompt 里写：用 API Key sk-xxxx 调用 Datadog API

六、配额、成本与安全边界

6.1 每日 Routine 运行次数限制

计划	每日 Routine 运行次数
Pro（$20/月）	5 次
Max 5x（$100/月）	15 次
Max 20x（$200/月）	15 次
Team（Premium）	25 次
Enterprise	25 次

超出后行为：取决于你的计划配置。部分计划开启 extra usage 后按 API 标准费率计价超出部分。配额每天重置，可在 claude.ai/code/routines 查看重置时间。

注意：Routine 消耗的 Token 与你的交互式 Claude Code 会话共享同一个使用额。如果你白天已经在用 Claude Code 大量编码，晚间 Routine 会叠加在已有消耗之上。

6.2 GitHub 触发器的额外配额

研究预览期内，GitHub Webhook 事件有每 Routine 每小时容量上限。超出的事件被丢弃，不会排队。如果计划把 Routine 绑到 push 等高频事件上：

先设严格过滤器（只匹配特定分支、特定路径）
观察一周实际触发量
考虑用定时 Routine + 汇总式扫描替代事件式触发

6.3 成本估算

以 Max 5x 计划为例，15 次/天 × 30 天 = 450 次 Routine 执行/月。每次 Routine 执行本质上是启动一个 Claude Code 云端会话，Token 消耗取决于任务复杂度：

任务复杂度	典型 Token 消耗	约合费用
Issue 分类（轻量）	2,000-5,000	~$0.01-0.05（Sonnet）
CI 失败分析（中等）	10,000-30,000	~$0.10-0.45（Opus）
文档漂移扫描（重量）	30,000-80,000	~$0.30-1.20（Opus）

6.4 安全边界

分支策略：Claude 在云端 clone 仓库的默认分支，所有修改推送到 claude/ 前缀专用分支，不能直接 push main/master。你审查后手动合并。

环境变量隔离：API Key / Token 存在云环境配置中，Prompt 不可见。每个 Routine 可选不同云环境实现权限隔离，网络访问可限制特定域名。

Token 安全：API 触发 Token 前缀 sk-ant-oat01-，与 API Key（sk-ant-api03-）不同。作用域仅限单个 Routine，不可跨 Routine。生成新 Token 自动吊销旧 Token，Token 只展示一次。

身份归属：Routine 以你的身份运行——Slack 消息、GitHub PR 都显示为你提交。团队使用时需留意：同事看到的"凌晨 3 点的 PR"实际上是 Routine 干的。

七、DeepSeek 用户替代方案

Routines 仅限 Anthropic API 用户。但"云端定时自动化"这个需求本身是通用的。以下是为 DeepSeek 用户设计的本地等效方案。

7.1 方案对比

需求	Routines 的做法	DeepSeek 替代方案
定时任务	云端 Cron + cloud clone	Windows Task Scheduler + Claude Code CLI（`-p` 模式）
外部系统触发	POST `/fire` 端点	自建简单 HTTP Server 接收 webhook → 调用 Claude Code
GitHub 事件响应	Claude GitHub App + Webhook	GitHub Actions workflow + Claude Code CLI
结果自动推送	原生 GitHub Connector	`gh pr create` 或 API 调用

7.2 方案一：Windows Task Scheduler + Claude Code Headless 模式

原理：用 Windows 自带的任务计划程序定时执行 Claude Code 的 -p（非交互/print）模式。

Step 1：编写自动化脚本

创建 C:\Users\<用户名>\claude-routines\nightly-issue-triage.ps1：

# nightly-issue-triage.ps1
$env:ANTHROPIC_API_KEY = "sk-你的DeepSeek-API-Key"
$env:ANTHROPIC_BASE_URL = "https://api.deepseek.com/anthropic"

$prompt = @"
你是一个 Issue 分类助手。请执行以下任务：
1. 用 gh CLI 拉取当前仓库昨天 18:00 至今所有新建 Issue
   gh issue list --repo your-org/your-project --search "created:>=YYYY-MM-DD" --json number,title,labels,author --limit 50
2. 对每个 Issue 按 bug/enhancement/question/documentation 分类
3. 用 gh issue edit 打标签和分配负责人
4. 生成汇总 Markdown 报告，保存为 triage-report-YYYY-MM-DD.md
5. 用 gh pr create 将报告提交为 Draft PR

不要在未经分析的情况下修改任何代码文件。
遇到不确定的分类标注为 "needs-triage"。
"@

$prompt | claude -p --model deepseek-v4-pro --output-format text --max-turns 30 `
    --allowedTools "Bash" `
    2>&1 | Out-File -FilePath "C:\Users\$env:USERNAME\claude-routines\logs\triage-$(Get-Date -Format 'yyyy-MM-dd').log"

Step 2：配置 Windows Task Scheduler

# 注册 Windows 定时任务：每天 8:00 执行
$trigger = New-ScheduledTaskTrigger -Daily -At 8:00AM
$action = New-ScheduledTaskAction -Execute "powershell.exe" `
    -Argument "-File C:\Users\<用户名>\claude-routines\nightly-issue-triage.ps1"
Register-ScheduledTask -TaskName "ClaudeNightlyIssueTriage" `
    -Trigger $trigger -Action $action

优缺点：✅ DeepSeek 极低 API 成本 · ✅ 可访问本地文件 · ❌ 电脑必须开机联网 · ❌ 无 Slack/GitHub 原生 Connector

7.3 方案二：替代 API 触发——自建 Webhook Receiver

当监控系统发出告警时，需要自动触发 Claude 分析。核心思路是用 GitHub Actions 或系统 cron 定期轮询告警源的状态，避免自建 HTTP Server 的安全和维护负担。以 Sentry 为例：

# sentry-poll.ps1 — 每 5 分钟轮询 Sentry API，发现新告警自动分析
$env:ANTHROPIC_API_KEY = "sk-你的DeepSeek-API-Key"
$env:ANTHROPIC_BASE_URL = "https://api.deepseek.com/anthropic"

$alerts = Invoke-RestMethod -Uri "https://sentry.io/api/0/projects/org/project/issues/?statsPeriod=5m" `
    -Headers @{Authorization = "Bearer $env:SENTRY_TOKEN"}

if ($alerts.Count -gt 0) {
    $alerts | ConvertTo-Json | claude -p `
        "你是告警分析助手。上面是近 5 分钟 Sentry 告警 JSON。分析根因并生成修复建议。不要修改任何文件。" `
        --model deepseek-v4-pro --max-turns 20 `
        2>&1 | Out-File -FilePath "C:\Users\$env:USERNAME\claude-routines\logs\alert-$(Get-Date -Format 'yyyy-MM-dd-HHmmss').log"
}

安全警告：API Token 存放在环境变量中，绝对不要硬编码在脚本里。

7.4 方案三：GitHub Actions 替代 GitHub Webhook 触发

# .github/workflows/claude-auto-review.yml
on:
  pull_request:
    types: [opened, synchronize]
    paths: ['src/auth/**', 'src/middleware/**']

jobs:
  auto-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - env:
          ANTHROPIC_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
          ANTHROPIC_BASE_URL: https://api.deepseek.com/anthropic
        run: |
          claude -p "Review this PR diff. Focus on auth security, error handling, validation." \
            --model deepseek-v4-pro --max-turns 25 --output-format text

7.5 `/loop` 替代定时 Routine

对于不要求机器关机的定时任务，/loop 是最轻量的选择：

# 在 Claude Code 会话中输入
/loop 60m 检查部署状态，如果发现错误率超过 1% 就通知我

/loop 的限制：

终端必须保持打开且 Claude Code 处于空闲状态
每隔 7 天自动过期，需要重建
错过触发时间不补做（missed fire = skipped，不排队）
一个会话最多 50 个定时任务

八、5 个真实 Debug 场景

Debug 1：GitHub 触发器不触发

报错：配置了 GitHub Webhook 触发，但 PR 提交后 Routine 没有任何反应

根因：只运行了 /web-setup 授权 clone，但没有安装 Claude GitHub App。/web-setup 只给 clone 权限，webhook 推送需要单独安装 App。

关键对比：

步骤	作用	是否为 GitHub 触发器的前提
`/web-setup`	授权 Claude Code 克隆你的仓库	是
安装 Claude GitHub App	接收 GitHub webhook 事件推送到 Routine	是（独立步骤）

修复：

进入 claude.ai/code/routines → 编辑 Routine → GitHub trigger 设置
如果提示安装 Claude GitHub App，完成安装
在 GitHub 仓库 Settings → GitHub Apps 中确认已安装

验证：在受监控的仓库创建一个测试 PR，确认 Routine 页面显示新的执行记录

Debug 2：API 触发返回 400 空响应

报错：

{"type": "error", "error": {"type": "invalid_request_error", "message": "Missing required header: anthropic-beta"}}

根因：缺少必需的 HTTP Header。/fire 端点要求四个 Header 缺一不可。

请求对比：

元素	错误请求	正确请求
Authorization	✅ Bearer sk-ant-oat01-xxx	✅ Bearer sk-ant-oat01-xxx
anthropic-beta	❌ 缺失	✅ `experimental-cc-routine-2026-04-01`
anthropic-version	❌ 缺失	✅ `2023-06-01`
Content-Type	✅ application/json	✅ application/json

修复：确保 curl 命令包含全部四个 Header。如果用的是脚本/工具（Postman、Python requests），逐项核对。

验证：重新发送请求，应返回 200 和 claude_code_session_url

Debug 3：Routine 执行超时，没有输出

报错：Routine 执行记录显示 "completed"，但没有产生任何文件变更或输出

根因：Prompt 过于模糊，Claude 不确定"完成标准"是什么，在细节上反复兜圈后自行判定"已完成"。这是无人审批模式下最常见的问题。

错误 Prompt vs 正确 Prompt：

方面	错误写法	正确写法
任务描述	"检查代码质量"	"用 ESLint 扫描 src/，找出 error 级别问题，每个生成修复建议"
完成标准	未定义	"生成 report.md 并推送到 claude/ 分支"
负面约束	未定义	"不要修改任何 .js/.ts 文件，只输出报告"
数据来源	"看最近的 Issue"	"用 gh issue list 拉取昨天 18:00 至今的 Issue"

修复：重构 Prompt，补充明确的完成标准和输出格式。参考第五节 Prompt 模板。

验证：在 Web UI 点击 "Run now" 手动触发一次，观察执行日志确认每步都按预期执行

Debug 4：配额耗尽，Routine 被跳过

报错：计划中的 Routine 在某个时间点后没有执行记录

根因：达到每日 Routine 运行次数上限或 GitHub 事件每小时容量上限。

排查步骤：

到 claude.ai/code/routines 查看当前周期使用量
如果 GitHub 触发器频繁点到 push 事件，考虑加过滤器
如果定时 Routine 之间间隔太近，叠加执行可能导致超限

修复：

Pro 用户：考虑升级到 Max 5x（5次/天 → 15次/天）
所有用户：给 GitHub 触发器加路径过滤（如只监听 src/auth/** 的 PR）
将高频事件触发改为定时扫描（从 "每个 push 触发" 改为 "每小时汇总扫描一次"）

验证：在 Routine 列表中查看 "Runs today" 计数，确认在配额内

Debug 5：API 触发 Token 丢失，无法调用

报错：

{"type": "error", "error": {"type": "authentication_error", "message": "Invalid bearer token"}}

根因：Token 生成时只显示一次，事后生成新 Token 会自动吊销旧 Token，但调用方还在用旧 Token。

修复：

到 Web UI 编辑 Routine → API trigger → Generate new token
立即复制新 Token 到密钥管理工具
更新所有调用方的 Token 值
旧 Token 自动失效

验证：用新 Token 发送测试请求，确认返回 200 和 session URL

九、速查卡

9.1 路径与命令速查

分类	路径/命令
Routine Web 管理	`claude.ai/code/routines`
云环境管理	`claude.ai/code/environments`
CLI 创建定时 Routine	`/schedule`
CLI 列出 Routine	`/schedule list`
CLI 更新 Routine	`/schedule update`
CLI 手动执行	`/schedule run`
API 端点格式	`POST https://api.anthropic.com/v1/claude_code/routines/{trig_id}/fire`
Token 前缀	`sk-ant-oat01-`（Routine 专用，非 API Key）

9.2 配额速查

计划	每日 Routine 运行	月费
Pro	5	$20
Max 5x	15	$100
Max 20x	15	$200
Team Premium	25	$100/seat
Enterprise	25	定制

9.3 报错映射

报错关键字	原因	看哪
`invalid_request_error` + `anthropic-beta`	缺少必需 Header	Debug 2
`authentication_error` + `Invalid bearer token`	Token 过期/错误	Debug 5
`rate_limit_error` + `Retry-After`	配额超限	Debug 4
`permission_error`	账号/计划不支持	确认已开通 Claude Code on the web
GitHub 触发器不工作	未安装 Claude GitHub App	Debug 1
Routine 执行了但没产出	Prompt 过于模糊	Debug 3

9.4 三层调度体系速查

场景	工具	一句话
关机后定时执行	Routines（云端）	唯一选择
需要本地文件的定时任务	Desktop 定时任务	机器必须开机
临时盯一个部署/构建	`/loop`	终端开着就行
外部系统触发 Claude	Routines API	任何能 POST 的系统
PR 自动审查	Routines GitHub 触发	原生事件驱动

十、扩展阅读

高手进阶（一）：Claude Code 五端完整指南 — Desktop App 中配置本地定时任务的详细步骤
高手进阶（六）：Headless 模式与 CI/CD 集成 — CI 管道中嵌入 Claude Code 的完整方案，与 Routines 互补
新手上路（四）：MCP 协议实战 — MCP Connectors 配置，Routine 依赖 Connectors 访问外部服务
新手上路（五）：Hooks 进阶 — Hooks 与 Routine 的自动化边界区别

高手进阶（二）：Claude Code Routines 完整指南：定时/API/GitHub 三种触发方式深度解析与 DeepSeek 替代方案

Routines 云端自动化——让 Claude Code 在关机后继续干活

一、这篇教程解决什么问题

二、为什么需要云端代理：单机串行的天花板

2.1 你现在的 Claude Code 工作流

2.2 Routine 的工作流

2.3 Claude Code 三层调度体系对比

三、三种触发方式详解

3.2 定时触发（Scheduled）

3.3 API 触发

3.4 GitHub Webhook 触发

四、三个完整实战案例

4.1 案例一：Issue 自动分类 + 分配 + Slack 汇总

4.2 案例二：CI 失败自动分析 + 修复 PR

4.3 案例三：文档与代码同步检测

五、Prompt 写法精要：无人审批模式下的 Prompt 设计

5.1 三条核心原则

5.2 Prompt 模板结构

5.3 环境变量 vs Prompt：敏感信息放在哪里

六、配额、成本与安全边界

6.1 每日 Routine 运行次数限制

6.2 GitHub 触发器的额外配额

6.3 成本估算

6.4 安全边界

七、DeepSeek 用户替代方案

7.1 方案对比

7.2 方案一：Windows Task Scheduler + Claude Code Headless 模式

7.3 方案二：替代 API 触发——自建 Webhook Receiver

7.4 方案三：GitHub Actions 替代 GitHub Webhook 触发

7.5 /loop 替代定时 Routine

八、5 个真实 Debug 场景

Debug 1：GitHub 触发器不触发

Debug 2：API 触发返回 400 空响应

Debug 3：Routine 执行超时，没有输出

Debug 4：配额耗尽，Routine 被跳过

Debug 5：API 触发 Token 丢失，无法调用

九、速查卡

9.1 路径与命令速查

9.2 配额速查

9.3 报错映射

9.4 三层调度体系速查

十、扩展阅读

参考文献

7.5 `/loop` 替代定时 Routine