《Loop Engineering橙皮书》发布！免费，开源

最近公众号后台和群里老有同学在问我：loop engineering 到底是啥？

以及催更我的《Loop Engineering橙皮书》的，

这词才出来一个多星期，已经满天飞了。行吧，我一次说清楚，并且真真给你们交付了一本32页的《Loop Engineering橙皮书》，获取方式在结尾，需要的可以直接拉到最后。

先给你一句话的版本：

你别再自己一句一句去指挥 AI 了。你该去设计一个替你指挥它的系统。

就这么简单。

不过，显然，真正的问题是，这背后的指挥系统究竟是指什么，以及我们该如何设计？

loop engineering是怎么火的？

要说这个概念的引爆，首先是Claude Code 的 负责Boris Cherny先在X发了句，说自己已经不靠自己手动promptClaude了，而是让一堆loop跑着去提示它、自己想下一步干嘛，他的工作就是写循环。

引爆它的则是 OpenClaw 的作者 Peter Steinberger 发的一条推：你不该再去提示你的编程 agent 了，你该去设计那些提示你 agent 的循环。这条推冲到了 830 万浏览。

最后，真正给它起名字的是 Google 的 Addy Osmani。6 月 7 号他写了篇博客，标题就叫 Loop Engineering，把这帮人各自在做的事收进一个词里，顺手把 Steinberger 和 Cherny 的话一起引了进去。

三个互不打招呼的一线的人，几天之内指向了同一件事，还用上了同一个词。每次出现这种情况，我都会多看两眼。它通常意味着，不是谁在造概念，是一群人各自做着类似的事，憋到现在终于需要一个共同的名字来交流了。

又一个「XX 工程」？

我知道你在翻白眼。

提示词工程、上下文工程、缰绳工程，过去一年「XX engineering」冒出来五六个，造词速度快赶上模型迭代了。

但这几个其实是一层一层垒上去的，不是并列的噱头。我给你排一下：

提示词工程，管的是你递给模型的那一段话写得好不好。

上下文工程，往前走一步，管的是这一次模型的脑子里该装哪些信息、该清掉哪些。

缰绳工程（harness），再往前，管的是单次一个 agent 跑起来的整套装备：给它哪些工具、允许它动什么、失败了怎么办、什么才算干完。

循环工程，又上一层楼。Addy 的原话是「它就坐在 harness 上面一层」。缰绳武装的是一次运行，循环干的是另一件事：它在定时器上跑、自己孵化小帮手、自己喂自己。

你发现没，这条线只有一个方向：你离亲手干活越来越远，离设计系统越来越近。循环工程只是把这件事说破了。

那一个「循环」到底长啥样

别被「系统」两个字吓到。拆开看，一个循环转一圈就五个动作：

发现 → 交付 → 验证 → 记下来 → 决定下一步。

Addy 给了个我觉得最好懂的例子。想象这么一套东西每天早上自己跑：

它先读昨天的 CI 哪些挂了、有哪些 open 的 issue、最近提了哪些 commit（这是发现）。挑出值得做的，开一个隔离的工作区，派一个 agent 去起草修复（交付）。再派第二个 agent，对着测试和项目规范去审这份草稿（验证）。审过了，自动开 PR、更新 ticket。所有进展写进一个 markdown 文件，活在对话之外，这样第二天早上能接着上次的地方跑（记下来，决定下一步）。

你睡你的觉，它干它的活。等你醒来，收件箱里摆着一排它处理好的、和它处理不了留给你看的。

你可能想说，这不就是挂个定时任务跑脚本吗？差就差在三点：它自己会醒，它记得上次干到哪（状态写在对话之外的文件里，不是跑完就忘），它能照这轮的结果决定下轮干嘛，不是干巴巴重复同一件事。定时脚本只占头一点。

这五个动作，靠六个零件搭起来：自动化、隔离工作区、技能、连接器、双 agent、记忆。每个都能单独讲半天，这儿先不铺。

全文我最想让你记住的一点

如果这篇你只带走一句话，我希望是这句：

写代码的那个 AI，不能给自己的代码打分。

其实之前写达尔文2.0的时候也提到过，你让一个 agent 去评价它自己刚产出的东西，它几乎总是自信地夸，哪怕在人眼里那活儿明显很一般。它太想让你满意了。

