分不清 /loop 與 /goal 何時用？Claude Code 新手看這篇就夠了

用咗 Claude Code 一段時間之後，你會發現個圈子入面有一種好奇怪嘅現象。

前腳，所有人都係咁瘋狂推薦你用 /goal，話呢個命令改變咗佢哋嘅工作方式，啲 post 截圖、使用心得、避坑指南洗版洗到傻。

後腳，個話題仲未凍，Loop Engineering 嘅浪潮又殺到，Claude Code 創辦人 Boris Cherny 親口話自己已經好耐冇手動 prompt Claude，全部靠寫 loop 嚟驅動。

跟住又有人周圍話要用 /loop，先係正確嘅工作方式。

一般遇到呢種情況，新手都會話，呢個都未搞掂，另一個新嘢又出嚟。

啲資訊迭代得真係好快～

不過呢篇文章，我唔打算講咩範式，又唔打算講咩理念，淨係做一件事。

就係幫你搞清楚 /loop 同 /goal 呢兩個命令，知道各自喺咩情況下用最適合。

先做個簡短總結：

/loop 係「定時器」，你話畀佢每隔幾耐做一次嘢。
/goal 係「終點線」，你話畀佢要做到咩程度先算完。

就呢兩句，你可以慢慢諗下。

先講 /loop

你可以當係俾 CC set 咗個「會重複響嘅鬧鐘」。

你話每五分鐘做一次呢件事，佢就會乖乖地跟住你嘅要求每五分鐘做一次，然後報告結果畀你。

佢係會話入面嘅功能，你 close 咗 terminal 佢就會停，任務最長可以存活三日，超過咗會自動清除。

佢最適合嘅場景係等待類、監控類、週期性檢查類。

總之你平時會坐喺度不斷 refresh、不斷手動 check 嘅嘢，都可以交畀 /loop 幫你睇住。

例如你啱啱 push 咗個新版本，等緊部署跑完，以前可能要每隔幾分鐘睇下個 terminal。

而家你可以咁寫：

/loop 每 5 分鐘，檢查一下 localhost:3000 有沒有響應，告訴我 HTTP 狀態碼是多少？

佢就會每五分鐘幫你去睇下，有結果就直接報畀你，你可以做你嘅嘢。

再例如你開咗個 PR，等同事 review，冇可能成日睇住 GitHub 刷新。可以咁樣：

/loop 每 10 分鐘，看看我當前的 PR 有沒有新的 review 評論，有的話幫我起草一下回復。

仲有一類場景係定期彙總。

你而家行緊一個 service，想每半個鐘睇下 log 有冇問題，你就可以咁講：

/loop 每 30 分鐘，掃一下 ./logs/app.log 裏最近三十分鐘的 FATAL 級別的報錯，整理出來告訴我。

呢度有個位要注意，亦係新手最開始成日搞亂嘅地方。

/loop 負責嘅只係「定時去睇下，然後彙報結果」，，唔係「幫你解決問題」。你叫佢每五分鐘 check 部署狀態，佢話畀你知「部署失敗咗」就完結。下一輪佢會繼續 check，唔會自己去 fix。

如果你想 CC 發現問題之後自動去搞，就係下面呢個命令嘅事。

再講 /goal

/goal 嘅邏輯同 /loop 完全唔同。

佢開工之前，你要俾個完成條件佢，做完一輪之後，會有一個獨立嘅細模型（Claude Haiku）出嚟判斷：條件達到未？未達到就繼續下一輪；達到咗就自動停，俾返控制權你。

成個過程唔使坐喺度不停咁話繼續。

佢適合嘅場景係有明確終點嘅任務。

例如重構一個 module、將個 API 由舊版本 migrate 去新版本、處理曬一批 files、將 tests 整到全部 pass。只要你講得清楚「做到咩樣先算完」，/goal 就可以接手。

但呢度有個關鍵，係新手用 /goal 失敗嘅最主要原因：一定要將條件寫到可以被驗證，唔可以寫成一個模糊嘅方向。

舉個反面例子，例如你咁寫：

/goal 優化一下這個模塊

CC 根本唔知咩叫「優化完」。佢可能改咗個 variable name 就覺得完成咗，亦可能一直 loop 唔知停喺邊度。

改做咁：

/goal 把 src/auth 目錄下所有調用 v1 接口的地方全部改成 v2，改完之後 npm test 要能全部通過，不能修改 test/ 目錄裏的任何文件，最多執行 25 輪。

呢個條件就清楚曬。

