硅谷爆火的Loop‑Engineering拆解：不靠强Prompt，靠循环让AI代码自我进化

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

前言

前段时间硅谷AI圈突然刮起一阵风，叫Loop Engineering。

传得有多快呢？比咱们公司群里传老板要裁员的消息还快。

先是Claude Code的负责人说自己现在都不直接写prompt了，写循环，让循环自己去折腾AI。接着Google Cloud的人给起了个正式名，国内媒体立马一窝蜂跟上。

我一看这不就是我偷偷跑了小半年的东西吗？合着我先实操了，概念才追上来。

今天就不跟大家扯概念了，网上讲概念的比讲养生的还多。我就拿自己跑了半年的生产环境实战，给大家拆解拆解这玩意儿到底是怎么回事，顺便吐槽吐槽那些踩过的坑。

单人写代码的三大致命坑，你中了几个？

先唠唠为啥要搞这套东西。

以前用AI写代码，主打一个vibe coding——张嘴说需求，AI哗哗写代码，我审查微调。效率确实涨了，以前干几天的活几小时搞定，原型几周的活几十分钟完事。

但爽是爽了，新问题也来了，而且全是单人开发的老毛病，AI一来全给放大了。

第一个坑：确认偏误

说白了就是，你说啥AI都附和。

你拍脑袋说“这个功能就得用方案A”，AI立马给你列八条理由证明方案A牛，给你哄得找不着北。

你永远不知道方案B是不是更香，因为根本没人跟你抬杠。一个人脑暴，本质就是自己跟自己玩回音壁，说啥都有回声，还以为自己想得贼全面。

第二个坑：审查疲劳

一开始AI写代码，你逐行看，比查对象手机还认真。

两周后开始跳读，一个月只看diff，三个月扫一眼函数名就敢提交。

真不是你懒，是大脑自带经济账：95%的代码都是对的，我费那劲干啥？自动就把审查预算砍到5%。

可问题是，那5%的bug从来不会自己贴个标签说“我是坑”。专等你上线了才跳出来给你惊喜，比老板突击查岗还准时。

第三个坑：记忆蒸发

三个月前修的那个诡异bug，你翻注释就写了一行“fix edge case”。

当场大脑一片空白，比酒醒了忘昨晚说了啥还茫然。

单人开发就这点惨，没同事能问“你还记得那bug咋修的吗”，每次遗忘都得从头debug一遍，相当于把吃过的苦再吃一遍，纯纯二次伤害。

这仨问题说穿了都是人的问题，AI只是把以前被团队掩盖住的单人弱点，全给扒出来了。

那咋办？总不能再招几个人吧，成本多高啊。

所以我就琢磨，能不能搞一套系统，用规则把这些毛病全管住？

这套loop流水线，就这么来的。

七步流水线：不是让AI变聪明，是让它少犯蠢

先给大家看整体结构，一共七步，从需求到记忆整成一个闭环。

说白了就是搭了个虚拟小团队，七个agent各司其职，各有各的性格、权限、用的模型，输出的文档全整整齐齐放一个目录里。

模型分配也不是瞎选的，不是哪个贵就用哪个。

审查这种需要判断力的活，就用贵的Opus，慢是慢点，但准；写代码、测功能这种执行活，就用性价比高的Sonnet，快还便宜。

跟开公司一个道理，专家岗给高薪干把关的活，执行岗招性价比高的干体力活，成本控制这块算是玩明白了。

下面不挨个念说明书，agent定义都在开源仓库里，纯文本五分钟就能看完。我挑几个最有意思的设计决策跟大家唠。

设计一：一次只问一个问题，禁止“顺便问一下”

一般AI澄清需求，都是一下甩五六个问题，看着效率高，实则质量稀碎。

人的注意力是串行的啊，你回答第三个问题的时候，心里已经在想“啥时候问完”了，后面的问题全是敷衍。

我就给clarify agent定了死规矩：一次只问一个，不许批量提问，不许搭便车。

而且它得先读代码再提问，代码里能找到答案的，就别张嘴问人。

改完之后啥效果？每轮对话深度直接上来了，产出的需求文档也靠谱多了。

代价就是慢，一个功能澄清得聊四五轮。但也有退出机制，你嫌烦了说一句“够了，开始设计”，立马就停，绝不墨迹。超过八轮还没问完，系统自己就停了，防止它变成话痨无限追问。

设计二：先猜后看，审查玩起了预判

这是我最得意的一个设计。

一般代码审查都是上来就读代码，找问题。我偏不。

review agent先不看代码，只看设计文档和实现说明，先列3到5个最可能出问题的地方，比如“错误处理会不会漏”、“并发会不会有竞争”。

