其实这东西简单得很——一旦你明白它为什么有效，你能做的远不止运行别人的现成配置。
这里我会拆解：
- Ralph到底是什么
- 那个让它变聪明的"上下文窗口"技巧
- 我自己工作中用Ralph循环的三种方式
看完你会脑子里有个清晰的画面，真正部署起来，不会被那些炒作和混乱信息带偏。
为啥我们要关心Ralph？
Ralph是一种"用算力换脑力"的方法。
你把每个大语言模型（LLM）想象成一个"智力单元"，然后你会发现：只要花得起钱，你能召唤多少个都行。这时候唯一的瓶颈就是你自己——你的注意力和时间。
你越能把自己从这个循环里摘出来，你能获得的"杠杆"就越大。但代价是，你的前期设置和规划变得超级重要。
最起码，你可以在用量重置的前一天晚上，把Ralph当成探索工具来用——反正那些没用完的token（算力额度）也要过期了，不用白不用，完全没有损失。
最棒的情况是，你能设计出一套工作流程，让自主AI代理在你的具体场景里发挥极致的杠杆效应。
不管怎样，我强烈建议你去了解、尝试自主AI代理，绝对不会后悔。
【好，我知道它牛了，但它到底是啥？】
Ralph Wiggum循环就是一个简单的bash（命令行）循环，给AI代理一个任务列表，让它一直做到满足停止条件为止。
每次循环里，我们告诉AI：
1. 仔细阅读规格说明书（specs）和执行计划
2. 给它任何跟代码库相关的信息
3. 让它挑一个"性价比最高"的任务来做
4. 然后写一个不偏不倚的单元测试
5. 如果测试通过了，就标记这个任务完成
这样一直循环，直到整个项目完成——不管你在不在旁边盯着。
具体怎么实现？
实际上就是一段bash脚本，大概长这样（用大白话说）：
> 在满足停止条件之前，把提示词传给Claude（用headless模式，就是那个-p参数），然后一直循环直到完成。
但别被它的简单骗了——要让Ralph跑起来，前期的规划和写规格书的工作强度是很大的。你得变成一个高级架构师。你前期投入越多，Ralph回报你的就越多。
【核心秘诀：上下文窗口的巧妙处理】
Ralph循环最牛的地方在于：它把"上下文窗口"当成一个静态分配问题来处理。所以传统的那种"上下文裁剪"方法根本用不着。
顺便说一句：千万别用Anthropic官方的那个Ralph Wiggum插件！ 它是在同一个会话里跑循环的，会导致严重的"上下文腐烂"和压缩问题。
让我解释一下基本原理：
想象模型的上下文窗口是一个固定大小的空间，你得精打细算怎么分配才能解决问题。Ralph循环的做法是：
- 先 upfront（提前）创建好规格书和执行计划
- 然后让模型每次只选一个最高优先级的任务
- 再创建一个单元测试
这样，Ralph在实现任务和写测试的时候只用一点点上下文，希望能快速完成，始终待在"傻区"（dumb zone）下面。
【什么是"傻区"？】
这是让Ralph循环跑起来的核心技能之一。对于Opus 4.5模型来说，"傻区"大约是用了10万token上下文的时候——超过这个点，性能就开始断崖式下跌。
与此同时，如果你用"氛围编程"（vibe coding，就是那种随性编码）的方式，实现过程可能会把上下文塞满。这是因为你没有给Claude一个清晰的画面，告诉它你想要什么、怎么做。注意，大部分"氛围编程"的实现都是在"傻区"里完成的——这意味着这么做的人在白白浪费性能。
在没有拉尔夫循环之前，很多开发者喜欢所谓的“氛围编码”（vibe coding），也就是一边跟模型聊天一边写代码，想到哪写到哪。这种方法听起来很自由，但问题在于，模型的上下文窗口是有限的。
以 Claude Opus 4.5 为例，一旦上下文使用超过大约 10万 tokens，模型的表现就会急剧下降，这个区域被称作“笨蛋区”（dumb zone）。
在笨蛋区里，模型不仅反应迟钝，还容易胡说八道，写出的代码漏洞百出。
更糟糕的是，为了腾出空间继续聊天，系统会自动对旧上下文进行压缩摘要，而这些摘要往往包含错误或矛盾的信息，就像传话游戏最后一棒听到的已经面目全非。于是越写越错，越错越写，最后整个项目变成一团浆糊。
拉尔夫循环之所以聪明，就是因为它压根不让模型进入笨蛋区——每次循环都从干净的上下文开始，只读取外部的规格说明书和实现计划，相当于每次开工前都重新看一遍施工图纸，而不是靠记忆瞎干。
【接下来发生什么？核心技巧来了！】
"氛围编程"这边：随着你继续实现，上下文满了，发生了压缩（compaction）——系统会把之前的实现总结成几行token塞进新上下文。这些总结出来的内容会开始"毒害"模型，因为过度压缩会产生不相关甚至矛盾的信息，性能进一步下降。这就是为什么"氛围编程"写出来的代码全是bug，我强烈建议你别这么干，除非只是为了好玩。
Ralph循环这边：它不往同一个窗口里塞更多功能，而是选择更新规格书，把子任务标记为完成。
基本上，它是把 执行计划和规格书 当成"真相来源"，而不是像普通AI编程那样把"之前的上下文"当真相。
随着你继续实现更多计划，Ralph循环始终保持在"傻区"以下，永远不需要压缩——因为只要规格书和执行计划写得够好，模型随时能靠它们快速跟上进度。
拉尔夫循环的核心机制：用外部文档代替内部记忆
拉尔夫循环的真正魔法在于它把“记忆”从模型内部搬到了外部文件里。
具体来说，整个流程分为三步：
第一，提前写好 spec.md（规格说明书）和 implementation plan.mmd（实现计划）；
第二，在每次循环中，模型先完整读取这两个文件；
第三，从中挑一个还没完成的高优先级任务，写代码、写单元测试，测试通过就打钩标记完成。
整个过程反复执行，直到所有任务都被打钩。
关键点在于，每次循环都是独立的，上下文不会累积，因此永远不会触发上下文压缩。
模型不需要记住上一轮做了什么，只需要看一眼实现计划就知道现在该干什么。这种设计把上下文窗口变成了一个“静态分配问题”——只要规格和计划足够简洁，模型就能始终在高性能区间工作。
【怎么写规格书和执行计划？】
要让拉尔夫循环跑得稳，前期规划必须滴水不漏。这里有个绝招叫“双向提问”（bidirectional prompting）：不是单方面告诉模型要做什么，而是让模型反过来问问题，直到双方对需求的理解完全一致。
我们为什么要问Claude问题？因为它能暴露出它做的隐性假设——这些假设对我们来说可能显而易见，但Claude不一定这么想。这些假设通常是很多bug的根源，而且会随着代码库变大变得超级阴险。
比如，人类可能觉得“用户登录”理所当然包括邮箱验证，但模型可能默认只支持手机号。如果不提前澄清，后期就会埋雷。
通过来回问答，可以暴露出那些“看似 obvious 实则致命”的隐含假设。
最终产出的规格说明书应该像法律条文一样精确，实现计划则要用带复选框的清单形式列出每个子任务，例如：“□ 实现 JWT 令牌生成 □ 编写密码强度校验函数 □ 添加双因素认证接口”。每完成一项，模型就在清单上打钩，下一循环自然跳过。
既然我们运行Ralph循环的时候大部分时间都不在旁边盯着，把这一步做对就能确保代码有一个清晰的轨迹，最终产出高质量的代码。
规划阶段结束后，Claude会写好规格书（spec.md）和执行计划（implementation-plan.md）。执行计划要用 bullet points（项目符号），每个点对应一个任务，旁边放个复选框。这样Ralph每次循环都能轻松勾选完成的内容。
【关键步骤：你必须逐行阅读这两个文档，每一行都要签字确认！】
如果你不这么做，你就不会理解计划是什么，实现结果很可能跟你想的不一样。如果计划不够严密，错误会层层叠加、被放大——因为Ralph循环是自动跑的，每次迭代都依赖前一次的结果。
所以，Ralph循环里最重要的技能，毫无疑问是 设计一个好计划的架构能力。
【prompt.md长什么样？】
实际运行拉尔夫循环的脚本可能比想象中简陋得多。核心逻辑就是一个 while 循环，不断调用 Claude 的命令行接口（headless mode），传入固定的提示词模板。
记住，这是我们每次循环都要给模型的提示词，非常重要。
提示词内容大致如下：先让模型仔细研读 spec.md，再仔细研读 implementation plan.mmd，然后选择一个未完成的最高杠杆任务，实现它，并编写一个无偏见的单元测试来验证功能。如果测试通过，就更新实现计划，把对应任务标记为完成。
文件里要告诉Claude：
1. 仔细阅读spec.md
2. 仔细阅读implementation-plan.md
3. 挑一个性价比最高的未完成任务
4. 完成它
5. 写一个不偏不倚的单元测试验证
你还要包含代码库结构、约定等信息，因为记住：Ralph每次循环都是全新的上下文窗口，你得想办法高效地让它跟上进度。
拉尔夫循环的 Bash 脚本长什么样？简单到令人发指
整个过程用 Bash 写出来可能就十几行：
while [ stopping_criteria_not_met ]; do claude -p "请研读 spec.md 和 implementation plan.mmd，选择一个未完成的高优先级任务，实现它并编写单元测试。如果测试通过，请更新 implementation plan.mmd 打钩。" done |
别看代码短，背后的设计哲学却很深：每次调用都是全新会话，上下文零残留；所有状态信息都存储在外部文件中；任务推进完全依赖显式文档而非隐式记忆。这种极简主义反而成了最强防护——没有花哨的插件，就没有隐藏的上下文污染。
【启动bash循环后】
一开始你要全神贯注地盯着。如果Ralph跑偏了，关键是：停下来，修改规格书，然后重启循环。这能让你了解模型的行为，也能让你的规格书更严密，为之后真正让它自动跑做准备。
一旦Ralph看起来在正轨上，你就可以离开让它自己实现，或者你想盯多久盯多久。但Ralph的重点就是获得那个"自动循环"的杠杆效应。
之后你可以回来，跑各种测试（端到端测试），让子代理帮你建测试，快速浏览代码，决定要不要改规格书重启。
【生产环境警告】
如果你是在软件工程师的生产环境里用自主编程AI，得超级小心。我的建议可能是：干脆别这么干。但如果非得干，你得彻底测试，逐行读代码。
为什么官方插件反而坑人？因为它把循环塞进同一个会话
有意思的是，Anthropic 官方推出的 Ralph Wigum 插件其实违背了拉尔夫循环的初衷。它把整个循环运行在同一个模型会话里，导致上下文不断增长，最终必然进入笨蛋区。这就像让一个人连续加班72小时不睡觉，还指望他保持清醒——理论上可行，实际上崩溃只是时间问题。
真正的拉尔夫循环必须每次重启上下文，就像每天早上换一张干净的白板，而不是在昨天的涂鸦上继续画。所以，与其依赖插件，不如自己写个 Bash 脚本，虽然原始，但可控、透明、高效。
【Ralph的缺点】
虽然Ralph作为自主代理潜力无限，但也有很多坑：
1. 不省token：并行跑的Ralph循环越多，token消耗呈指数级增长。
2. 质量换注意力：你不用花那么多脑力盯着循环，但代价是质量下降——因为你脱离了实际实现过程。
3. 规格书太大有风险：如果规格书太大，Ralph每次循环都可能遭遇上下文腐烂和压缩，几乎注定 catastrophic failure（灾难性失败）。所以规格书和执行计划必须尽可能简洁。
4. bug会传染：如果Ralph引入bug或写了烂测试，会毒害后续循环，彻底把应用带偏。
5. 前期规划极难：指望通过跟Claude聊几句就搞清楚所有想要的改动，是非常困难的。如果你不确定想要什么，强烈建议先用并行子代理去探索实现，然后把它们写的代码扔掉，基于快速结果做笔记，真正想清楚你要什么。
【第二种用法：探索模式】
这是我发现的几乎没缺点的方式，因为它只发挥Ralph的长处，不指望它干不擅长的事。
有时候我脑子里有个"后台任务"——可能是研究任务、一个问题、一个想做的MVP（最小可行产品）、或者一个功能的spike（技术预研）。我会花5分钟跟Claude brain dump（头脑风暴），稍微来回几句，让Claude写任务和规格书，不用太纠结细节。
然后启动Ralph循环，走开，或者去睡觉。
我通常在两种情况下用探索模式：
- 有想做但没时间做的事
- 我的Max Plan（Claude的付费套餐）用量第二天就要重置了
反正那些token要过期了，不如 wake up to something useful（醒来看到点有用的东西），让后台项目往前推一推。
如果你有Max Plan，绝对没理由不这么干。把模型放进沙盒，花5分钟规划，确保别超量产生API费用（关掉那个功能）。
【第三种用法：暴力测试】
从安全测试开始。比如，让Ralph系统地尝试你能想到的每一个攻击向量。你可以把这些攻击向量存起来，每次建应用都检查一遍。
UI测试方面，可以测试应用里每一个面向用户的操作：登录流程、结账、搜索、表单……用户可能走的每一条路径。方法是给Claude浏览器权限，让它在你的网站上通过浏览器做所有端到端测试——这些测试通常要花很长时间，但Ralph循环能暴力遍历每个案例，替你省时间。它可以通宵跑，你睡觉它干活。
你可能想给它一个沙盒环境，让它找出应用里的每一个bug和边界情况。
【这只是冰山一角】
注意，像Claude Code和Ralph循环这样的东西，本质上只是LLM架构的"包装器"——它们利用的事实是：LLM是一种"用token或能源换智力"的方法。
这意味着我们可以非常激进地并行化，尤其是token越来越便宜的时候。我们不仅能扩展产出，还能扩展投入应用中的智力或思考量。
所以，让LLM工作的时间越长、让它们思考还能做什么的时间越长，结果就越好。
拉尔夫循环的本质：把 LLM 当成可扩展的智力电池
归根结底，拉尔夫循环揭示了一个更宏大的趋势：大语言模型本质上是一种“智力外包”服务，用 token 或能源换取思考能力。只要价格持续下降，就可以无限并行化这种智力劳动。
拉尔夫循环正是这一理念的工程化体现——通过精心设计的外部架构，把单次推理转化为可持续、可扩展、可验证的自动化流程。它不依赖模型内部的“超能力”，而是靠人类的前期规划和系统的上下文管理来放大 AI 的产出效率。
未来，随着 token 成本进一步降低，类似拉尔夫循环的模式可能会成为复杂软件开发的标准范式，就像今天的 CI/CD 流水线一样普及。