Claude Code /loop 实战指南：十个场景让 AI 替你干活

Claude Code 的 /loop 命令让 AI 按你设定的节奏自主循环工作——你定好任务和间隔，去吃饭、睡觉、做别的事，回来时任务已经完成或正在推进。这是 Anthropic 在 2026 年 3 月发布的内置功能（需要 Claude Code v2.1.72 以上版本），标志着 Claude Code 从「你问它答」的对话工具，正式进化为可以自主运行的后台工作者。

本文是中文全网最全面的 /loop 深度教程。十个你今晚就能动手的真实场景，每个都有可直接复制的提示词；覆盖成本控制的核心规则和社区真实踩坑教训；最后给出 /loop、/goal、桌面定时任务、云端 Routines 的完整选型决策表。不翻译、不搬运——全部素材经过多源交叉检索验证。

要点速览

• /loop 有三种模式：固定间隔、自适应间隔、维护模式
• 十个实战场景：深度调研、SEO 体检、竞品监控、批量任务、文档生成、通宵重构、日报自动化、内容管线、Skill 自改进、全站编排
• 间隔保持在 5 分钟以内可大幅节省成本（复用提示词缓存）
• 每个循环提示词必须有预检查逻辑和退出条件
• /loop 之外还有 /goal、Ralph Loop、桌面定时任务、云端 Routines 四种进阶选择

一行命令改变了什么

2026 年 6 月，Claude Code 的创造者 Boris Cherny 在 Anthropic 开发者大会上说了一句话，24 小时内被转发数十万次：

"我不再给 Claude 写提示词了。我写循环，让循环替我给 Claude 下指令。这是今年剩下的时间我们都会经历的转变。"

这句话描述的就是 /loop 带来的变化——你的工作方式从「一问一答」变成「定目标，然后走开」。

翔宇的判断是：/loop 本身不难，难的是知道什么时候该用它、什么时候不该用。盲目开循环只会烧钱，想清楚再开才能真正省时间。

过去两年，AI 编程工具的演进经历了三个阶段：

• 2024 年是对话模式：你问一句，AI 答一句——这就是 vibe coding（氛围编程）的阶段
• 2025 年是代理模式：AI 能读文件、写代码、跑测试，但每一步都需要你在旁边
• 2026 年是自主模式：AI 按你设定的节奏自己工作，你去做别的事

/loop 就是从第二阶段跨到第三阶段的桥梁。Google Chrome 团队的 Addy Osmani 在 2026 年 6 月正式提出了「循环工程」（Loop Engineering）的概念——不是怎么写好一条提示词的问题了，而是怎么设计好一个循环的问题。

💡 通俗讲：你可以把 /loop 理解成给 AI 设了一个工作闹钟。闹钟每隔一段时间响一次，AI 醒来干一会儿活，干完继续等下一次闹钟。你不需要一直盯着它。

还有一种更简单的用法：一次性提醒

在聊 /loop 的循环之前，先说一个很多人不知道的用法——一次性提醒。你不需要用 /loop，直接用自然语言告诉 Claude「什么时间提醒我做什么」就行：

「45 分钟后提醒我检查集成测试的结果」

「下午 3 点提醒我把发布分支推送到远端」

Claude 会自动创建一个单次触发的定时任务，到时间执行一次后自动删除。不循环、不重复、不需要你管理。这是 /loop 的简化版——适合「某个时间点做一件事」的场景。

💡 通俗讲：/loop 是每天响的闹钟，一次性提醒是只响一次的倒计时。大部分人第一次用 Claude Code 的定时功能，从一次性提醒开始最无压力。

/loop 有哪些模式？

/loop 的语法只有一行。根据你给的参数不同，分为三种模式。下面逐一讲清楚每种模式的适用场景和注意事项。

模式一：固定间隔执行指定任务

在 Claude Code 中输入 /loop，后面跟上间隔时间和你想让它做的事。比如每 5 分钟检查一次部署状态。

时间单位支持秒（s，会向上取整到分钟）、分钟（m）、小时（h）、天（d）。间隔可以写在前面（如 30m），也可以写在后面（如 every 2 hours）。

这是最常用的模式——你明确知道要做什么、多久做一次。

🔍 深入一步：如果你设的间隔不能整除（比如 7 分钟或 90 分钟），Claude 会自动取最近的合法间隔，并告诉你实际采用了多少。底层使用的是标准的五字段定时任务表达式（cron expression），精度为 1 分钟。

模式二：让 Claude 自己决定间隔

只告诉 Claude 做什么，不说多久做一次。Claude 会自己判断——刚发生变化的时候查得勤（1 分钟一次），什么都没变的时候查得松（最长 1 小时一次）。每次执行结束后，Claude 会打印它选择的下次间隔和理由。

翔宇认为这是三种模式中最值得优先尝试的——大部分人一上来就想着「每 5 分钟查一次」，但实际上 AI 自己判断的节奏往往更合理。自适应模式下，Claude 有时会直接使用监控工具（Monitor tool）——运行一个后台脚本流式返回输出，比反复轮询更省资源也更快。

模式三：什么都不给——自动维护

直接输入 /loop，不带任何参数。Claude 会运行内置的维护任务——按顺序做三件事：

