Claude Code团队「四种循环」官方曝光！从手动到全自动，开发者工作流变天

公众号名称：程叙架构与AI.

作者名称：AI兴观点

发布时间：2026-07-05 20:18

✅点击上方🔺公众号🔺关注我✅

原文：Getting started with loops | Claude Blog 作者：Delba de Oliveira & Michael Segner | 2026年6月30日

“设计循环”是现在编程圈讨论最热的方向——替代了过去”给编程助手写提示词”的思路。但你要是去 X 上搜一圈”loop 到底是什么”，每个人给的答案都不太一样。

Claude Code 团队给出的定义很直接：循环就是代理重复工作，直到某个条件让它停下来。 按触发方式、停止条件、用了什么原语、适合什么任务，他们分了四类。

这篇文章是团队自己的总结。四种循环，各自什么时候用、怎么保证代码质量、怎么控制 token——都在下面了。

不过不是所有任务都需要复杂循环，从最简单的方案开始，你需要的时候再用这些模式。

Turn-based loops：最基本的交互模式

触发方式：用户输入提示词
停止条件：Claude 判断任务已完成或需要更多上下文
最适用于：不属于定期流程或日程的短任务
成本控制：写精准的提示词，用 skills 改善验证环节，减少交互轮次

你发的每个提示词都是一个手动循环——你指挥每一步，Claude 收集上下文、采取行动、检查结果、需要就重来，最后回复。这就是”代理循环”。

举个例子：让 Claude 创建一个点赞按钮。它会读你的代码、做修改、跑测试、然后交回一个它认为能跑的东西。你手动检查结果，写下一个提示词。

改进方法：把验证步骤写成 SKILL.md，让 Claude 能端到端地自动检查。

比如在你的 SKILL.md 里指定：

---
name: verify-frontend-change
description: 端到端验证 UI 变更，确认完成后才算完
---

# 验证前端变更
永远不要只靠"编辑成功"就声明 UI 变更已完成。像人工审查那样验证：

1. 启动开发服务器，在浏览器中打开刚编辑的页面
2. 直接操作变更内容。如果是新的控件（按钮、输入框、开关）：点击它，确认状态变化，截前后对比图
3. 检查浏览器控制台：零新错误或警告
4. 用 Chrome Devtools MCP 跑性能分析和 Core Web Vitals 审核

任何一步失败，都要修复并从头重跑——不要交回部分验证的工作。

Goal-based loop（/goal）：定义什么是”做完”

触发方式：实时手动提示
停止条件：达成目标或达到最大轮次
最适用于：有可验证退出标准（exit criteria）的任务
成本控制：设定具体的完成条件和明确的轮次上限，比如”尝试 5 次后停止”

有时候一轮不够，尤其是复杂任务。代理在能迭代的时候表现更好。用 /goal 定义”做完”的标准，就能延长 Claude 的迭代时间。

关键在于：当你定义了成功标准，Claude 就不需要自己判断什么是”够好了”然后提前喊停。每次它想停的时候，评估模型都会检查你的标准，没达标就送回继续，直到目标达成或轮次用尽。

这也就是为什么用”通过多少测试”或”达到多少分”这种确定性标准特别管用。

举个例子，用 /goal 命令：

/goal 把首页 Lighthouse 分数做到 90 或以上，尝试 5 次后停止

Time-based loop（/loop 和 /schedule）：定时检查模式

触发方式：指定的时间间隔
停止条件：你取消它，或工作完成（PR 合并了、队列空了）
最适用于：重复性工作，或需要与外部环境/系统对接
成本控制：设置更长的时间间隔，或用事件驱动替代时间驱动

有些代理工作是重复性的：任务不变，只有输入在变。比如每天早上汇总 Slack 消息。还有些工作依赖外部系统，简单的方式就是定时检查，根据变化做出响应。比如等待 PR 收到 Code Review 或 CI 失败。

/loop 定时重复运行一个提示词。例子：

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

/loop 在你本机运行，关掉就停。如果你想把循环迁移到云端，用 /schedule 创建例行任务。

Proactive loops：没有人坐在终端前

触发方式：事件或定时，没有人在线实时参与
停止条件：每个任务在达成目标后退出，例行任务本身持续运行直到你关掉
最适用于：定义明确的重复性工作流：Bug 报告、Issue 分类、迁移、依赖升级等
成本控制：例行任务用更小更快的模型，最强大的模型只留作判断决策

上面的原语加上 Claude Code 的 auto mode 和 dynamic workflows（研究预览版），可以组合成一个长期运行的工作循环。

比如处理用户反馈：

/schedule（研究预览版）定时检查新报告
/goal 定义做完的标准 + skills 记录验证方式
Dynamic workflows 编排多个代理分别分类、修复和审查
Auto mode 让例行任务无需中途停下来请示

组合起来大概是这样：

/schedule 每小时一次：检查 #project-feedback 中的 bug 报告。/goal：每次运行时，所有找到的报告都要被分类、处理、回复才算完。修 bug 时，用 workflow 在并行工作区探索三个解决方案，让评审代理对抗性审查。

保持代码质量

循环的输出质量取决于它周围的系统。设计系统时：

保持代码库本身干净：Claude 会沿袭代码库中已有的模式和惯例
给 Claude 验证自己工作的方式：用 skills 编码”好”的标准
让文档容易获取：框架和库的文档要包含最新最佳实践
用第二个代理做代码审查：新鲜上下文的审查者偏差更小，不受主代理推理的影响。可以用 Claude Code 内置的 /code-review skill 或 GitHub Code Review 集成

当单个结果不合标准时，别只修这个个案——把它编码到系统里，让所有未来的迭代都受益。

控制 Token 开销

循环需要有清晰的边界来控制 token：

为工作选择正确的原语和模型：小任务不需要多个代理或循环，有些任务可以用更便宜更快的模型跑
定义清晰的成功和停止标准：具体说明”做完”是什么样，让 Claude 尽快达成（但别太快）
大规模运行前先试点：Dynamic workflows 可以生成数百个代理，先在更小的切片上评估用量
确定性工作用脚本：跑脚本比通过推理来执行步骤便宜得多。比如 PDF skill 可以附带一个表单填充脚本，每次 Claude 直接跑，不用重新推导代码
不要让例行任务的频率超过实际需要：匹配你要监控对象的变化频率
审查用量：/usage 按 skills、子代理、MCP 分解用量；/goal（无参数）显示轮次和 token 用量；/workflows 显示每个代理的 token 用量，随时可以停止

总结对照表

循环类型	你交出什么	什么时候用	用什么
Turn-based	检查	你在探索或做决定	自定义验证 skills
Goal-based	停止条件	你知道做完是什么样	`/goal`
Time-based	触发	工作在项目外部，按计划进行	`/loop`, `/schedule`
Proactive	提示词	工作是重复且定义明确的	以上全部 + dynamic workflows

怎么开始？

看看你已经做的工作。挑一个你是瓶颈的任务，问问自己能交出哪一块：你能写出验证检查吗？目标够清晰吗？工作是否按计划

到达？

一旦有了想法，就跑起来，观察结果——看它在哪儿卡住了或做过了头，别怕迭代。

原文作者：Delba de Oliveira 和 Michael Segner

如果觉得这篇文章有帮助，欢迎点赞、在看、转发！有问题也可以在评论区留言，我会尽量回复！

内容效果不满意？点此反馈