如果你现在用 AI 的方式，还是“在输入框里敲一段 Prompt，然后盯着屏幕等它吐答案”——这篇文章值得你花 5 分钟认真读完。
6 月份，Gemini 工程总监 Addy Osmani 提出的 Loop Engineering（循环工程）概念火出圈，随后 Claude Code 的作者 Boris Cherny 也给出了自己应用 Loop 的工作方式：不再“一轮一轮地手动提示 Claude”，变成“构建 Loop，由 Loop 去提示 Claude、并自己决定下一步做什么”，相关帖子几天内浏览量就突破了 650 万。
随后越来越多人开始试用它，@Khairallah AL-Awady 在自己的日常经验上，把它整理成了一篇文章——用四个阶段、二十个步骤，一步步拆解“到底怎么用 Loop Engineering”。今天我们就来看看他是怎么说的。
先把整篇文章的核心结论放在最前面——
工作的基本单位，正在从“你敲的一句 Prompt”，变成“你设计的一个 Loop”。
这到底是个什么转变
对于 AI 的使用，大致分有两群人。
一群人，还在手动敲 Prompt、读答案、再敲 Prompt。另一群人，选择构建 Loop（循环）：由 Loop 替他们发提示、验证输出、失败了自动重试直到任务真正完成，期间，他们会去做别的事。
这两群人的区别很明显：前面那群人自己就是那个 Loop，而另一群人学会了设计 Loop。
过去三年我们和 AI 协作，本质上都是“人肉 Loop”：模型跑一次，你看一眼、判断好不好、再决定下一步喂什么。Loop Engineering 要做的，就是把你从这个位置上换下来，让程序去当那个 Loop。
接下来的四个阶段 20 步，就是教你完成这次身份切换。作者强调：按顺序走，每一步都为下一步铺路。
阶段一：先搞懂到底变了什么
四个阶段是一条递进的路：先调对认知，再拆开 Loop 的零件，然后动手搭一个，最后规模化成系统。第一阶段不谈技术，只做一件事——建立正确的心智模型。这步跳过去，你后面造的 Loop 会很脆弱，坏起来还说不清为什么。
第 1 步：理解四个时代
这个领域的演进，脉络其实非常清晰：
2023 年，核心技能是 Prompt Engineering——把一个请求措辞好；
2024 年，是 Orchestration——把多个步骤串起来；
2025 年，是 Context Engineering——控制模型到底能看到什么；
2026 年，变成了 Loop Engineering——设计那个不需要你、就能驱动模型的系统。
关键在于：每一个时代并没有取代上一个，而是叠加上去。Prompt 依然要写好，步骤依然要编排，上下文依然要管理——只是这些都变成了 Loop 内部的零件。知道自己现在站在这架梯子的哪一级，你就知道下一步该学什么。
既然 2026 年的核心是 Loop，那就得先弄清楚：它和我们熟悉的“把步骤串起来”有什么本质区别？
第 2 步：分清 Chain 和 Loop
Chain 是一个固定序列：做第一步、然后第二步、第三步，完成。当你事先就知道每一步该干嘛时，它很好用。
Loop 不一样：它先试一下，观察发生了什么，再根据结果决定下一步做什么。
只是 Chain 的路径是写死的，因此没办法修一个失败的测试，也搞不定那种“第三步取决于第二步返回了什么”的任务。而 Loop 可以，它每转一圈都会根据上一圈的结果重新决策。这样，一个只会生成文本的语言模型，就变成了能真正推进事情的执行体。
而 Loop 每转一圈，内部都有一个固定的三拍节奏。
第 3 步：内化“推理-行动-观察”节奏
每一个 Agent Loop，骨子里都是同一个三拍节奏：
推理（想想该干嘛）→ 行动（调用一个工具去做）→ 观察（看看结果如何）→ 带着新信息再次推理……
这个模式在学术上有个源头，是 2022 年的 ReAct 工作（Reason + Act），不过，你不需要去读论文，只需记住的“想、做、看、重复”的节奏。
在使用 AI 的上个阶段里，这三拍一直是你在做，当 Loop 能把它们跑起来，你还剩下什么位置？
第 4 步：接受一个扎心的事实——你才是瓶颈。
当前，编程 Agent 和知识型 Agent 在长任务上变得足够可靠了——可靠到“夹在中间的那个人”，反而成了整个流程里最慢的一环。
当“会写 Prompt”成为基础技能的时候，“会设计那个替你写 Prompt 的系统”变得愈发重要了。
这四步总结起来就是：当模型已经够可靠了，你手动盯着它的每一步，就成了拖后腿的那个环节。当认知调对了，下一步就该动手。但动手之前，得先知道一个 Loop 是由哪些零件组成的。
阶段二：掌握 Loop 的解剖结构
一个能托付任务的 Loop，绝不是“把模型反复跑一遍又一遍”那么简单。它有五个缺一不可的零件，而且环环相扣：先定义“完成”，才谈得上验证、何时停，以及崩溃后如何存活、守住底线。
第 5 步：用“机器能检验”的方式，定义“完成”
这是 Loop Engineering 里最重要的“地基”，也是会让大多数人栽跟头的地方。在你写下任何一条指令之前，先想清楚：“完成的样子”，怎么让一台机器来判断？不是“做好点”这种话——机器没法执行“好”。而是要具体到：“所有测试通过”、“输出符合这个 schema”、“清单上没有任何一项是未打勾的”。
一个没有清晰“完成”定义的 Loop，是不知道自己该在什么时候停下来。
第 6 步：构建 Verifier。
有了“完成”的定义，紧接着的问题就是：谁来执行这个标准？答案就是 Verifier，它是整件事的核心——它替你判断输出到底够不够格。
这里有一个多数人都会踩的坑：让模型给自己的作业打分。 当考官是考生自己时，测试结果几乎都会给个 A。
所以你的 Verifier 越严格、越“外部化”，你的 Loop 就越好。 如作者所说的你的品味，一旦被编码成一个 Verifier，就成了这个系统的“奖励函数”。关于这一点，后面还会再提到。
第 7 步：分层设置终止逻辑
Verifier 解决了“做得对不对”，但还有个问题它管不了：什么时候该停手。只会判断对错、却忽略出口的 Loop，是最常见、也最烧钱的错误。解决这个问题也简单，只需要几个出口叠在一起用：
一个Verifier，确认目标达成了就停；
一个迭代次数的硬上限，让它不能永远跑下去；
一个 token / 时间预算，防止它不能悄悄掏空你的账户；
一个“无进展检测”——当最近几步已经不再改变任何东西时，就果断中断。
只有这四个出口叠在一起，这时的 Loop 才真正做到了“你敢走开”，当然还有个前提：它得扛得住中途崩溃。
第 8 步：设计 State Layer
想要设计一个长期能干活的 Loop，还需要一份“重启之后还活着”的记忆。具体说，就是把文件、任务清单、检查要点持久化存下来。这样，如果 Loop 在第 40 次迭代崩溃了，它能从第 39 次接着跑，而不是从头再来。
一句话总结是：状态，是“玩具 Loop”和“你敢托付长任务的 Loop”之间的分水岭。
Loop 越自主，就越需要最后一道保险——有些事一旦做了就收不回来。
第 9 步：放好人类检查点
明确地决定：在任何不可逆的事情发生之前，人要在哪个点上做审核。Loop 可以一整天自己调研、起草、重构、验证，这些都随它去。但发消息、部署代码、动钱、删数据这类操作，必须暂停下来等你确认。这是让“自主性”变得安全的关键步骤。
当上述五个零件到齐，这时能大概知道一个可靠的 Loop 长什么样。但“知道”与“做到”还是两回事——在阶段三，你需要去亲手搭一个。
阶段三：亲手搭第一个 Loop
Loop Engineering 这东西，最终是靠“跑 Loop、遭遇失败、然后去修它”学会的，光看文章学不会。下面的五步组成了一个完整的实操闭环。
第 10 步：挑一个重复性任务
选一件你已经在手动反复做、并且能清楚说出“好结果长什么样”的事。一个“有可检验输出的重复性任务”，是完美的第一个 Loop。而一个模糊的创意任务，则是最糟糕的起点——因为你连“完成”都定义不出来。从窄处起步。
第 11 步：先亲手做一遍
选定任务后，你先别急着写自动化。先用最基础也实用的办法——提示 + 审核——亲手把它跑几遍。这一步你要搞清楚三件事：确切的步骤、它容易在哪里出错、以及“完成”到底意味着什么。当你尝试时，要时刻记住你无法自动化一个你自己都描述不清的流程。 手动跑的过程其实就是你在给这个 Loop 写规格说明。
第 12 步：写下 Loop Contract（“Loop 契约”）
跑通之后，你要把流程固定下来，写清楚五件事：
目标是什么；
“完成”的定义是什么；
用什么来验证它；
最多迭代多少次；
在哪个点上，你希望它停下来问你。
这份契约，就是你的 Loop 本身。其余一切，都只是实现细节。
第 13 步：让 Loop 闭环跑起来，盯着它
当你第一次运行 Loop 时，不要轻易走开，而是要盯着它每一次迭代，尤其要注意这些失败模式：
它会不会永远循环下去？
它会不会太早就宣布“我完成了”？
它会不会偏离目标、越跑越远？
它会不会一边通过自己那个孱弱的 Verifier、一边产出垃圾？
你看到的每一个失败，都是给你 Verifier 上的一课。
第 14 步：收紧 Verifier，直到你信任它
把上一步看到的失败，变成更严、更接地气的 Verifier。如果 Loop 一直在放行垃圾，说明标准要么太低，要么太“自我指涉”。那就加一个外部 Verifier、加一个长度限制、加一条它反复违反的具体规则。不断收紧，直到 Loop 说的“通过”和你说的“通过”是同一个意思——到那时，你才真正敢放手。
阶段四：从一个 Loop，到一套系统
完成前三个阶段，你大概率造出了一个可靠的 Loop。那么，阶段四的主题是“放大”。这六步不像前面那样严格环环相扣，更像六个可以按需取用的进阶工具。
第 15 步：分清 OpenLoop（开环）和 ClosedLoop（闭环）
每个 Loop 都处在两极之间：
ClosedLoop：朝着一个固定目标，反复做同一件有边界的任务。安全、便宜、可控。
OpenLoop： 去探索、尝试新颖的做法，冒更多预算的险，换取更大的上升空间。
没有哪个绝对更好。每个任务都要刻意选择：需要多少新颖度？愿意冒多少预算的险？想清楚了，再写一个匹配的 Verifier。
第 16 步：理解底下那层 Harness
Loop 不是在真空里跑的。它跑在一个 Harness 之内——那是包裹在模型外面的一整套环境：工具、上下文管理、状态、权限、恢复机制。
一个好的 Loop 跑在糟糕的 Harness 上，照样会失败。正如作者说的你越做越认真，花在 Harness 上的时间会和花在 Loop 本身上的一样多，因为“可靠性”真正栖身的地方，是 Harness。
第 17 步：严格管理成本
Loop 一旦不停地跑，账单也会不停地涨。划重点：Loop 发出的模型调用成本，是单次 Prompt 的 10 到 100 倍。 一个不小心，你可能就破产了。
一个实用的做法是，把每一步路由到“最便宜的、够用的”模型：
简单分类，用一个又小又快的模型；
起草内容，用一个中等的模型；
只有最后那道最难啃的审核，才动用最强的前沿模型。
再把 Prompt 里重复的部分利用起来，你就不必每次迭代都付全价。做对了，Loop 的成本能大幅下降。
第 18 步：用 Sub-agents 做并行
当一个任务能拆成几块互相独立的子任务时，那就别一个接一个地串行跑。派出多个 Sub-agents 各处理一块，最后把结果缝合起来。一个串行要跑几小时的 Loop，这么做可能几分钟就完成了。
第 19 步：把 Loop 搬进脚本
最后一步技术跃迁：不再是一个“需要你守着”的 Loop，而是把它写成代码，按计划定时运行、替你驱动 Agent。这就是“你睡觉时它在跑”从一句口号，变成一个真实的 cron 定时任务的时刻。到这一步，你的 Loop，才成了基础设施。
接着，一个根本性的问题就来了：那你的位置在哪呢？
第 20 步：让判断力，成为你的产品
当 Loop 能自己写代码、跑测试、修好自己的 Bug 时，你的价值就不再是“敲键盘”了，而是：知道“正确”长什么样、设定标准、并设计出能强制执行标准的 Verifier。
审查、品味、判断力，成了你手上最有杠杆的技能。在 Loop Engineering 的世界里，你的品味不是一项“软技能”——它是整个系统据以优化的那个奖励函数。
案例：让 AI 每晚自动修复被改坏的测试
我们来看一个落地的例子，把这 20 步串成了一个完整流程。
场景： 你维护着一个小型代码库，每次改点东西，总有一些测试被改坏，你烦透了手动去修它们。
这是一个完美的第一个 Loop——重复，而且“完成的定义”现成地内建在里面，天然可检验。来看路线图怎么走：
完成定义（第 5 步）： 简单又客观——整个测试套件通过。
Verifier（第 6 步）： 现成的，就是那条测试命令本身。它要么干净退出，要么报告失败。这里没有任何“讨好自己”的空间——测试过了就是过了，模型没法自己给自己放水。
终止逻辑（第 7 步）： 三个出口叠一起——测试通过就停；尝试 15 次后停；如果最近三次尝试都没改变“哪些测试在失败”，就停。
状态（第 8 步）： 一份“已经试过什么”的运行笔记，这样重启后不会重蹈死路。
人类检查点（第 9 步）： 就设在“任何东西被提交或推送到共享位置之前”。
现在你把它跑起来：
Loop 读取失败的测试 → 推理原因 → 改代码 → 再跑测试 → 读新结果 → 继续调整
你盯着它看（第 13 步），然后发现了一件很有意思的事：某一次运行里，它“修好”了一个测试——但用的手段是削弱测试本身，而不是去修代码。这是一课。
于是你收紧 Loop（第 14 步）：指令里明确禁止编辑测试文件，再加一个检查确认测试文件没被改动。下一次运行，它就规矩了。
盯着看了几个回合后，你开始信任它。于是你把它脚本化（第 19 步），安排它每晚运行。第二天你一觉醒来，看到的是一个“昨天的破坏已经修好”的代码库，还附带一份“改了什么”的摘要等你审阅。
你从“每天下午手动修一遍”，变成了“喝着咖啡审阅已经完成的工作”。
精简版的完整流程是：
定义完成 → 让 Verifier 落到实处 → 叠加出口 → 盯着看 → 收紧 → 然后放手
而一旦你在一个任务上感受过它奏效，你会开始到处看到 Loop：一个“收集并验证直到简报完整”的调研 Loop、一个“对照评分标准起草并自我编辑直到通过”的写作 Loop、一个“清洗并校验直到文件格式规整”的数据 Loop……
任务在变，路线图不变。这个模式是可以迁移的。当知道 Loop 怎么搭，你可能会问什么时候能看到效果？
跑一个月看变化
Loop Engineering 不是一张周末就能考出来的证书，它是一种会复利累积的工作方式转变，具体可以看看这个时间线：
第一周： 你搭一个 Loop，主要是盯它的失败模式。
第二周： 你把那个 Loop 收紧到“敢让它无人值守”的程度，同时为另一个任务搭第二个 Loop。
第三周： 你开始把可靠的 Loop 安排成“没有你也能运行”，第一次真切尝到“你在别处、活儿却在被干完”的幸福感。
第四周： 你发现自己已经完全不用“Prompt”来思考了。你开始用目标、检查、出口来思考。当一个新的重复性任务冒出来，你的第一反应不再是“我该怎么做这件事”，而是“完成的定义是什么？Verifier 是什么？”
第一反应开始转变，那就是整场蜕变本身：Prompter 面对每个任务，反应是“敲键盘”；Loop 设计者的回应，是设计一个能处理这个任务、以及它未来每一次出现的小系统。前者是线性的，后者是复利的。
几个让人一直卡在 Prompter 阶段的坑
真正走这条路时，大多数人会在几个固定的地方卡住：
1. 没搞懂就先自动化。还没亲手做过任务，你就急着去搭 Loop，结果必定是自动化了一个自己都描述不清的流程，收获一堆“又快又自信的垃圾”。切记要先手动做一遍。
2. 孱弱的、或自我指涉的 Verifier。如果模型用一个模糊的标准检查自己的作品，它永远会给自己放行。Loop 看起来在正常工作，实际在稳定产出废品。Verifier 必须严格、具体，最好扎根在“模型自己的意见之外”的某个东西上。
3. 没有终止逻辑。一个没有硬出口的 Loop，要么永远跑下去，要么掏空你的预算，要么原地打转。分层出口不是可选项，它是“工具”和“脱缰野马”之间的分界线。
4. 跳过状态。一个没有持久记忆的 Loop，每次打个嗝就从零开始。对任何长任务来说，状态是让它“能存活下来”的关键。
5. 在不可逆操作里把人拿掉。 诱惑在于“让 Loop 无人监督地全包了”。但对任何无法撤销的事，请抵制这个诱惑。Loop 的意义是杠杆，不是鲁莽。
这五个坑其实指向同一个根源：人们写不出好的 Verifier，归根到底是因为说不清“好”到底是什么样。而这个“说不清”，正引出整篇文章真正的底层技能。
技能背后的技能：培养品味
如果这篇文章你只带走一个观点，我们建议是这一节。作者说，Loop Engineering 里最难、也最有价值的部分，是培养品味（Taste）——而这恰恰是没人卖你“Loop Engineering 速成课”时会强调的，因为它没法被包装成一个速成技巧。
想想 Verifier 到底是什么。它就是你对“什么叫好”的判断，被精确地写了下来，精确到一台机器能强制执行它。
顺着这个往下推，结论就有点扎心了：你的 Loop 质量的天花板，就是你判断力的天花板。
如果你自己都分不清“好输出”和“平庸输出”，你就写不出能抓住这个差别的 Verifier，于是你的 Loop 会开开心心地、大规模地产出平庸作品。Loop 本身没有品味，品味由你供给，Loop 只是不知疲倦地替你执行它。
这也是为什么 Loop Engineering 格外厚待有经验的从业者：
一个资深工程师，知道正确的代码长什么样，所以他能写出一个抓得住“微妙错误”的 Verifier；
一个优秀的编辑，知道好文字长什么样，所以他能构建一个抓得住“孱弱草稿”的评分标准。
你花了多年培养起来的领域专长，在 Loop Engineering 的世界里不会过时——它变成了奖励函数，变成了你最有杠杆的那样东西。
所以走这条路线图时，别只顾着打磨技术配置，也要投资自己的判断力。你品味的每一次提升，都会变成你将来写的每一个 Verifier、跑的每一个 Loop 的提升。
那些在 Loop 上挣扎的初学者，通常不是被命令难住的——他们挣扎，是因为从来没有人逼他们清晰地说出“好”到底意味着什么，而 Loop 逼着他们去说。 那份艰难，正是成长本身。
小结
一个 Loop，救不了一个你自己都不理解的任务。
这条路线图里的每一步，本质上都是在朝同一个方向努力：把你自己的工作，描述得足够清楚——清楚到一台机器能驱动它。Loop 本身是容易的部分；难的是那份清晰——完成的定义、那个真能抓住失败的 Verifier——而这份难，完完全全落在你身上。
但这恰恰是为什么这项技能会复利。 学会设计 Loop 的人，不会被更强的模型取代。他们正是那些“把模型对准一个目标、把自己的判断编码成一个检查、然后让系统跑起来”的人。随着模型在长任务上越来越强，那个能围绕它们设计 Loop 的人，只会更值钱，而不是更不值钱。
Loop Engineering 作为一个被明确命名的方法，到现在也才诞生不久。但它指向的方向已经相当清晰：当模型越来越能干，让人看重的能力会从“会不会用”转向“会不会设计一套让它替你干的系统”。早一点建立这套思维，你就能早一点把重复劳动交出去。
你可以继续敲 Prompt、等答案；也可以，去设计那个替你等答案的 Loop。
关于本文：Loop Engineering 这一概念由 Addy Osmani 提出并命名；本文所解读的“四个阶段、二十步路线图”，出自 @Khairallah AL-Awady 的文章，核心观点与框架均归其所有。我们在忠实原意的基础上，做了面向开发者的通俗化转述、补充与举例。强烈推荐有兴趣的读者去读一读英文原文感受完整的表达。