1. 继续对话中没做完的工作
2. 维护当前分支的拉取请求（PR）：处理审查评论、修复失败的构建、解决合并冲突
3. 无事可做时运行清理：找 bug、简化代码

如果你在项目里放了一个 loop.md 文件（路径为 .claude/loop.md 或 ~/.claude/loop.md），Claude 会读这个文件替代内置维护任务。这个文件就是你的「自动工作清单」，编辑后下次循环立即生效，不需要重启。文件上限 25,000 字节。

💡 通俗讲：loop.md 相当于你给 AI 写了一份「值班手册」。每次 AI 醒来，先翻手册看看该干什么。你随时可以改手册的内容，AI 下次醒来就会照新手册做。这跟 CLAUDE.md 项目记忆文件是同一类配置机制——写法和最佳实践相通。

关键约束（必须知道）

常用间隔速查

不需要记语法，用自然语言就行。但如果你好奇底层，Claude 会把你说的话转成标准定时任务表达式。以下是常见的对应关系：

所有时间都按你本地时区解释。间隔不整除分钟时会自动取最近的合法值——比如你说「每 7 分钟」，Claude 可能改成每 5 分钟或每 10 分钟，并告诉你实际采用了多少。

⚠️ 常见踩坑：关于抖动（jitter）——为了避免所有用户的任务同时触发 API，系统会给每个任务加一个随机偏移量。循环任务最多延迟 30 分钟或半个间隔（取较小值）。一次性提醒如果设在整点或半点，最多提前 90 秒触发。如果你需要精确定时，避开整点——比如设 9:03 而不是 9:00。

怎么管理正在运行的循环？

用自然语言问 Claude 就行——「我有哪些在跑的任务」会列出所有活跃任务，「取消那个部署检查任务」会停掉指定任务。底层是三个工具：CronCreate（创建）、CronList（列出）、CronDelete（取消，需要 8 字符任务 ID）。

你也可以嵌套调用其他斜杠命令——比如 /loop 20m /review-pr 1234 会每 20 分钟执行一次 PR 审查命令。任何你已有的 Skill 或命令都可以这样定期调度。

禁用调度

如果你不想让任何人在你的环境里用 /loop，设置环境变量 CLAUDE_CODE_DISABLE_CRON=1 即可全局禁用调度器。

Boris Cherny 自己在跑哪些循环？

既然 /loop 的创造者说「我的工作就是写循环」，那他具体在跑什么？根据他在 howborisusesclaudecode.com 公开的信息，他日常同时运行以下四个循环：

1. babysit——每 5 分钟执行一次，自动处理代码审查评论、自动变基（rebase）、护送拉取请求到合并。这是他合并量最大的循环，单日最高纪录合并 150 个 PR
2. slack-feedback——每 30 分钟把 Slack 里的用户反馈自动转化成代码修改的拉取请求
3. post-merge-sweeper——合并后清理器，自适应间隔，扫描合并后遗漏的审查意见
4. pr-pruner——每小时清理过期或不再需要的拉取请求

这四个循环的共同特征：每个都很小，只做一件事。不是一个大循环做所有事，而是四个小循环各管一摊。合起来替代了一个维护工程师半周的工作。

Boris 分享的核心建议是：给 AI 一种自我验证手段（测试套件、构建通过、浏览器确认）是最有价值的事——有了可靠验证，AI 的产出质量能提升两到三倍。

🔍 深入一步：Boris 的 Anthropic 团队内部已经有数十个循环在运行。他们的 Claude 之间甚至通过 Slack 互相通信——一个 Claude 发现问题发到 Slack 频道，另一个 Claude 的循环从 Slack 捡到任务开始修复。这不是假想场景，是 Anthropic 内部正在发生的工作模式。

X 上最火的两个进阶模式

在进入具体场景之前，再介绍两个在 X（Twitter）上被大量引用的高阶模式。

Checker Agent 双会话模式

这个模式来自社区实战：同时开两个 Claude Code 会话。第一个会话是你的主工作区——你在里面写代码、做项目。第二个会话专门跑 /loop，每 15 分钟自动审查第一个会话的产出。

两个会话看到的是同一个项目文件，但各自有独立的对话上下文。第二个会话不知道你在想什么，只看到文件的变化——这种「不知道作者意图、只审查结果」的视角，反而能发现第一个会话在上下文中忽视的问题。

VISION.md 方向锚定模式

这个模式来自 Peter Steinberger（OpenClaw 创建者，现在 OpenAI）。他建议在项目根目录放一个 VISION.md 文件，写清项目的北极星目标和关键约束。每次循环开始时，提示词第一步要求 Claude 读取 VISION.md 确认方向。

为什么需要这个？因为长程循环会漂移——Claude 在第 1 轮很清楚要做什么，到第 20 轮可能已经偏离了原始目标（特别是上下文压缩之后）。VISION.md 是每轮的方向锚——不管对话历史怎么压缩，这个文件始终完整存在。

翔宇的判断：这和 CLAUDE.md 的理念完全一致。 CLAUDE.md 是给 Claude Code 看的项目记忆，VISION.md 是给循环看的方向锚。如果你的循环要跑超过 10 轮，强烈建议用 VISION.md 锚定方向。

