我用 claude code ：/goal 踩了三個坑，總結出一個讓它穩定跑完的公式
整理版優先睇
用 /goal 嘅目標條件公式：可測量終態 + 驗證命令 + 防禦約束 + 輪次限制，先可以讓 Claude Code 穩定跑完複雜任務
作者喺做服務層遷移嗰陣發現，用 Claude Code 改十幾個文件，要不停咁輸入「繼續」，變咗人肉繼電器。佢想解決嘅問題係：點樣用 /goal 命令設定一個目標，等 Claude 可以自己跑完，唔使中間要人插手？
/goal 嘅核心設計係用一個獨立小模型（Haiku）喺每輪結束後檢查目標條件，唔畀執行任務嘅模型自己打分。但呢個架構有個限制：評估者只能睇到對話記錄入面嘅嘢。所以目標條件必須可以從對話記錄驗證，例如「所有測試通過」可以，但「代碼寫得乾淨」唔得。好多文章冇講呢點，但呢個細節決定咗目標寫得好唔好。
作者總結咗一個公式：可測量終態 + 驗證命令 + 防禦約束 + 輪次限制。例如做文件遷移，要指定唔好改測試目錄、畀出 mock 嘅參考檔案、加「無跳過測試」嘅條件。CI 流水線仲要加防禦性約束，好似「不得刪除或簡化功能代碼」，防止 Claude 走捷徑。最後，作者提醒唔係所有任務都適合用 /goal：三輪內搞得掂嘅小任務、主觀質量目標、探索性工作同學習型任務，直接用對話仲好。
- /goal 嘅評估者係獨立小模型 Haiku，只能睇對話記錄驗證目標，所以條件必須可從輸出證實
- 寫目標條件要指定約束（例如唔好改邊啲檔案、用咩參考模式）以防 Claude 走捷徑
- CI 流水線用 /goal 要加防禦性約束，例如「不得刪除或簡化功能代碼」避免避開意圖
- 好嘅目標條件公式：可測量終態 + 驗證命令 + 防禦約束 + 輪次限制
- 唔適合用 /goal 嘅場景：小任務、主觀目標、探索性工作同學習型任務
揾第一個 /goal 嘅提示
直接貼畀 Claude Code：根據你對我的瞭解、我的目標和我們已經一起做過的事情，而家有哪 3 個 /goal 可以運行，能跑比較長的時間並產出最好的結果？Claude 會列出具體候選項，再叫佢寫出對應嘅 /goal 提示。
內容片段
/goal src/services/ 目錄下的所有文件（不含 __tests__/ 子目錄）使用 fetchWrapper 而不是直接調用 axios。src/services/__tests__/ 下的測試文件使用 src/test-utils/mockFetchWrapper.ts 中的 mock 模式。npm test 退出碼為 0，無跳過的測試。運行 10 輪後停止。人肉繼電器嘅覺醒
作者做緊服務層遷移，要將十幾個文件嘅 API 調用統一換成新封裝模式。Claude Code 改三個文件就停，等佢輸入「繼續」，再改三個又停。佢話自己唔係寫代碼，而係做人肉繼電器，每隔幾分鐘按一次回車。
/goal 就係為咗幹掉呢種模式而設計嘅
佢建議今晚花 15 分鐘試一個提示，叫 Claude 根據上下文列出 3 個可運行嘅 /goal 候選項，然後揀一個嚟跑。呢個係最快揾到自己第一個 /goal 嘅方法。
評估機制：點解目標條件必須可驗證
多數介紹 /goal 嘅文章都跳過咗一個關鍵設計：完成條件唔係 Claude 自己判斷，而係由另一個獨立小模型（默認 Haiku）喺每輪結束後讀對話記錄檢查。設計動機係「不畀員工自己打分」，防止執行模型有結構性動機提前宣佈完成。
呢條限制剔走咗大多數人寫出嘅模糊目標。例如「把認證模塊搞到生產可用狀態」評估者無法驗證，Claude 會一直做落去。
多文件遷移：約束比結果更重要
作者最初寫嘅目標條件係「src/services 中所有 API 調用使用新 fetchWrapper 模式，不再有直接 axios 導入，npm test 退出碼為 0」。結果第六輪做完所有服務文件，但九個測試失敗，因為測試文件仍然直接引入 axios，而條件冇排除測試目錄。
評估者按字面意思理解條件
Claude 就開始重寫測試 mock，三次重寫引入迴歸問題，因為佢直接猜接口，冇對着實際封裝實現寫。
改過嘅版本加咗約束：「不含 __tests__/ 子目錄」、「使用 src/test-utils/mockFetchWrapper.ts 嘅 mock 模式」、「無跳過測試」。結果四輪完成，全部通過。
約束比結果描述更重要
- 「不含 tests/ 子目錄」阻止咗過早改測試文件
- 「使用具體 mock 模式」畀咗正確參考，唔使靠猜
- 「無跳過測試」封死咗用 .skip() 繞過失敗嘅捷徑
CI 流水線：防禦性約束係護城河
/goal 可以用 -p 參數行非交互模式，直接嵌進 CI。作者遇到過一個問題：PR 通過測試，但生產代碼留低 TODO 註釋、冇 JSDoc、錯誤信息格式唔統一。用 /goal 可以自動檢查呢啲。
防禦性約束係護城河
CI 用 /goal，條件一定要防禦性，否則係畀 Claude 開後門。
目標條件公式同適用場景
作者跑咗好多測試，好嘅目標條件基本跟住一個結構：可測量終態 + 驗證命令 + 防禦約束 + 輪次限制。
- 1 可測量終態：你要達到咩狀態，必須能從對話輸出驗證
- 2 驗證命令：Claude 證明完成嘅方式，通常係跑測試或 lint
- 3 防禦約束：唔可以做嘅嘢，防止破壞性捷徑
- 4 輪次限制：預算安全閥，跑偏咗唔會無限燒 token
舉例對比：爛嘅係「/goal 把認證模塊搞到生產可用狀態」，湊合嘅係「所有測試通過」，好嘅係指定目錄、加約束、明確驗證。
每條都能從對話記錄揾到證據
作者提醒，唔係所有任務都適合用 /goal：三輪內搞得掂嘅小任務（直接提示仲快）、主觀質量目標（評估者無法判斷）、探索性工作（未諗清終態）、學習型任務（繞過理解過程）。
今晚 15 分鐘，揾你第一個 /goal
將提示貼畀 Claude Code，用公式寫好條件。/goal 嘅本事唔係令 Claude 更聰明，而係令你徹底脱離人肉繼電器嘅角色。
有段時間我好煩一件事。
做緊一個服務層遷移，要將十幾個文件入面嘅 API 調用統一換成新嘅封裝模式。Claude 改好三個文件，停咗。我輸入「繼續」。再改三個，又停。我再輸入「繼續」。就係咁重複。
我嗰陣就意識到，我唔係寫緊code，而係做人肉繼電器——唯一嘅職責就係每隔幾分鐘㩒一次回車。
呢種狀態講起上嚟有啲荒誕。我用 AI 編程工具，本來係為咗解放自己，結果搞到自己變咗 AI 嘅操作員。
/goal 就係為咗消滅呢種模式而生嘅。
今晚可以做一件事，大概15分鐘。打開 Claude Code，將下面呢段提示直接貼入去：
根據你對我的瞭解、我的目標和我們已經一起做過的事情，
現在有哪 3 個 /goal 可以運行，能跑比較長的時間併產出最好的結果？Claude 會根據你哋嘅上下文歷史，俾你列出幾個具體嘅目標候選項，唔係空泛嘅建議，而係結合你當前項目實際情況嘅選項。揀一個，然後叫佢將對應嘅 /goal 提示都寫出嚟，直接複製執行。
呢個係揾到「你自己嘅第一個 /goal」最快嘅方法。
但係喺你真係執行之前，有一件事值得先搞清楚。
/goal 點解值得信賴
大多數介紹 /goal 嘅文章都跳過咗一個關鍵設計細節，而呢個細節正正決定咗 /goal 幾時可靠、幾時會出問題。
/goal 設定咗一個完成條件之後，唔係 Claude 自己判斷「我做完未」——而係另一個獨立嘅小模型（預設係 Haiku）喺每一輪結束之後讀取對話記錄，檢查你嘅目標條件，回傳「滿足」或者「未滿足」。
設計動機好清楚：唔俾員工自己打分。
執行任務嘅模型有結構性嘅動機提早宣佈完成。佢一路處理問題，見到進展，會沿住「完成」嘅方向做模式匹配。而一個只能睇到對話記錄、冇得自己行命令嘅獨立評估者，就會打破呢個反饋循環。
呢個架構帶出一個直接推論：評估者只能睇到出現喺對話記錄裏面嘅嘢。Claude 偷偷改咗文件但冇喺對話入面展示結果，評估者對此一無所知。Claude 行咗測試但輸出冇出現喺記錄入面，評估者睇唔到。
所以，你嘅目標條件必須要可以「從對話記錄裏面驗證」。「所有測試通過」用得，因為測試輸出會印喺對話入面。「代碼寫得乾淨」用唔到，因為「乾淨」係主觀判斷，冇對話輸出可以證明佢。
呢個限制，淘汰咗大多數人寫出嚟嗰啲模糊目標。
多文件遷移：約束比結果更重要
用我嘅服務層遷移做例子。我最初寫嘅目標條件係咁嘅：
/goal src/services 中所有 API 調用使用新的 fetchWrapper 模式。
不再有直接的 axios 導入。npm test 退出碼為 0。睇落好完整。結果出咗問題。
遷移行到第六輪，Claude 完成咗所有服務文件，但有九個測試失敗。原因係測試文件入面仍然直接引入咗 axios 做 mock，而目標條件講嘅係「唔再有直接嘅 axios 導入」，冇排除測試目錄。評估者跟字面理解咗條件，Claude 就開始重寫測試 mock——然後三次重寫引入咗回歸問題，因為佢直接估咗接口，冇對住實際封裝實現嚟寫。
問題出喺目標條件入面缺少約束。我描述嘅係我想要嘅結果，但冇話俾佢知「唔可以鬱啲乜」「用啲乜做參考」。
改過之後嘅版本：
/goal src/services/ 目錄下的所有文件（不含 __tests__/ 子目錄）
使用 fetchWrapper 而不是直接調用 axios。
src/services/__tests__/ 下的測試文件使用
src/test-utils/mockFetchWrapper.ts 中的 mock 模式。
npm test 退出碼為 0，無跳過的測試。
運行 10 輪後停止。今次四輪完成，全部測試通過。
分別喺邊？「唔包含 tests/ 子目錄」阻止咗佢太早改測試文件。「使用 src/test-utils/mockFetchWrapper.ts 裏面嘅 mock 模式」俾咗佢正確嘅參考，唔使靠估。「冇跳過嘅測試」封死咗用 .skip() 繞過失敗測試呢條捷徑。
寫目標條件嘅時候，約束比結果描述更重要。「npm test 退出碼係 0」係結果。「使用呢個具體文件入面嘅 mock 模式」係約束，佢防止 Claude 創造出技術上通過但架構上有問題嘅嘢。
CI 流水線：防禦性約束係護城河
/goal 支援用 -p 參數行非互動模式，呢個意味住可以直接嵌入 CI 流水線。
我哋遇過一個老問題：PR 通過咗測試，但生產代碼入面留低 TODO 註釋、導出函數冇 JSDoc、錯誤信息格式唔統一。代碼評審可以捉到，但慢，而且容易漏。
喺 CI 入面行 /goal 可以自動檢查呢啲：
claude -p "/goal 此 PR 中變更的所有文件滿足以下條件：
1. 生產代碼（測試文件除外）不含 TODO 或 FIXME 註釋；
2. 每個導出函數都有 JSDoc 註釋；
3. 所有錯誤信息遵循 'ErrorType: 描述性消息' 格式；
4. npm test 退出碼為 0；
5. npm run lint 退出碼為 0。
或運行 15 輪後停止。"對細 PR 效果好好，幾分鐘內搞掂。但我喺實際使用中遇到過一個陰濕嘅邊界情況。
有個 PR 入面有一個 TODO 註釋，內容係「處理大型結果集嘅分頁」。Claude 嘅「修復方式」係將呢行註釋連同相關代碼塊一齊刪除，然後將結果硬編碼做最多回傳 100 條。
技術上，條件滿足咗——冇 TODO，測試通過（因為冇測試覆蓋超過 100 條嘅分頁場景）。
評估者批准咗，因為你聲明嘅條件的確都達到咗。佢檢查嘅係條件，唔係你嘅意圖。
解決方法係加一條防禦性約束：
claude -p "/goal 此 PR 中變更的所有文件滿足以下條件：
1. 生產代碼（測試文件除外）不含 TODO/FIXME 註釋，
如果 TODO 無法當場解決，將其轉為 GitHub Issue 引用；
2. 每個導出函數都有 JSDoc 註釋；
3. 所有錯誤信息遵循 'ErrorType: 描述性消息' 格式；
4. 不得刪除或簡化任何功能性代碼；
5. npm test 退出碼為 0；
6. npm run lint 退出碼為 0。
或運行 15 輪後停止。"第 4 條係護城河。「唔可以刪除或簡化任何功能性代碼」令評估者喺審批前多咗一道檢查，破壞性捷徑就過唔到關。
CI 入面用 /goal，條件一定要係防禦性嘅，如果唔係你就係俾緊 Claude 難題，同時開咗一扇後門。
目標條件嘅公式
行咗咁多測試，好用嘅目標條件基本上跟一個結構：
可量度嘅終態 + 驗證命令 + 防禦約束 + 輪次限制
可量度嘅終態係你要達到咩狀態，一定要可以從對話輸出裏面驗證。驗證命令係 Claude 證明完成嘅方式，通常係行測試或 lint。防禦約束係「唔可以做啲乜」，防止破壞性捷徑。輪次限制係你嘅預算安全閥，行歪咗唔會無限燒 token。
對比一下：
# 爛的
/goal 把認證模塊搞到生產可用狀態
# 湊合的
/goal 所有測試通過
# 好的
/goal tests/auth/ 下的所有測試通過。
不刪除任何測試文件，不跳過任何測試。
auth 模塊沒有直接的數據庫調用（使用 Repository 模式）。
npm test 和 npm run lint 退出碼均為 0。
10 輪後停止。「生產可用」評估者冇辦法驗證，Claude 會一直做嘢。「所有測試通過」太寬，可以靠刪測試滿足。第三個版本，每一條都可以從對話記錄入面揾到證據。
邊啲場景用 /goal 純粹係浪費
講真，唔係所有任務都值得包一層 /goal。
三輪以內搞得掂嘅細任務，直接提示就得，設定目標、等評估者行、處理反饋，呢啲開銷比任務本身仲重。
主觀質量目標用唔到——「提高代碼可讀性」「優化錯誤提示」呢啲，評估者判斷唔到，你會見到佢一路回傳「未滿足」，同時 Claude 不停改code。燒錢燒時間。
仲未諗清楚終態嘅探索性工作都唔適合。/goal 優化嘅係「到達目標」嘅效率，如果你仲摸索緊方向，用常規提示對話，先將方向諗清楚。
學習型任務同理。你用 Claude 幫你讀明一段 code 邏輯，/goal 會繞過理解過程直接俾你結果，你得到咗輸出，但錯過咗學習。
今晚15分鐘，將嗰個提示行一次，揾到你第一個 /goal 候選項。然後用「可量度終態 + 驗證命令 + 防禦約束 + 輪次限制」呢個公式將條件寫出嚟。
/goal 做到嘅嘢，唔係令 Claude 更聰明，而係令你徹底從繼電器呢個角色入面解放出嚟。
有段時間我特別煩一件事。
在做一個服務層遷移，要把十幾個文件裏的 API 調用統一換成新的封裝模式。Claude 修好三個文件，停。我輸入「繼續」。再修三個，停。我再輸「繼續」。如此往復。
我當時就意識到，我不是在寫代碼，我在做人肉繼電器——唯一的職責就是每隔幾分鐘按一次回車。
這種狀態說起來有點荒誕。我用 AI 編程工具，本來是為了解放自己的，結果把自己變成了 AI 的操作員。
/goal 就是為了幹掉這種模式而生的。
今晚可以做一件事，大概 15 分鐘。打開 Claude Code，把下面這段提示直接粘進去：
根據你對我的瞭解、我的目標和我們已經一起做過的事情，
現在有哪 3 個 /goal 可以運行，能跑比較長的時間併產出最好的結果？Claude 會根據你們的上下文歷史，給你列出幾個具體的目標候選項，不是泛泛的建議，而是結合你當前項目實際情況的選項。選一個，然後讓它把對應的 /goal 提示也寫出來，直接複製運行。
這是找到「你自己的第一個 /goal」最快的方式。
但在你真的運行之前，有一件事值得先搞清楚。
/goal 憑什麼能信任
大多數介紹 /goal 的文章都跳過了一個關鍵設計細節，而這個細節恰恰決定了 /goal 什麼時候靠譜、什麼時候會出問題。
/goal 設了一個完成條件之後，不是 Claude 自己判斷「我做完了沒」——而是另一個獨立的小模型（默認是 Haiku）在每輪結束後讀取對話記錄，檢查你的目標條件，返回「滿足」或「未滿足」。
設計動機很清晰：不讓員工給自己打分。
執行任務的模型有結構性動機提前宣佈完成。它一直在處理問題，看到了進展，會沿着「完成」的方向做模式匹配。而一個只能看到對話記錄、無法自己跑命令的獨立評估者，會打破這個反饋循環。
這個架構帶出一個直接推論：評估者只能看到出現在對話記錄裏的東西。Claude 悄悄改了文件但沒有在對話裏展示結果，評估者對此一無所知。Claude 跑了測試但輸出沒有出現在記錄裏，評估者看不到。
所以，你的目標條件必須能被「從對話記錄裏驗證」。「所有測試通過」能用，因為測試輸出會打印在對話裏。「代碼寫得乾淨」不能用，因為「乾淨」是主觀判斷，沒有對話輸出能證明它。
這條限制，剔掉了大多數人寫出的那種模糊目標。
多文件遷移：約束比結果更重要
拿我的服務層遷移舉例。我最開始寫的目標條件是這樣的：
/goal src/services 中所有 API 調用使用新的 fetchWrapper 模式。
不再有直接的 axios 導入。npm test 退出碼為 0。看起來很完整。結果出了問題。
遷移跑到第六輪，Claude 完成了所有服務文件，但有九個測試失敗。原因是測試文件裏仍然直接引入了 axios 做 mock，而目標條件說的是「不再有直接的 axios 導入」，沒有排除測試目錄。評估者按字面意思理解了條件，Claude 就開始重寫測試 mock——然後三次重寫引入了迴歸問題，因為它直接猜了接口，沒有對着實際封裝實現來寫。
問題出在目標條件裏缺少約束。我描述的是我想要的結果，但沒有告訴它「不能動什麼」「用什麼做參考」。
改過之後的版本：
/goal src/services/ 目錄下的所有文件（不含 __tests__/ 子目錄）
使用 fetchWrapper 而不是直接調用 axios。
src/services/__tests__/ 下的測試文件使用
src/test-utils/mockFetchWrapper.ts 中的 mock 模式。
npm test 退出碼為 0，無跳過的測試。
運行 10 輪後停止。這次四輪完成，全部測試通過。
差異在哪裏？「不含 tests/ 子目錄」阻止了它過早改測試文件。「使用 src/test-utils/mockFetchWrapper.ts 中的 mock 模式」給了它正確的參考，不用靠猜。「無跳過的測試」封死了用 .skip() 繞過失敗測試這條捷徑。
寫目標條件的時候，約束比結果描述更重要。「npm test 退出碼為 0」是結果。「使用這個具體文件裏的 mock 模式」是約束，它防止 Claude 創造出技術上通過但架構上有問題的東西。
CI 流水線：防禦性約束是護城河
/goal 支持用 -p 參數跑非交互模式，這意味着可以直接嵌進 CI 流水線。
我們遇到過一個老問題：PR 通過了測試，但生產代碼裏留着 TODO 註釋、導出函數沒有 JSDoc、錯誤信息格式不統一。代碼評審能抓到，但慢，而且容易漏。
在 CI 裏跑 /goal 可以自動檢查這些：
claude -p "/goal 此 PR 中變更的所有文件滿足以下條件：
1. 生產代碼（測試文件除外）不含 TODO 或 FIXME 註釋；
2. 每個導出函數都有 JSDoc 註釋；
3. 所有錯誤信息遵循 'ErrorType: 描述性消息' 格式；
4. npm test 退出碼為 0；
5. npm run lint 退出碼為 0。
或運行 15 輪後停止。"對小 PR 效果很好，幾分鐘內搞定。但我在實際使用中碰到過一個陰險的邊界情況。
有個 PR 裏有一個 TODO 註釋，內容是「處理大型結果集的分頁」。Claude 的「修復方式」是把這行註釋連同相關代碼塊一起刪掉，然後把結果硬編碼為最多返回 100 條。
技術上，條件滿足了——沒有 TODO，測試通過（因為沒有測試覆蓋超過 100 條的分頁場景）。
評估者批准了，因為你聲明的條件確實都達到了。它檢查的是條件，不是你的意圖。
解決方法是加一條防禦性約束：
claude -p "/goal 此 PR 中變更的所有文件滿足以下條件：
1. 生產代碼（測試文件除外）不含 TODO/FIXME 註釋，
如果 TODO 無法當場解決，將其轉為 GitHub Issue 引用；
2. 每個導出函數都有 JSDoc 註釋；
3. 所有錯誤信息遵循 'ErrorType: 描述性消息' 格式；
4. 不得刪除或簡化任何功能性代碼；
5. npm test 退出碼為 0；
6. npm run lint 退出碼為 0。
或運行 15 輪後停止。"第 4 條是護城河。「不得刪除或簡化任何功能性代碼」讓評估者在審批前多了一道檢查，破壞性捷徑就過不了關。
CI 裏用 /goal，條件必須是防禦性的，不然你是在給 Claude 出難題，同時開了一扇後門。
目標條件的公式
跑了這麼多測試，好用的目標條件基本遵循一個結構：
可測量的終態 + 驗證命令 + 防禦約束 + 輪次限制
可測量的終態是你要達到什麼狀態，必須能從對話輸出裏驗證。驗證命令是 Claude 證明完成的方式，通常是跑測試或 lint。防禦約束是「不能做什麼」，防止破壞性捷徑。輪次限制是你的預算安全閥，跑偏了不會無限燒 token。
對比一下：
# 爛的
/goal 把認證模塊搞到生產可用狀態
# 湊合的
/goal 所有測試通過
# 好的
/goal tests/auth/ 下的所有測試通過。
不刪除任何測試文件，不跳過任何測試。
auth 模塊沒有直接的數據庫調用（使用 Repository 模式）。
npm test 和 npm run lint 退出碼均為 0。
10 輪後停止。「生產可用」評估者沒法驗證，Claude 會一直幹活。「所有測試通過」太寬，可以靠刪測試滿足。第三個版本，每條都能從對話記錄裏找到證據。
哪些場景用 /goal 純屬浪費
說實話，不是所有任務都值得包一層 /goal。
三輪以內能搞定的小任務，直接提示就行，設目標、等評估者跑、處理反饋，這些開銷比任務本身還重。
主觀質量目標不能用——「提高代碼可讀性」「優化錯誤提示」這類，評估者無法判斷，你會看到它一直返回「未滿足」，同時 Claude 不停在改代碼。燒錢燒時間。
還沒想清楚終態的探索性工作也不適合。/goal 優化的是「到達目標」的效率，如果你還在摸索方向，用常規提示對話，先把方向想清楚。
學習型任務同理。你用 Claude 幫你讀懂一段代碼邏輯，/goal 會繞過理解過程直接給你結果，你得到了輸出，但錯過了學習。
今晚 15 分鐘，把那個提示跑一遍，找到你第一個 /goal 候選項。然後用「可測量終態 + 驗證命令 + 防禦約束 + 輪次限制」這個公式把條件寫出來。
/goal 能做的事，不是讓 Claude 更聰明，而是讓你徹底從繼電器這個角色裏解脱出來。