最近疯传的 Loop Engineering，是台印钞机，还是绞肉机？
你有没有发现，用 AI 写代码写到现在，自己越来越像个高级保姆？
你花半小时把需求掰碎、把上下文喂满，它「啪」一下吐出 500 行代码。然后你花一个半小时，瞪着眼睛找：这里有没有内存泄漏，那里是不是藏了个并发竞争，这个改动会不会在三个月后坑死另一个同事。你好不容易把它从一个屎山里捞出来，它扭头就跳进了下一个。
最后算下来，好像也没快多少。你从「敲键盘」的体力活里解放了，转身就掉进了「给 AI 当质检员」的脑力黑洞。
现在，有人告诉你，这个保姆你也不用当了。
最近一周，Addy Osmani、Boris Cherny（Claude Code 的主创之一）、Peter Steinberger 几乎前后脚提了同一个词——Loop Engineering，Addy 那篇冲了 180 万阅。说白了就是：别再手动一句句 prompt 了，写一个程序，让它自动喂 AI、自动验证 AI 吐出来的东西、再把验证结果喂回去让它自己改。套一个循环，让它自己跟自己玩，你躺着等结果。
整个栈是四层：prompt → context → harness → loop。loop 是 harness 上面那层楼。
听着是不是很美？一个 7×24 不打盹、不要钱、还会自我纠错的开发，正在向你走来。
别做梦了。
我拿过去半年踩的坑跟你打个赌：对绝大多数团队，这东西不是印钞机，是一台会自我繁殖的屎山制造机，一台能把自己活活转死的绞肉机。
因为所有人都把劲儿使错了地方。
一、成本不对称，才是那头房间里的大象
先把这个 loop 拆开，它无非三步：生成（Generator）→ 验证（Critic）→ 迭代。
现在所有鼓吹 Loop Engineering 的人，眼睛都死死盯着 Generator 那一环：用哪个模型生成更快、用什么技巧生成得更多、怎么让它一次写得更长。
这恰恰是最不重要的。
我在 5 月那篇《代码生成越快，工程交付越慢》里下过一个判断，今天看，它就是 Loop Engineering 的命门：
AI 生成 500 行代码，成本是 O(1)——点一下回车的事。而你作为审查员，去验证这 500 行黑盒里有没有藏并发竞争、会不会 OOM、符不符合业务，认知成本是 O(N)，甚至 O(N²)。
这个极端不对称，才是你今天用 AI 写代码所有痛苦的根源。你原本是创作者，现在是质检员，站在一条全是盲盒的流水线尽头，干着最高危的活。
现在你再看 Loop Engineering 干了什么。
它用一个自动化的循环，把那个 O(1) 的、几乎零成本的生成端，接上了无限动力。Generator 这一侧从此不要钱、不知疲倦、可以瞬间涌出海啸般的代码。
那个 O(N) 的、昂贵的、需要人来兜底的验证端呢？
它没动。
你想想这意味着什么：一个没有强 Critic 的 loop，本质上是在以 O(1) 的速度，往你那个 O(N) 的瓶颈里疯狂灌垃圾。 转得越快，灌得越猛。机器跑一夜，你第二天来，面对的不是一个交付物，是一座拔地而起、结构精巧、逻辑盘根错节、但从地基就烂掉的屎山——而且它还在以指数级的速度自我繁殖。
所以，决定一个 loop 是「资产」还是「负债」的，从来不是它的 Generator 有多强，而是它的 Critic——那个验证环节——有多硬。
Generator 是你花钱就能买到的现货，你用 Claude 还是 GPT，谁手里都有。但 Critic，是你必须自己动手、为自己的业务和代码库量身打造、决定整个系统生死的那块刹车和方向盘。
二、怎么造一个 AI 撞不穿的铁笼
那一个「硬」的 Critic 该长什么样？
答案我其实 3 月写 harness、5 月写「从生成工程到约束工程」时就摸到了。今天我把它讲得更狠一点：
别指望 AI 自我反思。你必须把人类工程师脑子里那些不能碰的「全局不变量」，铸成一个 AI 在循环里无论如何也跑不出去的铁笼。
一个资深工程师为什么靠谱？因为他脑子里有无数条高压线：表现层不能反向依赖数据层；领域模型必须单向数据流；这个状态变更必须是原子的、幂等的。正是这些约束，把程序可能出错的状态空间，死死锁在一个极小的可控范围里。
但 LLM 的思考方式是「局部最优」。为了让眼前这个小功能跑通，它会毫不犹豫地穿透三层架构去调一个底层连接，或者挂一个生命周期 hook 污染全局。它用一个局部的小聪明，换来一个全局的架构腐烂。手动模式下，你这个保姆还能拦住它；进了自动循环，没人拦得住。
所以一个能上生产的 loop，它的 Critic 必须由这几样「硬家伙」构成：
1. TDD 当锁链，不是质量小红花。 忘掉你以前理解的 TDD。在这里，测试不是「代码写完后的质量保证」，而是循环开始前就焊死的、带电的铁栅栏。先把业务不变量、性能基线、安全红线写成一个个会失败的测试。AI 生成的任何一圈，第一件事就是扔进去跑。过不了？连着失败日志一起打回去重写。测试在这里是循环的退出闸门，是关押 AI 的那道墙。
2. 类型与契约，当编译期的防线。 把你脑子里那些「想当然」的隐式假设，全变成代码里的显式契约：强类型、前置/后置断言、接口规范。让 AI 犯的那些低级但致命的错，在进入测试环节之前，就在编译期或静态检查阶段被直接拦下。这道防线越靠前，整个 loop 越高效——它能更早剪掉那些注定失败的分支，不让垃圾流进下一圈继续发酵。
3. DDD 划边界，切断 AI「污染全局」的能力。 别给 AI 一个上帝视角的 monorepo。给它一个边界清晰的有界上下文，它能读什么、能调什么，由你严格规定。这样就算它在自己的小圈子里玩脱了，也没机会顺着耦合链一路污染到核心领域模型。上下文越小越干净，AI 每一圈的输出越确定。
看明白没？这三样东西本质上是同一件事：把人类专家脑子里的隐性知识，变成机器必须遵守的显性规则；把验证，从事后靠人眼审查的软约束，变成循环内部自动执行的硬约束。
这才是 Loop Engineering 里真正的工程含量。不在那个让它「转起来」的脚本，在那个让它「不出轨」的铁笼。
三、机器踩油门，人决定方向盘在哪
loop 跑起来了，人是不是就能躺平了？
恰恰相反。你的角色，从一个跟 AI 掰扯代码细节的执行者，被逼成了另一个物种：一个控制系统熵增的架构决策者。
当机器能以近乎零的成本无限试错，你那个一次性的、无法自动化的「判断」，就成了整条流水线上最宝贵、也最危险的杠杆。
你设计的铁笼够不够结实？你给循环设的退出条件，是能交付一个 80 分的东西，还是会把它逼进一个永不收敛的死循环？loop 卡住时，你判断该调 Critic、该回去重写约束、还是干脆停掉另起炉灶？
AI 已经把油门踩到了底，而你，是那个唯一能决定方向盘往哪打、刹车什么时候踩的人。
从「写代码的执行者」，到「控制一台代码生成系统的人」，这道分叉，到 loop 这一层只会劈得更深、更残酷。不懂得怎么造 Critic、怎么踩刹车的人，迟早被自己造出来的这台机器活活埋掉。真正掌控它的，永远是那个知道刹车踩在哪的人。
更多 AI 工程一线判断，都在 rbits.uk；关注公众号「随机比特」，每天拆一个 AI 工程的真相。
—— 随机比特
