Prompt 工程已死？2026 年 Loop Engineering 范式转移深度解读

一场不声张的范式革命

2026 年 6 月，硅谷 AI 圈被两句话彻底点燃。

Claude Code 负责人 Boris Cherny 在一次访谈中说：「我不再给 Claude 写提示词了。我有一堆循环在运行，它们才是提示 Claude 并判断下一步该做什么的东西。我的工作变成了写循环。」

几乎同时，OpenAI 团队成员、OpenClaw 创始人 Peter Steinberger 在 X 上发文：「别再给编程 Agent 写提示词了。你应该设计一套循环机制，让这些循环去提示你的 Agent。」这条推文获得超过 800 万次浏览。

几天后，Google Cloud AI 总监、前 Chrome 工程负责人 Addy Osmani 发表长文，正式将这一新范式命名为 Loop Engineering（循环工程）。他在文中强调：「这不是 Prompt Engineering 的进化，这是 Harness Engineering 上面的一层。」

三个人，几乎同时，宣告了一场 AI 交互范式的换代。

四代演进：从手工作坊到自动化工厂

过去三年，开发者与 AI 的协作方式经历了四次迭代。每一次都不是简单的「换词」，而是从根本上重新定义了人与 AI 的分工边界。

阶段	核心工作	人的角色	核心瓶颈
Prompt Engineering	精心设计单条提示词	反复人工调参	人是最大瓶颈
Context Engineering	管理塞入上下文的信息	挑选相关资料喂给 Agent	上下文质量决定上限
Harness Engineering	搭建脚手架调度 Agent	设计调度逻辑	单次调用，无闭环
Loop Engineering	设计自迭代闭环系统	站在循环外做设计者	Token 消耗与成本控制

Prompt Engineering 的本质问题不在于「提示词写得不够好」，而在于它把人的判断力作为系统的唯一动力源。每一轮对话都需要人亲手点火——你催一下，AI 动一下。这更像「人工 + 智能」而非「人工智能」。

Loop Engineering 到底做了什么？

剥掉新词，循环（Loop）就是一段预先写好的「包工头」逻辑。

它自己找出有什么活要干，把任务拆块丢给 AI，检查交回来的东西，不合格就带着报错再丢一次，直到通过——或者撞到预设的次数和预算上限才停。

关键区别在于：过去是用户在中间一步步操作，现在是系统自动循环。

以写代码为例：

• 过去：跟 Claude 说「给待办事项写一套增删改查接口」→ 它写完 → 用户一看少了字段校验 → 再说「补上校验和测试」→ 它再改 → 来回拉锯。每一步都得用户盯着。
• 现在：用户写一小段脚本，一次性定好四样东西——目标（接口能跑通、测试全绿）、验收标准（跑一遍 npm test）、能动用的工具、什么时候停（测试通过，或最多尝试 50 次）。然后撒手。脚本自己反复提示模型、自己跑测试、不过就把报错喂回去让它改，全程不用人插话。

Boris Cherny 自己总结得很精辟：干活的最小单位变了——从敲一行代码，到写一句提示词，再到写一个循环。用户不再是那个写提示词的人，而是那个写「写提示词的东西」的人。

Loop 的五要素骨架

Addy Osmani 在系统化长文中给出了 Loop Engineering 的五个核心要素：

1. 目标定义（Goal）：清晰描述「什么算完成任务」，不能含糊。
2. 验收标准（Acceptance Criteria）：可自动化执行的验证逻辑，如跑测试、检查代码规范、验证输出格式。
3. 工具集（Tool Set）：Agent 可以调用的工具或 API，如文件读写、Shell 执行、Web 搜索。
4. 退出条件（Exit Condition）：何时停止循环——成功条件（测试全绿）和失败条件（达到最大迭代次数、超过预算）。
5. 反馈回路（Feedback Loop）：每次迭代的输出如何作为下一次迭代的输入，形成有效的信息闭环。

这五要素缺一不可。很多人第一次写 Loop 时最容易踩的坑就是退出条件太宽松——循环像一台永动机一样烧掉几百美元的 Token 费用，最后产出的结果还不如手动写的好。

不是替代，是转移

当「提示词工程已死」的口号开始传播时，行业中出现了针锋相对的质疑。

客观来说，Prompt 没有消失。Loop 里的模型照样靠 Prompt 驱动。变的是发 Prompt 的人——过去是工程师一轮轮手动喂，现在是 Loop 系统自动喂。

Loop Engineering 做的不是「消灭 Prompt」，而是把人和 AI 之间那个反复拉扯的环节自动化了。它把开发者的精力从「怎么写好这句话」转移到「怎么设计好这个闭环」。

这也意味着开发者技能树的更新方向变了：与其花时间钻研 Prompt 技巧，不如把精力投入到系统设计、错误处理、边界条件管理和成本控制上。因为 Loop Engineering 的核心难点从来不是循环本身，而是那些防止它在死循环里烧掉两百美元的边界条件。

实践建议：从哪开始？

如果你想把 Loop Engineering 引入自己的工作流，可以从以下几个方向切入：

• Claude Code + 自定义 Hook：利用 Claude Code 的 hooks 机制编写自动化循环脚本，让 Agent 自动迭代直到代码通过测试。
• Codex CLI + Loop 配置：OpenAI 的 Codex CLI 已原生支持循环执行模式，适合快速搭建开发反馈闭环。
• GitHub Copilot Agent Mode：Copilot 的 Agent 模式本质上就是一个内嵌 Loop 机制的系统，理解其内部循环逻辑可以更好地利用它。
• 自建 Loop Runner：用 Python 或 Node.js 写一个轻量级 Loop Runner，核心逻辑不超过 200 行——一个 while 循环 + LLM API 调用 + 结果验证函数。

结语

从 Prompt 到 Loop，表面上是交互方式的转变，深层上是人对 AI 定位的重新理解。AI 不再是一个需要你步步引导的实习生，而是一个可以自己跑循环、自己纠错的代理系统。

但这不意味着开发者可以躺平。正相反，Loop Engineering 对开发者的系统设计能力提出了更高要求。那个天天琢磨「怎么把 Prompt 写得更长更好」的时代，确实结束了。取而代之的，是「怎么造一台能自己干活、自己把关的机器」的新课题。