循环入门教程

现在有很多人讨论，与其给你的编码代理下提示，不如“设计循环”。如果你花些时间在 X 上试图弄清楚循环到底是什么，你会看到各种不同的答案。

在 Claude Code 团队，我们将循环定义为：代理重复执行工作周期，直到满足停止条件为止。我们会根据以下几个方面，将循环分成不同类型：

• 如何触发
• 如何停止
• 使用了哪种 Claude Code 原语
• 何种任务最适合该类型

我们将介绍主要的循环类型、各自的适用场景，以及在管理 token 使用的同时如何保持代码质量。并非所有任务都需要复杂的循环；应从最简单的方案开始，按需选择性使用这些模式。

• 触发方式：用户提示词。
• 停止条件：Claude 判断自己已完成任务，或需要更多上下文。
• 最适合：不属于固定流程或计划的短任务。
• 管理方式：编写具体提示，并通过 skills 改进验证，以减少回合数。‍

你发送的每个提示都会启动一个手动循环，由你来指挥每一轮。Claude 会收集上下文、采取行动、检查结果、必要时重复，然后给出回应。我们称之为 agentic loop。

例如，让 Claude 创建一个点赞按钮。它会阅读你的代码，进行修改，运行测试，然后返回它认为可用的结果。接着你再手动检查，并写下下一条提示。

你可以把自己的手动步骤编码成一个 SKILL.md，从而改进验证步骤，让 Claude 能够端到端地检查更多自己的工作。这应当包括工具或连接器，以便让 Claude 看到、测量或与结果交互。检查越具可量化，Claude 自我验证就越容易。

例如，在你的 SKILL.md 文件中，你可以这样写：

---
name: verify-frontend-change
description: 在宣布完成前，端到端验证任何 UI 变更。
---

# 验证前端变更
不要仅仅因为编辑成功就把 UI 变更报告为完成。要像人工审查者一样进行验证：

1. 启动开发服务器，并在浏览器中打开已编辑页面。
2. 直接与变更交互。对于新的控件（按钮、输入框、开关）：点击它，确认预期状态变化，并在前后分别截图。
3. 检查浏览器控制台：确保没有新的错误或警告。
4. 使用 Chrome Devtools MCP，运行性能追踪并审计 Core Web Vitals。

如果任何一步失败，修复问题后从第 1 步重新执行——不要把部分验证过的工作交回。

• 触发方式：实时手动提示。
• 停止条件：目标达成，或达到最大回合数。
• 最适合：具有可验证退出条件的任务。
• 管理方式：设置明确的完成标准和显式回合上限，例如“重试 5 次后停止”。

有时，一个回合不够，尤其是在更复杂的任务中。代理如果能够迭代，表现会更好。你可以通过用 /goal 定义“完成”的样子，来延长 Claude 持续迭代的时间。

当你定义好成功标准后，Claude 就不必自行判断什么算“足够好”并过早结束循环。每当 Claude 试图停止时，评估模型都会检查你的条件，并把它送回去继续工作，直到目标达成或达到你定义的回合数为止。

这就是为什么像“通过的测试数量”或“清除某个分数阈值”这类确定性标准如此有效。

例如：

/goal 将主页 Lighthouse 评分提升到 90 或以上，重试 5 次后停止。

• 触发方式：指定的时间间隔。
• 停止条件：你取消它，或者工作完成（PR 合并、队列清空）。
• 最适合：周期性工作，或与外部环境/系统交互。
• 管理方式：设置更长的间隔，或基于事件而不是时间做出响应。

有些 agentic 工作是周期性的：任务本身不变，变化的只有输入。例如，每天早上总结 Slack 消息。另一些工作则依赖外部系统，与之交互的一种简单方式是按固定间隔检查并对变化做出响应。例如，可能会收到代码评审意见或 CI 失败的 PR。

对于这些场景，你可以通过运行 Claude 的 /loop 来触发，它会按间隔重复执行一条提示。例如：

