Ralph Wiggum 方法：运行 AI Coding Agents 数小时（而非数分钟）
Source: Dev.to
我们都经历过这种情况。你启动 Claude Code，输入类似 “帮我构建一个待办事项的 REST API” 的提示，然后抱着期待。也许它能成功，也许不能。无论如何，你都盯着屏幕，看着 token 消耗，想知道代理是在取得进展还是只是在原地打转。
根本问题是什么？ 传统的 AI 编码是一次性 one‑shot 方案。你只有一个上下文窗口，一次解决问题的机会，然后要么完成，要么没有完成。
更好的想法：多次运行相同的代理
如果你在同一个提示上连续运行 10 次同一个代理会怎样？
- 每一次迭代都从上一次结束的地方继续。
- 代理能够看到它之前的操作（通过 git 历史和已修改的文件）。
- 它会迭代、改进，并且每次都更接近“完成”。
这就是 Ralph Wiggum 方法——它真的可以改变游戏规则。
立即尝试 Ralph
1. 安装插件
/plugin install ralph-wiggum@claude-plugins-official2. 运行你的第一个循环
/ralph-loop "Add JSDoc comments to all exported functions in src/utils/" \
--max-iterations 103. 完成后检查 git diff
就这样。你刚刚运行了你的第一个自主循环。Claude 对同一任务迭代了 10 次，每次都改进其工作，直至完成。
核心洞见
迭代胜过完美。
该技巧来源于 Geoffrey Huntley，他用一句话概括了它：
while :; do
cat PROMPT.md | claude
done名字取自《辛普森一家》中的 Ralph Wiggum——永远困惑、总是出错，却从不停止。这正是其氛围所在。
其核心是，Ralph 不断向 AI 代理提供相同的提示，直至满足 停止条件。代理能够查看其之前的工作（通过 git 历史和已修改的文件），从中学习并逐步改进。
“在一个不确定的世界里，这种技巧在确定性上是糟糕的。
与其不可预测地成功，不如可预测地失败。”
连 Matt Pocock 都是它的粉丝：
“Ralph Wiggum + Opus 4.5 真是太棒了，真的非常好。”
插件工作原理
- 调用
/ralph-loop并提供提示和完成标准。 - Claude 执行任务。
- 当 Claude 试图退出（认为已完成）时，Stop hook 使用 退出码 2 拦截它。
- 该钩子检查你的 完成承诺（例如
COMPLETE）。 - 如果未找到承诺，则重新提供原始提示，Claude 继续。
- 每次迭代都会看到上一次运行的已修改文件和 git 历史。
示例命令
/ralph-loop "Migrate all tests from Jest to Vitest" \
--max-iterations 50 \
--completion-promise "All tests migrated"循环会持续进行，直到 Claude 输出完成承诺或达到迭代上限。
演练示例：Jest → Vitest 迁移
提示
Migrate all tests from Jest to Vitest.
- Update all test files to use Vitest syntax
- Update package.json scripts
- Remove Jest dependencies
- Add Vitest dependencies
- Run tests after migration
Output MIGRATED when all tests pass.发生了什么
| 迭代 | Claude 的操作 |
|---|---|
| 1 | 将测试文件更新为 Vitest 语法；测试失败 |
| 2 | 修复语法错误；测试仍然失败 |
| 3 | 更新 package.json，移除 Jest，添加 Vitest |
| 4 | 运行测试，全部通过，输出 MIGRATED |
你会发现测试套件已经完整迁移。无需手动重新提示，也不需要在中间进行调试。只需设置好，让它自行运行即可。
真实案例
| 项目 | 成果 |
|---|---|
| Cursed programming language | 在 3 个月内使用单个 Ralph 循环构建：功能性编译器、LLVM 后端、标准库、部分编辑器支持。关键字包括 slay（函数）、sus（变量）、based（真）。 |
| 6+ repositories overnight | Y Combinator 黑客马拉松团队在一夜之间交付了多个仓库，API 成本仅 $297 —— 本来需要 $50 K 的承包商费用。 |
| 4‑minute → 2‑second tests | 一名开发者在睡眠时将集成测试迁移为单元测试；循环自动完成了机械转换。 |
| Full APIs with TDD | 通过迭代构建功能、运行测试、修复失败并重复，直至所有测试通过。 |
这些是精选的成功案例。每一次一夜之间的胜利背后，都有循环在迭代中消耗却未收敛。失败的尝试同样会花钱。但一旦成功，效果会非常惊人。
理想使用场景
| 使用场景 | 示例提示 |
|---|---|
| 大规模重构 | "将所有类组件转换为使用 hooks 的函数组件。当 npm run typecheck 通过时输出 MIGRATED。" |
| 框架迁移 | "将所有测试从 Jest 迁移到 Vitest。当所有测试通过时输出 COMPLETE。" |
| TDD 工作流 | "实现结账流程，使 checkout.test.ts 中的所有测试通过。完成后输出 TESTS_PASS。" |
| 测试覆盖率 | "为 src/ 中所有未覆盖的函数添加测试。" |
| TypeScript 采用 | "为 src/utils/ 中的所有函数添加类型注解。" |
| 新项目构建 | "构建具有 CRUD 操作的 REST API。当所有端点工作且测试通过时输出 COMPLETE。" |
共同点： 明确定义的成功指标。如果你能精确描述“完成”，Ralph 就能朝着它迭代。
何时不应使用 Ralph
- 模糊的需求 – 如果你无法精确定义“完成”，循环将无法收敛。
- 架构决策 – 新颖的抽象需要人类推理，而不是盲目的迭代。
- 安全敏感的代码 – 认证、支付、数据处理等需要在每一步都进行人工审查。
- 探索性调试 – “弄清楚为什么应用运行缓慢”不是一个合适的 Ralph 任务。
Ralph 自动化的是机械执行，而不是关于什么值得构建的决策制定。
常见陷阱（以及如何避免）
| ❌ 错误 | ✅ 解决方案 |
|---|---|
| 首次运行目标过于宏大 | 从一个小且明确界定的子任务开始。 |
| 完成标准模糊 | 使用明确的 “ token，便于可靠检测。 |
| 忘记保持 CI 通过 | 在每次迭代后运行 CI（或将其集成到循环中）。 |
| 未监控成本 | 设定合理的 --max-iterations 并关注 token 使用情况。 |
| 将其用于非确定性任务 | 仅将 Ralph 用于确定性、机械性的工作。 |
TL;DR
传统的 AI 编码是一锤子买卖。Ralph Wiggum 将其转变为一个 可重复循环，循环迭代直至出现明确的成功信号。
- 安装 插件。
- 定义 明确的 “ completion token。
- 运行
/ralph-loop并设定合理的迭代上限。 - 监控 成本、CI 状态以及 promise 输出。
在针对范围明确、机械化的任务时，Ralph 能把单次提示转化为全自动的开发流水线。祝循环愉快！
判断密集任务
代理在每次迭代中提交其工作，并将进度追加到 progress.txt 文件中。这起到以下作用：
- 日志，供后续迭代读取
- 文档，记录已尝试的内容
- 防止代理重复错误的方式
这点至关重要。 每次迭代必须通过测试和类型检查。提交有缺陷的代码会限制后续迭代，并导致调试噩梦。
规则： 如果测试失败，代理必须在继续之前修复它们。
精确的退出标准
大多数人会出错，因为他们的成功标准模糊不清。
| ❌ 坏的提示 | ✅ 好的提示 |
|---|---|
| “Build a todo API and make it good.” | “Build a REST API with CRUD operations. Input validation required. Tests must pass (> 80 % coverage). README with API docs. Output COMPLETE when done.” |
注意：
--completion-promise标志使用精确字符串匹配，这不可靠。请使用--max‑iterations作为真正的安全网。
为什么迭代限制很重要
自主循环会消耗大量 token。对大型代码库进行 50 次迭代的循环，轻易就会产生 $50‑100+ 的 API 费用，具体取决于上下文大小。在 Claude Code 订阅下，你会更快触及使用限制。
最佳实践
- 保守地设置
--max-iterations（先从 10‑20 开始）。 - 在了解 token 消耗模式后再扩大。
- 使用测试 / 构建成功 作为完成标准，而不是 Claude 的自我评估。
- 在长时间运行时监控使用情况。
常见症状与快速解决方案
| 症状 | 快速解决方案 |
|---|---|
| 循环卡在无限循环中？ | 检查 --max-iterations 和 progress.txt 中的阻塞点。 |
| 测试一直失败？ | 在下一次迭代前先修复失败的测试。 |
| 成本过高？ | 降低 --max-iterations 或缩小任务范围。 |
| Claude 说“完成”但实际并未完成？ | 验证测试结果和 CI 状态。 |
优缺点
| ✅ 优势 | ❌ 劣势 |
|---|---|
| 在你睡觉时就能提交代码 | 可能会快速消耗令牌 |
| 适合机械化任务 | 不适合需要大量判断的工作 |
| 自我纠正的反馈循环 | 需要良好的提示工程 |
| 减少手动重新提示的工作 | 如果标准模糊，可能会卡住 |
| 基于 git 历史进行构建 | Windows 环境需要 jq 依赖 |
| 生态系统不断壮大 | 有效提示的学习曲线较陡峭 |
生态系统亮点
ralph-claude-code– 364 ⭐。添加速率限制、tmux 仪表盘、用于故障恢复的断路器以及智能退出检测。ralph-orchestrator– 添加令牌跟踪、支出上限、git 检查点和多 AI 支持。
这些工具解决了运营挑战：成本控制、状态恢复和监控。官方插件提供核心机制；生态系统构建生产包装层。
常见问题
-
我可以将其与其他 AI 工具一起使用吗？
是的——该模式与工具无关，只需调整循环逻辑即可。 -
如果 Claude 卡住了怎么办？
使用保守的--max-iterations参数。循环会自动停止。 -
我可以一次运行多个循环吗？
在技术上可以，但要注意令牌使用量和 git 冲突。 -
它能在大型代码库中使用吗？
可以，但需要更高的迭代上限并仔细管理令牌预算。 -
我可以暂停并恢复循环吗？
使用/cancel-ralph停止。要恢复，重新运行相同的命令——Claude 会从 git 历史中接着执行。
入门
-
安装官方插件
/plugin install ralph-wiggum@claude-plugins-official -
Windows 用户: 插件有一个未记录的
jq依赖，在 Windows/Git Bash 上会出错。请先安装jq，或使用 WSL。 -
可用命令
/ralph-loop "" --max-iterations N /ralph-loop "" --max-iterations N --completion-promise "text" /cancel-ralph # 终止活动循环 -
从小任务开始 – 选择一个机械化、成功标准明确的任务：
- 安装插件（≈ 30 秒）
- 提示：
Add JSDoc comments to all exported functions in src/utils/ - 使用
--max-iterations 10运行
-
完成后检查 git diff。
如果第一次尝试未收敛，请细化成功标准并重试。
Community & Contribution
- 自己动手 – 从一个小而安全的任务开始。
- 加入社区 – 查看 GitHub 仓库和 Discord。
- 分享你的成果 – 发布你用 Ralph 构建的内容。
- 贡献 – 生态系统正在发展；还有空间容纳新工具。
- 保持更新 – 关注 Geoffrey Huntley 和 Claude Code 团队。
心态转变
| 传统 AI 编码 | Ralph 方法 |
|---|---|
| 一次性完美 | 迭代而非完美 |
| 失败是挫折 | 失败是数据 |
| 单次提示 | 提示、观察、重复 |
| 操作者抱有希望 | 操作者设计循环 |
| 直接一步步 | 编写收敛的提示 |
技能从“逐步指挥 Claude”转变为“编写收敛到正确解的提示”。你的工作变成：我如何设定条件，使迭代导致成功？
TL;DR
停止期望 AI 编码代理一次就完美。让它们在循环中运行，跟踪进度，保持 CI 绿色，让迭代承担繁重工作。睡觉时也能发布。
你尝试过 Ralph 或类似的方法吗？ 你的体验如何？在下方留下评论吧。
Sources
- Geoffrey Huntley 关于 Ralph 的讨论
- 官方 Claude Code 插件
- Ralph for Claude Code（社区分支）
- Ralph Orchestrator
- BetterStack YouTube 视频（60 K 观看）
- Paddo.dev 深度解析