Loop Engineering的边界与悖论分析

TL;DR

Loop Engineering 的真正上限并非 token 数量，而是工程师自身的判断力。然而，Loop Engineering 的运作本身，正在逐渐侵蚀这种判断力。

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

Flask 作者 Armin Ronacher——同时也是 Loop Engineering 的早期倡导者——总结了几种他认为真正有效的应用场景：代码移植、性能调优、安全审计以及研究探索。

这些场景初看似乎毫无关联，但深入分析后会发现，它们拥有一个共同特点：产生的成果无需长期维护，或者能够通过机械化方式验证。

代码移植是典型的等价转换——将 Zig 代码迁移到 Rust，行为保持一致，依赖现有的测试套件作为评判标准，通过即正确，不通过即错误。性能探索只需运行基准测试，数字结果一目了然。安全扫描本质上是模式匹配，命中即成功。研究探索的产出物——如发现报告、概念验证（PoC）、演示原型——通常是一次性的，评估后认为有价值即可。内部工具、脚本以及自动化辅助类产物也属于这一范畴——它们不运行在生产关键路径上，容错空间较大，失败的代价相对有限。

这些场景的验证器都具有一个共同特征：输出二元信号——非黑即白，不存在灰色地带，能够被机械化检测，无需依赖人为主观判断。Loop 只需要一个明确的信号来驱动下一次迭代，信号越清晰，循环就越能稳定收敛。

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

陈旧代码库常被称为“屎山”。

开发者在这样的代码库上工作，通常是一锹一锹地添加修改——每次改动的范围有限，清楚自己在哪里操作，也知道哪些区域不能随意触碰，因此反而更加谨慎。但 AI 在屎山上执行 loop，情况则完全不同。

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

单次执行时，这些倾向尚且可控。一位有经验的工程师通过代码审查能够发现其中的问题。

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

问题不在于 loop 运行了多少轮，而在于每一轮的偏差都在朝相同的方向累积。这与屎山的形成机制如出一辙——并非某一次改动造成了重大错误，而是无数局部决策叠加之后，整体结构变得无人能清晰描述。

区别仅在于速度：人在屎山上一锹一锹挖掘，而 AI 在屎山上一轮一轮加速。

三、真正的边界在哪里

说到这里，一个直觉上的解决思路是：选择合适的任务类型，避开容易失控的场景。

但这个思路是错误的。Loop 能否使用，并不取决于任务类型，而在于能否为其建立有效的验证器。

代码移植之所以适合 loop，并非因为它是“移植类任务”，而是因为它天然具备一个强验证器——测试套件全部通过即为正确，不通过则为错误，二元信号十分清晰。如果你要移植的代码没有测试，loop 同样会失控。安全扫描之所以适用，不是因为它是“扫描类任务”，而是因为漏洞模式可以被显式定义。

反过来，为什么在生产代码库上运行 loop 容易出问题？因为你无法编写一个能够检测“架构是否合理”“抽象是否恰当”“日后代码是否可读”的验证器。这些判断没有二元信号，无法机械化，只能依靠人工完成。

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

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

因此，验证器的上限，就是你的判断力中“可量化部分”的上限。而 loop 的真正上限更高——那就是你的判断力本身。大多数时候 loop 失控，并非因为运行次数太多，而是因为工程师没有将判断力充分编码进验证器，导致 loop 在标准不清晰的系统中盲目运行。

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

现在问题变得有些棘手了。

Loop Engineering 要求工程师具备足够强的判断力——你需要能够定义“完成”，能够设计出有效的验证器，能够识别 Loop Engineering 何时在向错误方向收敛。这是 Loop Engineering 得以使用的前提。

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

判断力并非凭空产生。它来自亲手编写代码时遇到的阻力、反复代码审查后建立的直觉、在系统中踩过的坑以及做出的权衡取舍。这些经验不是一次性下载的，而是用进废退的——长期不用就会退化。有文章说得更直接：判断力只能从真实的摩擦中生长出来，无法被检索，也无法被生成。

当 loop 开始替你完成大部分代码决策，你审查的是 loop 的输出，而非自己的思考过程。你越来越少遇到“这个抽象是否正确”“这里是否应该增加一层”这类需要动脑的时刻。输出越来越快，判断的机会越来越少。

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

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

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

这不是 Loop Engineering 本身的错误。任何将人从执行层抽离出来的工具都存在这种风险——问题在于，当执行层的摩擦消失之后，人是否主动为自己保留了判断的空间。

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

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

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

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

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

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

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

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

参考资料

[1] Armin Ronacher: https://lucumr.pocoo.org/2026/6/23/the-coming-loop/

[2] 他几乎没看到这方面的改进迹象: https://lucumr.pocoo.org/2026/6/23/the-coming-loop/

[3] 《从前慢：两种慢，两种命运》: https://atbug.com/from-slow-two-kinds-of-slow-two-fates/