🎯 什麼情境該想到我
當你希望 agent「自己跑完，不用你一直盯」的時候。
關鍵洞察：LLM 極擅長「不斷迴圈直到達成特定目標」。不要告訴它做什麼，給它成功標準，然後看著它跑。
⚙️ 怎麼用（步驟 / 公式）
把祈使句改寫成可驗證的目標
| 不要說 | 改成 |
|---|---|
| 「加上驗證」 | 「替無效輸入寫測試，然後讓它們通過」 |
| 「修掉這個 bug」 | 「寫一個能重現它的測試，然後讓它通過」 |
| 「重構 X」 | 「確保改動前後測試都通過」 |
共同結構：把「做某件事」換成「讓某個可自動判定的條件成立」。
多步驟任務就寫成「步驟 → 驗證」
1. [步驟] → 驗證：[怎麼確認]
2. [步驟] → 驗證：[怎麼確認]
3. [步驟] → 驗證：[怎麼確認]
每一步都有自己的驗證條件，agent 才知道什麼時候可以往下一步走。
⭐ 判準：這個標準夠不夠強？
- 強標準（「測試全綠」「這個指令回傳 0」「這個字串出現在輸出裡」）→ agent 可以自己迴圈，不用問你。
- 弱標準（「讓它能動」「弄好一點」）→ 每一步都要回來問你，你等於在手動驅動它。
寫完任務描述後回頭問一句：「這個條件機器判得出來嗎？」 判不出來就再收緊。
🧪 我實際套用的紀錄
- 2026-09-08：（待填）
⚠️ 注意 / 什麼時候不適用
- 可驗證不等於正確。測試全綠只代表符合你寫的測試；測試本身寫錯，agent 會很有效率地跑向錯的地方。成功標準的品質決定一切。
- 不是所有事都有機器可判的標準。版面好不好看、措辭恰不恰當、架構合不合理——這些要人看。硬掰一個假的量化標準比沒有更糟。
- 標準太緊會逼出鑽漏洞的行為：agent 可能改測試而不是改程式。要同時禁止這條 → 工具-防止agent造假通過驗收。
- 小任務不必這樣搞。改個錯字、明顯的一行修正，寫驗證條件的成本高於價值。
🔗 相關工具
- 工具-外科手術式修改 —— 同一份來源的另一條原則
- 工具-讓agent反過來拷問你 —— 那張處理「要做什麼」，這張處理「怎麼算做完」。先對齊目標再定驗收條件
- 工具-防止agent造假通過驗收 —— 有了可驗證的標準之後，下一個問題是怎麼防止它作弊達標
- 工具-紅綠重構循環 —— 「先寫會失敗的測試再讓它通過」正是這張卡的原型