2025年初，Andrej Karpathy 用"vibe coding"这个词给开发者画了一张饼：你动嘴，AI动手。但半年过去，大多数人发现这张饼硌牙——AI确实能写代码，但让它独立完成一个功能？它会在第17步忘记第3步要干嘛。
Ralph Loop 就是冲着这个痛点来的。它不是新模型，也不是新IDE，而是一套"套索"机制：把AI代理从"对话模式"强行拽进"任务模式"。
从" vibe "到" loop "：为什么你的AI代理总在最后一步翻车
vibe coding 的核心假设是：人类负责意图，AI负责实现。但实践中，AI代理的上下文窗口像漏勺——代码写到200行，它开始重复造轮子；测试失败3次，它陷入死循环改同一个bug。
Karpathy 自己提过这个困境：AI能生成代码片段，但缺乏"工程纪律"。Ralph Loop 的解法很粗暴：把一个大任务切成固定长度的循环，每轮循环必须产出可验证的工件。
具体怎么切？想象你让AI做一个登录功能。传统流程是：写代码→写测试→跑测试→改bug→再跑……直到崩溃。Ralph Loop 强制规定：每轮最多生成50行代码，必须附带单元测试，测试通过才能进下一轮。没过？回滚，重来。
3个设计细节，把"概率生成"变成"确定性交付"
第一，状态冻结。每轮循环结束时，当前代码库状态被锁定为"检查点"。AI代理不能随意覆盖，必须显式申请修改权限。这防止了那种"越修越烂"的螺旋下坠。
第二，测试即契约。不是跑完测试就完事，而是把测试用例提前写给AI看。代理在写代码之前，先复述一遍"我要满足这些条件"。这招降低了幻觉率——它至少知道自己该证明什么。
第三，人工闸门。Ralph Loop 不追求全自动。关键检查点必须等人点确认，但人可以批量预审：把接下来5轮的测试用例一次性看完，没问题就放行。这种"半自动"反而比全自动更快，因为减少了返工。
谁在用，以及为什么现在才火
这套机制最早出现在2024年底的实验性项目里，但真正跑通是在2025年Q1——刚好赶上 vibe coding 的概念爆发。目前采用者主要是中小团队的"一人全栈"场景：产品经理兼工程师，晚上丢需求给AI，早上收PR。
有个细节很有意思：Ralph Loop 对提示词工程的要求反而更低了。因为循环结构本身在约束行为，你不需要写"请记得检查边界条件"这种废话。框架替你做了纪律。
当然，它也有硬边界。涉及多服务架构、需要人工审核的合规代码、或者强依赖领域知识的业务逻辑——这些场景下，Ralph Loop 的循环会频繁触发人工闸门，效率优势被稀释。
但如果你经常让AI写那种"独立模块、测试明确、边界清晰"的功能，这套机制能把成功率从"碰运气"拉到"可预期"。
现在的问题是：当AI代理的上下文窗口从128K飙到1M，甚至能记住整个代码库的历史，Ralph Loop 这种"强制分段"的设计会不会变成累赘？还是说，工程纪律永远比内存容量更重要？
热门跟贴