Ralph Loop：AI 编程的暴力美学

最近 AI 编程圈里彻底火出圈了一个新词——“Loops 编程”。它指的不是传统 for/while 循环，而是一种全新的开发范式：AI Agent Loop（智能体循环），其中最著名的代表叫做 “Ralph Loop（拉尔夫循环）”。

简单来说，这就是把一个 AI 程序员关进自动化小黑屋，不把代码写对、测试跑通，就不准它下班的暴力美学。

传统 AI 编程 vs. Loops 编程

两种方式的差异非常直观：

传统 AI 编程（单次生成）： 发一个 Prompt——“帮我写个网页”，AI 啪嗒一下生成一堆代码。复制下来一运行——报错。再复制报错信息去问 AI，它再改。这种”你拍一，我拍一”的挤牙膏方式效率极低。

Loops 编程（循环迭代）： 只需写一份 Spec（需求与测试规范说明书），然后把 AI 扔进一个自动化循环。AI 自己写代码 → 自动运行调试 → 发现报错 → 自己看报错信息修改代码 → 再次运行……直到所有测试全部通过，或者达到上限，才跳出循环。

爆火的”5 行代码”梗

这个玩法之所以最近爆火，源于极客圈里流行的一个叫 “Ralph Wiggum” 的技术。

有开发者突发奇想：“如果我用一段几行的死循环 Bash 脚本，把 AI 死死锁在一个环境里，给它足够的权限，会发生什么？”

名字灵感来源于《辛普森一家》里那个永远不懈、无比乐观（甚至有点傻气）的小男孩 Ralph。这个循环的逻辑极其粗暴：

初始化：读取人类写好的目标文件（PROMPT.md）。
执行命令：AI 疯狂改代码、跑编译、跑测试。
检查条件：外部脚本检查 AI 有没有输出”我彻底搞定了（COMPLETE）“的承诺标识。
无限循环：如果没有，对不起，触发 Stop Hook，强行把外在环境（新的报错、Git 日志）塞回给 AI，命令它”继续加班”，直到完全正确为止。

这种”默认你第一次写不对，但靠编译器报错来疯狂喂养 AI”的套路，直接捅破了自主编程的窗户纸。

本质：调试闭环的自动化

Ralph Loop 其实不是新发明，而是旧模式的新宿主。

它的逻辑和传统 CI/CD 的 retry on failure 很像，和强化学习的 reward loop 也很像。区别在于 feed 给 AI 的不是梯度信号，而是编译器报错 + 测试输出 + Git diff——这恰恰是 LLM 最擅长消化的信息格式。

过去是人看报错 → 人改代码 → 人再跑，现在这个反馈闭环被压缩进了 Agent 内部。

程序的角色在变

这种 Loops 编程正在改变程序员的工作定义：

从”写代码”变成”写通告”： 程序员的核心价值不再是抠具体的语法和逻辑，而是如何写出一份完美、严谨的 Spec（规范和验收测试）。
恐怖的填坑能力： AI 自己跟编译器和 Linter 死磕。以往需要人类花几个小时排查的拼写、配置、环境报错，AI 在 Loop 里转个几十圈，几分钟就自己对齐了。

写 Spec 给人类同事看，和写 Spec 给 AI Agent 看，是两种完全不同的文体。AI 更需要边界条件穷举和可验证的验收断言，而不是”做一个好看的页面”这种模糊描述。这正在催生一种新的写作范式——还没形成公认的名字，但可以叫它 “Spec Engineering”。

代价与刹车

当然，这种方式并不免费。

这种暴力循环是非常烧钱的。AI 在循环里每转一圈都在消耗大量 Token，如果遇到死逻辑（Overbaking），它可能会在里面转到信用卡透支。

Overbaking 的本质问题是：LLM 缺乏”我卡住了，需要换思路”的元认知。目前的 Stop Hook 只是治标的硬刹车，真正需要的是一种收敛性检测器——判断本轮修改相比上轮是否实质性改善了测试通过率，如果没有，触发策略切换而非继续修补。各种工具正在给这个 Loop 加上更聪明的安全刹车机制。

一扇新窗

Ralph Loop 的暴力与优雅并存。它用最笨的方法——死循环 + 编译器——撬开了自主编程的大门。接下来的问题不是”能不能用”，而是”如何更聪明地用”，以及”谁来写那个更聪明的刹车”。