核心原理
传统的 Claude Code 工作流是单轮的：你给任务，Claude 完成，退出，你再手动启动下一轮。Ralph Wiggum 把这个过程变成了自动循环：
/ralph-loop "你的任务描述" --completion-promise "DONE" --max-iterations 50
执行流程如下：
- Claude 执行任务
- 尝试退出时被 Stop hook 拦截
- 自动重新读取同一个 prompt
- 读取自己之前写的代码和测试结果
- 继续改进，直到输出完成信号词或达到迭代上限
关键设计在于：每次迭代 prompt 不变，但文件系统和 git 历史在变。Claude 通过读取自己上一轮的产出来判断进度，实现自我迭代。
适用场景
这个插件最适合有明确验证标准的任务：
- TDD 开发：写测试 → 跑失败 → 改代码 → 重复直到全绿
- Greenfield 项目：定义好需求文档，过夜执行
- 自动化验证类任务：测试、Lint、类型检查能提供明确的对错反馈
不适合的场景：需要人类审美判断的设计决策，以及没有明确成功标准的开放性任务。
Prompt 写法要点
让 Ralph 有效工作的关键是：明确的完成条件 + 完成信号词。
构建一个 Todo REST API
完成标准：
- CRUD 全部可用
- 输入校验完备
- 测试覆盖率 > 80%
完成后输出：<promise>COMPLETE</promise>
没有明确的完成标准，Claude 要么无限循环，要么过早停止。
实际效果
几个值得注意的数据：
- 在 Y Combinator Hackathon 上，有人用它一夜生成了 6 个完整仓库
- 某项目用这种方式交付了价值 5 万美元的合同，API 调用成本仅 297 美元
安全机制
务必设置 --max-iterations 参数防止无限循环和 API 费用失控：
/ralph-loop "任务" --max-iterations 30 --completion-promise "DONE"
建议从小迭代数开始测试，确认 prompt 质量后再放开上限。
实操建议
对独立开发者来说，这个插件的最大价值在于把"等待时间"变成"生产时间"。建议从一个有完整测试覆盖的小模块开始尝试，比如一个 CRUD API 或工具函数库。写好明确的完成标准，设好迭代上限，让 Claude 跑一夜，第二天 review 产出。核心心法：你负责定义"什么算完成"，Claude 负责达到那个标准。