AI 不再需要你一步步帶：/goal 讓模型自己跑完全程

本文整理自《The AI Daily Brief》2026 年 5 月播出的單集。

---

為什麼你總是在幫 AI 按「繼續」

如果你經常使用 Claude Code 或 OpenAI Codex 這類程式開發代理工具，你一定很熟悉這種情境：AI 做完一步就停下來等你確認，你說「繼續」，它再做一步又停下來，你再說「繼續」。有些比較長的任務，你可能要按二三十次「繼續」才能看到最終結果。

AI Daily Brief 的主持人 NLW（Nathaniel Whittemore）把這叫做一問一答的「困局」。更早之前，社群甚至發明了一種叫做「Ralph Wiggum 迴圈」的技巧，本質上就是一種讓 AI 自己不斷按下「繼續」按鈕的 DIY 方法。這很笨，但有效，因為它解決了一個真實的痛點：很多工作的本質是序列性的，每一步的下一步取決於上一步學到了什麼，但人類不需要在每一步之間插手。

/goal 就是這個痛點的正式解法。它不是一個更聰明的 prompt，而是一種不同類型的互動機制。你定義目標和完成標準，AI 自己迴圈執行、自我評估、判斷該繼續還是停止。

/goal 的運作機制：自主迴圈與自我評估

Codex 團隊成員 Tebow 在 5 月初推文宣布：「/goal 可能是我們在 Codex 中推出過最具影響力的功能。」Pavel Huren 進一步解釋了運作方式：「你描述想要的結果，模型開始迴圈、自我評估，完成後自動停止。」

具體來說，當你輸入 /goal 並描述你的目標後，AI 進入一個持續的迴圈。每完成一步，它會做三件事：第一，檢查目前的進度是否滿足你定義的終點線；第二，如果還沒滿足，決定下一步該做什麼；第三，如果判斷自己真的卡住了、沒有合理的路徑可以前進，就停下來告訴你。整個過程中你不需要介入。

這個機制跟一般 prompt 的差異在於：prompt 是「給一個指令，得到一個回應」的單次交換；/goal 則是一個持續性的迴圈，AI 自己判斷什麼時候算完。前 OpenAI 共同創辦人、目前在 Anthropic 工作的卡帕西（Andrej Karpathy）用他的「自動研究迴圈」實驗印證了這個概念：「大型語言模型在朝特定目標迴圈執行這件事上表現得極為出色。不要告訴它該做什麼，給它成功標準，然後看著它跑。」

但這不代表你失去了控制權。/goal 保留了完整的生命週期指令：/goal pause 可以暫停、/goal resume 可以恢復、/goal clear 可以清除。如果你發現 AI 走的方向不對，或者成功標準需要調整，你隨時可以介入而不必丟棄已完成的工作。目標和所有累積的脈絡都住在同一個對話串裡（monothread 模式），不依賴全域記憶或專案層級的設定。

怎麼寫一個好的 /goal：六大要素拆解

寫好 /goal 跟寫好 prompt 是不同的技能。OpenAI 的官方指南文件指出，最有效的 goal 通常定義清楚六件事情，而這六件事情加在一起構成了 NLW 所說的「終點線合約」。

第一個要素是結果定義。你要說清楚，當工作完成的時候，什麼狀態應該為真。這不是「做什麼事」，而是「什麼事應該被做完」。差異看似微妙，但它決定了 AI 能不能自我判斷任務是否完成。「重構這個模組」是做什麼事；「這個模組的所有公開方法都有單元測試、測試覆蓋率達到 85%、原有的整合測試全部通過」是完成狀態。

第二個要素是驗證面。你的目標需要有 AI 可以自行檢查的證據。可能是能跑過的測試、能建置成功的頁面、可以查核的引用來源、或者有具體格式的產出物。如果完成與否只能靠「感覺」來判斷，/goal 就沒辦法好好運作。

第三個要素是約束條件。告訴 AI 在追求目標的過程中，什麼不能被破壞。比如「不能改動 public API 的介面」、「現有的測試不能因為你的修改而失敗」、「不能引入新的相依套件」。這些護欄讓 AI 在自主探索時不會不小心拆了你不想拆的東西。

第四個要素是邊界設定。明確告訴 AI 它能碰哪些檔案、用哪些工具、存取哪些資源。沒有邊界的自主執行可能會讓 AI 跑去改不該改的地方。

第五個要素是迭代策略。當 AI 完成一步之後，它應該怎麼決定下一步？是先跑測試看看哪裡還不過？還是先檢查覆蓋率報告找出缺口？這個策略幫助 AI 做出更聰明的下一步選擇，而不是盲目亂試。

