如何在 14 个步骤内让 Claude 自动运行：/loop、Routines 以及完整的自动化技术栈。

你每个月花 20–200 美元 买 Claude，却只把它当个付费版 ChatGPT 用。10 个人里 9 个 都没设置过能自动运行、不用自己点按钮的自动化流程。

没有 /loop，没有 定时任务，没有 Routines，没有 触发器。本该在你睡觉时干活儿的工具，却还在 等着你打字。这份 14 步路线图带你摸透完整的自动化体系——以及每周省出来的大把时间。

订阅我的 Substack 获取最新 AI 动态：

movez.substack.com

过去三个月，Claude Code 一直在默默构建一整套自动化体系。/loop 已经发布。

Auto Mode 于 3 月 24 日上线。Cloud Routines 于 4 月 14 日进入研究预览。到 2026 年 5 月，整个图景已经清晰：三层自动化，从你的终端直达 Anthropic 云端，每一层都解决了一个让你离不开屏幕的理由。

这就是覆盖全部三个层次的 14 步路线图——所有细节均已对照 code.claude.com/docs 的官方文档核实，截至 2026 年 6 月有效。整条路径很简单：先搞定手动循环，让它跨会话持久化，然后推送到云端，这样你的笔记本就不再是瓶颈。

14 步。3 个层次。一个在你睡觉时也在工作的 Claude。

01. /loop 命令。明示和自然语言都有效。

让 Claude Code 定时干任何活儿最快的方法。在任何会话中，运行 /loop <间隔> <提示词>。

底层调用三个原生工具：CronCreate、CronList、CronDelete。间隔使用数字加单位：m 代表分钟，h 代表小时，d 代表天。最短间隔是 1 分钟——30 秒会自动向上取整。

1> /loop 1m say hello
2
3▲ Claude
4  CronCreate(*/1 * * * * : say hello)
5✓ 已调度 c21d95a0 (每分钟)
6  - 任务: say hello
7  - 频率: 每分钟 (*/1 * * * *)
8  - 任务 ID: c21d95a0
9  - 持续时间: 重复任务 7 天后自动过期
10  - 随时取消: CronDelete c21d95a0

你其实根本不需要手动输入 /loop。Claude 对自然语言的时间安排同样理解得很好：

• 每 10 分钟，检查一次部署状态
• 每个工作日上午 7 点，总结昨晚的提交
• 今天下午 6:30，在 Slack 上发一条状态更新

时间使用本地机器的时区，而不是 UTC。Claude Code 中可用的任何斜杠命令都可以放在 /loop 里——包括 /run、/review，甚至如果你想玩点花的，再嵌套一个 /loop 也行。

02. 真正的 cron 表达式，做真正的定时任务。

CronCreate 工具接受标准的 5 字段 cron 表达式：分钟 小时 日 月 星期。所有字段都支持通配符（\）、单个值（5）、步长（\/15）、范围（1-5）和逗号分隔列表（1,15,30）。星期字段用 0 或 7 表示周日，1-6 表示周一到周六。

不支持的语法： L（最后一天）、W（工作日）、? 或者 MON、JAN 这类名称别名。当日和星期同时有限制时，只要 任意一个 字段匹配就算匹配——这是标准的 vixie-cron 语义。

值得记住的 cron 模式：

1# 那些真正有用的 cron 模式
2
3# 每 5 分钟（仅工作时间）
4*/5 9-17 * * 1-5
5
6# 每个工作日上午 7 点
70 7 * * 1-5
8
9# 每月第一天上午 9 点
100 9 1 * *
11
12# 每 15 分钟
13*/15 * * * *
14
15# 每天凌晨 2:30
1630 2 * * *
17
18# 每周五下午 4 点
190 16 * * 5
20
21# 每 6 小时整点
220 */6 * * *

03. 自动过期与停止条件

四个硬性限制，决定了 /loop 是否适合当前任务。记住它们，不然回头就得花时间自己摸索：

• 7 天自动过期。 每个重复任务在创建 7 天后会自动删除。任务会执行最后一次，然后自行移除。这限制了遗忘的循环能跑多久。如果需要它活得更久，请在截止前取消并重新创建——或者使用 Routines（第 10 步）。
• 每个会话最多 50 个任务。 对于个人工作流来说绰绰有余。如果你在构建更复杂的东西，请务必计数；直到撞墙你才会收到警告。
• 没有补跑机制。 如果任务到期时 Claude 正忙于处理一个长时间运行的请求，它会在 Claude 恢复空闲时 执行一次，而不是为每个错过的周期执行一次。一个 5 分钟的循环在一个 20 分钟的重构期间命中，之后只会触发一次，而不是四次。
• 绑定会话。 关闭终端会取消所有任务。重新启动 Claude Code 会清除所有已调度的任务。没有跨会话的持久化——这就是第 2 层和第 3 层存在的意义。

