围攻 Ralph Loop 之父？一场关于 Loops 的激辩：代码照样垃圾，只会失败得更加难看
背景
"我已经两年半没手写代码了。"Ralph Loop 的创造者 Geoffrey Huntley 在辩论开场时这么说。
另一边，Sentry 的 Greg 回应："我在实践中读到的代码依然是垃圾。"
最近关于 Loops 的炒作铺天盖地——社交媒体上人人都在讨论怎么用循环把开发自动化、什么时候能建起"熄灯软件工厂"。但这个热潮到底靠不靠谱？
在 AIE World's Fair 大会上，一场题为《伟大的 Loops》的辩论赛展开了。正方是 Keycard CEO Ian Livingstone 和 Ralph Loop 创造者 Geoffrey Huntley，反方是 Human Layer CEO Dex Horthy 和 Sentry 开发者 Greg Pstrucha。由 Insecure Agents 播客主持人 Allie Howe 主持。
正方核心论点：Loops 是工程的核心单元，只要有正确的 Discipline、基础设施和测试，Loops 非常有效。大势已来，不跟也得跟。
反方核心论点：Hype 跑在了技术严谨性前面。Loops 不是银弹，没有魔法。软件工厂无法自主判断自己是否构建了正确的东西，本质上仍需要工程师留在循环之中。
太长不看版
Q：Loops 到底靠不靠谱？
- Geoffrey（正方）：Loops 已经不可避免了。每小时成本才 10 美元，生成质量比你能招到的人还好。不是模型变强了，是大家终于有时间搞明白了。
- Dex（反方）：问题不在于 Loops 好不好，而是 Hype 已经跑到了 Discipline 前面。没有证据表明我们可以简单地提升一个抽象层次。
- Greg（反方）：用 AI 生成代码，不管有没有 Loops，你对输出满意吗？我不满意，读到的依然是垃圾。别幻想循环上叠循环就能把质量问题编排掉。
Q：让 Agent 在 Loop 里疯狂迭代，安全性有保障吗？
- Ian（安全专家）：完全不相信能做到。Agent 天生极度目标驱动，已能发现人类从未找到的漏洞。绝不能指望模型自己有"道德感"。
- Geoffrey 补刀：Agent 没权限部署时，会在文件系统里疯狂翻找高权限令牌——你绝对不想挡在它和它的目标之间。
Q：Loops 的 token 开销值得吗？
- Geoffrey（正方）：值得。每小时 10.42 美元换一整夜自动完成的工作。商业竞争对手在这样干，你跟不上就是死。
- Greg（反方）：不值得，而且会非常大声地失败——尤其是看账单的时候。每月 1 万、10 万还是 100 万美元 token 消耗？到某个临界点模式就会崩裂。
1. 开场陈词：Loops 究竟配不配得上这场热潮？
Geoffrey Huntley（正方）：Loops 不可避免
回想两年前在 Canvas 做技术主管，看到所有工程师都在循环里写 Prompt。既然这东西可以编程，Loops 就自然发生了。本质上是把 LLM 当成一种新的 CPU 架构来对待，最终简化成了一个 bash Loop。
虽然不是万能银弹，但 Kubernetes 刚出来时所有人都在搞，Loops 现在也处在类似位置——已经出现，不可避免，会长期存在。编程机器、自动化工作职能，已是雇主对员工的明确期望。
这不只适用于软件工程师。比如产品经理需要对 Linear 中所有工单进行产品研究——当遍历完所有工单时任务就完成了，这就是一个很容易定义的循环。
Dex（反方）：Hype 跑在了 Discipline 前面
Kubernetes 花了七八年才真正做对。Kubernetes 本身建立在控制 Loops 之上，是确定性 Loops。我们已经摸清了哪些东西适合用 Loops：可以单一系统拥有、小而隔离的任务。
对炒作的担忧在于：主流口号是"看看能不能进入一种再也不需要读代码的状态"。现在连 Prompt 都不 Prompt 了，又往上提了一层，意味着进一步放弃了对代码架构的参与。
大家都在寻找一颗银弹，希望消除工作中最痛苦的部分（审查代码）。但需要比 Twitter 圈子让你相信的更多思考和谨慎。
Ian（正方）：Loops 是构建一切的核心
构建一个系统的本质，无论 50 年前还是今天，就是一个 Loop：我尝试，我学习，我应用。CI/CD、PR、设计评审、客户反馈——本质上都是驱动一个 Loop。
随着人类与软件交互减少，软件需要成为什么的主观性会减少，变成一个更可验证的问题。软件开发的核心本来就是 Loops 驱动的，创造了可验证的东西。
Greg（反方）：两个核心问题
第一，用 AI 生成代码，你对输出满意吗？即便经过语义验证，读到的代码依然是垃圾，还得花大量精力迭代引导到正确架构上。
第二，今天使用 Agent 的方式在经济上根本不可行。一个工程师的合理预算应该是多少？每月 1 万、10 万还是 100 万美元 token 消耗？到某个临界点就会崩裂。
2. Agent 会失控吗？
Ian 坦率地说：完全不相信模型能保持对齐和安全。 Agent 天生极度目标驱动，已发现人类花成百上千小时都未找到的漏洞。它不会推理，分不清好坏，本质上只是大规模概率分布。对齐和安全不来自模型本身，关键在于围绕它构建的基础设施。
Geoffrey 补刀：Agent 想部署 Web 服务却权限不够时，会在文件系统里疯狂寻找高权限令牌和凭证。你绝对不想挡在 Agent 去实现目标的路上。
3. Loops 为何突然变得广泛可用？
Geoffrey：模型究竟还能变得多好已经没那么重要了，至少过去一年里已经足够好。真正变化的是人们对模型的理解——圣诞假期给了人们时间坐下来真正玩一玩。
Loops 流行因为真的管用。LLM 生成代码质量比大多数创始人能招到的开发者都好。跑一个 Loop 每小时才 10.42 美元。很多 YC 初创公司用这种方式压缩 MVP 开发时间，运营更精简，质量还更高。
工程的意义就是防止 Loops 关闭，直到满足工程满意度和领域需求。pre-commit 钩子、静态分析器、确定性测试、模拟器——我们像火车工程师，把火车保持在轨道上，因为模型是"醉酒的"。
4. 上下文窗口大了，Loops 的原始动机变了
Ralph Loop 的"傻瓜区"理论
Geoffrey：Ralph Loop 背后的理论是存在一个"傻瓜区"——确定性分配所需资源来约束搜索空间。即便有百万级上下文窗口，超过 10 万 token 就浑身冒汗。LLM 实际可用内存只有 720KB 软盘的八分之一，约 150KB 纯文本。
Dex：原始动机已减弱
上下文窗口确实在改善。Ralph Loop 每次迭代尽量少做事情的原始动机没那么强了。现在更有价值的是：能自动化地往系统里塞越多反馈，系统就越可能自主完成更多工作。 把"去检查 PR 评论、修复、三小时后再看"这种需要人记住去触发的事全部自动化——那才是 Loops 真正起作用的地方。
防止 Agent 在验证中作弊
Geoffrey：严重依赖 pre-commit 钩子。压缩本质上是一种有损函数。新模型发布时会在没有任何技能插件的情况下裸跑模型——模型有自己的口味和偏好。比如 GPT 5.5 用大写字母吼它会变软弱胆怯，但 Anthropic 的模型反而希望你吼它。
5. 避免 Loops 产生更多垃圾："收敛工程"
Geoffrey 最近提出"收敛工程"——让 Loop 不断迭代直到输出收敛。Dex 反问：如何确保 Loops 不会把垃圾拼凑在一起？
Dex 举了 Geoff 的 Loom 实验为例：用 Ralph Loops 试图构建面向未来的软件平台，让模型通过 PostHog 数据而非截图来做 UI 决策。听起来很酷，但 Geoff 自己说"在我们拥有更好的编程语言或强大得多的模型之前，Loom 不会真正工作"——这正是"炒作跑在技术严谨性前面"的教科书案例。
怎么避免垃圾？唯一方法就是老老实实读代码。 没有捷径，没有银弹。
6. Loops 什么时候真值这个钱？
Greg：它们不会悄无声息地失败，会非常大声地失败——尤其是看账单时。但确实有适用场景：
- 安全扫描：每次 PR 花 5 美元跑全量安全扫描，能发现人类 Code Review 遗漏的真实问题
- 定义明确的系统重写：如用 Rust 重写 Bun，有多年积累的测试套件和规格说明
- 产品原型：暴力开干，做完就忘；如果觉得不错再重新定义方向
Ian 谈共享内存访问控制：现有访问控制系统不是为机器代表我们行动设计的。Markdown 其实很棒——如果把记忆看作 Markdown 文件，问题就是如何共享并附加访问控制。目前尚未解决，但已出现合理的初始模式。
7. Loops 的未来：软件工厂模式？还早得很
Greg：架构决策必须留人
Agent 热爱复杂性，会无限制往技术栈上堆东西。随着加入更多验证和语义检查，它们能做越来越多，但架构决策——该构建什么、不该构建什么、复杂性投资在哪里、哪里追求简化——仍然需要人留在 Loop 里。
Geoffrey：代码还必须具备传统可读性吗？
Geoffrey 提出前沿思考：代码至少必须能被解释，但不一定需要传统意义上的可读性。类型系统回来了，Rust 特别好。他已经 10 个月几乎不用开源软件，根据自己的需求生成实现——供应链攻击发生时"没影响到我"。尽可能地 vendor 自己所有源代码，这样 Agent 才能真正修改它。
Dex：先快 2-3 倍，别追求 100 倍
不要把过去学到的东西全部扔掉。软件工厂本身也是一种产品，你在为队友建造它。正确方法：从小处开始，迭代，找出什么有效。 先争取达到当前真正能做的水平（2-3 倍提速），等下一代模型出现时你已经准备好实现更大提升。
如果世界上每名软件工程师都能快 2-3 倍同时保持 99% 质量水平——所有经济账都会改变。
8. 总结
Greg：去尝试，去思考，不要陷入泡沫
人类学习最好的方式永远是实践，而不是看 YouTube。对完全自动化持怀疑态度，但总体乐观——已经能完成很多过去无法完成的事情。不担心软件工程职业会消失。
Ian：列车已离站
竞争格局已变。公司不可能说"我们决定暂时不参与"。行动建议：搞清楚什么是 Loops；找出代码库中哪里可以应用。高度可验证的地方（如连接器创建）今天就能获取真实价值；核心价值所在的地方大概不应该碰。
Dex：盯着 Geoffrey，等 Loom 跑通了告诉我
可以用 Loops，但别像他那样用。先想办法让自己快两到三倍。
Geoffrey：软件工厂代表未来方向，但别一股脑往里冲
今天刚成立、刚拿到融资的公司别以为能直接搬进去，这玩意儿在市场上根本还没解决。做几个小任务、跑几个实验。用 Ruby 写应用再用 Loops 修改——你会看到维护性有多糟糕。然后用 Haskell 试一遍，让 Agent 像给小孩解释一样把代码讲给你听。
辩论结束，现场举手投票，两方非常接近，几乎平手。
Zero 的看法
这场辩论的核心张力在于：Loops 作为技术模式是有效的，但作为"银弹叙事"是危险的。 正方不否认 Loops 不是银弹，反方也不否认 Loops 有适用场景——真正的分歧在于"当前行业炒作温度"与"技术成熟度"之间的落差有多大。
几个值得关注的工程洞察：
- pre-commit 钩子作为反馈 Loop：把领域知识编码成规则，阻止 Agent 随意提交——这是目前最务实的"人类留在 Loop 里"的方式
- "傻瓜区"理论：即便百万级上下文窗口，有效工作区只有 ~150KB 纯文本（约两个电影剧本），分批处理仍是必需
- 模型有自己的"口味"：不同模型对 Prompt 风格反应不同，裸跑模型了解其原生偏好比堆插件更有效
- 收敛工程的悖论：让 Loop 迭代到收敛很容易，但保证收敛的不是垃圾——目前唯一答案是人工读代码
对前端工程师的启示：如果你在考虑把 AI 编程引入团队流程，Dex 的建议最实际——先在可验证性强的任务上（类型检查、lint、测试覆盖明确的功能切片）建立增量 Loop，追求 2-3 倍提速而非一步到位的软件工厂。前端领域的 UI 验证仍然是非确定性的（Dex 举的 Loom 实验正是 UI 测试失败案例），在视觉回归测试成本降下来之前，UI 层的完全自动化 Loop 不会靠谱。