企业官网建设流程全解析

随着 AI Agent 越来越强，Loops 逐渐成为大热门，就像曾经的 Prompts，Skills。它们一次次预示着 AI 又迈上了一个新台阶。

眼下，AI 来到了“自动驾驶”时代，你设定好目的地（目标），它自己会规划路线、自己驾驶、观察路况、修正方向，直到把你送到地方，全程不需要你手动操作方向盘。

关于“设计循环（designing loops）而非给你的编码智能体写提示词”的讨论越来越多。如果你花点时间搞清楚一个循环到底是什么，会看到五花八门的答案。

Claude 开发者官方账号刚刚发布一篇 Loops 入门教程，教你怎么坐上 AI 自动驾驶仓。

在 Claude Code 团队里，循环（loop）定义为：智能体反复执行一段工作循环，直到某个停止条件被满足。

他们依据以下几个维度，把循环划分成了几种不同类型：

• 它们如何被触发

• 它们如何被停止

• 它们使用哪种 Claude Code 原语（primitive）

• 每种循环最适合哪类任务

主要的循环类型有哪些？各自的适用场景是什么？在控制 token 消耗的同时如何维持代码质量？这篇入门教程都给你讲明白了。

并非所有任务都需要复杂的循环，从最简单的方案入手，按需选用这些模式。

基于轮次的循环

• 触发方式（Triggered by）：用户提示词（prompt）。

• 停止条件（Stop criteria）：Claude 判断任务已完成，或需要更多上下文。

• 最适用于（Best used for）：较短、且不属于常规流程或排程的任务。

• 用量管理（Managed usage by）：撰写具体的提示词，并通过 skills 强化验证环节，从而减少所需的轮次。

你发出的每一条提示词都会启动一个手动循环，由你主导每一轮。Claude 会收集上下文、采取行动、自检工作、必要时重复，最后给出回应。

举个例子，让 Claude 创建一个点赞按钮。它会读取你的代码、做修改、跑测试，然后交还一个它认为能跑的东西。接下来你手动检查这版工作成果，再写下一条提示词。

你可以把“验证”这一步做得更强：把你那些手动步骤编码进SKILL.md，让 Claude 能够端到端地自检更多工作。这应当包括让 Claude 可以看见、测量或与之交互最终结果的工具或连接器。检查越能量化，Claude 自检就越容易。

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

---name: verify-frontend-changedescription: 在声明完成之前，验证任何端到端的UI更改。---# Verifying frontend changes切勿仅凭成功编辑就将UI更改报告为完成。按照人类审阅者的方式进行验证：1.启动开发服务器，在浏览器中打开编辑后的页面。2.直接与变化互动。对于新控件（按钮、输入、切换）：单击它，确认预期的状态更改，并在之前/之后截图。3.检查浏览器控制台：无新错误或警告。4.使用Chrome Devtools MCP，运行性能跟踪并审核核心Web生命周期。如果任何步骤失败，请修复问题并从步骤1重新运行——不要退回部分验证的工作。

基于目标的循环，/goal

• 触发方式：实时手动提示词。

• 停止条件：目标达成，或达到最大轮次数。

• 最适用于：具有可验证退出条件的任务。

• 用量管理：设定明确的完成条件以及显式的轮次上限，例如“在 5 次尝试后停止”。

有时候一轮并不够，尤其是更复杂的任务。智能体在能够迭代时表现会更好。你可以用/goal定义“什么算完成”，从而延长 Claude 的迭代过程。

当你定义了成功标准后，Claude 就不必自己判断什么叫“够好”而过早结束循环。

每次 Claude 试图停下时，一个评估模型（evaluator model）会检查你设定的条件，并把它打回去继续工作，直到目标达成或达到你设定的轮次上限。

这就是为什么确定性条件会如此有效。比如通过的测试数量、或越过某个分数阈值：

/goal 主页Lighthouse得分达到90分或以上，尝试5次后停止。

基于时间的循环，/loop和/schedule

• 触发方式：指定的时间间隔。

• 停止条件：你手动取消，或工作完成（PR 合入、队列为空等）。

• 最适用于：周期性工作，或需要与外部环境/系统对接的场景。

• 用量管理：设置更长的间隔，或改为基于事件（event）响应而非基于时间。