要在会话中列出和取消任务，直接用自然语言提问就行——Claude 会路由到 CronList 和 CronDelete：

1> 显示正在运行的 cron 任务
2
3▲ CronList()
4   ID         任务                       频率
5   c21d95a0   say hello                 每分钟
6   8f3aa412   check deploy status       每 10 分钟
7   bb7c0d91   morning summary           0 7 * * 1-5
8
9> 取消部署状态检查
10
11▲ CronDelete(8f3aa412)
12✓ 已取消。还剩 2 个任务。

对于不希望后台调度运行的 CI 环境或共享服务器，请在环境中设置 CLAUDE_CODE_DISABLE_CRON=1。cron 工具和 /loop 将不可用，任何已调度的任务也会停止触发。

对于任何运行 Claude 的用户并非计划所有者的环境，这都是正确的做法。

04. 将 /loop 与 /goal 结合使用

单独的 /loop 只是让 Claude 重复做某件事。而 /loop 配合 /goal 则是让 Claude 重复做某件事，直到满足特定条件——并且能在中间宣布“做得差不多了”之后继续循环。

这种组合解决了重复任务中 agent 的“懒惰”问题。没有 /goal，一个循环可能处理了它本应处理的 50 项中的 20 项，然后就说剩下的“处理好了”。有了 /goal，停止条件是明确且强制的：

1A /loop on its own asks Claude to do something repeatedly.
2A /loop paired with /goal asks Claude to do something repeatedly until a specific condition is met — and to keep looping past intermediate “done enough” declarations.
3
4This pairing solves agentic laziness inside a recurring task.
5Without /goal, a loop might address 20 of the 50 items it’s meant to handle and call the rest “handled.” With /goal, the stop condition is explicit and enforced:

这种组合最值得使用的三种场景：

• 不稳定测试调试。 复现问题，提出假设，验证假设，直到找到根本原因。
• 长时间运行的迁移。 处理数据项，保存进度，继续处理，直到队列清空。
• 收件箱式分类处理。 处理待办项，继续处理，直到一个完整周期内没有新内容出现。

四步走，你就能拥有一个可用的手动循环。现在，让它能在重启后存活。

05. 桌面端定时任务。

Claude 桌面应用有自己的调度器，与 CLI 的 /loop 是分开的。通过 Schedule → New task → New local task 创建定时任务。

你可以定义名称、提示词、频率、权限和工作目录。每次触发都会启动一个全新的 Claude Code 会话——与其他任何内容都没有共享上下文。

这一层能提供 /loop 所不具备的能力：

• 重启后依然存活。 重启机器，关闭所有终端——任务到时间点仍然会触发。
• 每次触发都是全新的上下文。 没有上次运行的累积状态。每个任务本质上是独立的。
• 预配置权限。 允许的工具、工作目录、模型，每个任务都锁定。

它仍然需要的条件：你的机器必须处于唤醒状态。 如果任务触发时你的笔记本处于休眠状态，该次运行会被跳过。当机器唤醒或你重新打开 Claude Desktop 时，它会检查过去 7 天是否有错过的运行，为最近一次错过的时间点启动一次补跑，并显示一条通知。

要防止因空闲而休眠，请在桌面端设置的"通用"下启用保持电脑唤醒。合上笔记本电脑盖子仍然会触发休眠。

桌面端定时任务

仅支持 macOS 和 Windows

。Linux 用户有两个选择：(1) 使用 CLI 的 /loop 进行会话级调度，或 (2) 设置系统 cron 作业，以无头模式运行 claude -p <提示词> 进行持久化调度。Routines（第 10 步）适用于所有平台，因为它们在云端运行。

06. Token 预算和速率限制。

对于 Pro 套餐来说，最大的意外是：每次定时触发都会启动一个完整的 Claude Code 会话，每个会话都会计入你的使用额度。一个每 5 分钟运行一次、持续 24 小时的循环，就是 288 个会话。

这些会话可不小——每个都要加载上下文、调用工具、可能还会调用子 agent。在设置任何雄心勃勃的自动化之前，一定要考虑到这一点。

三条让自动化保持经济实惠的习惯：