十个你今晚就能用的场景

以下十个场景面向翔宇的读者——用 AI 做内容、做调研、做运营、学编程的同学。每个场景都有完整的提示词，你复制进 Claude Code 就能跑。提示词设计遵循三个原则：有预检查（无事不做）、有退出条件（不无限跑）、有输出位置（结果写到文件）。

场景一：深度调研自动化

痛点：你要研究一个话题（比如「2026 年 AI 编程工具的最新趋势」），需要从多个角度搜索、阅读、整理成报告。手动做要 2-3 小时，而且容易漏掉角度。

做法：在项目目录创建 .claude/loop.md 文件写入调研指令，然后启动 /loop。每 20 分钟 Claude 自动搜索一个新角度，把结果追加到同一份报告。

🎯 实战提示词（写入 .claude/loop.md，然后输入 /loop）

「我正在研究"[话题名称]"。请按以下步骤执行每一轮循环。第一步，读取 report.md 文件，检查已经覆盖了哪些角度。第二步，从以下预设角度中选择一个尚未覆盖的：技术原理与演进脉络、市场格局与主要玩家、真实用户反馈与口碑、成本结构与性价比、替代方案与竞品对比、行业趋势与未来预测、实操案例与最佳实践、常见误区与踩坑教训。第三步，用搜索工具查找这个角度的最新信息，至少搜索 3 次不同关键词，阅读至少 2 篇完整文章。第四步，将发现整理成 300-500 字的段落，追加到 report.md 的对应章节，标注每条信息的来源链接。第五步，如果所有 8 个角度都已覆盖，在 report.md 末尾写一句"调研完成"，然后停止循环。」

🔍 深入一步：这个提示词的关键设计是「先检查已有、再选择未覆盖的角度」。如果不加这一步，AI 每轮都可能重复搜索同一个角度。另外，明确要求「至少搜索 3 次不同关键词」能避免 AI 用一次搜索就草草了事。翔宇测试发现，给调研循环配合 MCP 搜索工具效果更好——搜索结果更丰富，覆盖面更广。

场景二：官网 SEO 自动体检

痛点：你发了一批文章到官网，想检查所有文章的 SEO 基础项是否合格——元描述（meta description）长度、标题关键词、标签配置、内链覆盖。逐篇人肉检查枯燥又容易漏。

做法：给 /loop 一个每小时执行的检查任务，让 Claude 逐篇扫描文章目录。

🎯 实战提示词

「/loop 1h 请执行以下 SEO 体检任务。第一步，扫描文章目录下所有 .md 文件，读取每个文件的 frontmatter。第二步，逐篇检查以下六项：meta_description 是否在 60-80 个汉字之间；title 是否在前 30 个字符内包含目标关键词；tags 列表是否至少有 2 个标签且第一个是一级分类标签；slug 格式是否为全小写连字符；文章正文是否包含至少 2 个指向站内其他文章的内链；Schema 结构化数据是否完整（BreadcrumbList + BlogPosting + FAQPage 三件套）。第三步，把不合格的文件列成清单写入 seo-audit.md，每个文件标注具体哪项不合格以及建议修改方式。如果全部合格，写一行"全部通过，共检查 N 篇"。第四步，与上次审计结果对比，标注哪些问题是新出现的、哪些是上次就有但未修复的。」

⚠️ 常见踩坑：如果你的文章目录里有几百篇文章，一次全扫会消耗大量上下文空间。建议分批检查——每次只扫最近 30 天修改过的文件，或按一级标签分批。翔宇用 SEO 工具做过类似的自动巡检，发现分批比一次全扫的准确率更高。

场景三：竞品动态监控

痛点：你想追踪 2-3 个竞品最近发了什么新内容、产品有什么更新，但每天手动搜费时间。

做法：设一个每 30 分钟执行的循环，让 Claude 搜索竞品最新动态，与历史记录比较，新发现追加到日志文件。

🎯 实战提示词

「/loop 30m 请执行竞品监控任务。第一步，读取 competitor-log.md 中已有的记录，确认上次检查时间和已知条目。第二步，分别搜索以下竞品的最新动态：[竞品A名称]、[竞品B名称]、[竞品C名称]。搜索关键词包括品牌名 + "发布"、品牌名 + "更新"、品牌名 + "教程"。第三步，将搜索结果与已有记录逐条比对。如果发现新内容（标题或链接不在已有记录中），追加到 competitor-log.md，格式为：日期 | 竞品名 | 内容标题 | 链接 | 内容类型（文章/视频/产品更新）| 一句话摘要。第四步，如果本轮没有发现任何新内容，什么都不写，直接结束本轮循环。」

关键点在最后一步——没有新发现时什么都不做。这是 Jiri Dolejs（一位把 /loop 用到生产级别的开发者）总结的核心模式：预检查（pre-flight check）。每轮循环先做一个低成本的判断——有活干就干，没活干就直接退出。

翔宇用了几周 /loop 之后发现：预检查不是可选的优化，而是必须的纪律。 不加预检查的循环，和不设预算的广告投放一样——跑着跑着你就不知道钱花到哪里了。加了预检查之后，大部分循环轮次的实际消耗接近于零。这个模式的完整案例可以看 Jiri Dolejs 的博客——他用 /loop + 自定义 Skill 搭建了一个整夜运行的 GitLab 自主代理，预检查是整个方案的成本命脉。

