Ralph Wiggum

你有没有想过，让 AI 助手在你下班后继续工作？不是简单跑一次任务就停，而是持续迭代、自我修正、直到任务完成——就像一个不知疲倦的程序员，盯着测试结果，不断调整代码，直到所有用例通过。

这就是 Ralph Wiggum 插件（简称 Ralph）的核心能力：

让 Claude 自己跟自己对话，形成一个自动演进的开发循环。

你只需在下班前输入一行指令，第二天醒来，代码可能已经跑通、测试全绿、甚至 ready for review。

传统用法 vs Ralph 用法

传统方式：

你给 Claude 一个任务 → 它生成代码 → 对话结束 → 你手动检查 → 发现问题 → 再开新对话修正。
这是一个人工驱动、离散、中断频繁的工作流。

Ralph 方式：

/ralph-loop "构建一个支持 JWT 的用户认证模块" \
  --completion-promise "DONE" \
  --max-iterations 50

Claude 会进入一个自动循环：

1. 执行当前任务（如写代码、写测试）
2. 尝试输出结束语（如 “任务完成”）
3. 被 Ralph 的 Stop Hook 拦截，不真正退出
4. 自动重新加载相同的初始 prompt
5. 但此时它能读取自己之前写入的文件和 Git 提交历史
6. 基于最新状态继续改进，直到输出指定的完成信号（如 DONE）或达到迭代上限

每次迭代的 prompt 不变，但环境在变——Claude 通过观察自己的“作品”实现自我进化。

最适合 Ralph 的场景

✅ TDD（测试驱动开发）

写一个失败的测试 → 让 Ralph 生成实现 → 运行测试 → 失败则继续迭代 → 直到全绿。
整个过程无需人工干预。

✅ Greenfield 项目（从零开始）

你提供清晰需求（如 “用 FastAPI 写一个博客 API”），Ralph 可在夜间完成基础结构、路由、模型和测试。

✅ 具备自动验证机制的任务

只要有明确的“对/错”判断标准（如测试通过、Lint 无 error、类型检查通过），Rough 就能持续优化。

❌ 不适合的场景

• 需要主观判断的设计决策（如 UI 布局、架构权衡）
• 没有明确成功标准的模糊任务（如 “让代码更好”）

如何写一个有效的 Ralph Prompt？

关键：必须包含明确的完成标准 + 完成信号词

示例：

构建一个 Todo REST API，使用 FastAPI。

完成标准：
- 实现完整的 CRUD 操作（创建、读取、更新、删除）
- 所有端点有输入校验（非法 ID、空标题等）
- 单元测试覆盖所有主要路径，覆盖率 > 80%
- 通过 pytest 且无失败用例

完成后，请在最后一行输出：
<promise>COMPLETE</promise>

Ralph 会监控输出，一旦看到 <promise>COMPLETE</promise>，就终止循环。

真实使用成果

• Y Combinator 黑客松：团队使用 Ralph 一夜之间生成 6 个可运行的仓库原型
• 某商业项目：一份 $50,000 的开发合同，AI 调用成本仅 $297，大部分基础代码由 Ralph 在夜间完成

这些案例的共同点是：任务边界清晰、验证自动化、无需人类介入判断。

安全机制：防止无限循环

Ralph 强制要求设置最大迭代次数，避免因逻辑死锁导致资源浪费：

/ralph-loop "任务描述" \
  --completion-promise "DONE" \
  --max-iterations 30

即使 Claude 忘记输出完成信号，30 轮后也会自动停止。你可以检查中间产物，调整 prompt 后重新启动。