带着这些预判再去审代码，一边找一边对答案：哪些猜中了，哪些没猜中。没猜中的更重要，说明这是盲区。

这可不是我瞎想的，认知科学里早就有结论：先看答案再推理，你会高估自己的水平；先做预测再对答案，准度直接飙升。

而且预判不是瞎猜，是从历史踩坑记录里扒出来的。每次做完项目，系统都会把教训存起来，下次审查先翻旧账，专盯着以前摔过的地方看。

说白了就是，在哪摔过，下次就先盯着哪，绝不同一个坑摔两次。

设计三：小问题当场修，不许“以后再说”

审查出问题，也不是全打回去重写，分等级。

严重的、重要的，必须修，不修就卡着不让过，跟考试不及格不让毕业似的。

那些小问题、小建议，就走“低风险即修”规则。

啥意思？只要有客观依据、不改接口、改动不超20行还在一个文件里、不用问人，那就必须当场修掉，不许说“这个不重要先跳过”。

别小看这些小问题，今天跳过一个，明天跳过一个，三个月后一百个小问题堆在一起，代码库就烂得没法看了，跟你攒了三个月没洗的袜子一样，碰都不想碰。

而且想延后也得有正当理由，就四种：超范围了、要问用户、得大改、跟设计冲突。不许说“后续优化”这种屁话，说了直接打回，照样卡着。

设计四：经验不是啥都存，三条铁律筛废话

很多人搞经验总结，最后全存了一堆正确的废话：“要写测试”、“注意并发”、“文档很重要”。

这不扯吗？这些东西谷歌一下全有，占内存干啥？

我给存经验定了三条死规矩，三条全满足才能存：

第一，网上搜不到的，通识一律不要；

第二，跟项目强相关的，能指到具体文件具体错误的，空泛的经验一律不要；

第三，真踩过坑付出代价的，顺手做的功能不算。

而且总数量就保持5到8个，有上限。新的进来，旧的就得合并或者扔掉，防止越存越多，最后变成没人看的垃圾场。

这么一筛，存进去的全是真金白银踩出来的坑，下次用的时候一搜全是干货，效率直接拉满。

设计五：换个厂商挑毛病，抓自家模型的盲区

虽说审查和测试是两个独立agent，但都是同一个模型家族的，就像亲兄弟，有些盲区一模一样。

有些错Claude就是看不见，不是能力不行，是训练数据带的偏见。

咋办？找外援。

写代码之前，先换个厂商的模型，独立评审设计文档。DeepSeek、Kimi啥的，只要兼容接口都能用，拉个独立会话，把文档喂进去，拿一份评审报告。

当然这个评审只是建议，不卡流程。就是给你多一个视角，Claude觉得没问题的设计，换个模型说不定能找出好几个坑。你觉得有道理就改，觉得没事就接着往下走，选择权在你手里。

编排层：把审查做成真·闸门，不是走形式

前面说的都是单个agent的设计，整套系统最核心的，其实是/ship这个编排器。

它不是一个agent，是个状态机，把开发、审查、测试串成一个循环，没问题了才放行。

听起来简单，细节里全是门道，决定了这套流程是真把关，还是走个过场装样子。

第一，审查和测试，上下文完全隔离

写代码在当前会话，你能实时看着改，随时打断。

但审查和测试，是开独立子agent跑的，上下文完全隔离。它们只能看到设计文档和实现说明，看不到你中途改了啥又撤回了啥，也看不到开发agent的思考过程。

为啥要这么干？

要是共享上下文，审查很容易被开发的思路带偏，不知不觉就顺着人家的话走了，还审个啥劲。

独立上下文就是强制审查保持中立，别搞官官相护那一套。

第二，闸门是真阻断，不是摆设

很多所谓的流程卡点，都是纸老虎，失败了手动点个跳过就完事了。

我这不行，是硬阻断。

审查结果回来，只要严重和重要问题的数量大于0，直接跳过测试，打回开发重写。

必须把所有阻断项都处理完，才能进下一轮。

为啥有问题要跳过测试？省钱啊。带着已知bug去测，测出来也是同样的问题，纯纯浪费token。先修干净了再测，才是正经事。

第三，循环有上限，防止无限烧钱

token都是真金白银啊，可不能让系统瞎折腾。

跑了4轮还没搞定，就会停下来问你：“还接着跑吗？”超过5轮直接强制终止，给你列剩下的问题和原因分析。

不是不信任AI，是防止它陷入“差一点就成了”的死循环，跟你刷短视频似的，不知不觉半小时没了，钱也没了。