场景四：批量任务自动推进

痛点：你有一个 tasks.md 文件，里面列了 10 个待办项（比如：给 10 篇文章补写 FAQ 段落）。一条一条手动指挥 Claude 太慢。

做法：用 /goal（Claude Code 的另一个自主命令，v2.1.139+ 版本支持）设定完成条件——全部完成时停止。Claude 会自己逐条推进，每完成一个就标记。

🎯 实战提示词

「/goal 请打开 tasks.md 文件，找到所有标记为"待处理"的条目。按从上到下的顺序逐条执行每个任务。每完成一个任务后，立即将该条目的标记从"待处理"改为"已完成"并保存文件。执行每个任务前，先读取任务描述确认你理解了要做什么。如果某个任务遇到问题无法完成（比如找不到目标文件、缺少必要信息），将该条目标记为"需人工处理"并在旁边写一句原因说明，然后跳到下一个。全部条目都不再是"待处理"状态时停止。或者超过 30 轮未全部完成也请停止。」

💡 通俗讲：/loop 是按时间触发的闹钟——每隔多久响一次；/goal 是按条件触发的目标——做完了才停。两者是互补关系。如果你的任务有明确的「全部做完」标准，用 /goal 更合适；如果你的任务是持续性的监控（永远不会"做完"），用 /loop 更合适。详见后文的选型决策表。

场景五：文档与文件自动生成

痛点：你需要批量创建一组结构相似的文件——比如给 10 个新模块各写一份说明文档，或者给一批产品各生成一个介绍页骨架。这种重复性的创建工作完全可以交给 AI。

做法：用 /goal 配合一个清单文件，让 Claude 逐条创建目标文件。

🎯 实战提示词

「/goal 请读取 file-list.md，里面列出了需要创建的文件清单，每行一个文件路径和简要说明。按顺序逐个创建：对每个条目，先检查目标文件是否已存在；如果已存在则跳过并标注"已有"；如果不存在，根据文件路径判断类型（文档用 Markdown、配置用 YAML、脚本用对应语言），参考同目录下已有文件的格式和风格来创建新文件。每创建一个文件，在 file-list.md 对应行末尾追加"[已创建]"标记。全部标记完成后停止。超过 25 轮未完成也请停止。」

这个场景的价值在于：格式统一、不会遗漏、不会犯人在第 8 个文件时开始马虎的错误。翔宇认为，凡是「按模板批量创建」的任务，都应该第一时间考虑交给 AI 循环做。

场景六：通宵代码重构

痛点：你有一个 800 行的大文件需要拆分成多个小模块，或者需要把一批旧写法迁移成新写法。手动做要一两天专注时间。

做法：晚上给 Claude 一个重构任务，设好护栏，然后去睡觉。

🎯 实战提示词

「/goal 请执行以下重构任务：将 [目标文件路径] 按关注点拆分成独立的子模块文件。具体要求：1）分析文件中的逻辑分组，每个独立关注点拆成一个单独文件，放在同目录的子文件夹中。2）每个新文件必须包含必要的导入声明，确保可以独立运行。3）更新原文件中所有引用这些被拆出部分的地方，改为从新模块导入。4）每完成一个模块的拆分，运行一次项目测试确认没有破坏现有功能。5）测试失败时，先回退当前拆分再尝试其他方案；如果同一个模块连续 3 次拆分都导致测试失败，标记为"需人工处理"并跳过。6）所有模块拆分完成且测试全部通过后停止。或者超过 40 轮未完成也停止。约束：不修改目标文件夹之外的任何文件；不删除原文件（拆分完成后由人工确认删除）；每次拆分产生一个独立的 git 提交，提交信息描述拆出了什么。」

社区有开发者用类似方法做过通宵重构——800 行单体文件拆成 6 个聚焦模块，47 个新测试全部通过，12 个干净提交附描述性信息。不完美之处是两个文件命名可以更好、一个测试有冗余——但这只需要早上 30 分钟清理，相当于两天工作量压缩到一夜。

⚠️ 常见踩坑：通宵运行的最大风险不是 AI 做错了什么，而是 AI 在循环中做错了什么却不会自己停下来。社区有一个真实案例——一位开发者让 AI 整夜无人值守修代码，12 小时后产生了 204 个拉取请求，其中 509 次构建连续失败。实际只需要改 23 行就能修好，但 AI 在自己制造的问题上越修越错。根本原因是：AI 在循环中是无状态的——它不记得「我已经尝试过 3 种方案都失败了」。人类在第三次失败后会退一步反省，循环中的 AI 不会。 所以上面的提示词里「连续 3 次失败就标记并跳过」是不可省略的安全阀。详见翔宇的 Claude Code 权限与安全指南。

场景七：邮件日报与新闻摘要

痛点：你想每天早上收到一份行业新闻摘要，或者每天下午收到一份当日工作总结。手动整理太花时间。

做法：用 /loop 设一个每天执行一次的任务，让 Claude 搜索、筛选、汇总。

🎯 实战提示词

