Loop Engineering：当你不再是那个敲 Prompt 的人

❝三个人、三条产品线、一周之内、同一个判断——开发者的工作正在从"写提示词"变为"写循环"。❞

一、引爆点：12 个词和 220 万次浏览

2026 年 6 月 7 日，Peter Steinberger 发了一条推文。

Steinberger 是 OpenClaw 的创始人——那个在 2025 年底横空出世、一度成为 GitHub 历史上最高星标新仓库的开源 AI Agent 框架的缔造者（他后来在 2026 年 2 月加入了 OpenAI）。推文只有 12 个英文单词：

❝"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." （你不该再给 coding agent 写 prompt 了，你该设计 prompt 它们的 loop。）❞

这条推文在 24 小时内获得超过 「220 万次浏览」。回复区瞬间炸裂，但绝大多数人的反应不是赞同，而是困惑。播客主持人 Matthew Berman 的回复精准概括了当时的情绪："没人知道他在说什么，除了他和 Boris。"

二、Boris Cherny：那个已经不 prompt Claude 的人

"Boris"指的是 Boris Cherny，Anthropic 的 Claude Code 负责人——Claude Code 最初在 2024 年 9 月只是他的一个副项目，如今据报道 GitHub 上接近 4% 的公开提交都在它背后完成。

5 天前（6 月 2 日），在 WorkOS 赞助的 Acquired Unplugged 活动上，Boris 对主持人 Ben Gilbert 和 David Rosenthal 说了一段话：

❝"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." （我已经不 prompt Claude 了。是 loops 在跑，它们负责 prompt Claude、决定做什么。我的工作是写 loops。）❞

这段视频剪辑在 X 上疯传，有转述称 24 小时内近 70 万播放。

Boris 给出了他的个人工作流演进轨迹：

• 「一年前」：用自动补全手写代码
• 「中间阶段」：并行跑 5-10 个 Claude 会话，逐个提示
• 「现在」：完全不再提示。数百个 Claude 实例自动读取 GitHub issues、扫描 Twitter 反馈、梳理 Slack 信息，自行决定下一步构建什么

他的成果数据令人咋舌：过去 30 天，Claude Code 代码仓库 100% 的贡献都是 Claude Code 自己写的，合入了 259 个 PR。他 2025 年 11 月删除了 IDE，此后再未打开。

三、Felix Rieseberg：从"帮我修 bug"到"别让它崩"

6 月 9 日，Claude Fable 5 发布。次日凌晨，Claude Cowork 的工程负责人 Felix Rieseberg 发了一条 thread，把"写循环"这个概念拧了半圈，从工程师视角拧到了「产品视角」：

❝"I no longer tell Claude to investigate a particular crash report. It runs in a loop, watching every crash report that comes in. Its job is no longer to help me fix a crash, it's to keep our apps from crashing." （我不再让 Claude 去调查某一个崩溃报告了。它在一个循环里运行，监控着每一个进来的崩溃报告。它的工作不再是帮我修崩溃，而是让我们的应用不崩溃。）❞

这不是语义游戏。Felix 描述的是一个质变：AI 从「被动工具」变成了「主动守护者」。以前你要说"帮我看看这个 crash"，现在你设计一个系统，让它 7×24 小时自己盯着，自己判断，自己修。

Felix 此前在 Latent Space 播客上就已经说过：执行成本已经便宜到可以"直接把所有候选方案都构建出来"——循环化的前提条件已经成熟。

四、Addy Osmani：给它正式命名

三个人从不同角度说了同一件事，但还没人给它一个名字。

6 月 7 日同一天，Google Cloud AI Director Addy Osmani 在个人博客发布了一篇长文，直接为这个现象定名：「Loop Engineering（循环工程）」。

他的定义极其清晰：

❝"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead." （循环工程就是用一个你设计的系统，取代你自己作为那个 prompt Agent 的人。）❞

Osmani 将其拆解为五个核心组件加一个状态层：

他还放了一个重要注脚：「构建循环，但要像一个打算继续做工程师的人那样构建它，而不仅仅是按下启动键的人。」

五、那到底什么是一个 Loop？

社区最大的困惑就在这里。Matt Van Horn 写了一篇在 LinkedIn 上传播甚广的文章《WTF Is a Loop?》，专门解答这个问题。

最直白的回答：「循环就是你写的一个小程序。它替你提示编码智能体，读取产出结果，判断任务是否完成；如果没完成，就再次提示它。你不再是循环里面那个不断输入提示词的人，你变成了循环的作者，模型变成了子程序。」

有人问：这不就是 cron job 吗？

诚实的回答：

• 「相同点」：调度层确实就是 cron。Boris 字面意义上就是用 cron 跑循环。
• 「不同点」：cron 运行固定脚本；循环运行的是一个「会做决策的模型」——它查看状态、决定下一步、执行、检查成功与否、决定是否继续。

❝循环 = cron + 模型作为决策者。真正有趣的工程是你围绕决策者包裹的一切——用来防止它冲下悬崖。❞

六、演进光谱：从 ReAct 到编排循环

循环不是今天发明的。它有一条清晰的演化线：

「关键区别」：单智能体 Ralph 循环是旧东西。「多智能体编排监督」——循环嵌套循环，有验证、有记忆、有停止条件——才是 Steinberger 和 Boris 真正说的新层级。

七、一个完整循环长什么样

Osmani 在文中给出了一个典型日常循环的样子：

