Ralph Wiggum 技巧：让 Claude Code 自主运行数小时

转载

你写一个 prompt。Claude 工作了一会儿。然后它停了。"我已经完成了实现，"它自豪地宣布。

你看了看结果。它只完成了 60%。

所以你重新 prompt。Claude 又工作了一会儿。又停了。"功能现在已经完成了。"

还是没完成。

如果 Claude 就这样......一直继续呢？ 如果它在自己的工作上进行迭代，直到任务真正完成------不是当它认为完成时，而是当你的测试真正通过时呢？

这正是 Ralph Wiggum 技巧所实现的。开发者们为此疯狂。

Ralph Wiggum + Opus 4.5 真的非常非常好

--- Matt Pocock (@mattpocockuk) 2026 年 1 月 1 日

Ralph Wiggum 插件是什么？

Ralph Wiggum 插件是一个官方的 Anthropic Claude Code 插件，用于创建自主开发循环。Claude 不会在单次尝试后停止，而是会让 Ralph 持续在同一任务上工作------一次又一次地迭代------直到它真正成功。

这个名字来自《辛普森一家》的角色 Ralph Wiggum，体现了一个简单的哲学：尽管有挫折，仍坚持迭代。不断尝试直到你做对为止。

这是核心命令：

/ralph-loop "Fix the token refresh logic in auth.ts. Output <promise>FIXED</promise> when all tests pass." --max-iterations 10 --completion-promise "FIXED"

这个想法是持续迭代，并希望能收敛到一个明确的目标。<promise> 标签模式给 Claude 一个明确的信号，告诉它何时输出完成标记。

当你运行这个命令时：

1. Claude 尝试修复
2. 当 Claude 认为它"完成"并试图退出时，一个 Stop hook 会拦截
3. hook 检查：Claude 是否输出了完成 promise（"FIXED"）？
4. 如果没有，原始 prompt 会带着更新的上下文被重新注入
5. Claude 看到它自己之前的工作（修改过的文件、git 历史）
6. 它继续迭代，直到 promise 出现在输出中

关键洞察： 每次迭代都不是从头开始。Claude 看到了它在上一轮构建的内容。它审查自己的代码，注意到什么坏了，然后修复它。这个循环创建了一个自我纠错的反馈系统。

它实际上是如何工作的

技术机制令人惊讶地优雅。Ralph Wiggum 使用了 Claude Code 的 Stop hook 功能------一种拦截 Claude 试图结束会话的方式。

流程如下：

You: /ralph-loop "Add auth to admin panel. Output <promise>DONE</promise> when tests pass." --max-iterations 20 --completion-promise "DONE"

[Iteration 1]
Claude: *writes auth logic, tests, middleware*
Claude: "Authentication implemented."
Stop hook: *Checks output for "DONE" - not found*
Stop hook: "Continue working."

[Iteration 2]
Claude: *sees failing tests, reviews own code*
Claude: "Found issue with session handling. Fixing..."
Stop hook: *Checks output for "DONE" - not found*
Stop hook: "Keep going."

[Iteration 3]
Claude: *fixes edge case, runs tests*
Claude: "All tests passing. <promise>DONE</promise>"
Stop hook: *Found "DONE" in output*
Stop hook: "OK, you can exit now."

--completion-promise 参数定义了"完成"的实际含义。通过在你的 prompt 中将其嵌入 <promise> 标签内，你给 Claude 一个明确的信号，告诉它何时输出标记。hook 只是简单地检查该字符串是否出现在 Claude 的响应中。

Ralph Wiggum 擅长的场景

这项技术在特定类型的工作中表现出色：

大型重构

从一个框架迁移到另一个框架。更新数百个文件以使用新的 API。将类组件转换为 hooks。这些任务需要 Claude 多次迭代才能把所有事情都做对。

/ralph-loop "Convert all class components to functional components with hooks. Output <promise>MIGRATED</promise> when npm run typecheck passes." \
  --max-iterations 30 \
  --completion-promise "MIGRATED"

测试驱动开发

先编写失败的测试，然后让 Ralph 迭代直到它们通过：

/ralph-loop "Implement the checkout flow to make all tests in checkout.test.ts pass. Output <promise>TESTS_PASS</promise> when done." \
  --max-iterations 25 \
  --completion-promise "TESTS_PASS"

批量操作

文档生成、代码标准化、在整个代码库中添加 TypeScript 类型------这些受益于迭代的重复性工作。

有明确规格的全新功能

当你有明确定义的功能和自动验证（测试、linter、构建）时，Ralph 可以增量构建它。

何时不要使用它

Ralph Wiggum 并不是解决所有问题的魔法方案：

模糊的需求 ------ 如果你无法定义客观的成功标准，Ralph 就无法知道何时停止。

架构决策 ------ 在微服务和单体之间选择不是可以盲目迭代的事情。