第四，文档就是接口，全程可追溯

所有agent的输出都老老实实存在目录里，七份文档整整齐齐。审查报告和测试报告都是增量追加，新内容放上面，旧的往下推，不许改历史记录。

啥好处？你能回溯整个功能的演变过程：第一轮查出啥问题，开发怎么改的，第二轮验证了啥，哪些问题修了哪些接受了，一清二楚。

这些文档不是为了归档吃灰，是给下一个功能当参考的，前人踩坑后人避坑。

说实话，这玩意儿也不完美，坑还不少

吹了这么多，也得说说实话。这套东西不是银弹，毛病也挺多。

第一个毛病：上下文窗口吃紧

循环跑多了，历史文档越来越长，每个agent都得读一遍，几万token哗哗就没了。

就跟你开二十个网页，电脑不卡才怪。我现在也在琢磨自动压缩历史文档，但还没整利索。

第二个毛病：审查和测试偶尔“串通”

毕竟是同一个模型家族的，有些盲区一模一样。你看不到的我也看不到，俩人情不自禁就统一战线了。

所以才搞了跨厂商评审，但目前只在设计层做了，代码层还没整。

第三个毛病：简单任务太笨重

修个typo、改个文案，也要跑完整套七步流程，纯纯脱裤子放屁。

我现在就是凭感觉判断，小任务就不跑全流程。但啥叫小任务，还没个准数，这也是后面要解决的问题。

第四个毛病：经验闭环还不够紧

按理说，存的经验应该在设计阶段就用上，避免重蹈覆辙。但现在设计环节用得还少，主要还是审查的时候用。

相当于学了知识只在考试的时候翻，平时上课不用，效果打了折扣。

第五个毛病：全靠CLAUDE.md撑着

要是你项目的CLAUDE.md写得烂，或者干脆是空的，那所有agent都在瞎忙活。

垃圾进垃圾出，这是AI的老毛病了，不是loop能解决的。前提条件不行，啥流程都白搭。

真正牛的不是代码循环，是进化循环

说了这么多，大家要是只记一件事，就记这个：

这套系统最值钱的，不是开发-审查-测试的代码循环，是复盘-存经验-下一次优化的进化循环。

代码循环保证这次少出错，进化循环保证下次比这次强，而且是自动变强。

刚搭起来的时候，就是个防错流水线，经验库是空的，审查预判全靠瞎蒙，命中率也就一半。

跑了半年，经验库存了七条实打实的事故模式，不是空话，都是“这个模块跨市场时间对齐会飘”、“上次漏了异步竞态是因为没画时序图”这种干货。

现在审查先翻经验库，命中率直接干到七成多。

模型没升级，还是那个Opus，但系统自己变强了。因为它记住了在哪摔过，下次先盯着那个地方看。

这也是为啥存经验的规矩那么严。不是存储空间贵，是废话会毁了这个进化循环。存一百句“注意边界条件”，下次检索全是噪音，命中率反而更低。

少而精的经验才是燃料，多而杂的纯纯是阻力。

那Loop Engineering和以前的Prompt Engineering到底啥区别？

核心区别就是：循环本身会不会学习。

没有记忆、没有校准、不会改进的循环，就是个带重试的脚本，同一个错重复犯，烧N倍token，最后碰巧过了。每次都是从零开始，啥也没留下。

会学习的循环，每跑一个功能，都在三个地方攒经验：

知识上，踩过的坑存起来；

校准上，漏过的错变成重点关注区；

流程上，不好用的规则就改。

这不是一次性的效率提升，这是复利。跑的功能越多，系统就越强。

最后说点实在的

整套东西我已经开源了，clone下来跑个安装脚本就能用，在项目里敲几个斜杠命令就能跑流程。

开源不是因为我觉得它完美，恰恰是因为它不完美。上面说的那些毛病，全是真实用出来的。开源就是想让更多人用用，告诉我哪设计错了，大家一起改。

要是你也想试试，给你几个建议：

别一下七个全上，先从审查和复盘开始，这俩性价比最高。一个拦bug，一个攒经验，先用起来再说，其他的等你觉得需要了再加。

先把CLAUDE.md写好。花一小时写个靠谱的上下文，比花一天调prompt有用多了。地基打不牢，楼盖得越高越容易塌。

第一个功能的经验积累，就当投资。头几个功能可能啥都存不进去，因为规矩严，很正常。等跑两三个功能，经验慢慢就有了，后面的功能会越来越顺。

这套东西的目标从来不是完美，而是今天比昨天强一点，下个功能比这个少踩一个坑。

六个月跑下来，它确实做到了。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01