ClearForge
重點：跟 AI 寫程式陷入 bug 循環，問題不在 prompt 寫得好不好，是沒有測試保護。用 SbE GIVEN-WHEN-THEN 讓 Claude Code 自己跑測試自己修到全綠。
在 Claude Taiwan FB 社團看到一個問題：完成正式開發好的 App，Test Run 或正式用的時候就出現 Error，要修好幾輪。
我在留言回了一句：你需要的不只是提示詞，你需要建立測試保護。 本來上午又去補充留言，想了想，乾脆今天發一篇文分享我的做法。
你有沒有經歷過這個迴圈？
跟 AI 寫程式時的典型痛苦：
- 跟 Agent 說要做什麼
- Agent 做完
- 我測試 → 發現 bug
- 叫 Agent 修 → 修完
- 又有新的 bug → 再修
- 又壞別的地方
- 修了 5–6 次才穩定
- 下次做新功能，同樣的循環再來一次
這個迴圈真正卡住的地方，比「修 bug 的 prompt 怎麼寫」更前面。
一個小實驗：餐廳訂位系統
假設你要做一個餐廳訂位系統，規則是「預約後 15 分鐘未到自動取消」。
你跟 Agent 說：「幫我做一個餐廳訂位系統，預約後 15 分鐘未到自動取消。」
Agent 做出來了。你開始測試：
- 客人預約 18:00，18:15 到 → 結果被取消了。等等，15 分鐘整到底算不算遲到？ 你沒說，Agent 自己猜了一個。
- 客人 18:10 打電話說會遲到 → 系統完全沒處理這個情況。因為你沒提到「來電通知」這回事。
- 訂了 6 位、18:05 來了 2 位 → 系統判定「已到場」。但你心裡想的是「6 位才算到」。
三個 bug，但 Agent 的程式邏輯沒寫錯——是規格不夠精確，Agent 只能自己猜。
我的做法：先用 GWT 寫場景
在叫 Claude Code 寫程式之前，先列出最關鍵的場景，釐清每個場景的需求：
Scenario: 準時到場
假設：客人已預約今日 18:00
當：客人於 18:05 到場報到
那麼：訂位應確認有效，應安排入座
Scenario: 超過 15 分鐘未到
假設：客人已預約今日 19:00
當：時間到達 19:16 且客人未到場
那麼：訂位應被自動取消，桌位應釋出
Scenario: 第 15 分鐘整到場
假設：客人已預約今日 12:00
當：客人於 12:15 到場
那麼：訂位應仍然有效（15 分鐘整不算超過）
Scenario: 來電告知遲到
假設：客人已預約今日 20:00，且於 20:05 來電告知將遲到 10 分鐘
當：時間到達 20:16 且客人未到場
那麼：訂位應保留至 20:30這個方法叫 實例化需求（Specification by Example），語法格式叫 GIVEN-WHEN-THEN（GWT or Gherkin），最早來自 BDD（Behavior-Driven Development）。
它的核心概念很簡單：用具體的例子把每個情況的預期結果寫清楚。
把規格變成可執行的測試
光寫清楚還不夠。過去我們寫完規格，還是要自己去 Test Run 才知道對不對。
但 GWT 有個特性：它寫出來既是規格，也是測試案例。
也就是說，你可以讓 Claude Code 拿著這些場景，同時產出程式碼和對應的測試，自己跑、自己驗、碰到紅燈自己修，修到全綠才回報你：
claude "請讀取 CLAUDE.md 和 驗收規格.md。
根據業務規則建立互動式原型，
根據每條 GIVEN-WHEN-THEN 產生驗收測試，
跑測試，如果有紅燈就修正後重跑，
全部通過後回報結果。"Claude Code 回報的時候，你看到的是一份測試報告：
🧪 驗收測試結果
✅ 準時到場 → 訂位有效
✅ 超過 15 分鐘未到 → 自動取消
✅ 第 15 分鐘整到場 → 訂位有效
✅ 來電告知遲到 → 保留至 20:30全綠。你不需要自己 Test Run 去找 bug——Claude Code 在回報你之前就已經把紅燈修完了。
你要做的是看這份測試報告，判斷結果是不是你要的。如果某個場景的預期結果你覺得不對，那是規格要調，不是程式要修。
在 CLAUDE.md 裡定治理規則
我會在專案的 CLAUDE.md 裡放一些規則，讓 Claude Code 在寫程式和產生測試的時候自動遵守。例如：
- 每條 GIVEN-WHEN-THEN 都要有對應的測試
- 測試結果用 ✅/❌ 顯示，❌ 要說明預期值和實際值的差異
- 紅燈要自行修正後重跑，全綠才回報
- 如果規格中沒有涵蓋某個情境，不要自己猜，標記為 TODO
這樣 Claude Code 碰到規格沒寫到的情況會告訴你，而不是自己決定然後做錯。
整套協作模式
所以我跟 Claude Code 的協作模式就是：
我說明需求 → Claude Code 依照我的規範產生 GWT 實例規格與測試 → 依據規格實作功能 → 執行測試 → 回報全綠的測試報告 → 我判斷結果對不對 → 討論規格沒覆蓋到的情境。
找 bug 和修 bug 佔我的時間比例很少。
不敢說完全沒 bug——實例化需求場景覆蓋的是關鍵業務流程，邊界案例不可能全靠場景寫完，那些不影響核心流程的 bug 還是要靠其他層次的測試保護來接住。但「盲目 Test Run 然後到處冒 Error」的情況確實大幅減少了。
回到原 po 的問題
「提示詞如何寫才最好修復？」
至少對我來說，與其想辦法寫出更好的修復 prompt，不如把力氣花在前面——把規格寫精確，讓 Claude Code 自己跑測試、自己修到全綠。
寫好規格 → Claude Code 照規格做 + 照規格測 → 紅燈？Claude Code 自己修 → 重跑到全綠 → 回報你看測試報告。