Prompt Engineering 过时了吗？我天天跑长任务，看到的是 Loop Engineering 正在顶上来
哈喽，我是飞飞。
这两天我刷推、刷朋友圈，老看到同一句话在转。Boris Cherny，就是 Anthropic 那边做 Claude Code 的负责人，他在一段访谈里说：「我不写 prompt 了。我有一堆 loop 在跑，它们替我去 prompt Claude、自己琢磨下一步该干嘛。我的活就是写 loop。」这段视频片段二十四小时内在 X 上奔到快七十万播放。配套还有一句被反复截图的：「我已经八个月没手敲过一行代码了。」
我看到这句的第一反应没有惊呼，反倒点了点头。因为他说的这件事，我每天都在干，只是没人替它起这么一个名字。现在有人起了，叫 Loop Engineering。
那句「Prompt Engineering 已死」，我先把话说在前头
网上现在最爱配的标题是「Prompt Engineering 已死」。这话我不认。
你想想 prompt 是什么。哪怕你写了一个能自己跑一整夜的 loop，循环里每一步，agent 跟模型对话那一下，仍然是一句 prompt。退出条件怎么描述、给它的任务怎么交代、出了岔子怎么纠偏，全是 prompt 在干活。把 prompt 写糊了，你那个 loop 只会更快、更自动地把活搞砸，还没人盯着。
所以我更认另一个说法。国外有篇讲这事的文章里有句话我觉得最稳：prompt engineering 没死，它成了 table stakes，桌上的底注。意思是这玩意儿现在是入场门槛，人人都得会，但光会它已经不够你赢这一局了。真正拉开差距的那层活，挪到了上面。
那上面那层，就是 loop。
说人话，Loop Engineering 到底是个啥
我先把这几年的演进给你捋一遍，全是黑话，我翻译成人话。
最早是 Prompt Engineering，2022 到 2024 那阵子。核心就一件事：怎么把一句话调到完美，让模型一次就给你想要的东西。
后来是 Context Engineering，2025 火的。Shopify 的 CEO Tobi Lütke 那句定义最好懂：把任务能被模型解出来所需要的全部上下文，都喂给它。重点从「这句话怎么写」挪到了「模型眼前到底摆着哪些料」。Anthropic 自己也说，context engineering 是 prompt engineering 的自然延伸，不是把它废了。这个「延伸不是废掉」的调子，下面还要用。
再往后是 Harness Engineering，2026 年初。当 agent 开始在生产里干多步、长程的活，大家发现真正费心的是它周围那套架子：工具、约束、反馈，把模型裹起来的整个环境。
到了 2026 年六月，最上面这一层有了名字，Loop Engineering，Addy Osmani 给它命的名，Boris Cherny 那句话把它点燃。
那 loop 本身是个啥？说白了，就是你设计 agent 要钻进去跑的那个圈：找活、规划、动手、验收，跑完一轮看没到位就再来一轮。最关键、也最容易被忽略的一个零件，是退出条件。有句话我特别认同：没有退出条件，就不算 loop，那只是一个 agent 在那儿空转。退出条件可以是死的，比如所有测试通过、CI 绿了；也可以是活的，比如再派一个 agent 当裁判，拿产出去比对你给的标准。
人在这里面的角色变了。你不再是那个每一轮都坐在键盘前敲下一句话的操作员，你变成了设计这个圈怎么转的人。设计一次，它替你跑很多次。
我为什么一看就懂：这事我每天都在经历
这套东西落到我身上不是概念。
我每天主力是 Claude Code 配 Opus，改的是真实仓库，不是玩具 demo。前阵子我干了一个七千多行的 SpringBoot Java 工程往 Kotlin 迁的活，那一个任务，前前后后来回改了几十次。这就是一个 loop：它改一版，我或者它自己跑一遍看哪儿崩了，读报错，再回去改，再验。不是我把一句完美的 prompt 写出来它就一把过的，是靠一轮一轮的反馈往收敛里磨。
更典型的一回，是我实测一个国产的终端编程 agent，叫 MiMo Code。我让它写一个零依赖的 Node 小工具，解析 Markdown 的 frontmatter，顺手自己写测试。它写完第一轮跑，五个用例，三过两败。败在哪呢？它那个解析标量的正则太贪心，把 tags: 这种带列表的字段也抢着匹配了，直接赋成了 null，底下的 - javascript 没人接。
我盯着看接下来发生了什么。它自己写的那个测试，把它自己写的 bug 给逮住了。它读 TAP 报错，自己诊断出来，原话是「标量正则在列表项被处理之前就匹配了 tags: 并把它设成了 null」，这判断跟我手动看代码得出的一模一样。然后它一次 Edit 把正则收紧，重跑，五个用例零失败。我自己拿真实样例又独立复核了一遍，全过。
「写测试 → 测试抓出自己的 bug → 读报错自诊断 → 改 → 再验」，这一整条自我修正的环，真的收敛了，诊断准，改得也干净。那一刻我没想到「loop engineering」这个词，但现在回头看，这不就是教科书级的一个 loop 吗。它的命根子，恰恰就是那个 verify 的环节和那个「跑通了才停」的退出条件。
Simon Willison 其实早在 2025 年九月就把这层窗户纸捅破了，他写过一篇就叫《Designing agentic loops》，里面那句「设计 agentic loop 是一项要练的关键新技能」，比今年六月这波命名早了大半年。想法其实一直在那儿，变的是工具。这一年它们终于把这些零件做成了产品自带的能力，不再是每个人攒一堆自己的 bash 脚本。
别光顾着兴奋，loop 是会咬人的
我得把另一半也说清楚，不然就成了无脑吹。
一个能自己跑的 loop，最贵的隐藏成本不是算力，是没人盯的时候它会悄悄出事。这个我刚栽过。我博客整条发布是 GitHub Actions 自动化的，有天负责部署的一个令牌过期了，构建明明成功，只有最后推送那一步认证失败红了，结果静默挂了一整天，我隔天主动去查才发现。没人盯着的自动化，失败是会无声堆积的。loop 也一样，你不给它配一个「失败能被人看见」的告警和一个清醒的退出条件，它能一整夜产出垃圾，或者去追一个永远够不到的目标，停都不停。
还有钱。loop 跑起来 token 是会滚的，一轮套一轮，没有 budget cap 兜着，一个本来两块钱的小活能给你滚成两百块的账单。我对这个特别敏感，每个月给模型的钱不算少，所以我让 agent 干正经活之前，都会下意识在心里掂量一下值不值得动用最贵的那档模型。这种「用之前先过一遍秤」的绷着感，放到 loop 上只会更重，因为它不再是你点一下跑一次，是它自己决定要跑多少次。
所以那句话我特别认：今年能从 loop 里真拿到价值的，不会是 prompt 写得最花的人，是能把「我到底要什么、为什么重要、活干到哪算完」说得最清楚的人。
绕一圈，prompt 和 loop 到底什么关系
回到开头 Boris Cherny 那句「我不写 prompt 了」。
我现在的理解是这样。他没说 prompt 没用了，他是把写 prompt 这件事，下沉成了 loop 里自动发生的一个零件。他往上走了一层，去管那个圈怎么转、什么时候停、出错怎么兜。prompt 还在，只是从他亲手敲的活，变成了他设计的系统替他敲的活。
对我这种天天泡在长任务里的人，这个转变是实打实的。短平快的活，写个函数、改个具体的 bug，我还是会老老实实手敲一句 prompt，那样最快。但凡是要来回磨几十次、能拿测试或者某个明确标准卡住「算完了没」的活，我就该花心思去设计那个 loop，而不是当个人肉的循环，坐那儿一轮一轮手动催它。
prompt 是每一步的底座，loop 是长出来的上层。底座没塌，只是楼往上盖了。
你呢，你现在是还在一句一句手动催着 agent 干活，还是已经开始给它搭能自己跑、自己收尾的圈了？你最想先交给 loop 自动跑的，会是哪个天天重复又能验收的活？评论区聊聊。