一个正在发生的范式切换

如果你最近还在研究"怎么写好提示词"，可能已经错过了AI编程领域正在发生的最大变化。

这不是一个渐进式的改进，而是一个拐点。这个拐点由两个关键人物几乎同时引爆：

• Boris Cherny，Claude Code的创建者（Anthropic），在一次分享中说了一句被反复引用的话："我现在已经不自己给Claude写提示词了。我有循环（loops）在运行，它们负责提示Claude、决定下一步做什么。我的工作变成了写循环。"
• Peter Steinberger，"龙虾"（OpenClaw/Crawd）的创造者，现在OpenAI任职。他在X平台上几乎同时发声："你不应该再给你的编程Agent写提示词了。你应该设计循环（loops），让循环去提示你的Agent。"

两位各自赛道最具影响力的实践者，从不同的方向，走到了同一个结论上。

这个结论正在催生一个新概念——Loop Engineering（循环工程）。而它的本质，是提示词工程（Prompt Engineering）的终结。

参考：InfoQ《大人，AI编程又变天了！Claude Code之父、龙虾创始人同时力捧新范式，杀死提示词工程？》，2026年6月

提示词工程的宿命

要理解为什么"循环"会取代"提示词"，先要理解提示词工程的天花板在哪里。

过去两年，"写提示词"是AI编程的核心技能。你写一段指令，Agent执行一次，你检查结果，再写下一段指令。本质上，你充当了循环中的调度器——每次对话之间的大脑切换。

这个模式有几个内在限制：

第一，它是手工操作。 每一轮人机交互都需要你主动参与。你不可能在睡觉的时候让Agent继续工作，因为"下一轮"的提示词还没写。

第二，它依赖"人在回路中"。 Agent每完成一个步骤，都要等你检查、判断、给出下一步指令。这个模式对于单次任务还能接受，但对于跨天、跨周、需要持续迭代的大型项目，效率瓶颈在你，不在Agent。

第三，它无法规模化和并发。 一次只能处理一个任务，一个上下文窗口。你想同时推进多个特性的开发？那你需要同时写多套提示词、管理多个会话——这本质上又回到了手工操作。

提示词工程的天花板，不是"写得不够好"，而是"人成了这个系统中最慢的节点"。

循环工程：五块积木

那所谓的"循环"到底是什么？它不是简单的"定时任务"或"设置好让它自动运行"。Addy Osmani（Google Chrome团队的前端技术专家）在一篇详细的技术分析中，拆解了循环工程的核心结构：

引用：Addy Osmani, "Loop Engineering", addyosmani.com, 2026

一个有效的循环需要五个基本构件，再加上一个持久化的状态存储：

1. 自动化调度

循环的"心跳"。按设定频率自动执行发现和分类任务，把结果推给你，而不是等你去查。Claude Code通过/loop、/goal和定时任务实现；Codex通过Automations选项卡实现。

2. 工作树隔离

当你并行运行多个Agent时，文件冲突是最大的失败模式。Git worktree让每个Agent在自己的独立工作目录中运行，互不干扰。

3. 技能定义

把项目知识、编码规范、构建步骤写成SKILL.md。每个Agent启动时自动加载，不用每次都从零解释项目上下文。这是防止循环"退化"的关键——循环不是机械重复，而是在规则下迭代。

4. 插件与连接器

让循环能够触及你的真实工具链——Issue Tracker、数据库、CI管道、Slack频道。没有连接器的循环只能操作文件系统，有了连接器，它能自动开PR、关联Ticket、在CI通过后发通知。

5. 子Agent分离

写作代码的Agent不应该同时负责检查代码。模型对自己的产出过于宽容。一个独立的验证Agent——有时使用不同的模型、不同的指令——才能发现第一个Agent自己"说服自己"通过的缺陷。

+1：状态存储

