從 prompt 到 goal：AI 使用方式正在發生根本轉變

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

---

聊天機器人的瓶頸，不是模型不夠聰明

你有沒有過這種經驗：請 AI 幫你做一件稍微複雜的事，結果變成無止盡的來回對話？你給一個指令，它做一步，你看完結果再給下一個指令，它再做一步。整個過程像在跟一個很聰明但完全不會主動的實習生合作，每做完一件小事就停下來等你的下一道指示。

這就是 AI Daily Brief 主持人 NLW（Nathaniel Whittemore）所說的「一問一答典範」（turn-based paradigm）。過去幾年我們跟聊天機器人的互動方式就是這樣：給 prompt、等回應、審查結果、給回饋、再等下一次回應。這種模式在簡單任務上還行，但一旦任務需要多步驟的探索、比對、修正，效率就會急速下降。瓶頸不在模型的能力，而在人類跟模型之間的「來回延遲」。

OpenAI 的開發者 Jason Liu 曾寫了一篇關於如何最大化 Codex 使用效率的文章，提出九種互動模式，包括持久對話串（durable monothreads）、語音輸入、側邊面板即時檢視產出物、中途介入修正方向（steering）、以及遠端遙控和心跳通知。所有這些技巧的共同方向，都是試圖減少人機之間的往返延遲。但 /goal 的出現，把這件事推到了一個全新的層次：它不只是縮短延遲，而是根本改變了互動的結構。

什麼是 /goal：終點線合約

2026 年 5 月初，OpenAI Codex 團隊成員 Tebow 在推文中寫道：「/goal 可能是我們在 Codex 中推出過最具影響力的功能。好的指令從未像現在這樣有價值。」另一位開發者 Pavel Huren 則簡潔地解釋了它的核心機制：「你描述想要的結果，模型開始迴圈執行、自我評估，完成後自動停止。」

這裡的關鍵字是「迴圈」。NLW 指出，/goal 不是一個更大的 prompt，而是一種根本不同的東西。他引用 Codex 內部的說法，稱之為「終點線合約」（finish line contract）：你要定義的是「完成時什麼應該為真」、「怎麼檢驗成功」、以及「過程中什麼不能被破壞」。

如果傳統的 prompt 是一次性的指令與回應，那 /goal 啟動的是一個持續的迴圈：AI 朝著你定義的目標推進，每一步之後檢查當前的證據是否滿足終點線的定義，然後決定是繼續、宣告完成、還是因為真的卡住而停止。這個自我評估的機制，就是從「告訴 AI 該做什麼」到「告訴 AI 你希望完成什麼」的根本轉換。

前 OpenAI 共同創辦人、目前任職於 Anthropic 的卡帕西（Andrej Karpathy）也花了大量時間實驗類似的迴圈機制。他觀察到：「大型語言模型在朝特定目標迴圈執行這件事上表現得極為出色。不要告訴它該做什麼，給它成功標準，然後看著它跑。」這段話精確地捕捉了 /goal 背後的設計哲學。

寫好一個 /goal 的六大要素

既然 /goal 不是更大的 prompt，那要怎麼寫好一個 /goal？OpenAI 的開發者指南文件提出，最強的 goal 通常定義六件事情。

第一是結果（outcome），也就是工作完成時什麼應該為真。第二是驗證面（verification surface），可能是測試、基準報告、產出物、引用來源，任何能證明任務完成的可檢驗證據。第三是約束條件（constraints），指的是 AI 在工作過程中不能破壞的東西。第四是邊界（boundaries），定義 AI 可以使用哪些檔案、工具和資源。第五是迭代策略（iteration policy），也就是每次嘗試之後，AI 應該如何決定下一步該做什麼。第六是阻斷停止條件（block-stop condition），告訴 AI 什麼時候應該承認走不下去，而不是無限迴圈。

除了這六個要素之外，目標的範圍也有一個「甜蜜點」需要拿捏。NLW 稱之為「金髮女孩區間」（Goldilocks zone）。太狹窄的目標，像是「修好這一行程式碼」，無法給 AI 足夠的彈性去發現真正的問題可能在上游的相依套件裡。太寬泛的目標，像是「改善整個系統」，則無法提供具體到可以自我驗證的完成證據。理想的範圍介於兩者之間，既有明確的終點線，又保留足夠的探索空間。

產出物的定義也很關鍵。一個模糊的產出物定義，像是「幫這個功能寫文件」，AI 很難判斷自己到底完成了沒有。但如果你寫成「產出一個文件頁面，用兩個範例說明 lifecycle 指令，驗證頁面可以在本機成功建置，確認所有參考指令符合目前的 CLI 行為」，AI 就有了具體的、可檢驗的證據面。

超越寫程式：知識工作者的應用場景