1. 「每天早上」 Automation 自动触发，分类技能读取昨天的 CI 失败、未关闭 issue、最近提交
2. 将发现写入 markdown 或看板
3. 对每个值得处理的发现：
   • 打开隔离的 worktree
   • 派出子 Agent 起草修复
   • 「第二个子 Agent」 对照项目规范和测试审查草案（制衡）
4. 连接器负责开 PR、更新票据
5. 循环无法处理的内容进入你的 Triage 收件箱
6. 状态文件记住了什么被尝试过、什么通过了——「第二天从上次停止处继续」

你只设计了一次。没有手动提示任何步骤。

八、Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering

The New Stack 的报道精准梳理了这条技术概念演进线：

• 「Prompt Engineering」（2023）：精心构造单条提示
• 「Context Engineering」（2024）：管理上下文窗口和检索增强
• 「Harness Engineering」（2026 初）：围绕模型搭建约束、反馈与控制脚手架
• 「Loop Engineering」（2026 年 6 月）：把整个 harness 放进自动调度、自我验证的循环中

每一步都是同一个方向：「把人从循环里拿出来，但不是拿掉判断力——而是把判断力从"每次交互"提升到"系统设计"层面。」

九、Boris 的"低配原则"：为什么少给人反而更好

Boris 在访谈中透露了一个反直觉的管理策略：

当团队提出一个看起来需要 4 个工程师的项目时，他故意只分配 2 个。

「目的不是省钱」，而是通过约束迫使团队自动化。人手不足时，团队被迫构建 loops，让 Claude 处理可自动化的工作。自动化后，下次同样的任务成本更低、速度更快、质量更好。

本质上是把预算从人力转向 tokens——提高前期投入，大幅降低持续成本。这样的团队产生复利效应。

十、三个尖锐风险

循环不是银弹。Osmani、Boris 和社区讨论中反复提及三个无法被循环消除的风险：

1. 验证仍然需要人类

无人值守的循环也是无人值守的错误机器。"完成"是一个声明，不是证明。你能放心离开的唯一理由是——你设计了一个你信任的验证者 Agent。但最终，发布按钮还是应该在人手上。

2. 理解力债务（Comprehension Debt）

循环越快地交付你没写的代码，你的理解和代码库现实之间的差距就越大。代码库在膨胀，但你对它的心智模型在萎缩。除非你读循环产出的东西——但谁有时间读 259 个 PR？

3. 认知投降（Cognitive Surrender）

❝"带着判断力设计循环是加速器。为了逃避思考而设计循环则是毒药。同一个动作，相反的结果。"❞

两个工程师运行完全相同的循环，一个用它加速深度工作，另一个用它回避所有艰难决策。Loop Engineering 放大了你本来的样子。

十一、Token 经济学：停不下来的循环是最昂贵的 bug

这不是免费的。一些参考数字：

Uber 的案例已经成为警示：四个月烧完全年 AI 预算后，限制每人每工具每月 1500 美元。

「生产环境最可怕的失败模式是停不下来的循环。」 所有严肃的循环实践都收敛到三个硬停止条件：

1. 最大迭代次数
2. 无进展检测
3. Token 或美元预算上限

十二、我的思考

这不是新概念，但是新共识

坦率说，"让程序自动驱动 AI"这个想法不新。AutoGPT 在 2023 年就做了，Ralph Loop 在 2025 年 7 月就被提出。但区别在于——「之前是极客的实验，现在是产品的标配」。当 Claude Code 内置了 /loop 和 /goal、Codex App 内置了 Automations 标签、连 GitHub Actions 都能调度 Agent 时，"写循环"从一个需要解释的概念变成了一个一键就能用的功能。

三个人一周内说同一件事不是巧合，是因为「产品已经到那了」。

杠杆点真的在转移

过去两年，开发者花大量时间在"怎么写好一条 prompt"上。但当模型能力到达某个阈值后，单条 prompt 的边际收益急剧递减。真正拉开差距的变成了：你能不能设计一套系统，让 AI 「持续、自主、可验证地」 工作？

这就像从"怎么写好一封邮件"到"怎么设计一个自动化营销漏斗"的跳跃——底层能力没变，但上层抽象完全不同。

最大的风险不是技术性的

我最担心的不是 token 成本或循环跑飞。最大的风险是 Osmani 说的"认知投降"——当一切看起来都在顺畅运转时，人会停止思考。

Boris 说"我的工作是写循环"——但这句话的前提是他对 Claude Code 的代码库有深入理解，对产品方向有清晰判断，对用户需求有敏锐感知。他知道循环应该往哪个方向跑。

如果一个初级工程师照搬这套话术，却不具备底层的判断力，"写循环"就会退化成"按下按钮然后祈祷"。

工程师的新技能树

Loop Engineering 对工程师的要求不是降低了，而是转移了：

这不是"工程师要失业"的故事，是"工程师的杠杆点在上移"的故事。但历史告诉我们，每次杠杆点上移，都会有一批人跟不上。

十三、原始出处索引

结语

从 Prompt Engineering 到 Loop Engineering，开发者的角色没有消失，但坐标系变了。

你不再是坐在终端前一条一条输入指令的操作员，你变成了一个系统的设计者——设计 Agent 应该看什么、做什么、怎么验证、什么时候停下。

但请记住 Osmani 的那句话：

❝「"构建循环——但要像一个打算继续做工程师的人那样构建它。"」❞

Loop 放大你本来的样子。如果你是一个有判断力的工程师，循环让你产出十倍；如果你只是想逃避思考，循环会帮你十倍速地制造债务。