「/loop 24h 请执行以下每日新闻摘要任务。第一步，用搜索工具查询以下关键词的最近 24 小时新闻：AI 编程工具、Claude Code、Codex、AI Agent、AI 自动化。第二步，从搜索结果中筛选与 AI 编程直接相关的前 10 条，排除广告和重复报道。第三步，为每条新闻写一句话摘要（不超过 50 字），并标注原文链接。第四步，按重要性排序（产品发布 > 功能更新 > 教程 > 评论），写入 daily-digest/YYYY-MM-DD.md 文件。第五步，在文件末尾追加一段"翔宇视角"——从这 10 条新闻中提炼 1-2 个值得关注的趋势或判断。」

这个用法灵感来自 Allie K. Miller（前 Amazon AI 高管）在 LinkedIn 分享的非编码 /loop 创意——她的原版还包括「每 30 分钟检查邮箱总结新邮件」和「每小时扫描竞品网站变化记录到日志」。核心价值在于：这些用例不需要写任何代码，非技术人员也能直接用。

场景八：内容创作自动管线

痛点：你是自媒体运营，每天需要从选题、调研、写初稿、排版到发布，流程很长。虽然每一步都可以让 AI 帮忙，但你得一步步手动推。

做法：把整个内容创作流程写进 loop.md，让 Claude 按管线自动推进。

🎯 实战提示词（写入 .claude/loop.md）

「请执行内容管线的下一步。先读取 pipeline-status.md 确认当前进度。如果状态是"选题阶段"，搜索本周 AI 编程领域的热门话题，提出 3 个选题候选写入 topics.md，将状态改为"选题待审"，然后停止等待人工选择。如果状态是"已选题"，读取选定的话题，进行深度调研（搜索 5 个不同角度），将素材整理到 research.md，将状态改为"调研完成"。如果状态是"调研完成"，基于 research.md 的素材写出 2000-3000 字的初稿到 draft.md，将状态改为"初稿完成"。如果状态是"初稿完成"，对 draft.md 做一轮自检（检查错别字、逻辑断裂、信息准确性），将修改后的版本存为 final.md，将状态改为"待发布"。如果状态是"待发布"，什么都不做——等人工审阅后手动发布。」

然后启动 /loop（裸输入，自适应间隔）。Claude 会按状态机自动推进——需要人工选题时停下来等你，你选完后下一轮自动进入下一步。

这种模式的灵感来自 Kieran Flanagan（HubSpot 营销副总裁），他在 Claude Code 中搭建了 11 个 Skill 组成的完整内容团队——一个人零员工运营，设置自动模式后系统每天早上自主跑完全部流程，他只需要审查产出。

场景九：Skill 自改进循环

痛点：你写了一个 Claude Code Skill（比如一个自动生成图表的 Skill），但效果不稳定，有时好有时差。手动调优提示词试一遍要 10 分钟，试 20 遍就是 3 小时。

做法：借鉴 Andrej Karpathy 的 Autoresearch 概念——让循环自动试错：修改提示词 → 测试效果 → 打分 → 保留赢家、回滚输家 → 重复。

🎯 实战提示词

「/loop 2m 请执行 Skill 自改进循环。第一步，读取 program.md 了解当前优化目标和约束。第二步，读取当前 Skill 的提示词文件。第三步，对提示词做一处（只一处）修改——可以是调整措辞、增加约束、改变格式要求。第四步，用修改后的提示词跑一遍 eval-cases.json 中的全部 10 个测试用例。第五步，统计通过率：如果通过率高于上一版，将当前版本保存为 best-version.md 并做一个 git 提交写明"改进：通过率 X/10 → Y/10"；如果通过率不变或下降，回滚到上一版。第六步，在 progress-log.md 追加本轮记录：修改了什么、通过率多少、保留还是回滚。超过 50 轮后停止。」

场景十：全站改进编排

痛点：你想对整个项目做一轮全面改进——修 bug、补测试、更新文档、清理技术债——但这些事分散在各处，手动一个个做要一周。

做法：给 /loop 一个「编排器」角色，每轮循环让它评估项目当前状态、选出最高优先级的改进项、执行、提交。

🎯 实战提示词

「/loop 10m 你是一个项目改进编排器。每一轮请做以下事情。第一步，浏览项目当前状态——读取 README、检查最近的 git 提交记录、扫描是否有 TODO 注释或已知 issue。第二步，从以下改进类别中选择当前最需要做的一件事：修复已知 bug（优先级最高）、补充缺失的测试、更新过时的文档、清理冗余代码或依赖、改善错误处理。第三步，执行选定的改进，确保改动范围小且独立（每轮只做一件事）。第四步，改动完成后运行测试确认没有破坏。第五步，做一个 git 提交，提交信息清楚写明改进了什么。第六步，在 improvements-log.md 追加记录。如果扫描后发现没有明显可改进的地方，什么都不做，直接结束本轮。连续 3 轮都没有改进可做时，停止循环。」

Developers Digest 的创始人用类似方法做过一次「过夜编排」——晚上 11:47 输入一行命令然后去睡觉。到凌晨 1:53，编排器派出数十个子代理，在 21 个仓库开了 59 个拉取请求，搭建了 12 个新项目。当然，这是一个极端案例——多数人不需要这么激进的编排。但核心理念是对的：把重复性的改进工作变成循环，每轮只做一件小事，积少成多。

