循环工程（Loop Engineering）到底在干什么？拆穿一个被过度包装的概念

Claude Code 之父 Boris Cherny 前段时间说了一段话：一年前我还在写提示词让 AI 写代码，现在我不写提示词了，我有一堆循环在后台跑着，它们替我去提示 AI、替我判断下一步做什么。我的工作变成了写循环。

紧接着，现在在 OpenAI 工作的 Openclaw 创始人 Peter Steinberger 也发推：你不该再给编程 Agent 写提示词了，你应该设计一套循环机制，让循环去提示你的 Agent。

700 万浏览量，评论区炸了。有人说这是下一个范式转移，有人预言 LinkedIn 上马上会冒出一堆"循环工程师"的新头衔。

但我最喜欢的是这条评论："我们已经从学会写代码，走到了学会编写那个会写代码的东西。不知道为什么，这听起来既像进步，又像金字塔骗局。"

我对这个话题做了一轮比较深的思考，想把我想到的东西分享出来。

一、你本人就是那个循环

在聊任何技术细节之前，先想一个问题。

你用 AI 写代码的时候，你在干嘛？提需求，看结果，判断行不行，拍板下一步做什么。AI 改完你再看，不满意再改。

提需求，看，判断，拍板。再看，再判断，再拍板。

这个过程本身就是一个循环，只不过跑在你脑子里，靠你的手一轮一轮驱动。

所谓"写循环"，说白了就是：把你脑子里那套监工逻辑写成规则，交给一个程序替你盯着。你之前是亲自在工地转悠的包工头，现在你想写一本巡检手册，让机器人替你转。

为什么会走到这一步？因为瓶颈转移了。早期 AI 能力弱，瓶颈在 AI 那头，它代码写不好你只能自己上。后来 AI 变强了，能独立搞定不少活，瓶颈就悄悄挪到你身上了。AI 一分钟产出的东西你要花十分钟审，还不一定审得过来。你的注意力成了整条链路上最窄的口子。

"能不能搞个程序替我审？"这个念头就是循环工程的起点。

方向完全没毛病。但接下来的问题才是真正要紧的：你能把巡检手册写得跟你亲自转悠一样靠谱吗？

二、一个跑通了的案例

有个开发者说自己已经在用循环做开发了，效果还很好。做法挺值得拆开看的。

他先用 HTML 写了一份像素级精确的设计稿，最终页面该长什么样全部定死在里面。然后写了三层测试：端到端测试模拟用户操作，点登录、填密码、提交，看是不是正常跳转；UI 测试把 AI 写出来的页面截图跟设计稿截图做像素级比对，差 1 个像素就红灯；单元测试管底层逻辑，输入 A 该输出 B，错了就报。最后写了一份 plan.md，把需求拆成一个个明确的小任务。

然后他在 Claude Code 里敲了一行：

/goal 实现 plan.md 中的所有需求，直到 npm run test:all 通过

Claude 就开始干了。读 plan，挑一个没做的，写代码，跑测试，红了就改，改了再跑。折腾几个小时，UI 完美还原，功能全部到位。

到这里你可能觉得循环工程真的很猛。但我反复看这个案例，越看越觉得有意思的地方不在循环本身。

你想想 AI 在这整个过程里做的判断有多复杂？它只需要看灯。红了就改，绿了就下一个。它不需要"懂"这个需求，不需要有品味，不需要权衡任何取舍。它就是一台把红灯变绿灯的机器。

那谁在做真正难的判断？"页面该长什么样"、"功能做到什么程度算对"、"逻辑该怎么组织"，这些全是那个开发者在循环启动之前就做完了的事情。他把自己脑子里的标准，硬生生翻译成了机器能跑的测试用例。

这个人的核心能力不是会敲 /goal，/goal 三岁小孩都会敲。他的核心能力是能写出那套测试。

你发现了吗？循环替代的不是他的判断力，而是"写代码和 debug"这个苦力环节。他的判断力没有被自动化，只是被前置了，提前编码进了测试用例里。

三、循环的天花板长什么样

上一节那个案例能跑通，有三个前提：目标可以像素级精确定义，成功标准可以全自动验证，任务范围从头到尾不会变。

所有的模糊性都被提前消灭了。AI 其实是在一个完全确定的框架里做填空题。

那如果模糊性没法被提前消灭呢？