解法是把它劈成两个。一个负责生成，一个专门负责挑刺，后面这个还要特意调教得多疑一点。一个造，一个判，互相顶着。判定「干完了没」的，不能是干活那个。

落到工具上，Claude Code 最近上的两个命令，正好各管循环里的一件大事。

先说 /goal。你给它一个可评估的完成条件，它每跑完一轮，由另一个独立的快模型判断条件满足了没，没满足就自己再来一轮。这就是上面那把刀落到工具上的样子，生成的和评判的分家。它适合有明确终点、能被验证的活：修一个 bug 修到测试全绿、做一个功能做到验收清单全打勾。

这里有个坑我踩过：别图省事拿「开发完成」当目标，那等于让它自己说自己行，结果往往很糟。得把你心里那些模糊的「好」翻译成它能一条条核对的可衡量的指标，执行出来的结果才能真正有价值。比如我自己常用的策略是让CC给我的产品定义5个目标用户，在产品完成后需要持续调用subagent让这5个用户分别进行评价，需要他们的平均评价超过9分才能停止，才算完成目标。

再说 /loop。它干的是另一件事：把一个任务按固定节奏反复跑，比如每五分钟查一次部署好了没、或者盯着一批 PR 一直处理下去；你也可以不给间隔，让它自己掂量隔多久跑一轮。它对应的是循环自己会醒、周而复始那一面，适合需要持续盯、轮询状态、周期重复的活。

一句话记住分工：/goal 是进度驱动，朝着终点跑，到了就停；/loop 是时间驱动，踩着节拍一圈圈转，你不喊停它不停。把这俩用反是最亏的：拿 /loop 去干有终点的活，干完了它还在空转烧 token；拿 /goal 去盯一个你左右不了的外部状态（比如等同事合你的 PR），它会永远转不出来，因为那个条件压根不归它管。

这两类动作搭一块，循环工程才算真落了地。

这一刀下去，循环才有了底线。不然就是一个 AI 对着镜子，一遍遍同意自己。

当然，想跑起来也没那么容易

当然，新手开始干所谓的loop engineering很容易遇到各种坑，下面是我自己遇到，以及看到现在开发者社区里很多人反馈的：

第一笔，验证债。一个没人盯着的循环，也是一个没人盯着在犯错的循环。它跑得越欢，错也错得越离谱。

第二笔，理解烂掉。它越快地交付一堆你没亲手写的代码，你脑子里以为的代码、和仓库里真实的代码，缝就越大。哪天出事，你连它写了啥都不知道。

第三笔，token 失控。自主循环烧多少 token 很难预测，看用法能差出好几倍。账单有时候挺吓人的。

还有第四笔最隐蔽的——你会忍不住把它吐出来的东西照单全收，慢慢就不想自己有判断了。Addy 给了句话我觉得是全文的题眼：

同一个循环，两个人能用出完全相反的结果。一个人用它在自己吃得很透的活上跑得更快；另一个人用它来逃避「吃透」这件事本身。loop分不清这俩，它只管转。

所以他最后那句话是：去搭loop。但你要像一个打算继续当工程师的人那样去搭，而不是一个只负责按下启动键的人。

我把它从头到尾写成了一本书

这篇能讲的就这么多。但说实话，一篇推文塞不下这个话题。

被问了太多遍之后，我干脆把它从定义、演化、解剖、六个零件、生成器和评判器，到真实案例、四笔代价、怎么搭你的第一个循环，整整理成了一本橙皮书：

《别再问我什么是 Loop Engineering》。

它接着我之前那本《Harness Engineering》往上走：那本讲怎么武装单次一个 agent，这本讲怎么在它之上搭起会自己跑的循环。两本独立成书，没看过前一本也不影响。

跟我所有橙皮书一样，免费，开源，你可以直接在GitHub上找到：https://github.com/alchaincyf/loop-engineering-orange-book

或者，如果你有微信读书会员的话，你也可以直接在微信读书上搜「花叔」，然后免费阅读就好了：

读完它，下次再有人问你 loop engineering 是啥，换你来解释。

我先去搭我的下一个循环了。