loop.md 深度配置指南

loop.md 是 /loop 最容易被忽视但最有价值的配置机制。它不是一般的文档，而是你给 AI 写的「值班手册」——决定了裸 /loop 每次醒来干什么。

文件位置

两个都存在时，项目级优先。两个都不存在时，/loop 回退到内置维护任务。

写好 loop.md 的五个要点

1. 当成提示词来写：把它想成你直接输入 /loop 后面的那段话。不需要 Markdown 格式或特殊结构，就像正常给 Claude 布置任务一样写。

2. 加预检查逻辑：在指令开头明确写上「先检查有没有需要做的事情，如果没有就什么都不做直接结束」。这能避免空转浪费。

3. 指定输出位置：每次循环的结果要写到哪个文件、追加还是覆盖，都要明确。否则 Claude 会把结果打印在对话里，几轮之后上下文就满了。

4. 实时可编辑：loop.md 的修改在下次循环立即生效。你可以在循环运行中实时调整指令——比如发现某个角度已经搜够了，直接编辑文件去掉那个角度。

5. 控制文件大小：超过 25,000 字节会被截断。保持简洁——把详细的背景资料放在独立文件里，loop.md 里只写「读取 context.md 了解背景」。

官方示例

Claude Code 官方文档给出的 loop.md 示例是这样的：

「检查 release/next 这个拉取请求。如果构建失败（CI 红灯），拉取失败日志、诊断问题、推送最小修复。如果有新的审查评论，逐条处理并标记为已解决。如果有合并冲突，解决它。如果一切正常（绿灯、无评论），用一行话说"一切正常"就行。」

这个示例体现了好的 loop.md 的所有特征：有清晰的优先级顺序、每种情况有明确的处理方式、无事可做时有简短的退出路径。

怎么防止 /loop 烧钱和失控？

/loop 的核心风险不是「AI 做错了什么」，而是 AI 在循环里做错了什么，你又不在旁边。社区里有大量真实事故可以借鉴。

规则一：间隔保持在 5 分钟以内

Claude Code 有一个提示词缓存机制——如果两次调用之间间隔不超过 5 分钟，第二次调用可以复用上次的缓存，成本大幅降低。间隔超过 5 分钟，缓存过期，每次调用都要从头加载完整的对话历史。

一句话总结：5 分钟以内调一次很便宜，超过 5 分钟调一次就是全价。 社区有用户因为把间隔设成 30 分钟（超出缓存窗口），一晚上循环 46 次，每次都从头加载完整对话历史——醒来发现用量已经见底。这不是个例，缓存过期是 /loop 成本失控的头号原因。

如果你的任务不需要很频繁地执行，翔宇建议选择自适应模式（不指定间隔），让 Claude 自己根据情况调节。更多关于 Claude Code 成本优化的内容，详见最佳实践指南中的成本控制章节。

规则二：每个提示词必须有预检查

循环最大的风险是空转——Claude 每轮都执行完整流程，但其实没有任何事情需要做。这是 Jiri Dolejs 反复强调的核心原则：

"没有预检查模式，你的 AI 每 20 分钟消耗一次完整的对话成本去分析一个什么都不需要做的代码库。"

解法就是前面每个场景提示词里都有的预检查步骤：每轮循环的第一步不是干活，而是先判断「有没有活需要干」。没有就直接跳过。这一步成本极低，但能避免空转的巨大浪费。

规则三：必须有退出条件

循环的第二大风险是死循环——Claude 发现一个错误，修复导致新错误，新错误又触发修复，无限重复。一位独立开发者的真实案例：AI 的修复循环是一个稳定吸引子——构建失败 → AI 修复 → 修复破坏别的东西 → 构建再失败 → AI 再修复，没有自然退出条件。他的总结：

"人类在第三次失败后会退一步反省'我越修越糟'。循环中的 AI 没有这个机制。"

所以每个提示词必须写明退出条件：最大轮次（「超过 30 轮停止」）、最大失败次数（「同一问题连续失败 3 次就跳过」）、或者完成标记（「所有条目标为已完成时停止」）。

规则四：关终端就停——这是你的安全网

/loop 是会话级的，关了终端所有循环立刻停止。这不是缺陷，是刻意设计的安全机制。

社区几乎所有严重事故都发生在「AI 无限制运行」的场景下。108 小时无人值守实验的作者总结了七大事故类型，前三位是：子代理删除了整个源码目录、API 调用失控 1 小时花了大量资源、无限错误循环每次都报告「已修复」但问题依然存在。他总结的三个首要防线：

1. 用 Hooks 设置预执行检查，阻断危险命令
2. 在提示词中写明重试上限——连续失败 3 次后写入待人工处理文件，跳到下一个任务
3. 用一个 mission.md 文件在上下文压缩前保存工作状态

"这三个就能阻止 70% 的事故。"

/loop 之外还有哪些自主运行方式？

/loop 只是 Claude Code 自主运行能力的一种。翔宇把所有选项整理成一张决策表，帮你根据场景选对工具。