实际开发中大量判断就是这种。这个架构方向走不走得通？用微服务还是先上单体？这个功能做到什么程度就够了，再多是不是过度设计？这些问题你自己可能都是边做边想明白的。让你在动手之前就写成测试用例，你写不出来。

不是你能力不行，是这些判断的性质决定了它不可能被提前编码。有些答案在你做的过程中才会浮现，运行过程中会冒出新状态，那些状态在启动之前根本不存在。

所以循环能走多远，完全取决于一件事：你面对的这个任务，有多少判断可以被翻译成机器能自动验证的规则。

CI 监控、依赖升级、代码格式检查、有完善测试的功能开发，这些场景里循环确实好用，因为"做没做对"可以用脚本判定。

但一旦进入需要品味、需要取舍、需要理解"用户到底想要什么"的地带，循环就转不动了。你没法把"品味"编译成一个返回 true 或 false 的函数。

四、那些布道者没有提到的事

Boris 和 Peter 说的都是真话，但不是全部真话。

他们没提到的那部分：他们仍然在频繁审查循环的产出，仍然在手动调参数，仍然在关键节点做判断。人没有被移出循环，只是从"每一轮都盯着"变成了"隔几轮看一次"。

他们也没提到一个更大的前提：他们背后的公司给了近乎无限的 token 预算。有开发者直接怼了一句大实话："你们有无限 token，我没有啊。"循环跑 8 小时就是 480 次 API 调用，对 token 预算紧巴巴的团队来说这不是一个"试试看"的事情。

而且循环跑偏的代价，远不是一条写错的提示词能比的。

有个真实案例：AI 要处理一个数据库外键约束问题，它明明已经读到了错误信息，知道毛病在哪。然后它花了 47 轮反复尝试同一条命令的各种语法变体。一个 5 毛钱就能解决的问题，变成了 30 美元的学费。还有更离谱的，某个 Agent 一夜之间烧掉 437 美元，因为它陷入了一个"自己觉得有道理但其实在原地打转"的推理循环。

循环放大了 AI 的生产力，但同样放大了 AI 的愚蠢。而且是悄无声息地放大，你不盯着都不知道钱去哪了。

五、诚实的定位

循环工程不会杀死提示词工程，就像自动挡没有杀死驾照考试。

它就是自动化的边界往外挪了一步。以前只能自动化纯机械的重复动作，现在因为 AI 能做一些简单判断了，一部分需要判断力的持续性工作也可以被自动化了。

但这一步能走多远有个硬顶：你能把多少判断编码成可验证的规则。编码得出来的部分交给循环，编码不出来的部分还是你的活。

那些说"我的工作变成了写循环"的人，如果真的跟拍他们一整天，你会发现他们大部分时间不在写循环。他们在看循环产出的东西对不对，在修不满意的地方，在处理循环搞不定的棘手情况。循环扛掉了 80% 的常规事务，但真正决定项目质量的，往往就是那 20% 需要人出场的部分。

说"杀死提示词工程"是炒作。说"让人的注意力从低价值操作中释放出来，集中到高价值判断上去"是实在的价值。前者是标题党，后者是工程现实。

六、真正值钱的是什么

回到那个成功案例。

那个人凭什么能让循环跑几个小时就交付一个完整功能？不是因为他懂什么循环工程，而是因为他能把脑子里那句"这个东西该做成什么样"，翻译成一整套精确的、机器能自动执行的验证体系。

他对产品质量的品味有多高，测试就能写得多严格。他对需求理解有多透，验收标准就能定得多精确。他对系统边界的判断有多准，约束范围就能画得多合理。

循环只是壳子。灌进去什么质量的判断力，就出来什么质量的产出。

这跟提示词工程是一回事。当年大家喊"提示词是新范式"的时候，真正重要的也不是句式、格式、角色扮演技巧，而是你有没有想清楚自己到底想要什么。

不管明年又冒出什么新词，底下那个能力需求从来没换过：想清楚你要什么，说得足够精确，让对面能照着做。

这个能力永远稀缺。因为大多数人卡住的地方，从来不是"怎么跟 AI 说话"，而是自己压根没想清楚要什么。

我建了一个AI学习研究群，目前几十来人，都是在真正动手搞AI的人。如果你也在自己跑模型、写代码、做项目，欢迎点赞关注转发一键三连，然后加我微信，备注写清"你在做的AI方向"，聊得来的话我拉你进群。纯围观的和小白就不加了，有一定门槛。