你有沒有遇過這種情況：Claude Code 跑到一半說「完成了」，結果測試根本沒過？或是修好一個 bug 後，卻發現另外三個地方壞掉？

更慘的是，每次都要手動檢查、手動下指令、再手動確認。一個簡單的「把所有測試跑通」任務，你可能要來回操作 10 次以上。

如果我告訴你，有個技術能讓 Claude Code 自己迭代、自己修 bug、自己跑測試，直到真的完成為止——甚至有人用它讓 AI 自主開發了整整 3 個月，做出一個完整的程式語言編譯器，你信嗎？

這就是 Ralph Wiggum。

問題：AI 的「一次性思維」困境

症狀 1：虛假的「完成」

Claude Code 很聰明，但它有個致命問題：它以為自己做完了，但其實沒有。

1
2
3
4
你：「幫我把這個 API 的測試覆蓋率提升到 80%」
Claude：「好的，我已經新增了 5 個測試檔案」
你：npm test
結果：❌ 12 tests failed, coverage: 45%

問題在哪？Claude 寫完測試就認為任務結束，但它沒有真正驗證結果。

症狀 2：迭代開發的高成本

真實的開發場景通常是：

  1. 寫代碼
  2. 跑測試 → 失敗
  3. 看錯誤訊息
  4. 修 bug
  5. 再跑測試 → 又失敗
  6. 重複 10 次...

如果每一步都要你手動介入，AI 輔助開發的效率優勢就消失了。

症狀 3：複雜任務的放棄機制

當任務需要多次嘗試，Claude 很容易在第一次失敗後就「建議你手動處理」。但實際上，80% 的問題只要多試幾次、看看錯誤訊息，AI 自己就能解決。

解決方案：Ralph Wiggum 的自主迴圈

核心概念：讓 AI 自己重試到成功

Ralph Wiggum 的原理極其簡單，簡單到你可能會懷疑「就這樣？」

最早的實作就是一行 Bash：

1
while :; do cat PROMPT.md | claude ; done

沒錯，就是無限迴圈。

每次 Claude 說「我做完了」想退出，Ralph 就把它攔下來，塞回同一個指令：「繼續做，直到真的完成。」

官方插件：更聰明的自主迴圈

2025 年夏天，Anthropic 把這個「民間土砲」正式化為官方插件。現在你可以直接在 Claude Code 裡用：

1
2
3
/ralph-loop "修復所有測試失敗，確保覆蓋率達 80%" \
  --max-iterations 30 \
  --completion-promise "ALL_TESTS_PASSED"

這背後發生了什麼？

  1. Claude 開始執行任務
  2. 寫代碼、跑測試
  3. 測試失敗 → Claude 想說「完成了」
  4. Stop Hook 攔截：「等等，測試還沒過，繼續！」
  5. Claude 看到自己的錯誤訊息、修改代碼
  6. 再跑測試 → 還是失敗
  7. 重複步驟 4-6...
  8. 直到測試全過，或達到 --max-iterations 上限

為什麼這麼有效？關鍵是「上下文累積」

每次迭代，Claude 都能看到：

  • 上次修改的檔案（Git 記錄了變更）
  • 上次的錯誤訊息（stdout/stderr 保留在終端）
  • 上次的測試結果（哪些測試通過、哪些失敗）

這就像你在 debug，每次失敗都是新的線索。差別在於，Ralph 讓 Claude 自己收集線索、自己修正，你完全不用插手。

實戰範例：從理論到實踐

範例 1：測試覆蓋率提升（最常見場景）

任務：把一個舊專案的測試覆蓋率從 30% 提升到 80%

傳統做法：

  1. 看 coverage report → 找出沒測試的檔案
  2. 請 Claude 寫測試
  3. 跑測試 → 發現有些測試寫錯
  4. 請 Claude 修正
  5. 重複 10 次，花 2 小時

Ralph 做法：

1
2
3
4
5
6
7
8
9
10
11
12
/ralph-loop "
任務：提升測試覆蓋率到 80%

步驟：
1. 跑 npm run test:coverage，檢查當前覆蓋率
2. 找出覆蓋率最低的檔案
3. 為這些檔案寫單元測試
4. 跑測試，確保全過
5. 如果有測試失敗，分析錯誤並修正
6. 重複直到覆蓋率達 80%
7. 輸出 <promise>COVERAGE_COMPLETE</promise>
" --max-iterations 40 --completion-promise "COVERAGE_COMPLETE"

結果：去泡杯咖啡回來，測試覆蓋率已經從 30% → 82%，總共迭代了 23 次。

範例 2：框架遷移（複雜場景）

任務：把一個 React Class Component 專案遷移到 Hooks

Ralph 做法：

1
2
3
4
5
6
7
8
9
10
/ralph-loop "
遷移 src/components 下所有 Class Component 到 Hooks

