Loop Engineering 的边界与悖论

TL;DR

Loop Engineering 的天花板不是 token，是工程师的判断力。而 Loop Engineering 本身正在削弱这个判断力。

一、Loop 为什么在某些场景特别好用

Armin Ronacher——Flask 的作者，也是 Loop Engineering 的早期实践者——整理过几个他认为 loop 真正有效的场景：代码移植、性能探索、安全扫描、研究探索。

这些场景乍看起来没什么共同点，但仔细看，它们共享同一个结构：这类产物不用被长期维护，或者可以被机械化验证。

代码移植是等价变换——把 Zig 写的东西搬到 Rust，行为不变，有现成测试套件做裁判，通过就是通过，不通过就是不通过。性能探索是跑 benchmark 数字，更高就是更好。安全扫描是模式匹配，命中就是命中。研究探索的产物——发现报告、PoC、demo——本来就是一次性的，没有长期维护的预期，人看一眼觉得有价值就算完。内部工具、脚本、自动化辅助类产物也在这个范围里——不跑在生产关键路径上，容错空间大，跑坏了代价有限。

这些场景的验证器都有一个共同特点：给出二元信号——非此即彼，没有灰色地带，可以被机械化检测，不依赖人的判断。loop 只需要一个能驱动下一次迭代的信号，信号清晰，loop 就能稳定收敛。

二、为什么其他场景 loop 会失控

老代码库有个俗称：屎山。

人在屎山上开发，通常是一锹一锹地加——每次改动范围有限，知道自己在哪里挖，也知道哪里不该乱动，反而会比较慎重。但 AI 在屎山上跑 loop，是另一回事。

Ronacher 直接描述了他观察到的模型倾向：生成的代码过于保守、过于复杂、推理范围过于局部。模型倾向于观察局部故障并添加局部防御——不是找到根本原因，而是在出问题的地方再包一层。它们回避强不变量，用回退方案替代杜绝错误状态的设计，重复代码，用更多机制掩盖设计缺陷。

单次执行时，这些倾向还算可控。一个有经验的工程师 review 一下，能看出问题。

但 loop 会把这些倾向逐轮放大。每一次迭代，模型在上一轮的基础上继续加防御、加回退、加补丁，系统在表面上越来越「健壮」，内部却越来越难以理解。Ronacher 说：他几乎没看到这方面的改进迹象。

问题不在于 loop 跑了多少轮，而在于每一轮的偏差都在往同一个方向积累。和屎山的形成机制是一样的——不是哪一次改动出了大错，是无数次局部决策叠加之后，整体变得没人能说清楚。

区别只有一点：人在屎山上是一锹一锹，AI 在屎山上是一轮一轮，速度快得多。

三、真正的边界在哪里

说到这里，一个直觉上的解法是：选对任务类型，避开容易失控的场景。

但这个解法是错的。Loop 能不能用，不取决于任务类型，而取决于能否为它建立有效的验证器。

代码移植之所以适合 loop，不是因为它是「移植类任务」，而是因为它天然有一个强验证器——测试套件全过就是对，不过就是错，二元信号。如果你要移植的代码没有测试，loop 一样会失控。安全扫描之所以适合，不是因为它是「扫描类任务」，而是因为漏洞模式是可以被显式定义的。

反过来，为什么在生产代码库上跑 loop 容易出问题？因为你写不出一个能检测「架构是否合理」「抽象是否恰当」「日后还能不能看懂」的验证器。这些判断没有二元信号，无法被机械化，只能靠人来做。

这里有一个关键的区分：验证器是工程师判断的投影，但只是其中「可机械化表达」的那部分。

你能量化的部分——测试通过、lint 不报错、方法不超过 30 行——可以写进验证器。但工程判断里还有大量无法量化的部分：这段代码有没有多余的间接层？这个设计遇到新需求时会不会崩？这里的抽象是解决了问题还是在掩盖问题？这些判断存在于工程师脑子里，写不进任何自动化检查。

所以验证器的天花板，就是你的判断力里「可量化部分」的天花板。而 loop 的真实天花板更高——是你的判断力本身。大多数时候 loop 失控，不是因为跑得太多，而是因为工程师根本没有把判断力充分编码进验证器，loop 在标准不清晰的系统里盲目跑下去。

四、悖论：Loop Engineering 在侵蚀它自己依赖的那个前提

现在问题变得有点难看了。

Loop Engineering 要求工程师有足够强的判断力——你得能定义「完成」，能设计出有效的验证器，能识别出 Loop Engineering 什么时候在往错误的方向收敛。这是 Loop Engineering 能用起来的前提。

但 Loop Engineering 的使用本身，正在让这个前提越来越难以维持。

判断力不是凭空存在的。它来自于亲手写代码时遇到的阻力、反复 review 之后建立的直觉、在系统里踩过的坑和做过的取舍。这些经验不是一次性下载的，是用进废退的——长期不用就会退化。《从前慢：两种慢，两种命运》 里说得更直接：判断力只能从真实的摩擦里长出来，不能被检索，不能被生成。

当 loop 开始替你做大部分代码决策，你 review 的是 loop 的输出，而不是自己的思考过程。你越来越少遇到「这个抽象对不对」「这里应不应该加一层」这类需要动脑的时刻。输出越来越快，判断的机会越来越少。

Ronacher 在文章里点出了一个更隐蔽的风险：工程师开始合并自己无法完全解释的代码。不是因为他们变懒了，而是因为loop 的速度让「停下来搞清楚」变成了一种代价高昂的选择。系统在运转，测试在通过，继续跑似乎比深究更合理。

这对刚入行的人尤其不友好。资深工程师至少还有积累下来的直觉兜底，知道什么时候该叫停、什么地方值得深究。新人没有这个储备——loop 替他们跳过了本该用来建立判断力的那些摩擦，而他们甚至不知道自己跳过了什么。

这是 Loop Engineering 真正的悖论：它依赖工程师的判断力，但它的运作方式在系统性地减少工程师动用判断力的机会。 用得越多，前提越弱；前提越弱，Loop Engineering 的天花板就越低。

这不是 Loop Engineering 本身的错。任何把人从执行层拉出来的工具都有这个风险——问题在于，当执行层的摩擦消失之后，人有没有主动为自己保留判断的空间。

五、两个天花板，都在人身上

上一篇 讲的是模型的天花板：LLM 的效用域被锁在符号空间，越深入现实域，不确定性越高而不是越低。这个天花板在认识论层面，暂时没有绕过去的办法。

Loop Engineering 是工程对这个天花板的回应——用结构和机制弥补模型的先天不足，让系统能在模型能力的上限之内尽量跑稳。这是有意义的工程，也确实有效。

但 Loop Engineering 有自己的天花板，而且这个天花板不在技术层面。

验证器能写多完善，取决于工程师对「好」的定义有多清晰。Loop 能收敛到什么位置，取决于工程师的判断力有多强。当系统越来越复杂、loop 跑得越来越多，还能识别出「这个方向错了」的能力，来自于工程师没有放弃亲手理解系统的那部分习惯。

模型的天花板在认识论，Loop Engineering 的天花板在工程师。两个天花板都在人身上，不在工具里。

这不是在说 Loop Engineering 没有价值，也不是在说你应该回去手写每一行代码。而是说：loop 能替你做的，是执行；loop 替不了的，是判断。工程师的核心价值不是生产代码的速度，而是知道系统应该往哪里走、以及什么时候该叫停。

这个判断力，是 loop 能跑多远的唯一锚点。