有可以 run 嘅驗收標準（npm test 全部通過），有邊界限制（唔可以改 test files），有輪次上限（最多 25 輪）。CC 每做完一輪，負責判斷嘅細模型就可以睇住 test results 做可行性驗證。

關於輪次上限，我建議你最好喺條件入面一定要加類似「最多執行 N 輪」呢啲限制。

點解？

假設你寫嘅條件有問題，或者個任務比預期複雜，CC 可能會不停 loop，咁你啲 token 就會一直流失，費用就會失控。

但如果你加咗呢個上限，最壞情況都只係去咗個輪次數自動停，你睇下再決定點搞。

判斷方法

而家俾你一個最簡單嘅判別方法。

先問自己一個問題：我要做嘅呢件事有冇一個可以被驗證嘅終點？

有終點，而且 CC 可以判斷係咪到達咗，就用 /goal。
冇終點，只係需要定時去睇下做監控、檢查或者彙總，就用 /loop。

如果兩種場景都存在嘅話，例如你想邊監控邊推進任務，可以組合用。

/loop 負責定時觸發，/goal 負責將每次觸發後嘅任務做完。

呢個就係目前用 Coding Agent 最流行嘅兩個命令嘅全部核心。

寫在最後

呢兩個命令本身其實唔難，邏輯都好簡單。

令新手覺得亂嘅，我反而覺得係個圈子嘅敍事節奏太快造成。

新功能啱啱上線，使用心得仲喺度傳播，新名詞、新範式又嚟。今日講 /goal，聽日跳到 Loop Engineering，後日可能又變第二個。

對於啱啱接觸或者啱啱開始學 Claude Code 或者其他 Coding Agent 嘅新手嚟講，呢種節奏可能會變成一種幹擾。

CC 老豆 Boris 唔係話過：「我而家絕大部分工作就係寫 loop」。

但你就唔好當真啦，佢已經將 /loop、/goal、hooks、skills、MCP 呢啲嘢玩到好透，佢哋始終係建立規則嘅人。

而對於新手嚟講，先搞得清楚 /loop 同 /goal 有咩分別、分別做咩、幾時用邊個，已經算冇落後。

工具係死嘅，用得順先至會變成你手上嘅武器。

既然睇到呢度，如果覺得唔錯，順手幫手㩒個「讚」、「在看」、「轉發」三連；如果想第一時間收到推送，都可以幫我加個星標★，非常多謝！

用 Claude Code 一段時間之後，你會發現圈子裏有一種特別奇怪的現象。

前腳，所有人都在瘋狂推薦你用 /goal，說這個命令改變了他們的工作方式，帖子截圖、使用心得、避坑指南刷了一波又一波。

後腳，話題還沒涼透，Loop Engineering 的浪潮又撲過來了，Claude Code 的創始人 Boris Cherny 親口說自己已經很長時間沒有手動提示過 Claude，全都靠寫循環來驅動。

再後來，有人又開始到處說要用 /loop，說這才是正確的工作方式。

一般遇到這種情況，新手都會說，這一個還沒整明白呢，另一個新玩意兒又出現了。

這信息迭代的也忒快了~

然而這篇文章，我不打算說什麼範式，也不打算講什麼理念，只做一件事兒。

就是幫你把 /loop 和 /goal 這兩個命令搞清楚，知道各自該在什麼情況下用最合適。

先做個簡要總結：

/loop 是「定時器」，你告訴它每隔多久去做一件事兒。
/goal 是「終點線」，你告訴它做到什麼程度才算完。

就這兩句話，你可以細品。

先說 /loop

你可以把它想象成給 CC 設了一個「會重複響的鬧鐘」。

你說每五分鐘把這件事做一下，那它就會乖乖地按照你的要求每五分鐘去做一次，然後把結果報告給你。

它是會話內的功能，你關掉終端它就停了，任務最長能存活三天，超過會自動清除。

它最適合的場景是等待類、監控類、週期性檢查類。

凡是你會坐在那裏不斷刷新、不斷手動去確認的事兒，都可以交給 /loop 來幫你盯着。

比如你剛推了一個新版本，等部署跑完，以前你可能需要每隔幾分鐘就要去看一眼終端。

現在你可以這麼寫：

/loop 每 5 分鐘，檢查一下 localhost:3000 有沒有響應，告訴我 HTTP 狀態碼是多少？

它就會每五分鐘去幫你探一次頭兒，有結果了直接報給你，你該幹嘛幹嘛去。

再比如你提了一個 PR，等同事來審查，總不能一直盯着 GitHub 刷新。可以這樣：

