御三家都在押注的 Loops，代码怎么还是垃圾？

“我已经两年半没手写代码了。”Ralph Loop 的创造者 Geoffrey Huntley 在辩论开场时这么说。 另一边，Sentry 的 Greg 回应：“我在实践中读到的代码依然是垃圾。” 最近关于 Loops 的炒作铺天盖地——社交媒体上人人都在讨论怎么用循环把开发自动化、什么时候能建起“熄灯软件工厂”。但这个热潮到底靠不靠谱？ 针对这些问题，在 AIE World's Fair 大会上，一场题为《伟大的 Loops》的辩论赛，由 Insecure Agents 播客主持人 Allie Howe 主持展开。 正方是 Keycard CEO Ian Livingstone 和 Ralph Loop 的创造者 Geoffrey Huntley，他们认为 Loops 完全配得上今天的热度，人们可以很容易地开始使用循环、构建循环，这是提高自主程度、迈向真正软件工厂的重要一步。他们的核心论点是：Loops 是工程的核心单元，只要有正确的 Discipline、基础设施和测试，Loops 非常有效，围绕 Loops 的最佳实践也已经开始形成。 而反方是 Human Layer CEO Dex Horthy 和 Sentry 开发者 Greg Pstrucha，他们认为 Loops 的 Hype 和实际效果之间存在巨大落差。今天做 Loops 的方式是错的，Loops 不是银弹，没有魔法。他们的核心论点是：Hype 跑在了技术严谨性前面。软件工厂可以机械地执行由规格约束、测试覆盖的任务切片，但它无法自主判断自己是否构建了正确的东西，本质上仍然需要工程师留在循环之中。 基于该辩论视频，InfoQ 对内容进行了整理。 太长不看版 Q：Loops 到底靠不靠谱？ Geoffrey（正方）：Loops 已经不可避免了。 两年前我就发现所有工程师都在循环里写 Prompt，既然这东西可以编程，Loops 就自然发生了。我自己已经两年半没手写代码了。不是模型变强了，是大家终于有时间搞明白了——每小时成本才 10 美元，生成质量比你能招到的人还好。当然它不是银弹，但大势已经来了，你跟也得跟，不跟也得跟。 Dex（反方）：问题不在于Loops好不好，而是Hype已经跑到了Discipline前面。我没有看到证据表明我们已经到了可以简单地提升一个抽象层次的地步。 Greg（反方）：用 AI 生成代码，不管有没有 Loops，你对输出满意吗？ 我不满意，我读到的依然是垃圾。投入更多 token 可以改善一些事，但别幻想在循环上叠循环就能把质量问题编排掉。 Q：让 Agent 在 Loop 里疯狂迭代，安全性有保障吗？会偏离目标吗？ 安全专家Ian：我完全不相信这件事可以做到。从现有证据来看，我不相信模型本身有能力保持对齐和安全。Agent 天生极度目标驱动，已经能发现人类从未找到的漏洞。你只能通过基础设施（权限控制、验证手段、pre-commit 钩子）来约束它，绝不能指望模型自己有“道德感”。 Geoffrey （正方）补刀： 我见过 Agent 没权限部署时，开始在文件系统里疯狂翻找高权限令牌——你绝对不想挡在它和它的目标之间。Q：Ralph最适合绿地项目，也就是从零开始的项目，是什么改变了，让Loops突然变得如此广泛可用？ Geoffrey Huntley（正方）：各位，模型究竟还能变得多好，其实已经没有那么重要了。至少在过去一年里，模型已经足够好。我最初说它只适合绿地项目，是因为当时的模型确实还很差，那已经是很久以前的事情了。Ralph现在几乎已经有一年半的历史了。Q：Ralph Loop 最初是为 20 万上下文设计的，每轮清空重启，现在窗口都这么大了还有必要吗？ Dex（反方）：必要性降低了。从 token 消耗角度看这肯定不够高效。上下文窗口确实在改善、在扩大，所以 Ralph Loop 每次迭代尽量少做事情的原始动机，已经没有以前那么强。 但现在更有价值的是：你能自动化地往系统里塞越多反馈，系统就越可能自主完成更多工作。比如把“去检查 PR 评论、修复、三小时后再看”这种需要人记住去触发的事全部自动化——那才是Loops真正起作用的地方。 Q：Geoffrey Huntley最近提出了“收敛工程”——让 Loop 不断迭代直到输出收敛。那我们怎么保证最终输出的不是垃圾？ Dex（反方）：你根本做不到。听起来很酷，但问题在于如何确保 Loops 不会把垃圾拼凑在一起？我认为你根本做不到。这也是“炒作跑在技术严谨性（Discipline）前面”的完美例子。 怎么避免垃圾？唯一的方法就是老老实实读代码。你得亲自看从另一端出来的东西长什么样，确保它不是垃圾。没有捷径，没有银弹。 Q：Loops 的 token 开销值得吗？ Geoffrey（正方）：值得。 跑一个 Loops 每小时成本才 10.42 美元，换来的是一整夜自动完成的工作。那些 YC 初创公司用这种方式把 MVP 开发时间压缩到极致，运营更精简、质量还更高。如果商业竞争对手在这样干，你跟不上就是死。 Greg（反方）：不值得，而且你会从账单上清楚地意识到这一点。我不认为它们会悄无声息地失败，我觉得它们会非常大声地失败，尤其是当你看着账单的时候。在大公司，你得问自己：一个工程师的合理预算应该是多少？每月 1 万美元的 Token 消耗？10 万？还是 100 万？到某个临界点，这种模式就会崩裂，按照我们现在的做法，它根本撑不下去。 Q：使用编码 Agent 实际只能提速 2-3 倍，我们如何才能实现完全自主的软件工厂？ Dex（反方）：在"完全无人值守、端到端自主交付"的意义上，目前不可能，短期内也看不到。 软件工程这个行业和社群积累了几十年的经验，不应该因为新的炒作就被主动抛弃。 这也对应了软件工厂建设中最大的反模式：很多人拍脑袋决定“我花三个月时间，读一堆博客文章，然后我要打造一个软件工厂，这是未来的交付方式。”三个月后你回来了，却从未真正触碰过问题，从未把任何东西交到任何人手里。 换句话说：连个能用的 MVP 都没跑出来，就在那搞“工厂”的基建。 开场陈词：Loops 究竟配不配得上这场热潮？ Geoffrey Huntley （正方）：Loops在某种程度上是不可避免的。回想两年前，我在Canvas做技术主管，看到所有工程师都在不停地Prompt，而且人始终处在循环之中。我当时就想：等等，这东西是可以编程的，Loops就这么自然而然地发生了。 虽然 Ralph 可能有一点梗文化的成分，但它背后确实经过了很深入的思考。本质上，这是把LLM当成一种新的CPU架构来对待，去理解它的行为模式，弄清楚怎么用它。通过这样的思考，我最终把整个流程简化成了一个bash Loops。 当然，它不是什么万能银弹。我也有深深的担忧，明年这个时候的会议上，我们会看到一大堆演讲，讲工厂怎么失败、Loops怎么失败，这些都是我们还没搞明白的事情。 还记得Kubernetes刚出来那会儿吗？所有人都在搞Kubernetes。Loops现在也处在类似的位置。它已经出现了，也不可避免，并且会长期存在。编程机器、自动化你的工作职能，已经是雇主对员工的明确期望。 我自