• 在提示词中设置明确的 token 预算。 “最多使用 5k 个 token。如果在这个预算内无法完成，请保存部分进度并干净退出。” 这能限制每次触发的开销。
• 根据任务匹配合适的模型。 不要什么都默认用 Opus。大多数自动化在 Sonnet 上运行得很好。简单的探索性任务用 Haiku 就行。任务配置中的模型选择器默认使用面板的默认设置——而不是你交互式会话用的模型。请为每个任务明确设置模型。
• 根据用量选择合适的套餐。 Pro 套餐在大量自动化下很快就会被限制。Max 套餐提供 5 倍的额度空间；Team 和 Enterprise 更多。如果你在运行真正的自动化，升级套餐省下的时间完全值回票价，免得周二下午三点被限速。

07. 为无人值守运行配置权限。

默认情况下，Claude Code 在运行任何 bash 命令、写入任何文件或调用任何外部 API 之前，都会请求批准。

你看着的时候这没问题。但没人的时候，这就是灾难。三种配置模式能让默认设置变成可以真正无人值守运行的状态：

• 通过 settings.json 预批准特定工具——一个允许的安全命令列表和一个禁止的危险命令列表。
• 在项目根目录下使用 .claudeignore，在任何无人值守任务触及凭证、环境文件和敏感目录之前就阻止它们。
• 启用审计日志，记录每一个自主操作。第二天早上再看日志，而不是盲目信任运行结果。

1{
2  "permissions": {
3    "autoApprove": [
4      "Read(*)",
5      "Grep(*)",
6      "Bash(npm test)",
7      "Bash(pytest)",
8      "Bash(git status)",
9      "Bash(git diff*)",
10      "Bash(git log*)",
11      "WebFetch(domain:docs.python.org)"
12    ],
13    "deny": [
14      "Bash(rm -rf*)",
15      "Bash(git push*)",
16      "Bash(*--force*)",
17      "Bash(curl*)",
18      "Edit(.env*)",
19      "Edit(secrets/*)"
20    ]
21  },
22  "auditLog": true
23}

判断自动批准什么的标准：如果出错了，撤销的代价是多少？ 撤销代价低（比如在草稿 PR 上留个评论）——可以自动批准。撤销代价高（比如强制推送到主分支）——永远不要。

中间地带（创建一个分支、开一个 PR）可以自动批准，前提是你有真正会去看的审计日志。

08. Auto Mode — AI 分类的权限

Auto Mode 是 --dangerously-skip-permissions 的替代方案。它不是全盘授权，而是由一个 AI 分类器逐个评估每个工具调用，对照当前的权限策略决定是自动批准、提示用户还是直接阻止。

Anthropic 的测量数据显示，用户批准了 93% 的权限提示；Auto Mode 自动处理了这 93%，而那 7% 需要人工介入的则保留给用户。

实际运行方式如下：

• 三个层级。 宽松、平衡、严格。根据项目风险承受能力选择合适的级别。
• 两层防御。 服务端的提示注入探测器会在工具输出进入 Claude 上下文之前进行扫描。然后分类器会评估每个提议的操作。
• 审计追踪。 每个自主决策都会被记录。事后你可以查看哪些操作被批准了以及原因。

截至 2026 年 5 月的套餐可用性： Max、Team、Enterprise 和 API 套餐（通过 Anthropic API）。目前 Pro、Bedrock、Vertex 或 Foundry 套餐不可用。

在规划围绕 Auto Mode 的方案前，请查阅 code.claude.com/docs/en/auto-mode。启用后，Auto Mode 会加入 Shift+Tab 的模式循环，与 Accept Edits 和 Plan 并列。

Auto Mode 仍处于研究预览阶段。分类器的决策逻辑正在优化中，行为可能会在不同版本间发生变化。

将其与 .claudeignore 和审计日志配合使用——Anthropic 强烈建议两者都使用。在没有额外安全措施的情况下，不要在共享团队环境中使用它。

09. 为任务选择合适的调度器。

三个调度器，容易混淆。决策规则只有一个问题：这个任务需要在哪儿运行，谁需要保持清醒？

复合模式：先在会话中用 /loop 搞清楚什么方案可行，然后推广到桌面任务用于日常使用，最后在你想让它独立于硬件运行时提升为 Routines。

每一层都通过消除一个你必须在场的理由来证明其价值。

10. 云端 Routines。

于 2026 年 4 月 14 日以研究预览形式发布。Routines 是保存好的 Claude Code 配置——包括提示词、仓库、连接器、权限——由 Anthropic 管理的云基础设施在触发器下运行。

你的笔记本可以关机。 运行照常进行。

所有付费套餐（Pro、Max、Team、Enterprise）均可使用。在 claude.ai/code/routines 或通过 CLI 中的 /schedule 创建。CLI 仅创建由定时器触发的 routines；要添加 API 或 GitHub 触发器，请到网页上编辑。