有些 agentic 工作是周期性的，任务本身不变，只是输入在变。例如，每天早上汇总 Slack 消息。

另一些工作则依赖外部系统，对接它们的一种简单做法就是按时间间隔去检查、并对变化做出反应。例如，一个 PR 可能会收到代码评审意见或 CI 失败。

对这些场景，你可以用/loop控制 Claude 何时运行。它会在指定间隔上反复执行一段提示词。

例如：

/loop 5分钟一次检查我的PR，处理审核意见，并修复失败的CI。

/loop跑在你自己的电脑上，所以一旦你关机，它就停了。你可以用/schedule创建一个 routine，把循环搬到云端运行。

主动式循环

• 触发方式：由事件或排程触发，过程中没有人在实时参与。

• 停止条件：每一个任务在其目标达成时退出；routine 本身则一直运行，直到你把它关掉。

• 最适用于：源源不断、定义良好的周期性工作：bug 报告、issue 分诊（triage）、迁移、依赖升级等。

• 用量管理：把 routine 路由到更小、更快的模型上，只在需要判断决策时调用最强大的模型。

上面提到的原语，再加上 Claude Code 的其他能力，例如 auto mode 和研究预览版 dynamic workflows（动态工作流），可以组合成一个用于长时间运行工作的循环。

例如，要处理源源不断反馈进来的意见，你可以这样组合：

• 用/schedule（研究预览版）跑一个 routine，定期检查是否有新报告；

• 用/goal定义“什么算完成”，并用 skills 文档化如何验证它；

• 用 Dynamic workflows 编排多个 agent：分别负责分诊每份报告、修复问题、并复核修复；

• 用 auto mode 让 routine 不必停下征求许可而持续运行。

组合起来，一段提示词可以长这样：

/schedule 每小时：查看项目反馈渠道中的bug报告。/goal: 在发现此运行的每个报告都经过分类、处理和响应之前，不要停止。在修复错误时，使用工作流在并行工作树中探索三个解决方案，并让裁判对其进行对抗性审查。

代码质量、Token 消耗与快速上手

一个循环产出的质量，取决于围绕它搭建的整套系统。

在设计这套系统时：

• 保持代码库本身整洁：Claude 会沿用你代码库里已有的模式与约定。

• 给 Claude 一种自检的方式：用 skills 把“你和团队眼中什么样算好”编码下来。

• 让文档触手可及：框架与库的文档要随时能拿到最新最佳实践。

• 用第二个 agent 做代码评审：带着全新上下文的评审者偏见更少，不会被主 agent 的推理带偏。你可以用内置的/code-reviewskill，或针对 GitHub 使用 Code Review。

当某一次产出不达标时，不要止步于修掉这一处个别问题，试着把它编码进系统里，让未来每一次迭代都受益。

为控制 token 消耗，循环应当有清晰的边界：

• 为任务选对原语和模型：较小的任务用不上多 agent 或循环；有些任务可以用更便宜、更快的模型。

• 定义清晰的成功与停止条件：把“什么算完成”说清楚，让 Claude 更快抵达答案（但别快得过头）。

• 大规模运行前先试点：Dynamic workflows 可能会派出几百个 agent。先用一小片工作量摸一摸用量。

• 确定性的工作用脚本：跑脚本比让模型推理每一步更便宜。例如，某个 PDF skill 可以附带一段填表脚本，让 Claude 每次直接运行，而不是每次重新推导代码。

• 别比实际需要更频繁地跑 routine：把间隔对齐到“你正在盯的那件事”实际变化的频率。

• 回顾用量：/usage命令会按 skills、子 agent 和 MCP 拆解最近用量；不带参数的/goal会显示到目前为止的轮次数与 token 用量；/workflows显示每个 agent 的 token 用量，且你随时可以停掉某个 agent。

要上手循环，先看看你已经在做的工作。

挑出你自己成了瓶颈的那一项任务，问问自己：你能把哪一块交出去？验证检查你能写下来吗？目标够清晰吗？这工作是按排程到来的吗？

有了想法之后，跑起循环，观察结果，看它在哪里卡住、在哪里做过头，然后反复迭代。

参考资料：

https://x.com/ClaudeDevs/status/2074208949205881033