雖然 /goal 最早是為程式開發設計的，處理像是效能分析、修補程式碼、資料庫遷移、重現不穩定的測試這類任務。但 NLW 認為，這個原語的價值遠不只是寫程式。他的判斷標準是：當你想要的產出不只是一個答案，而是一份稽核報告時，那就是 /goal 的好候選場景。

所謂稽核報告，指的是一份完整的紀錄：查了什麼、什麼被證實、什麼被反駁、什麼證據薄弱、什麼仍然未知。這種結構化的產出物本身就是 AI 可以用來自我評估的證據面。

在定義成功標準時，知識工作跟程式開發有一個重要差異。程式碼有測試可以跑、有基準可以量，但知識工作的成功標準往往需要使用者自己提供。你的招聘標準、供應商評分卡、編輯方針、投資盡職調查的優先事項，這些都是只有你才能定義的成功判準。NLW 建議反過來想：如果一項任務隱含著某種評分標準或成功準則，那它可能就適合用 /goal 來處理。

他列出了十個可能適合 /goal 的知識工作領域：文獻回顧、市場版圖分析、供應商評估、盡職調查、聲明稽核、政策研究、訪談綜合整理、時間線重建、試算表稽核、以及將雜亂輸入結構化的策略備忘錄。

三個具體範例

NLW 詳細展開了三個知識工作的 /goal 範例。第一個是聲明稽核：「逐一稽核這份備忘錄中的每個聲明，針對提供的來源和可靠的外部來源進行驗證。最後產出一張表格，將每個聲明標記為『已證實』、『被反駁』、『部分證實』或『未經驗證』，附上引用出處和不確定性註記。」這之所以適合 /goal，是因為 AI 做出的每個結論都可以回溯到具體證據。

第二個是市場版圖分析：「建立 X 市場的競爭版圖，以引用的公司頁面、財務報告、分析師報告、定價頁面和產品文件作為驗證來源。最後產出一張比較表格，標示信心水準，以及證據不足的缺口。」這跟一般的「幫我研究某個市場」不同之處在於，它要求的不只是資訊彙整，而是一份帶有信心水準標註的稽核型產出物。

第三個是文獻回顧：「提供一份以證據為基礎的文獻回顧，主題是 X。建立一份來源矩陣，涵蓋研究方法、樣本量、發現、限制和衝突。最後列出已確認的主題、有爭議的發現、以及開放性問題。」這種做法刻意保留衝突和分歧，而不是把所有東西壓扁成一個單一結論。

什麼時候不該用 /goal

NLW 也坦言，不是每個任務都該用 /goal。多數時候，傳統的對話模式可能就夠了。當目標夠小、一次對話就能搞定時，/goal 的迴圈架構只會增加不必要的負擔。同樣，當成功標準無法被清楚定義到 AI 可以自我評估的程度時，/goal 也不會是好選擇。

他舉了一個簡單的區分範例：「依據這個評分標準審查這五份申請書，引用證據，建議面試問題」，這是一個適合用 prompt 的任務，因為輸入量小、標準明確、一次比較就能完成。但如果同樣的評分標準要持續應用在陸續收到的申請書上，需要反覆提取證據、檢查一致性、重新審視邊界案例、標記缺漏資訊、並且持續更新一份文件，那就進入了 /goal 的領域。

開發者兼評論者 Sean Wang（Swix）提出了一個有用的框架：AI 互動存在一個自主程度的光譜。從 /skill（預設 prompt）到 /plan（人類精煉過的輸入）到 /goal（AI 自我評估的產出），每一步都把更多的判斷授權給模型。但光譜是光譜，不同的工作類型適合不同的位置，沒有一種方法適用於所有情境。

我的觀察：管理 AI 就像管理人

/goal 最讓我覺得有意思的地方在於，它把「怎麼用 AI」這件事，推向了一個跟「怎麼管理人」非常相似的方向。好的主管不會告訴下屬每一步該做什麼，而是定義清楚「完成的樣子長什麼樣」，然後給予足夠的自主空間。/goal 本質上就是在做這件事。

Pavel Huren 說得精準：「贏的技能是工程化你的意圖。為什麼這件事重要、策略脈絡是什麼、成功如何被衡量，讓 AI agent 能做出更好的自主決策。」這聽起來跟管理學教的東西幾乎一模一樣。我們花了幾十年學怎麼把模糊的目標拆解成可衡量的成果，現在這套技能的應用對象從人變成了 AI。

這也意味著，未來用好 AI 的門檻可能不是技術門檻，而是思考門檻。你能不能把一個模糊的需求，拆解成有明確終點線、可驗證的成功標準、清楚的邊界和約束條件？如果能，你就能讓 AI 自己跑完全程。如果不能，你就只能繼續一步步帶著它走。