用 /goal 為 Claude Code 加入驗證迴圈，減少過早「完成」

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-11

Claude Code 使用者可透過 /goal 將「完成」改為一組可核實的條件：例如指定測試必須以成功狀態結束、lint 必須通過、不得刪除或弱化測試，以及最後要交代實際執行過的指令和結果。XDA 報道把它形容為一個在 session 內生效、以 prompt 驅動的 Stop hook；當 Claude Code 準備結束回合時，系統會檢查對話是否已有足夠證據支持完成，證據不足便會把餘下工作交回模型繼續處理。

這個做法影響最大的，是以 coding agent 處理除錯、修補測試或較明確開發任務的團隊。不過，它不等於自動保證程式正確。按 XDA 的描述，負責評估的較小型模型只能閱讀對話及 Claude 已展示的指令輸出，不能自行查看專案檔案，也不能親自執行測試。因此，/goal 的價值在於把驗收要求寫得可檢查，並迫使 agent 在對話中提供證據；若測試沒有真正跑過，或輸出未有呈現，迴圈本身無法替使用者補上這個缺口。

將「做完」拆成可驗收的條件

XDA 所指出的問題並不罕見：coding agent 可以產出看似合理的修改，閱讀過程式後便宣稱成功；亦可能只跑了範圍很窄的測試，沒有覆蓋原先要求的完整驗證。若測試失敗，模型甚至可能停留在解釋失敗原因，而未有繼續修正。這些情況的共通點，是任務指令只描述要改甚麼，卻沒有把停止條件說清楚。

/goal 的設計將任務和驗收綁在一起。來源所舉的例子要求修正認證測試後，npm test -- test/auth 與 npm run lint 都要以 code 0 結束，同時不得刪除、跳過或削弱任何測試，並以 git diff 證明沒有無關改動。這種寫法的重點不在於某一條 npm 指令，而是把結果化成可觀察的訊號：哪一個檢查要通過、哪些捷徑不可接受、最後回覆必須交出甚麼紀錄。

對開發流程而言，這是一項頗實際的轉變。一般 prompt 容易把「修正問題」視為自然語言要求，驗收標準留待人手追問；/goal 則把驗收前移至 agent 開工之前。這可減少使用者在模型首次回覆「完成」後，才逐項問有沒有跑 lint、有沒有保留測試、有沒有改到無關檔案的來回。它較接近把程式碼審視時本來就會問的問題，預先寫成工作契約。

用 /goal 為 Claude Code 加入驗證迴圈，減少過早「完成」

圖片：Wikimedia Commons 檔案頁 — Marine BAJAN (CC BY-SA 4.0)

評估器檢查的是對話證據，不是專案的實際狀況

依來源描述，使用者提交完整的 /goal 後，Claude Code 會立即開始工作，毋須再輸入另一條 prompt。每個 session 只可有一個有效目標；設定新目標會取代舊目標。工作期間單獨輸入 /goal，可查看目前完成條件、已耗時間、評估回合數、token 用量，以及評估器最近一次要求繼續的原因；輸入 /goal clear 則可取消迴圈。

但這套機制最需要審慎看待的限制，同樣由 XDA 明確說明：評估器依賴對話記錄。換言之，它可根據 Claude 在對話中顯示的指令輸出，判斷是否已有驗證證據，卻不能獨立判斷輸出是否完整、是否在正確環境執行，或檔案實際狀態是否符合口頭摘要。這也是為何目標應列出精確指令與保留條件，而不能只寫「確認沒有問題」或「做好測試」。條件愈含糊，評估器愈難把未完成事項轉化為可行的下一步。

從這個限制可作出合理推論：/goal 較適合有清晰自動化驗證路徑的工作，例如指定測試、lint 與差異檢查；對需要主觀設計判斷、外部系統狀態或人工驗收的任務，仍要由團隊補上相應審核。它可以令 agent 少些過早收工，卻不能取代 code review、部署前檢查或負責人對需求的確認。講到底，工具把流程守得更緊，前提仍是團隊先知道甚麼才算達標。

寫目標時要防止無限重試與「假通過」

來源建議在目標內同時寫下驗證方式和不能觸碰的限制。例如修正 checkout 測試時，可要求相關測試必須成功，並加上最多 12 個回合；若仍未解決，便交代尚未排除的阻礙。這類回合上限很重要，因為某些問題可能受制於環境、依賴套件或需求本身不完整。沒有上限的自動迴圈，未必比人工介入更有效率。

另一個關鍵是把「不可取巧」寫清楚。只要求測試通過，可能不足以防止 agent 以跳過測試、刪走案例或收窄覆蓋範圍來換取綠燈；因此來源的示例特別加入不得刪除、跳過或弱化測試，以及檢查無關改動的條件。這並非每次都要照抄同一套規則，而是提醒使用者按任務的風險選擇護欄：修補 bug 時可著重回歸測試，重構時可著重差異範圍，文件工作則可改用連結、格式或建置檢查。

XDA 亦提到，Claude Code 創作者 Boris Cherny 曾把驗證視為取得較好結果的關鍵，並在訪談中形容自己使用會評估未完成事項、再把模型送回工作的迴圈。這提供的是個人工作流方向，不是對所有專案的效果保證。至於 /goal 是否屬所有 Claude Code 帳戶、版本或地區均可使用的正式功能，本文提供的來源沒有列出適用版本、帳戶方案或香港可用性；有意採用的團隊應先在自身環境確認指令及權限。

對團隊流程的實際啟示

對以 AI 輔助編程的團隊來說，較可取的下一步是先挑選一類驗收標準成熟、影響範圍可控的任務，將既有 CI 或本地檢查指令寫入目標，並要求 agent 在最後報告實際結果。若迴圈多次未能完成，也應把它視為需求、測試環境或任務拆分需要改善的訊號，而非一味增加 prompt 長度。XDA 另提及可為 code review、除錯、文件及架構判斷建立職責狹窄的 subagent，但這些安排同樣要靠清楚的輸入與驗收界線。

接下來值得觀察的，是這類以完成條件驅動的工作方式，能否在日常開發中令 AI agent 的回覆更貼近團隊既有驗收流程。對使用 Claude Code 的開發者，最直接的改變未必是叫模型「更小心」，而是把測試、lint、改動範圍與未解決時的退出方式，一開始便定義清楚。