速读#
这篇把 Loop Engineering 从圈内说法落到一次真实任务：用 /goal 和 Stop hook 跑完一批博客改造。核心不是「让 AI 自动干活」，而是把调度交给 loop，把终止条件、验证机制和刹车留给人设计。
背景：Loop 是什么#
2026 年 6 月圈内同时在传两句话。Anthropic 的 Boris Cherny 说「我不再直接 prompt Claude 了，我有 loops 在跑，是它们在 prompt Claude、决定下一步，我的工作变成了写 loops」；OpenClaw 的 Peter Steinberger 说得更干脆——「你不该再亲自 prompt 编程 agent 了，你应该设计能替你 prompt agent 的 loops」。Addy Osmani 在 6 月 7 日的文章里把这套做法写成了 Loop Engineering。
读到这堆话时我没马上信，也没马上否定。我对新词的纪律还是那条：能跑 ≠ 理解，得自己跑一遍。正好手头有件够大、够枯燥、形状合适的活——把 39 篇博客按一套标准二次加工。我就拿它当试金石，在 Claude Code 里真跑了一遍，跑完才对「写 loop」这四个字有了自己的判断。
从 prompt 到 loop#
从 2022 的 Copilot、到 Prompt Engineering、到 Karpathy 的 Context Engineering、到 Vibe Coding、到 Harness Engineering、再到这次的 Loop，这条链有个比「潮流更替」更准的读法：它是一组嵌套的关切层，每一层包裹前一层，不是取代它。2022 年我们学写完美的邮件，2025 年学管理收件箱，2026 年在设计邮件系统本身。工程的严谨性没消失，只是不断从 prompt 迁到 context，再从 context 迁到系统架构。Loop 是目前最外那层——内核就一句：你不再是那个 prompt agent 的人，而是设计出一套替你 prompt agent 的系统的人。
loop 的五件套#
「一套 loop」到底由什么撑着，我跑了才分得清。它不是玄学，是五件东西搭起来的：一个触发器决定它何时启动（定时、git 推送、还是人工喊一句）；一个可验证的终止条件决定它何时停；一组行动集合是它手上能用的工具（读写文件、跑终端、跑测试）；一个验证机制比 agent 自称「我完成了」更强，比如真去跑测试、让另一个 reviewer 对比 diff；一份跨迭代记忆，保证它不会每轮都从零理解自己在干嘛。Harness 和 loop 的差别也清楚了——harness 是让单个 agent 跑得稳的那个环境，loop 是在 harness 外再包一圈：加上触发器、能把下一轮活派出去的调度，和把结果喂回去的反馈，才成为完整的循环。
把五件套摊开后，成败压在哪件就清楚了——七成压在「可验证终止条件」上。给它「让测试通过」这种可检查的目标，它知道终点；给它「改进代码」「写得更好」这种模糊目标，它永远不知道该停，会无限优化那句模糊描述，结果可能比老老实实手动过一遍还糟。还有一条告诫是我真碰到后才信的：不是越自动越好，每个认真的 loop 都要硬性刹车——最大迭代上限、停滞检测、按日预算上限。动力和刹车必须一起装，不能后补。Martin Fowler 关于人站三种姿态的说法也在这里定下来：人在循环外（完全不参与）、在循环里（逐项审查）、在循环上（维护 loop 本身），只有「在循环上」这一种能随 agent 吞吐量增长而扩展。
这些都是读来的，我跑之前对其中一半是半信半疑的。
真跑一遍#
在 Claude Code 里，我把自定义的 /goal 目标命令和 Stop hook 组合成闭环，不用再单独写调度脚本。我把「39 篇博客二次加工」这个目标交给它跑完了全部。把上面五件套对照到我这套：触发器是 /goal 设的目标加 Stop hook，每次我想收手，hook 就检查「39 篇改造完成」成不成立，不成立就挡住逼我继续；可验证终止条件是「完成所有文章的二次加工」，因为它有客观计数（39 篇），loop 知道何时停；行动集合是读写 D:\Agent\ 下稿子、对照标准文件、跑 wmux 查看；验证机制是 TaskList 计数加每篇对照一套审稿七问，而且写稿的 agent 不给自己的作业打分；跨迭代记忆是标准文件、改造清单和 TaskList 跨轮次持久，下一轮不从零理解「标准是什么」。
这次能跑顺，原因我也是跑完才想明白的：任务形状正好合上了 loop 的强项。每篇标准一样（过程重复）、完成可数（目标可验证）、好坏靠人对照标准判（判断离散）。换「写一个让我惊喜的新功能」这种没法验证的活，loop 会瞎跑，我不会上这套。跑下来最直接的体感是：loop 把「接下来该写哪篇」这个调度问题从我脑子里搬走了。平时我写一篇要先想还剩哪些、先写哪个、写到啥程度算够，这些调度本身耗注意力。loop 接管后，我的注意力从「调度」挪到「判断」——它递下一篇，我专注做「这篇符不符合标准」。这正是任务边界那一面：把调度执行交给 loop，把质量判断留给自己。Boris 那句「我的工作变成了写 loops」，跑完才真懂它的分量：不是不用干活，是活从「逐个 prompt」变成「先把 loop 装对，然后只做 loop 干不了的判断」。
那些半信半疑的，跑完都落成了具体感受#
终止条件写软会空转，这是 loop 的能力边界。 它对「可计数目标」很强，对「好不好」这种主观目标会瞎跑。我的应对是把目标钉死在「39 篇加对照七问」，不给自己留「差不多了就停」的口子。如果当时给的是「把文章改得更有深度」，这个 loop 大概率一直转，要么过早停，要么空转烧 token。
每轮验证不能靠 agent 自证。 「worker agent 不能给自己打分」那条，我没踩但清楚它就在那——让写稿的同一个 agent 判「够不够好」，它会倾向说够。所以我这套审稿七问是对照外部标准，不是问 agent「你写得行不行」。这反过来让我对「生成之后必须能逐行解释」这条纪律的理解更深一层：loop 里它更硬，因为自动会放大自证的倾向。
成本和刹车。 loop 是会烧 token 的，跑十轮和跑三轮差很多。前面列的那几样刹车——最大迭代上限、停滞检测、按日预算——这次任务有天然终点（39 篇跑完即停），我没全用，但清楚一件事：一个没刹车的 loop 和一个没终止条件的 loop 一样危险。下次规模更大的任务，我会先把「每日预算上限」和「停滞检测」装上再起跑。这是「破坏性命令绝不盲执行」在 loop 这里的升级版——破坏性循环绝不裸跑。
关于「在循环上」这个姿态。 我这次没逐篇审 agent 写得对不对，我维护的是「标准 + 终止条件 + 验证机制」这套让它能自转的东西。Fowler 说只有 on 能扩展，我跑了才信：逐项审扛不住量，全交出去危险，真正能扛量的是我把 loop 这个系统本身维护对。on 的意思不是「我少干了」，是「我干的那部分更关键了」：定义目标、设计验证、装刹车。
这个词对我来说落成的几条判断#
跑完 39 篇，我对 Loop Engineering 这个词的理解，从「圈内新概念」变成了几条能落地的判断。它不是「让 AI 替你写代码」的升级，是「让系统替你调度 AI」的范式——前者你还在逐轮 prompt，后者你设计终止条件和刹车，然后只做质量判断；39 篇能连跑完，靠的不是 AI 更聪明，是我把「调度」这层交给了 loop。它的成败不在 AI，在那个「可验证终止条件」和「刹车」上——AI 再强，loop 装错照样空转或失控，核心工程量从「调 prompt」挪到了「定义目标 + 设计验证 + 装刹车」。而且它只匹配「目标可验证、过程重复、判断离散」的活，39 篇改造恰好是这类；换成目标没法验证的活，loop 不灵。loop 不是万能生产力，是匹配特定任务形状的工具。
边界我也写清楚，不把它说成定律。loop 不是「自动出活」的魔法，我跑顺是因为任务形状对，换任务不敢保证。「写 loop」也有门槛：定义可验证终止条件本身需要工程判断，不是把活丢给 AI 就行——loop 越强，对「人定义目标」的能力要求越高，不是越低。再加上 loop 当前的 token 经济性还在波动，这套姿势本身也还早；我这次只是单会话小规模，真上生产级长跑，刹车和预算我会先想清楚再起跑。
我从「亲自写 39 篇」这段路程里，最值钱的不是 39 篇成品，是这个判断：当一件事目标可验证、过程又在重复时，就该考虑把「调度」交给 loop、把「判断」留给自己。Loop Engineering 这个 2026 年 6 月的词，对我来说不再是圈内话题，是我用一天跑出来的一个工作姿势。
Boris Cherny 说「我的工作变成了写 loops」。我加一句自己的：写 loop 的核心不是写，是把终止条件和刹车想清楚——那才是 loop 这套范式里真正属于人的部分。