怎么选？一个简单的决策方法

• 「我在电脑前，想让 Claude 帮我盯着点」→ 用 /loop
• 「这件事做完就行了，不需要反复」→ 用 /goal
• 「我要跑一个复杂的多步骤项目，需要每轮都有干净的上下文」→ 用 Ralph Loop
• 「我想睡觉了，但希望明天早上有结果」→ 用桌面定时任务
• 「我要出门好几天，但这件事每天都得做」→ 用云端 Routines
• 「这个自动化要在生产环境可靠运行」→ 用 GitHub Actions

/goal 值得单独说一下

/goal 是 /loop 的互补命令（需要 v2.1.139+ 版本）。区别很直观：

• /loop 问的是：每隔多久做一次？
• /goal 问的是：什么时候算做完了？

你给 /goal 一个完成条件（最长 4,000 个字符），Claude 每一轮结束后会用一个快速小模型（默认 Haiku）判断条件是否满足。没满足就继续干，满足了就自动停。

写好完成条件的三要素：

1. 一个可度量的终态——测试通过、构建成功、文件数量达标、队列为空
2. 一个明确的检查方式——「运行测试退出码为 0」比「代码应该没问题」好一百倍
3. 一个不能违反的约束——「不修改其他模块的文件」「公开接口保持不变」

建议在条件里加安全阀——比如「或者超过 20 轮后停止」「或者超过 90 分钟后停止」。Claude Code 创始工程师 Sid Bidasaria 曾跑过一次 14 小时的 /goal 重构——有信心的场景可以设得长一些。

/goal 可以在非交互模式下运行，也可以通过远程控制（Remote Control）从手机监控。搭配自动模式（Auto Mode）使用效果更好——自动模式免除每个工具调用的人工审批，/goal 免除每轮的人工提示，两者叠加实现完全无人值守。

Ralph Loop 是什么

在 Anthropic 发布 /loop 之前，社区已经用一个叫 Ralph Loop（也叫 Ralph Wiggum 循环）的开源方案解决了同样的问题。名字来自《辛普森一家》里最执着的角色——不聪明但不会放弃，一直试到成功为止。

核心原理极其简单：一个永不停止的外部循环，每次给 Claude 喂同一份任务描述文件。Claude 完成后退出，外部循环又把它拉回来。每次迭代 Claude 通过文件系统（git 历史、progress.txt）看到之前的工作，在此基础上继续改进。

Ralph Loop 和 /loop 的本质区别：Ralph 每次启动全新会话（干净的上下文窗口，满血认知能力），而 /loop 在同一会话内累积（上下文越来越长，后期推理质量可能下降）。对于简单任务 /loop 够用，复杂的多步骤项目可能更适合 Ralph 的新鲜上下文模式。

Anthropic 官方也发布了 Ralph Loop 插件，可以通过安装插件后输入 /ralph-loop 来使用——设定任务描述、最大迭代次数和完成承诺词即可启动。

/loop + /goal + Skill 的组合模式

Boris Cherny 自己使用的模式是三者组合：

• 一个 /loop 每隔几分钟检查所有未关闭的拉取请求
• 对每个有未处理审查评论的 PR，用 /goal 风格的条件判断评论是否已妥善处理
• 具体的处理逻辑封装在自定义 Skill 里

这不是什么高级框架，只是三个原语的组合。动态工作流（Dynamic Workflows）提供了更强大的编排能力——Claude 可以动态写自己的工作流骨架，不需要预配置。Anthropic 官方博客明确建议：「把 /loop 与可重复的 workflow 配对用于持续分诊和研究。」

为什么说「从提示词到循环」是范式转变？

Addy Osmani 在他的「循环工程」文章中总结了一个核心观点：

"循环设计比提示词工程更难，不是更简单。杠杆点变了。"

过去你的产出取决于你写的提示词有多精确；现在你的产出取决于你设计的循环有多健壮——有没有预检查、有没有退出条件、有没有成本控制、有没有可靠的停止信号。

他总结了循环设计的五个层次：

1. 意图锚定——用 loop.md 或 CLAUDE.md 写清目标和约束
2. 可拒绝的验证器——测试通过/失败、类型检查干净/报错，机械判断比 AI 自我判断可靠
3. 值得调用的 Skill——把复杂操作封装成 Skill，循环里一行调用
4. 停止条件——迭代上限、无进展检测、成本上限，三重保险
5. 定时调度——/loop 管时间触发，/goal 管条件评估

翔宇对 /loop 的总体判断：工具型任务用 /loop 效果拔群，创作型任务不要用。 凡是有明确检查标准的事（文件格式对不对、链接通不通、关键词在不在），/loop 比人做得好；凡是需要审美判断的事（文案好不好、逻辑通不通、例子贴不贴切），还是得你在旁边。把对的任务交给循环，效率翻几倍；把错的任务交给循环，你只是在给 AI 制造加班的机会。

但最底层的道理没变：你写得越清楚，AI 做得越好。 不管是一条提示词还是一个循环，背后考验的都是你把需求表达清楚的能力。循环放大的是你的规范——规范好，放大好结果；规范差，放大坏结果。这和翔宇一直强调的核心方法论一致：自动化来自于标准化，标准化来自于结构化。

