Claude Code /goal 完整教學 — 設一個完成條件，讓 AI 自己跑到目標達成才停

先別管 /goal 能拿來做什麼。先看它每一輪做完之後，第一件事是去找誰。

答案有點出乎意料：它去找一個「快速模型」當裁判，問一個是非題——「你剛剛設的那個條件，現在成立了嗎？」如果裁判說還沒，Claude 不會像平常那樣把控制權交還給你、停在那裡等你下一句話，而是自己再開一輪繼續做。成立了，這個 goal 才自動解除。

整個 /goal 的魔法，全在這個「每輪結束問一次裁判」的迴圈裡。把這顆齒輪看懂，剩下的就都是它的推論。

先拆第一個零件：什麼叫「完成條件」

平常你跟 Claude 講話，給的是動作——「跑一下測試」「把這個函式改掉」。/goal 要你給的是另一種東西：一個終點的描述。

官方文件給的範例長這樣：

1	> /goal all tests in test/auth pass and the lint step is clean

讀一下這句話的結構。它沒有叫 Claude 做任何具體動作，它描述的是「事情做完之後，世界會長什麼樣子」——test/auth 底下所有測試都過、lint 那關是乾淨的。這是一個可以被驗證真假的狀態，不是一串待辦清單。

這個差別是整個機制的地基。因為裁判要能判「到了沒」，那個條件就必須是它有辦法檢查真假的東西。「把程式碼寫好看一點」沒辦法當完成條件——裁判沒有客觀標準去說它成不成立。「所有測試通過」可以——跑一下，紅的還是綠的，一翻兩瞪眼。

再拆第二個零件：每一輪的那個裁判

這裡是 /goal 跟你直覺裡的「自動模式」最不一樣的地方，所以要講清楚。

你可能會想：那它不就是一直跑、跑到我喊停為止？不是。它的迴圈是有閘門的。每跑完一輪，系統不會直接讓 Claude 衝下一輪，而是先抽出一個快速、便宜的模型，把當前的狀態和你設的條件擺在它面前，讓它做一次判斷。判斷的結果只有兩種走向：成立，整件事收工、goal 清掉；不成立，才放行下一輪。

為什麼要特別找個「快速模型」來當這個裁判，而不是讓主力模型自己順手判？這裡藏著一個務實的成本考量。檢查「測試過了沒」這種是非題，不需要動用最強的腦力，殺雞用不著牛刀。用一個便宜的模型專門做這件事，等於在迴圈裡塞了一個低成本的守門員——它的工作不是解題，是回答一個是非題，所以可以又快又省。

把這兩個零件合起來，你就得到 /goal 的完整心跳：做一輪 → 裁判檢查 → 沒到就再做一輪 → 到了就停。 它不是一頭悶著跑的蠻牛，是一個邊做邊回頭確認「我到了沒」的東西。

拆完零件，反推它到底解了什麼問題

現在零件都攤在桌上了，回頭看它替你省掉的那件事，就很清楚了。

以前你做一件「要反覆試到對為止」的工作——比方把一個模組遷移到新的 API，過程是這樣的：Claude 改一版，你叫它跑測試，它跑完報告「還有三個紅的」，你說「那繼續修」，它再改，你再叫它跑……你變成了那個迴圈裡的傳令兵，每一輪都要靠你按一下「繼續」，它才肯動下一步。

/goal 做的事，是把「按繼續」這個動作，從你手上接走，交給那個裁判。終點還是同一個終點，但中間那幾十次「跑一下、還沒、再來」的來回，不再需要你坐在那裡當人肉節拍器。你設好終點就可以去做別的事，它自己會一輪一輪逼近，到了才回來找你。

這就是這個功能真正的價值：它把你從「監工」的位置上釋放出來。你的注意力本來被綁在那個低階迴圈上，現在可以挪去想真正值錢的事——比如，這個遷移的方向對不對。

那它跟 /loop、跟自動模式差在哪

Claude Code 裡有幾個聽起來很像、但解的是不同問題的東西，混在一起會用錯，分清楚很重要。

/goal 看的是「條件」。 它停不停，取決於那個可驗證的終點有沒有到。沒到，它可以跑很多輪；到了，它一輪都不多跑。

/loop 看的是「時間」。 它是按你給的間隔重複跑某件事（你不給間隔，它會自己抓個節奏）。它的停止點是你喊停，不是某個狀態成立。適合的是「每隔一段時間去做一次」這種週期性的事，不是「做到對為止」。

自動模式（auto mode）看的是「權限」。 它解的是另一個層次的問題——當 Claude 要做某個動作時，由一個分類器決定這個動作安不安全、要不要放行，讓安全的操作不用每次都跳出來問你 yes/no。它管的是「這一步能不能做」，不是「整件事做完了沒」。

一句話收：要它做到某個狀態成立用 /goal，要它週期性地重複用 /loop，要它別每三秒問你一次權限用自動模式。三個是不同的工具，不是三個名字的同一個東西。

用之前該知道的幾件事

/goal 是在 5 月 11 到 15 那週、v2.1.139 進來的，在互動模式、-p 命令模式、還有手機端的 Remote Control 都能用。意思是你可以在電腦上設好一個 goal，闔上筆電，讓它在背景一輪一輪跑。

但有個地雷得先講：整個機制的可靠度，押在你那句完成條件寫得好不好。 條件寫得模糊，裁判就判得模糊——你寫「讓程式碼變乾淨」，它可能跑兩輪就覺得「夠乾淨了」收工，也可能永遠覺得不夠、空轉燒錢。條件要寫成那種「跑一個指令、看一個明確結果」就能驗真假的形式：測試通過、某個檔案編譯得過、某個指令回傳 0。越接近一個能被機器跑出是非的判斷，這個迴圈就越聽話。

還有一點要老實說：這是相對新的功能，上面講的機制是依官方 digest 的描述整理的，我自己拿它跑過小範圍的遷移，但沒有壓過那種要連跑幾十輪的大工。真要把它放進你的日常流程前，先拿一個你已經知道答案、終點很明確的小任務試一遍，看裁判判得準不準，再決定要不要信任它去跑大的。

收尾：值錢的不是那個指令，是你被逼著學會的那件事

繞了一圈回到最前面那個裁判。

/goal 表面上是個讓 AI 自己跑迴圈的便利功能，但它真正逼你練的，是一個更底層的本事：把一個模糊的目標，翻譯成一個機器能裁決真假的條件。 「把這個模組弄好」沒辦法交給它，但「所有呼叫點都編譯得過、測試全綠」可以。前者是願望，後者是規格。

而這件事的用處，遠不只在 Claude Code 裡。你會發現，凡是你能把一個目標講成「怎樣算完成」的明確條件，這個目標就變得可以自動化、可以託付、可以驗收；凡是你只能含糊地說「做好一點」，它就只能繼續卡在你手上、靠你一輪一輪盯。/goal 給了你一個練這件事的場子——下次你想把任何事交出去之前，先試著回答那個裁判會問的問題：「到底，怎樣才算到了？」答得出來的事，你就有機會放手；答不出來的，先別急著怪工具不夠聰明。