規則：
- 保持功能完全一致
- 每遷移一個檔案就跑測試
- 測試失敗就修正，不要跳過
- 完成後執行 npm run build 確保沒有 TypeScript 錯誤
- 全部完成後輸出 <promise>MIGRATION_DONE</promise>
" --max-iterations 50 --completion-promise "MIGRATION_DONE"

真實案例：某團隊在 YC Hackathon 用這個方法，一晚生成了 6 個 repositories，全都能跑。

範例 3：Bug 修復（迭代型任務）

任務：修復一個會導致 API 500 錯誤的 bug

1
2
3
4
5
6
7
8
9
10
11
/ralph-loop "
修復 /api/users 端點的 500 錯誤

調試步驟：
1. 查看錯誤日誌，找出錯誤堆疊
2. 定位問題代碼
3. 修正問題
4. 跑整合測試
5. 如果測試失敗，繼續 debug
6. 測試通過後輸出 <promise>BUG_FIXED</promise>
" --max-iterations 20 --completion-promise "BUG_FIXED"

常見陷阱與避坑指南

陷阱 1：--completion-promise 不可靠

官方文檔明確警告：這個功能用的是字串完全匹配。

如果 Claude 輸出 COMPLETE 但你設的是 COMPLETION，迴圈不會停。

避坑方法：

  • ✅ 永遠設定 --max-iterations 作為安全網
  • ⚠️ 把 --completion-promise 當輔助，不要完全依賴

陷阱 2：Token 消耗爆表

Ralph 的成本不是免費的。

真實數據：

  • 一次簡單任務（10 次迭代）：約 $5-10
  • 複雜任務（50 次迭代）：約 $50-100
  • 極端案例（3 個月持續迭代）：數千美元

避坑方法：

  • 先用小的 --max-iterations（如 10）測試
  • 監控 API 用量儀表板
  • 複雜任務分階段執行，不要一次跑到底

陷阱 3：模糊的成功標準

❌ 不好的 Prompt：

1
/ralph-loop "讓這個專案變好" --max-iterations 50

Claude 不知道「好」的定義，會瞎忙 50 次然後放棄。

✅ 好的 Prompt：

1
2
3
4
5
6
7
8
/ralph-loop "
確保以下條件全部達成：
- npm test 全過（0 failures）
- npm run build 成功
- eslint 零警告
- 所有 TODO 註解已移除
完成後輸出 <promise>DONE</promise>
" --max-iterations 30

陷阱 4：安全敏感代碼別自動化

絕對不要用 Ralph 做這些事：

  • ❌ 身份驗證邏輯
  • ❌ 支付系統整合
  • ❌ 加密/解密實作
  • ❌ 資料庫 migration（會炸資料）

這些需要人工審查，不能讓 AI 自己迭代。

適合 Ralph 的場景：

  • ✅ 測試補充
  • ✅ 代碼風格統一
  • ✅ 框架遷移
  • ✅ 文檔生成
  • ✅ Refactoring（有測試保護的前提下）

震撼案例：真實世界的成果

案例 1：$297 完成 $50K 的外包案

某開發者接了一個大型重構案，傳統報價 $50K。他用 Ralph 跑了整整一週，最終 API 成本：**$297**。

案例 2：3 個月做出程式語言編譯器

Geoffrey Huntley（Ralph 技術的創始人）讓 Claude 持續迭代 3 個月，產出了：

  • 完整的程式語言（Cursed）
  • LLVM 後端支援
  • 標準函式庫
  • 編譯器工具鏈

案例 3：Hackathon 一晚 6 個 Repo

YC 加速器團隊在測試中，一晚之間用 Ralph 生成了 6 個可運行的專案。

總結：何時該用 Ralph？

核心判斷標準：

  • ✅ 任務有明確的成功標準（測試通過、build 成功、覆蓋率達標）
  • ✅ 需要多次迭代才能完成（一次做不完的事）
  • ✅ 可以自動驗證結果（測試、linter、編譯器）
  • ❌ 需要架構決策（選 Redux 還是 Context？）
  • ❌ 安全敏感代碼（auth、payments）
  • ❌ 探索性開發（不知道要做什麼的時候）

下一步你可以做什麼：

  1. 安裝 Ralph Wiggum 插件：claude plugin install ralph-wiggum
  2. 找一個小任務試試（建議：補測試覆蓋率）
  3. 設定保守的 --max-iterations（如 10）
  4. 觀察 Claude 怎麼自己 debug
  5. 根據結果調整 Prompt

Ralph Wiggum 改變的不只是開發效率，而是開發哲學：從「AI 幫我寫代碼」到「AI 自己把事情做完」。

試試看，你會發現很多「需要人工介入」的任務，其實 AI 自己就能搞定。

延伸閱讀：