自检清单

• [ ] 用 /loop 成功启动过至少一个循环任务
• [ ] 尝试过自适应模式（不指定间隔）
• [ ] 在项目目录创建过 .claude/loop.md 文件
• [ ] 每个提示词都有预检查逻辑（无事可做时零消耗退出）
• [ ] 每个提示词都有退出条件（最大轮次或完成标记）
• [ ] 尝试过 /goal 命令（有明确终态的任务）
• [ ] 了解 /loop、/goal、桌面定时任务、云端 Routines 的区别和适用场景
• [ ] 知道间隔超过 5 分钟会导致缓存过期、成本上升
• [ ] 知道关终端就停——这是安全网不是缺陷
• [ ] 在提示词中指定了输出文件路径（结果不堆在对话里）

常见问题

/loop 关了终端还能跑吗？

不能。/loop 是会话级功能，关闭终端或退出 Claude Code 会话后所有循环立即停止。需要关机后运行的用桌面定时任务，需要完全离线运行的用云端 Routines。

最长能跑多久？

循环任务创建后 7 天自动过期。过期后执行最后一次然后自动删除。用 --resume 恢复会话时未过期的任务一起恢复。

/loop 和 /goal 有什么区别？

/loop 按时间间隔定期执行，适合轮询和监控。/goal 设定完成条件让 Claude 持续工作直到条件满足，适合有明确终态的长程任务。两者互补可组合。

怎么防止失控烧钱？

三条核心规则：间隔 5 分钟以内复用缓存；提示词加预检查（无事可做就退出）；加退出条件（最大轮次或完成标记）。

/loop 能不能跑自定义 Skill？

可以，这是最强大的用法。输入 /loop 20m /your-skill 即可定期执行封装好的 Skill。Skill 开发详见翔宇的 Skill 开发指南和 Skill 从入门到变现路线图。

Ralph Loop 和 /loop 有什么关系？

Ralph Loop 是社区在 /loop 发布前开发的方案，用停止钩子（Stop Hook）拦截退出实现反复执行。/loop 是 Anthropic 受此启发推出的官方功能。核心区别：Ralph 每次启动新会话（上下文干净），/loop 在同一会话内累积。

/loop 适合什么样的任务？

最适合三类：定期轮询外部状态（部署、收录、排名变化）、周期性维护（依赖升级、代码清理、文档更新）、需要反复检查的监控（竞品动态、日志异常、SEO 指标）。

云端定时任务和 /loop 怎么选？

工作期间的临时监控用 /loop（零配置即开即用）；每天固定时间要做的事用桌面定时任务（关了会话也跑）；完全不依赖本地机器的用云端 Routines（最小间隔 1 小时）。

能同时跑几个任务？

每个会话最多 50 个并发调度任务。多个任务同时到期时按队列依次执行，不会中断正在进行的对话。

不给间隔会怎样？

Claude 进入自适应模式——根据上次执行的观察结果自行决定间隔，范围 1 分钟到 1 小时。有变化时查得勤，没变化时查得松。通常比固定间隔更省钱。

loop.md 怎么用？

在项目目录放 .claude/loop.md（项目级）或 ~/.claude/loop.md（用户级），写入默认循环指令。之后裸输入 /loop 时 Claude 读这个文件。编辑后下次循环立即生效，上限 25,000 字节。

/loop 能和 /goal 一起用吗？

可以。常见组合：/loop 每隔一段时间检查任务列表，对每个任务用 /goal 的条件判断是否已完成。这是 Boris Cherny 本人使用的模式。

相关教程

• Claude Code 是什么？新手一篇看懂
• Claude Code 完整学习指南：13 个知识点地图
• Claude Code 最佳实践完整指南
• Claude Code Hooks 指南：8 个检查点怎么用
• Claude Code 子代理与多代理协同指南
• Claude Code 斜杠命令指南
• Claude Code Skill 开发指南
• Claude Code 动态工作流指南
• Claude Code 上下文窗口与 Auto Compact 指南
• Claude Code 权限与安全沙箱指南
• CLAUDE.md 最佳实践：Karpathy 四原则 + 6 套模板
• 什么是 Harness Engineering（驾驭工程）
• Agent 编程方法论：不教工具教方法

参考来源

• Claude Code 官方文档：定时任务与 /loop
• Claude Code 官方文档：/goal 完成条件
• Anthropic 官方视频：构建主动式代理工作流
• Addy Osmani：Loop Engineering（2026-06-08）
• Addy Osmani：Long-Running Agents（Substack）
• Jiri Dolejs：用 /loop 把 Claude Code 变成自主代理
• Pat Walls：能不能在循环里创建一个生意（DEV Community）
• Simon Scrapes：Build Self-Improving Claude Code Skills（YouTube）
• Kieran Flanagan：11-Skill 内容团队（YouTube）
• Claude Code Guide：6 个过夜循环创意

获取完整配置和提示词模板

本文介绍了 /loop 的十个实战场景和核心配置方法。如果你想获得更多可直接复制的 loop.md 模板、Skill 工作流编排方案、以及进阶的多 Agent 协作配置，可以在翔宇的 AI 编程实操课 中找到完整的配置文件和手把手教程。