一个 routine 实际包含什么：

• 一个自包含的提示词。 routine 会自主运行，没有后续提问，所以任何含糊不清的地方都会导致每次运行结果像抛硬币一样。要明确说明做什么、成功的标准是什么、结果发送到哪里。
• 一个或多个仓库。 每次运行开始时克隆。
• 连接器。 Slack、Linear、Drive、GitHub，任何你已集成的服务。
• 一个环境。 控制网络访问和密钥。默认是受信——允许包注册中心，但不允许任意外部出站调用。
• 一个或多个触发器。 定时器、API、GitHub 事件，或任意组合。

默认情况下，routines 只能推送到以 claude/ 为前缀的分支。一个写得不好的 routine 不太可能意外推送到主分支。只有在你拥有确实可信的下游审查流程时，才禁用这个设置。 默认设置存在是有原因的。

11. 定时器触发的 Routines

这是最常见的触发器，也是你应该开始使用的。设置一个频率——每小时、每天、工作日、每周，或未来的某个一次性时间——然后就走开。

1> /schedule weekdays at 7am
2  Goal: 拉取昨天的 GitHub issues，按严重性分类，
3  为任何 "P0" 或 "P1" 的问题起草修复方案，打开草案 PR 以供审查。
4  在 Slack 的 #engineering 频道发布摘要。
5
6▲ Claude
7  Creating routine: morning-briefing
8  - trigger: schedule (0 7 * * 1-5)
9  - repositories: org/api, org/web
10  - connectors: github, slack
11  - environment: Trusted
12✓ Active · first run Monday 07:00 local time.
13  View at claude.ai/code/routines

三种很快就能回本的模式：

• 晨间简报。 拉取昨天的指标和事故，总结新的 GitHub issues，在 Slack 上发布摘要。到早上 8 点你就知道昨晚发生了什么，不用打开任何东西。
• PR 审查浏览。 每个工作日上午 9 点，扫描分配给你的打开的 PR，给出带有安全和风格标记的初步审查评论。人工审查从已经清理过的内容开始。
• 文档漂移检测。 每周一次，扫描代码变更，标记任何没有随之更新的文档。打开一个包含修改建议的草案 PR。

时间根据你的本地时区，并会自动转换。由于错峰安排，运行可能会在预定时间后几分钟才开始——但每个 routine 是一致的。

12. API 触发的 Routines

API 触发器会为每个 routine 提供一个唯一的 HTTP 端点和 bearer token。从任何地方——告警系统、部署流水线、监控工具、你自己的应用——发起 POST 请求，routine 就开始运行。可选的 JSON 主体会成为附加到 routine 提示词的一次性上下文。

1# 从任何能访问 HTTP 的地方触发一个 routine
2curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
3  -H "Authorization: Bearer $ROUTINE_TOKEN" \
4  -H "anthropic-version: 2023-06-01" \
5  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
6  -H "Content-Type: application/json" \
7  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'
8
9# 响应包含 claude_code_session_id + 可实时观看的 URL

两个需要注意的操作细节：

• 令牌只在创建时显示一次。 立即将其存储在密钥管理服务中——事后无法重新获取。
• 注意 beta header。 /fire 端点包含在 experimental-cc-routine-2026-04-01 下。预览期间请求和响应的格式可能会变化。Anthropic 保证最近两个版本的 header 会保持可用——请在弃用窗口期内进行迁移。

这种触发器模式实际解锁的能力：Claude 可以从你技术栈中的任何系统作为一个可调用的工作流。

CI 失败 → 触发一个 routine 来调查并打开修复 PR。PagerDuty 告警 → 触发一个 routine 进行分类并发布初始上下文。Stripe webhook → 触发一个 routine 更新内部仪表板。

13. GitHub 触发的 Routines。

GitHub 触发器通过 Claude GitHub App 的 webhook 将 routine 钩入。支持的事件非常广泛：拉取请求、推送、Issue、检查运行、工作流运行、讨论、发布、合并队列。

每个匹配的事件都会启动一个独立的会话——事件之间不重用会话。

这种触发器在以下场景最有价值：

• PR 打开事件 → routine 执行代码审查，标记安全和风格问题，留下初步评论。作者在人类审查者介入之前就能收到预审查反馈。
• Issue 创建事件 → routine 对新 issue 进行分类，应用标签，关联相关代码，起草初步回复。积压的工作事项保持整洁，无需任何人手动管理。
• 工作流运行事件 → routine 调查 CI 失败，找出最可能的根本原因，打开修复草案 PR。失败的构建不再是手动苦差事。
• 发布事件 → routine 起草发布说明，发布到变更日志，通知相关人员。不再有“这次迭代谁来写发布日志”的问题。