第六個要素是阻斷停止條件。什麼情況下 AI 應該承認「我做不到」而停下來？這很重要，因為沒有這個條件的話，AI 可能會在一個死胡同裡無限迴圈。

範圍拿捏：太窄不行，太寬也不行

除了六大要素之外，目標的範圍（scope）也需要仔細拿捏。NLW 稱之為「金髮女孩區間」，意思是存在一個恰到好處的中間地帶。

太窄的目標，例如「修好第 47 行的 null pointer exception」，問題在於真正的根因可能不在第 47 行，而是在呼叫它的某個上游函式裡。如果你把目標定得太窄，AI 就算修好了這一行，可能只是貼了一個 OK 繃而沒有治好病根。但太寬的目標，例如「改善整個系統的穩定性」，問題在於你根本無法定義具體的完成證據。什麼叫「穩定」？穩定到什麼程度算完成？AI 沒辦法用這種模糊的標準來自我評估。

好的範圍介於兩者之間：「找出並修復導致結帳流程在高併發下出現 race condition 的原因，確保壓力測試在 100 個並行連線下連續跑 10 分鐘不出錯。」這既給了 AI 足夠的彈性去探索問題的根源，又提供了具體到可以自動驗證的完成標準。

產出物的定義精確度同樣重要。「幫這個功能寫文件」是弱定義，因為 AI 不知道什麼程度的文件算「寫完了」。但「產出一個文件頁面，用兩個範例說明 lifecycle 指令的使用方式，驗證頁面可以在本機建置成功，確認所有參考指令都符合目前 CLI 的實際行為」就是強定義，每一個條件都可以被檢驗。

不只是程式開發：知識工作的十個應用方向

NLW 認為 /goal 的價值不限於寫程式。他的判斷標準是：當你想要的產出不只是一個答案，而是一份稽核時，/goal 就可能適用。他列出了十個知識工作領域：文獻回顧、市場版圖、供應商評估、盡職調查、聲明稽核、政策研究、訪談綜合整理、時間線重建、試算表稽核、以及策略備忘錄。

這些領域的共通點是：產出物應該是一份紀錄，清楚交代什麼被檢查了、什麼被證實、什麼被反駁、什麼仍然存疑。這種稽核型的結構讓 AI 可以自我評估完成度，因為它能對照自己的產出物看看還有沒有未查核的聲明、未標註信心水準的結論、或是缺少引用來源的判斷。

拿聲明稽核來舉例：「逐一稽核這份備忘錄中的每個聲明。針對提供的來源和可靠外部來源進行驗證。最後產出一張表格，將每個聲明標記為『已證實』、『被反駁』、『部分證實』或『未經驗證』，附上引用出處和不確定性註記。」這就是一個完整的 /goal：有明確的結果定義、有可檢驗的產出物格式、有品質標準（每個結論都必須追溯到證據），AI 可以清楚判斷自己什麼時候算做完了。

知識工作跟程式開發有一個重要差異：定義成功的人不一樣。程式碼有測試可以跑，有基準報告可以量，成功標準往往是客觀的。但聲明稽核要查到什麼程度算完整？市場版圖分析要涵蓋多少家公司才算全面？這些標準只有你自己才能定義。NLW 觀察到，知識工作的 /goal 最常見的模式是「使用者提供成功判準」：你的招聘偏好、你的投資標準、你的編輯方針，這些就是 AI 自我評估時要對照的終點線。

我的觀察：/goal 能力的上限取決於你定義問題的能力

用了一段時間之後，我覺得 /goal 最大的挑戰不在於技術，而在於人。這個工具要求你在開始之前就想清楚：「完成長什麼樣子？」很多人其實說不清楚自己要什麼，只知道「我會在看到的時候認出來」。但 /goal 不接受這種模糊。你必須把「看到就知道」轉換成 AI 能理解、能檢驗的具體條件。

Pavel Huren 說在 /goal 時代，「贏的技能是工程化你的意圖」。我同意這個判斷。但我想補充一點：這不是新技能，這是舊技能的新應用。任何做過專案管理的人都知道，定義清楚「完成標準」（Definition of Done）是專案成功的前提。/goal 只是把這個觀念從人類協作的情境搬到了人機協作的情境。

如果你想開始實驗 /goal，NLW 的建議是先找一個不在你主要工作流程中的任務來試。這樣即使失敗了也沒有太大損失，但你能從中學會如何把模糊的需求翻譯成明確的終點線合約。一旦你掌握了這種思維，它不只會改變你使用 AI 的方式，也會改變你定義工作本身的方式。