循环运行在时间中，而模型没有跨会话的记忆。一个Markdown文件、一个Linear Board——任何能持久化记录"什么已做完、什么待做、什么试过但失败"的外部状态——是整个循环的脊柱。

循环工程的核心洞察：判断力的转移

理解了这五块积木之后，一个更根本的洞察浮现出来：

循环工程不是"让AI自己干活"，而是"把你从调度者的角色提升到设计者的角色"。

你还是那个做判断的人。你只是不再逐行调度，而是在更高的抽象层次上设计规则、设定目标、验证结果。

Boris Cherny的原话其实包含了一个更锋利的信息——难度没有降低，只是杠杆点转移了。

提示词工程时代，你要精准地告诉Agent"怎么做"。循环工程时代，你要精准地设计一个系统，让Agent自己知道"什么时候该做什么"——这比写提示词更难，因为你不是控制一个节点，而是设计整个网络。

Peter Steinberger对这一点有一个非常形象的实践："我发的代码我自己都没读过。" 他的意思是，循环已经替他完成了代码审查、测试验证、质量门禁，他只需要在关键节点上做取舍。这不是不负责任，而是把验证能力也编进了循环里。

参考：The Pragmatic Engineer, "The creator of Clawd: 'I ship code I don't read'", 2026

挑战与边界

循环工程距离"全面落地"还有很长的路要走。

最直接的问题是成本。 一个循环运行一天，可能产生数十万甚至上百万的Token消耗。对于Token"富裕"的团队（比如Anthropic的Boris Cherny），这是可以接受的成本；但对于预算有限的个人开发者或中小团队，这可能是一个巨大的负担。

调试的复杂性也成倍增加。 提示词出错了，你调试的是几行指令。循环出错了，你要调试的是一个经过了数十轮迭代的状态机。这不是"改了重启"就能解决的问题，它需要完全不同的调试工具和心智模型。

上下文窗口的限制仍然存在。 让一个Agent连续运行数小时甚至数天，上下文窗口会被撑满，早期信息会被遗忘，模型会产生"上下文腐烂"——逐渐偏离最初设定的目标，或者把半成品当成最终结果。

解决这些问题的方向是双轨并行的：一方面提升模型本身的能力（更大的上下文窗口、更强的长期规划能力），另一方面改造外部的Agent脚手架架构——比如引入生成器/评估器分离的架构，让每个Agent的上下文保持独立和聚焦。

参考：InfoQ《大人，AI编程又变天了》原文，"生成器、评估器和规划器分离的架构……利用拥有独立上下文的评估器对代码进行严格的真实环境测试与主观质量打分"

从提示词工程到循环工程，意味着什么

这篇文章并不是在宣告提示词工程"已死"。对于单次的、明确的、定义清晰的任务，写一段好的提示词仍然是最高效的方式。

但对于正在建设复杂软件系统、需要持续交付、并行推进多个特性的团队来说，循环工程提供了一种全新的可能性——你把写提示词的次数从每天数百次，缩减为每周一次（设计循环），然后让循环去完成那数百次提示词的执行和判断。

这是一条"杠杆率"极高的路径。代价是，你不能再把Agent当作一个被动的工具——你得像一个系统架构师一样，去设计一套能自主运行、自主纠错、自主闭环的工作流。

Boris Cherny和Peter Steinberger同时告诉我们的是同一件事：

编程Agent时代的工作方式，已经不取决于你用哪个工具，而取决于你有没有意识到——提示词只是一个起点，循环才是终点。

---

本文参考了以下来源： - InfoQ《大人，AI编程又变天了！Claude Code之父、龙虾创始人同时力捧新范式，杀死提示词工程？》（褚杏娟，2026年6月） - Addy Osmani, "Loop Engineering", addyosmani.com, 2026 - The Pragmatic Engineer, "The creator of Clawd: I ship code I don't read", 2026 - Boris Cherny, Sequoia Capital AI Ascent 2026 活动演讲 - Peter Steinberger, X/Twitter (@steipete), 2026年6月