/loop 5m 检查我的 PR，处理评审意见，并修复失败的 CI

/loop 在你的电脑上运行，所以如果你关闭它，它就会停止。你也可以通过 /schedule 创建一个 routine，把循环迁移到云端。

• 触发方式：事件或计划触发，无需人实时介入。
• 停止条件：每个任务在达成目标后退出；routine 本身会一直运行，直到你将其关闭。
• 最适合：定义明确的周期性工作流，如 bug 报告、问题分流、迁移、依赖升级等。
• 管理方式：将 routine 路由给更小、更快的模型，并在需要判断时使用最强大的模型。

上面的原语，再加上 Claude Code 的其他功能，如自动模式和动态工作流（研究预览），可以组合成一个用于长时间运行工作的循环。

例如，要处理传入反馈，你可以这样使用：

1. 使用 /schedule（研究预览）运行一个 routine，检查新的报告
2. 使用 /goal 定义“完成”的标准，并用 skills 记录如何验证
3. 使用动态工作流来编排代理，对每条报告进行分流、修复并审查修复结果
4. 使用自动模式，让 routine 在运行时无需停下来请求权限

组合起来，一个提示可能像这样：

/schedule 每小时执行一次：检查 project-feedback 频道中的 bug 报告。/goal：不要停止，直到本次运行中找到的每条报告都完成分流、处理并回复。修复 bug 时，使用工作流在并行 worktree 中探索三种解决方案，并让评审者对它们进行对抗式审查。

一个循环输出的质量取决于其周围的系统。在设计系统时：

• 保持代码库本身整洁：Claude 会遵循你代码库中已存在的模式和约定。
• 给 Claude 一种验证自己工作的方式：用编码出对你和团队而言什么是“好”的标准。
• 让文档易于获取：框架和库的文档包含最新最佳实践。
• 使用第二个代理进行代码审查：拥有新鲜上下文的审查者偏见更少，也不会受主代理推理过程的影响。你可以使用内置的 /code-review skill，或为 Github 使用。

当某个单独结果不达标时，不要只停留在修复这个个体问题上，而要尝试将其编码进去，以改进整个系统，惠及未来所有迭代。

为管理 token 使用，循环应当有清晰边界：

• 为任务选对原语和模型：较小的任务不需要多个代理或循环。有些任务可以使用更便宜、更快的模型。
• 定义清晰的成功与停止标准：明确“完成”是什么样子，这样 Claude 能更快到达解决方案（但又不要太快）。
• 在大规模运行前先试点：动态工作流可以生成数百个代理。先在较小样本上评估使用量。
• 对确定性工作使用脚本：运行脚本比逐步推理更省成本。例如，PDF skill 可以附带一个表单填写脚本，供 Claude 每次运行，而不是重新推导代码。
• 不要比需要的更频繁地运行 routine：把间隔与你关注的事物变化频率匹配起来
• 审查使用情况：/usage 命令会按 skills、子代理和 MCP 拆解最近使用情况，/goal 在不带参数时会显示当前回合数和 token 使用量，/workflows 会显示每个代理的 token 使用量，而且你可以随时停止某个代理。

总结如下：

循环	你交出去的部分	适用场景	应优先使用
按回合	检查	你正在探索或做决策时	自定义验证 skills
基于目标	停止条件	你知道“完成”长什么样时	/goal
基于时间	触发器	工作在你的项目之外、按计划发生时	/loop ，/schedule
主动式	提示词	工作是周期性的且定义明确时	以上全部，以及动态工作流

要开始使用循环，先看看你已经在做哪些工作。挑一个你是瓶颈的任务，问问其中哪一部分可以交出去：你能写验证检查吗？目标是否足够清晰？工作是否按计划到来？

一旦有了想法，就运行这个循环，观察结果，比如它在哪里卡住或过度扩展，并且不要害怕对其进行迭代。