安全关键代码 ------ 认证、加密、支付处理------这些需要人工审查，而不是自主迭代。

探索性工作 ------ "弄清楚应用程序为什么慢"不是一个好的 Ralph 任务。你需要人工判断来解释结果。

需要人工判断的任务 ------ 设计决策、UX 选择、业务逻辑边缘案例------让人工保持在循环中。

社区的真实成果

Ralph Wiggum 技巧产生了一些令人印象深刻的成果：

Geoffrey Huntley 的编程语言：一个 3 个月的连续循环构建了 "Cursed"------一门完整的编程语言，带有 Z 世代的关键字。是的，真的。

YC 黑客马拉松团队：一夜之间交付了 6+ 个仓库，API 成本约 297 美元。多个完整的项目在人类睡觉时自主运行。

集成测试优化：一位开发者使用 Ralph 重构测试，将运行时间从 4 分钟减少到 2 秒。

共同的主线：具有自动验证的明确定义的任务运行了延长的时间。

成本考虑

让我们现实地谈谈 token 使用。自主循环会快速消耗 token。

在一个中等规模的代码库上，一个典型的 50 次迭代循环可能会花费 50-100 美元以上的 API 使用费。--max-iterations 标志不仅仅是一个安全机制------它是成本控制。

最佳实践：

• 对新任务从较低的迭代限制开始（10-20）
• 在你了解 token 消耗模式后扩大规模
• 使用特定的完成标准，以便尽早退出
• 监控成本与价值------一个节省 20 小时工作的 100 美元循环是值得的

入门指南

如果你正在使用 Claude Code，以下是尝试 Ralph Wiggum 的方法：

1. 安装插件

Ralph Wiggum 是一个官方的 Anthropic 插件。从 Claude Code 中安装它：

/plugin install ralph-wiggum@claude-plugins-official

你也可以随时使用 /cancel-ralph 取消活动的循环。

2. 从简单开始

从一个小的、明确定义的任务开始：

/ralph-loop "Fix all ESLint errors in src/. Output <promise>LINT_CLEAN</promise> when npm run lint passes." \
  --max-iterations 10 \
  --completion-promise "LINT_CLEAN"

3. 定义明确的成功标准

你的 --completion-promise 应该是：

• 一个简单的、唯一的字符串（如 "DONE"、"FIXED"、"COMPLETE"）
• 使用 <promise>YOUR_MARKER</promise> 语法嵌入到你的 prompt 中
• Claude 只会在实际目标实现时才输出的东西

4. 与版本控制一起使用

总是在 git 跟踪的目录中运行 Ralph 循环。如果出现问题，你可以恢复。每次迭代都会添加到 git 历史，给你一个清晰的变更记录。

背后的哲学

Ralph Wiggum 反转了典型的 AI 编码工作流。不再是：

1. Prompt → Claude 工作 → 输出 → 人工审查 → 重复

你得到的是：

1. Prompt + 成功标准 → Claude 自主循环 → 人工审查最终结果

这项技术将__失败视为学习数据__。每次失败的尝试都告诉 Claude 什么不起作用。在迭代过程中，解决方案会收敛向成功。

这种哲学------即持续迭代胜过完美的首次尝试------感觉违反直觉。我们被训练认为 AI 应该"立即做对"。但复杂编码任务的现实更加混乱。有时你需要多次尝试。有时你需要看到什么坏了才能修复它。

Ralph Wiggum 接受了这种现实。

这对开发工作流意味着什么

Ralph Wiggum 技巧是我们与 AI 编码助手合作方式更广泛转变的一部分：

从交互到自主：不再是看守每一步，而是定义目标并让 AI 向其迭代。

从单次到迭代：接受复杂任务需要多次尝试，并将其构建到工作流中。

从人类节奏到机器节奏：一个过夜的循环可以完成人类需要几天专注工作才能完成的事情。

对于大量使用 Claude Code 的团队，Ralph Wiggum 开启了一类新的任务------那些对人类来说太繁琐但对单个 prompt 来说又太复杂的任务。

关于 Opus 4.5 的说明

有一点值得一提：随着 Opus 4.5 的出现，Ralph Wiggum 技巧对许多任务来说变得不那么必要了。正如 savage-bits 在 Reddit 上指出的那样：Opus 4.5 在遵循计划方面非常出色，而且压缩（上下文管理）已大大改进。

这些增强意味着 Claude 更擅长在更少的迭代中完成复杂任务------有时甚至可以一次性完成。模型改进的维护上下文和执行多步骤计划的能力，减少了对强制迭代循环的需求。

尽管如此，对于真正的大型重构、过夜的批量操作，以及你想要明确迭代控制的任务，Ralph Wiggum 仍然表现出色。它是你的工具箱中的一项强大技术，即使你发现自己随着新模型的推出而越来越少地使用它。

---