/loop 每 10 分鐘，看看我當前的 PR 有沒有新的 review 評論，有的話幫我起草一下回復。

還有一類場景是屬於定期彙總。

你當前跑着一個服務，想每半小時看一眼日誌裏有沒有出問題，你就可以這樣說：

/loop 每 30 分鐘，掃一下 ./logs/app.log 裏最近三十分鐘的 FATAL 級別的報錯，整理出來告訴我。

這裏有一個坑要注意，也是新手在最開始的時候特別容易搞混的地方。

/loop 負責的只是「定時去看一眼，然後彙報結果」，不是「幫你把問題解決掉」。你讓它每五分鐘檢查部署狀態，它彙報給你"部署失敗了"，就結束了。下一輪它還會繼續檢查，不會自己去修復。

如果你想讓 CC 發現問題之後自動去處理，那是下面這個命令的事兒了。

再來說 /goal

/goal 的邏輯跟 /loop 完全不同。

它開始幹活兒前，你需要給它一個完成條件，幹完一輪之後，會有一個獨立的小模型（ Claude Haiku）出來判斷：條件達到了沒？沒達到，繼續下一輪；達到了，自動停止，把控制權交還給你。

整個過程不需要你坐在那裏一遍又一遍的說繼續。

它適合的場景是有明確終點的任務。

比如重構一個模塊、把接口從舊版本遷移到新版本、把一批文件處理完、把測試修到全綠。只要你能說清楚「做到什麼樣算完」，/goal 就能接。

但這裏有個關鍵，是新手用 /goal 失敗的最主要原因，就是：一定要把條件寫得可以被驗證，不能寫成一個模糊的方向。

舉個反例，比如你這麼寫：

/goal 優化一下這個模塊

CC 壓根兒不知道什麼叫「優化完了」。它可能改了一個變量名就覺得自己完成了，也可能一直轉下去不知道停在哪裏。

換成這樣：

/goal 把 src/auth 目錄下所有調用 v1 接口的地方全部改成 v2，改完之後 npm test 要能全部通過，不能修改 test/ 目錄裏的任何文件，最多執行 25 輪。

這個條件就清楚了。

有可以運行的驗收標準（npm test 全部通過），有邊界約束（不能動測試文件），有輪次上限（最多 25 輪）。CC 每幹完一輪，那個負責判斷的小模型就能看着測試結果做可行性驗證了。

關於輪次上限，我建議你最好是在條件裏一定要加上類似於「最多執行 N 輪」這樣的約束。

為什麼？

假設你寫的條件有問題，或者任務比預期的要複雜，CC 可能會一直循環下去，那你的 token 就會一直在消耗，費用就會變得不可控了。

但如果你加上了這個上限，最壞的情況也就是到了輪次自動停，你來看一眼再決定怎麼辦。

判斷方法

現在給你一個最簡單的判別方法。

先問自己一個問題：我要做的這件事兒有沒有一個可以被驗證的終點？

有終點，而且 CC 能判斷有沒有到達，就用 /goal。
沒有終點，只是需要定時去看一眼做個監控、檢查或者彙總，就用 /loop。

如果兩種場景都存在的話，比如你想邊監控邊推進任務，可以組合用。

/loop 負責定時觸發，/goal 負責把每次觸發後的那個任務做完。

這就是目前在使用 Coding Agent 時最流行的兩個命令的全部核心了。

寫在最後

這兩命令本身其實並不難，邏輯也都很簡單。

讓新手感覺亂的，我到反而認為是圈子裏的敍事節奏太快造成的。

新的功能剛上線，使用心得還在傳播，新的名詞、新的範式就又來了。今天聊 /goal，明天跳到 Loop Engineering，後天可能又變成了另外一個。

對於剛接觸或者剛上手學習 Claude Code 或者其他 Coding Agent 的新手來說，這種節奏可能就變成了一種干擾。

CC 之父 Boris 不是說過麼："我現在的絕大部分工作就是寫循環"。

但你可別當真了，那是他已經把 /loop、/goal、hooks、skills、MCP 這些東西都玩兒的透透了，他們畢竟是建立規則的人。

而對於新手來講先能搞清楚 /loop 和 /goal 有什麼區別，分別幹什麼、什麼時候用哪個，就已經是沒掉隊了。

工具是死的，把它用順了才能成為你手上的武器。

既然看到這兒了，如果覺得還不錯，幫忙隨手點個「贊」、「在看」、「轉發」三連；如果想第一時間收到推送，也可給我加個星標★，非常感謝！