Claude Code循环：AI编程从写指令到设计系统的转变

「不再手动编写提示词了」——近期，这一说法在AI开发社区引发了广泛讨论。

从主导OpenClaw项目、如今在OpenAI负责下一代个人智能体研发的Peter Steinberger，到Claude Code的核心开发者Boris Cherny，再到将这一趋势命名为「循环工程」的谷歌工程师Addy Osmani，一众行业顶尖从业者都已经转向了循环开发模式。

Boris Cherny表示，自己现在几乎不再亲手撰写提示词，而是通过一个智能体来完成提示词的编写工作，自己只需要和这个负责协调的智能体直接对话即可。他甚至提到，十年之后，循环相关的功能将成为自己最引以为傲的工作成果之一。

Peter Steinberger则更进一步，他建议开发者不要再直接给编程智能体编写提示词，而是应该设计用于投喂提示词的循环系统。他在社交平台上展示了自己的循环方案：让Codex每5分钟自动运行一次，完成代码仓库维护、任务分派等工作，部分任务可以完全自主落地执行。

那么，这些大佬口中反复提及的「循环」到底是什么？Claude Code团队在官方博客中给出了明确的定义，并梳理了四种典型的循环类型，为智能体的自动化工作建立了工程规范。

可以说，四种循环类型其实对应了四种不同的停止条件，这也是理解相关技术文档的核心要点。Claude Code从触发机制、停止条件、适用原语和应用场景四个维度，将循环划分为四大类。

1. 回合制循环（turn-based）

这种模式由人类逐轮控制，用户每发送一次指令，智能体就运行一轮任务，用户检查结果后再发起下一轮请求，全程由用户掌握主动权。它适合零散的短期任务，不需要纳入固定流程或日程安排。

如果想要减少来回沟通的次数，可以将日常手动检查的步骤写入规范文件，让智能体自行完成验收。检查规则越量化，智能体就越能自主判断任务是否完成，需要用户干预的环节也就越少。

2. 目标循环（/goal）

用户先明确设定具体的目标，例如「将首页的性能评分提升至90分以上，最多尝试5次」。每当智能体尝试完成任务后，就会有一个评估模型对照用户设定的标准进行校验，如果未达标就将任务打回，让智能体继续优化，直到达成目标或者用完设定的尝试次数。

测试通过率、分数阈值这类可量化的标准非常实用，因为它不需要智能体自行判断「是否足够好」，而是由评估模型直接给出结论，避免智能体过早停止迭代，让循环能够干净利落地完成。

3. 时间循环（/loop和/schedule）

这种循环按照固定的时间间隔触发，就像日常使用的闹钟一样。有些任务是重复性的，任务本身不变但输入数据会变化，比如每天早上自动整理消息汇总。还有些任务需要持续监控外部系统，最简单的方式就是按固定时间间隔检查状态变化，比如监控可能收到评审意见或者构建失败的任务请求。

使用/loop指令可以按照设定的间隔重复执行某一条提示词，如果希望智能体在用户离线后仍然持续运行，可以通过/schedule指令将循环部署到云端执行，这套逻辑和程序员熟悉的定时任务机制非常相似。

4. 主动循环（proactive）

这种循环由事件或时间触发，全程无需人工值守。配合自动模式和动态工作流，可以将长任务完全自动化串联起来：比如每小时扫描一次反馈渠道，收到新的问题报告后，自动完成问题分类、代码修复和结果回复的全流程，全程不需要向用户请求权限。

单个任务达成目标后就会自动退出，而持续性的例行任务则会一直运行直到用户手动关闭。这类循环适合处理源源不断、边界清晰的工作，比如问题上报处理、数据分类、依赖包升级等。

从底层机制来看，这套循环系统的核心非常简单：智能体先对用户的提示词进行评估，调用相关工具完成实际工作，获取执行结果后再次进行评估，如此循环往复，直到某一轮不再需要调用任何工具，才会输出最终的执行结果。所谓的自主智能体，本质上就是这样一个闭环的工作流程。

当然，我们不能将循环设计看作是从零开始的全新革命。定时任务、流程编排、反馈循环这些概念早就已经存在，相关团队的贡献更多是将这些实践统一命名，并整理成一套标准化的分类体系。那么，到底是什么发生了真正的变化？核心在于「停止条件」的设计。

在官方总结的实战技巧中，被列为最有价值的一条是「验证机制」：为智能体提供能够自行检查产出结果的方式。这个道理其实很好理解，就像让工程师开发网页却不提供可视化工具，很难保证最终的效果；如果有了校验工具，开发者可以每修改一次就验证结果，反复调整直到满意为止。模型循环的强大之处，恰恰就来自这种「自我闭环」的能力。

在这个过程中，提示词并没有消失，而是退化成了循环系统中的一个组件。真正的核心工作，变成了停止条件设计、验证器开发、token预算控制和多轮执行策略的制定。

没有闸门的循环：强大但危险

很多人会认为循环意味着可以完全放手让智能体自主工作一整天，但实际上并非如此。循环至少面临两大核心风险：

• 成本问题：没有上限的循环会快速消耗token预算，导致高额的API费用。正如相关从业者所说，只有享受免费福利的少数人才能无顾虑地使用，普通开发者必须考虑成本控制。
• 无效循环：智能体可能陷入看似有进展但实则原地打转的死循环，反复修改同一个文件却始终无法通过测试，甚至会将错误的方案越做越「完整」。

行业社区对此的共识非常明确：循环本身能力强大，但如果没有设置「闸门条件」就会非常危险。开发者总结了三个必须在编写循环前就设计好的闸门：

官方也给出了一套完整的成本控制原则：小型任务不要强行使用多智能体模式；能够使用轻量快速的小模型完成的任务，就不要全部使用最强的大模型；大规模部署前，先使用小范围样本进行测试；确定性的任务交给脚本执行，脚本运行的成本远低于让模型逐步推理；例行任务的执行频率不要高于实际需要的频次。

因此，循环本质上是一套「如何管控智能体」的设计方案，而不是放任智能体自由运行的工具。这也决定了循环目前最适合的应用场景是边界清晰的结构化任务，而非天马行空的开放性创作。

从拼提示词到拼系统设计

这一轮AI编程的变革，真正改变的是开发的重心：从「单次指令的内容设计」转向「整套行为系统的设计」。过去开发者需要设计的是单条指令的具体内容，而现在需要设计的是智能体的完整工作流程：如何触发任务、如何验证结果、如何停止循环。

官方为想要尝试循环设计的开发者提供了一个简单的切入点：观察自己日常工作中的瓶颈环节，然后回答三个问题：

只要其中任何一个问题的答案是肯定的，你就找到了第一个可以交给智能体自动执行的循环任务。

AI编程领域的竞争已经从最初的「谁能写出更好的提示词」，转向了「谁能设计出更高效的自动化循环系统」，也就是能够让智能体自行验证结果、自主判断停止时机的系统。手动编写提示词的时代不会立刻消失，但它的行业光环正在逐渐向循环设计转移，而真正掌握循环设计能力的开发者，才刚刚站上这个赛道的起点。