写了一个脚本，核心逻辑就一句话：让AI读一段需求，自动写代码，自己跑测试，如果挂了就自己改，改完再跑，直到通过为止。然后我就去睡觉了。
对，就是网上最近疯传的那个写法。
“`bash
while :; do cat PROMPT.md | claude-code; done
“`
一个死循环，一行bash。就这么简单。
早上八点醒来，我一打开电脑就傻了。API账单多了九百多块。但它写出来的东西，居然真的能跑。
你敢信？？？
那一刻我感觉到一种非常奇怪的东西。不是兴奋，也不是心疼钱，而是一种说不上来的不安。就像一个工人半夜回到车间，发现机器自己把活干完了，地上干干净净，工具归位，出库单都签好了。
一个活生生的例子，让我不得不认真对待现在火遍AI圈的这个新概念，Loop Engineering。
很多人一听到这个词就开始头大。什么循环工程，什么自反馈系统，听起来又像是硅谷那帮人发明出来卖课的东西。但其实它的核心想法特别朴素。
就是不要让AI干完一件事就停下来等你。让它自己判断接下来该干什么。
你品品这句话。
过去的AI编程，是你跟AI对话。你问一句，它回一段代码。你再问一句，它再改。你俩像两个人在微信上聊需求，一句一句地来回。这叫什么，这叫Prompt Engineering。
后来我们学聪明了，开始把项目文档、架构说明、编码规范一股脑塞进上下文里。AI不用每次都重新学你的项目长什么样了。这叫Context Engineering。
但Loop Engineering干了一件更狠的事。它把你也给省了。
不是说不需要你了，而是不再需要你盯着它干活了。你变成了一开始定规则的那个人，然后系统自己跑去了。它自己发现要做什么，自己拆任务，自己执行，自己检查结果，自己决定要不要重来，直到你定的目标达成了才停。
说到这儿你可能觉得，这不就是个自动化脚本嘛，有什么新鲜的。
区别大了。
自动化脚本是你把每一步都写死了。第一步删文件，第二步装依赖，第三步跑测试。顺序是死的，分支是死的，出错了也不知道怎么处理。
Loop Engineering是你只告诉它「目标是什么」和「边界在哪里」，具体怎么走到那个目标，它自己去找。
有点像一个新员工入职。你不可能把他每天要干的每件事都写在操作手册上，对吧。你只能告诉他你的期望是什么、什么是不能碰的红线、做完之后怎么检查质量。剩下的，他自己看着办。
Loop就是让AI自己看着办。
我花了好几个晚上翻Addy Osmani那篇论文，又看了国内几位大佬的实践分享，慢慢摸出了一些门道。
Loop Engineering的核心循环分五步。发现，计划，执行，验证，迭代。
发现就是你得让AI知道现在是什么状态。哪些做完了，哪些卡住了，哪些还没开始。计划是让它自己决定下一步做什么。执行就是干活。验证是跑测试、lint、类型检查之类的自动校验。迭代就是如果验证没过，回到第二步重来。
你看这个过程，其实跟人做事一模一样。唯一的区别是它不会累，不会烦，不会说「算了明天再说吧」。
但就是因为它不会停下来，所以有个问题变得特别致命。
状态管理。
你让一个人类盯着一个项目干，你不需要每五分钟跟他重复一遍「这个项目的目标是什么，现在做到哪了」。因为他脑子记着。但AI不记着。或者说，AI的上下文窗口不是用来干这个的。
这是Loop Engineering里面最容易被忽略、但也是最重要的一个真相。别把模型上下文当持久化存储用。模型会忘，会跑偏，会在长对话里悄悄把关键约束吞掉。你让它连着跑五十轮，到后面它可能已经不记得自己的初始目标是什么了。
所以所有靠谱的Loop系统，状态都放在外面。要么写在markdown文件里，要么记在git commit message里，要么挂在一个issue tracker上。每一轮循环都是从一个全新的上下文窗口开始的，但它读到的状态文件是持续更新的。
就像一个迭代了二十轮的AI任务，每一轮的日志都在文件里。AI不需要「记住」前面十九轮发生了什么，它只需要在第二十轮启动的时候读一下文件，就知道现在做到哪了。
这个设计哲学，说实话，我在第一次看到的时候整个人是愣住的。
因为我们太习惯把什么都塞进上下文了。文档塞进去，代码塞进去，规则塞进去，历史对话塞进去。觉得塞得越多越聪明。但Loop Engineering告诉你，恰恰相反。上下文越干净，循环越稳定。记忆交给文件，推理交给模型。各干各的。
把底层的问题解决了，Loop才能跑起来。那跑起来之后呢。
老实说，很烧钱。
我那个脚本一晚上烧了八百多块，还是在设置了最大迭代限制的情况下。如果是真正的生产级Loop系统，几十上百轮地跑，一天烧几千块钱非常正常。而且更让人难受的是，有些烧掉的钱你收不回来。
比如AI在验证阶段发现自己写的代码跑不过测试，它会自动滚回去重写。一遍两遍三遍，每写一遍都是API调用的钱。而且有时候它会在两个错误方案之间反复横跳，一会儿说「我觉得该用方案A」，改完发现跑不过，又说「那试试方案B」，改完还是跑不过，又说「看来还是方案A更合理」。
我特么看日志的时候差点一口气没上来。
所以Loop Engineering有一个我自己总结的铁律。如果你的任务不值得花五百块钱以上的API费用去解决，不要上Loop。手动写给AI的prompt，两三轮对话搞定的事情，别套个循环。
Loop是用来解决那些「你知道目标但不知道路径」的问题的。不是用来解决「你会写但懒得写」的问题的。说到底，Loop Engineering给我的感受不是「AI变强了」。而是「人类在AI面前的角色变了」。
我们从操作员变成了监督员。从写prompt的人变成了设计规则的人。从亲自动手的工匠变成了站在流水线后面看仪表盘的工厂经理。
这种感觉特别拧巴。一方面你觉得效率确实提上去了。另一方面你又觉得，你离创造越来越远了。
但这是时代的选择。不是你的选择。
Loop Engineering现在还很早期，很多最佳实践还是散落在各个大佬的GitHub和个人博客里。但它的方向已经非常清楚了。AI编程的下一个战场，不是谁的模型更强，而是谁的反馈系统设计得更聪明。
一个模型再强，你只能跟它一对一对话，它也只能帮你干一件事。一个反馈系统设计得好，你可以让十个模型同时干活，你只需要负责在它们搞砸的时候踩一脚刹车。