拉取请求过滤器 让你能精确限定范围：作者、标题、正文、基础分支、头部分支、标签、草稿状态、合并状态、是否来自复刻。

一个只在标记为 needs-security-review 且目标为 main 分支的 PR 上触发的 routine，只需设置好过滤器即可。

14. 结合技能和动态工作流进行组合。

最后一步，将前面所有 Claude Code 引入的功能整合在一起。当你将每一层自动化与堆栈的其他部分配对时，每个层次都会变得更强。

• Routines 中的技能。 技能是一个可复用的指令文件。把你的“PR 审查”或“晨间简报”技能放到 ~/.claude/skills/ 下，然后在 routine 提示词中引用它：“使用 morning-briefing 技能。” 技能是你的可复用配方；routine 是执行它的触发器。
• Routines 中的动态工作流。 对于需要并行子 agent 的复杂自动化——深度验证、锦标赛、多方向调研——让 routine 提示词调用一个工作流。Routines 提供调度；工作流提供结构。
• 由其他 Routines 触发的 Routines。 一个 routine 的输出（一个打开的 PR、一条 Slack 消息、一个标签变更）可能成为另一个 routine 的触发器。这不是一个你可以打开或关闭的功能特性——这是一种模式，通过将一个 routine 的输出指向另一个 routine 的触发器来设置。
• 每个 Routine 有独立的权限，而不是全局的。 每个 routine 都带有自己的权限配置。晨间简报 routine 可以到处读取，但不能推送。自动修复 routine 只能推送到 claude/ 分支。安全检查 routine 有最大的拒绝列表。将每个 routine 的权限文件视为其安全边界的一部分。

整个体系在最佳状态下是这样的：技能作为你的配方，动态工作流作为编排层，Routines 作为触发层，Auto Mode 作为权限分类器，审计日志作为你的晨间回顾。 本文中的每一步都配置了该体系的一个片段。

你不需要第一天就全部用上。从 /loop 开始。升级到桌面任务。再升级到 Routines。配合技能使用。当复杂性需要时，再加入工作流。

在 Claude 自动化上浪费钱的习惯

• 从一开始就没尝试过 /loop。 最简单的自动化层级不花钱，你却已经忽视了三个月。
• 忘记了 7 天自动过期。 设置了一个关键循环后就走开了，一周后纳闷为什么什么都没发生。
• 用 /loop 做那些应该比终端会话活得更久的任务。 第 2 层和第 3 层存在的全部意义就是这种场景——升级它。
• 让自动化默认使用 Opus 模型。 每次触发都用 Opus，而 Sonnet 做同样的活儿成本更低。请检查每个任务的模型选择器。
• 在应该持续运行直到完成的循环里没有用 /goal。 循环在“处理得差不多了”就停止了，而不是达到实际的停止条件。
• 通过 --dangerously-skip-permissions 进行全盘授权。 离一个 git push --force origin main 只差一个坏的提示词。请使用 Auto Mode 或白名单。
• Routine 提示词含糊不清。 Routine 自主运行，没有后续提问。含糊的提示词会导致每次运行都像抛硬币。
• 没有审计日志。 “相信自动化”而不审查它的行为，就是让无声的失败变成响亮事故的方法。
• 禁用了 claude/ 分支前缀。 默认设置存在是有原因的。在你下游的审查流程真正稳固之前，不要关掉它。
• 在 Pro 套餐上运行大量自动化。 大量自动化会很快触发速率限制。如果你在部署真实的工作流，升级到 Max 套餐省下的时间完全值回票价，免得被卡住。

结论：

Claude 并不会在你停止打字时就停止工作。

这套自动化体系在过去三个月里一直在逐步发布。3 月发布了 /loop。两周后是 Auto Mode。4 月是 Routines。整个体系已经上线、有文档，并且你已经买了包含它的套餐。

介于“昂贵的聊天机器人”和“劳动力”之间的，只有十四步配置。

大多数用户会继续手动输入提示词并止步于此。对日常使用来说这没问题，但对其他任何事情来说都很糟糕。那 1% 运行真正自动化的用户，已经让 Claude 在早上 7 点自动分类问题、每小时刷新仪表板、每 10 分钟起草 Slack 回复——这一切都在他们睡觉的时候。 他们已经建立了手动循环，将其升级为桌面任务，再进一步升级为 Routines。

选一个你之前没做过的步骤——很可能是你在终端里的第一个 /loop——然后明天就加上它。然后再做下一步。Claude 的输出取决于 Claude 的配置。把它配置成自动驾驶模式，你就能得到自动驾驶模式的效果。