如何解決Codex、Claude Code的 /goal 跑一會就停的問題？

哈囉各位精神股東，我係Next蔡蔡！

Claude Code同Codex嘅 /goal 功能出咗一段時間啦。呢個號稱可以令AI「長時間自主運行直到目標完成」嘅功能，用過嘅人嘅表現反差好大：

有啲人用佢可以行幾個鐘甚至幾十個鐘，複雜任務真係放手俾AI搞，自己沖杯咖啡或者瞓覺返嚟就可以驗收結果，另一邊就話佢行一陣就停。呢個差距，唔關AI本身事，而係在於你俾嘅 /goal 指令。

今日呢篇文章就係為咗解決呢個問題，分為兩部分：

1）通過 /goal 同 prompt 嘅分別嚟搞明 /goal

2）三個方法，解決 /goal 行一陣就停嘅問題

一、透過 prompt 同 /goal 嘅分別去理解 /goal

呢段係一個常規嘅提示詞：、

優化我們網站首頁的加載速度，讓它在手機上打開變得更快。

呢段係結合 /goal 使用嘅提示詞：

/goal 優化首頁（pages/index.js）的加載性能。
驗證標準：在本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到 90 分以上，且 First Contentful Paint (FCP) 小於 1.8 秒。
約束條件：不能壓縮或降低現有的核心高保真產品圖片的質量。
停止條件：如果嘗試了代碼分割和懶加載後分數仍低於 85 分，請生成當前的性能火焰圖報告並停止。

如果剩係睇指令本身，/goal 就好似一個更詳細嘅提示詞。

但兩者底層邏輯完全唔同。我哋一齊睇下 Codex 收到兩類指令之後，成個過程係點運作嘅。

普通 Prompt 模式係咁嘅：

雖然普通 Prompt 喺 Codex 嘅「思考執行」過程中都會被拆做一小步一小步執行，但佢輸出嘅結果係冇標準嘅，如果結果錯咗或者唔係你想要嘅，就要重新輸入新嘅 Prompt 去修正佢。

無論係初始 Prompt 定後續修正嘅 Prompt，佢哋大部分都係臨時、一次性嘅。因為 AI 執行完呢啲指令之後，指令嘅約束力通常就會消失，上下文亦都被後續嘅對話沖淡。

Goal 模式就唔同：

Goal 係你俾 AI 設定一個持久嘅目標，呢個目標有客觀證據可以證明達到嘅，例如「喺本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到90分以上，而且 First Contentful Paint (FCP) 細過 1.8 秒」。

只要目標未達成，佢就會一直喺後台激活，例如喺 Codex 入面，激活狀態嘅 Goal 會懸浮喺當前對話中，跨越幾輪對話依然有效。直到達成目標或者預算用盡或者遇到解決唔到嘅阻礙（例如權限不足），Goal 先會停。而唔需要好似 prompt 咁要額外 push 佢「繼續」或者「再試其他方法」。

當然，喺呢個過程中，你亦都可以隨時暫停（/goal pause）、恢復（/goal resume）、清除（/goal clear）。

如果用一句話總結 Prompt 同 Goal 嘅核心分別：

prompt 係你每一步都要推住 AI 行，/goal 係你劃定一條終點線，AI 自己跑到終點線先同你匯報。

二、三個方法，解決 /goal 行一陣就停嘅問題

透過 Prompt 同 Goal 嘅對比，大家可能已經發現自己運行 /goal 行一陣就停嘅問題喺邊，通常係因為冇清晰嘅目標、過程處理標準同最終驗收標準。

就好似你俾團隊成員分配個任務，但你又冇講清楚任務嘅範圍邊界同驗收標準，咁佢喺執行過程中遇到唔肯定嘅就會不停問你，所以冇辦法長時間專注去做任務。

既然知道問題喺邊，咁解決就唔難，呢度分享三個方法：

方法一：用 goal 模板

我之前喺知識星球分享過呢套模板，用一條公式總結就係：作用範圍+硬性約束+驗收清單+停止條件。

亦可以直接套用呢條模板：

/goal { 一句話描述目標 }

Scope：
{ 作用範圍：改哪些文件/哪個模塊的代碼，以及明確不在作用範圍的區域 }

Constraints：
{ 硬性約束（可以多個），比如不要修改數據庫 schema，保持現有公開 API 不變，不允許新增 npm 依賴 }

Done when：
{ 明確可驗證的交付物或最終狀態（可以多個），比如npm run test 通過，checklist 全通過}

Stop if：
{ 明確停止條件（可以多個），比如需要 npm install 新依賴，超出 token 限額}

例如第一部分嘅 goal 指令，就係呢套模板嘅產物。

/goal 優化首頁（pages/index.js）的加載性能。
驗證標準：在本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到 90 分以上，且 First Contentful Paint (FCP) 小於 1.8 秒。
約束條件：不能壓縮或降低現有的核心高保真產品圖片的質量。
停止條件：如果嘗試了代碼分割和懶加載後分數仍低於 85 分，請生成當前的性能火焰圖報告並停止。

模板係有，但對於非開發者嚟講，要寫好 goal 喺開發場景下嘅各種約束條件並唔容易，當時就有圈友喺帖子下評論，「純小白點寫好 /goal 命令嘅約束條件」，我之後認真諗過呢個問題，發現最好嘅方案都係俾 AI 輔助撰寫。

如果你常用嘅係 Codex，咁就方便好多，因為佢自帶 set_goal 函數，所以將你描述得唔夠清楚嘅需求掟俾 Codex，等佢幫你輸出完整嘅 /goal 指令。

但如果你常用嘅係 Claude Code，可以將前面嘅 goal 公式做成通用 skill，例如咁樣：https://github.com/nextcaicai/caicai-skills/blob/main/skills/caicai-goal-prompt/SKILL.md

用呢個 Skill 生成完整 goal 指令嘅效果大概係咁樣，係咪比我哋寫嘅清晰全面好多呢（不過呢個 Skill 仲只係初始版本）。

方法二：用 Goalbuddy

Goalbuddy 都係一個 Skill，佢同方法一嘅自製 Skills 有兩個比較大嘅分別。

一個係面對模糊需求例如「/goalbuddy 優化桌面段性能」，佢會先叫我哋澄清幾個關鍵問題，例如係優化頁面加載速度、交互響應性能，定係資源佔用優化等。

另一個就係喺執行過程中多咗個本地嘅實時滾動看板，可以直接睇到任務清單、進行中項目、阻塞項目、完成項目等等。

Github🔗：https://github.com/tolibear/goalbuddy

佢成個實現邏輯由三個關鍵文件支撐，分別係 SKILL.md + goal.md + state.yaml。

SKILL.md ：定義怎麼做（過程 + 規則），透過約定結構化嘅文件（goal.md同state.yaml）、清晰角色分工（Scout/Judge/Worker）以及強制嘅驗證條件（Oracle），令 AI 可以按照工程化嘅軟件開發流程去執行長期任務。

goal.md ：定義今次任務做乜 + 做到咩程度先叫完成，即係我哋前面提到嘅約束條件、驗收標準。當 goal.md 梳理清楚之後，就會執行 /goal Follow docs/goals/goal.md 呢條指令，背後嘅邏輯同方法一一樣，分別係方法一係用 prompt 形式去梳理 goal，呢度係用 markdown 文件去承載 goal。

所以 GoalBuddy 並唔係取代原生 /goal。呢個係項目作者都寫喺 README 文檔入面嘅，「GoalBuddy 為佢（原生 /goal）準備本地看板同交接提示，但佢唔啟用亦唔取代原生嘅 /goal。」

state.yaml ：用嚟共享當前任務做到邊一步（實時狀態），呈現形式就係前面提到嘅實時滾動看板。

喺任務運行時，你可以透過呢個看板清晰睇到整體計劃、當前進行緊嘅任務、工作證明、子目標同驗證狀態，而唔需要喺聊天記錄入面揾。AI 每輪循環都會先讀 goal.md，再結合 state.yaml 決定下一步點做。

方法三：結合你之前常用嘅 Plan 或 Spec 工具

透過方法一同方法二理解咗 /goal 嘅本質之後，咁我哋都唔一定要用呢啲 Goal Skills，而係可以用返我哋之前常用嘅 Plan 或 Spec 工具，去梳理出 goal 需要嘅目標同驗收標準。

例如你可以用 Codex 或 Claude Code 自帶嘅 Plan 模式，透過對話將自己模糊嘅需求一步步梳理清楚，記得要追問確認 Done when 同 Stop if 呢兩組邊界問題。最後就可以退出 Plan 模式，用 /goal 執行上面嘅開發計劃。

一定要記住先退出 Plan 模式再執行 /goal，因為喺 Plan 模式係冇辦法編輯同創建文件嘅，咁樣 /goal 就會失效。

亦可以用 openspec 呢類 Spec 工具，因為佢哋會輸出呢啲規格文檔，包括：

• proposal.md：提案文檔。用嚟解釋點解要進行呢項變更，同埋具體會改變啲乜嘢內容。

• specs/：規範文件夾。包含具體嘅需求同使用場景。

• design.md：設計文檔。詳細說明實現呢個功能嘅技術方案同途徑。

• tasks.md：任務清單。提供用喺實際編碼階段嘅實施檢查列表。

呢啲規格文檔，基本上就係比較標準嘅 goal 指令，可以直接啟動 /goal，然後叫 AI 嚴格按照規格文檔實現，基本上同方法二嘅實現好似。

仲可以用 Superpower 入面嘅 brainstorming + writing-plans，或者用 Matt Pocock 嘅 grill-with-doc + to-prd 等工具。工具唔係問題，只要你係常用嘅可以形成類似需求執行文檔嘅都得。

最後，如果你之前未用過 /goal 嘅話，可以將 Codex 或 Claude Code 更新到最新版，佢通常就會出現喺斜槓命令列表中。

如果冇出現，可以直接叫 Codex 或 Claude Code 幫你啟用，呢類功能開啓、工具安裝或者問題排查，而家都可以用 AI First 嘅原則去快速得到解決。

開啓 /goal 之後，就用上面任意一個方法去試下 /goal 啦，相信會帶俾你全新嘅 AI 體驗。

哈嘍各位精神股東們，我是Next蔡蔡！

Claude Code 和 Codex 的 /goal 功能已經出來有一段時間了。這個號稱能讓 AI “長時間自主運行直到目標完成”的功能，使用它的人的表現卻反差極大：

一撥人用它能跑幾個小時甚至幾十個小時，複雜任務真就甩手給 AI，自己去喝杯咖啡或睡個覺回來就可以驗收結果，另一撥人卻吐槽它跑一會兒就停。這種差距，不在 AI 本身，而在你給的 /goal 指令。

今天這篇文章就是來解決這個問題的，分為兩部分：

1）通過 /goal 和 prompt 的區別搞懂 /goal

2）三種方法，解決 /goal 跑一會就停的問題

一、通過 prompt 和 /goal 的區別理解 /goal

這是一段常規的提示詞：、

優化我們網站首頁的加載速度，讓它在手機上打開變得更快。

這是結合 /goal 使用的一段提示詞：

/goal 優化首頁（pages/index.js）的加載性能。
驗證標準：在本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到 90 分以上，且 First Contentful Paint (FCP) 小於 1.8 秒。
約束條件：不能壓縮或降低現有的核心高保真產品圖片的質量。
停止條件：如果嘗試了代碼分割和懶加載後分數仍低於 85 分，請生成當前的性能火焰圖報告並停止。

如果單看指令本身， /goal 就像是更詳細的提示詞。

但兩者在底層邏輯上完全不同。我們來看 Codex 在收到兩類指令後，整個過程是怎麼運轉的。

普通 Prompt 模式是這樣的：

雖然普通 Prompt 在 Codex 的“思考執行”過程中也會被拆解成一小步一小步的執行，但它輸出的結果是沒有標準的，如果結果是錯的或者不是你想要的，你還需要重新輸入新的 Prompt 去糾正它。

不論初始 Prompt 還是後續糾正的 Prompt，它們大都是臨時的、一次性的。因為 AI 在執行完這些指令後，指令的約束力一般就隨之結束，上下文也被後續的對話沖淡。

Goal 模式則不同：

Goal 是你給 AI 設定了一個持久的目標，這個目標是有客觀證據可以證明達標的，比如“在本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到 90 分以上，且 First Contentful Paint (FCP) 小於 1.8 秒”。

只要目標還沒達成，它就會一直在後台激活，比如在 Codex 中，激活狀態的 Goal 會懸浮在當前對話中，跨越多輪對話依然有效。直到達成目標或預算耗盡或遇到無法解決的阻礙（比如權限不足），Goal 才會停止。而不需要像 prompt 那樣得額外去 push 它“繼續”或“再試試別的辦法”。

當然，在這個過程中，你也可以隨時暫（/goal pause）、恢復（/goal resume）、清除（/goal clear）。

如果用一句話概括 Prompt 和 Goal 的核心差異：

prompt 是你每步都得推着 AI 往前走，/goal 是你劃定一條終點線，AI 自己跑到終點線後才給你彙報。

二、三種方法，解決 /goal 跑一會就停的問題

通過 Prompt 和 Goal 的對比，大家可能已經發現自己運行 /goal 跑一會就停的問題在哪了，往往是因為缺少清晰的目標、過程處理標準和最終驗收標準。

就像是你給團隊成員佈置個任務，但你又沒講清楚任務的範圍邊界和驗收標準，那他在執行過程中遇到不確定的就會來反覆問你，所以沒法長時間專注地跑任務。

既然知道了問題所在，那解決起來就不難了，這裏分享三種方法：

方法一：使用 goal 模板

我之前在知識星球分享過這套模板，用一條公式來總結就是：作用範圍+硬性約束+驗收清單+停止條件。

也可以直接套用這條模板：

/goal { 一句話描述目標 }

Scope：
{ 作用範圍：改哪些文件/哪個模塊的代碼，以及明確不在作用範圍的區域 }

Constraints：
{ 硬性約束（可以多個），比如不要修改數據庫 schema，保持現有公開 API 不變，不允許新增 npm 依賴 }

Done when：
{ 明確可驗證的交付物或最終狀態（可以多個），比如npm run test 通過，checklist 全通過}

Stop if：
{ 明確停止條件（可以多個），比如需要 npm install 新依賴，超出 token 限額}

比如第一部分的 goal 指令，就是這套模板的產物。

/goal 優化首頁（pages/index.js）的加載性能。
驗證標準：在本地運行 lighthouse-cli 模擬移動端測試時，Performance 分數必須達到 90 分以上，且 First Contentful Paint (FCP) 小於 1.8 秒。
約束條件：不能壓縮或降低現有的核心高保真產品圖片的質量。
停止條件：如果嘗試了代碼分割和懶加載後分數仍低於 85 分，請生成當前的性能火焰圖報告並停止。

模板是有了，但對於非開發者來說，要寫好 goal 在開發場景下的各種約束條件並不容易，當時就有圈友在帖子下評論，“純小白怎麼寫好 /goal 命令的約束條件”，我後面認真思考了下這個問題，發現最好的方案還是讓 AI 輔助撰寫。

如果你常用的是 Codex，就方便很多，因為它自帶 set_goal 函數，所以把你描述不夠清楚的需求丟給 Codex，讓它給你輸出完整的 /goal 指令。

但如果你常用的是 Claude Code，可以將前面的 goal 公式做成通用 skill，比如這樣的：https://github.com/nextcaicai/caicai-skills/blob/main/skills/caicai-goal-prompt/SKILL.md

用這個 Skill 生成完整 goal 指令的效果大概長這樣，是不是要比我們寫的清晰全面多了（不過這個 Skill 還只是初始版本）。

方法二：使用 Goalbuddy

Goalbuddy 也是個 Skill，它和方法一的自制 Skills 有兩個比較大的區別。

一個是面對模糊需求如“/goalbuddy 優化桌面段性能”，它會先讓我們澄清幾個關鍵問題，比如是要優化頁面加載速度、交互響應性能，還是資源佔用優化等。

另一個就是在執行過程中多了個本地的實時滾動看板，可以直查看任務清單、進程項、阻塞項，完成項等等。

Github🔗：https://github.com/tolibear/goalbuddy

它的整個實現邏輯由三個關鍵文件支撐起來，分別是 SKILL.md + goal.md + state.yaml。

SKILL.md ：定義怎麼做（過程 + 規則），通過約定結構化的文件（goal.md和 state.yaml ）、清晰角色分工（Scout/Judge/Worker）以及強制的驗證條件（Oracle），讓 AI 可以按照工程化的軟件開發流程來執行長期任務。

goal.md ：定義本次任務做什麼 + 做到什麼程度才算完成，也就是我們前面提到的約束條件、驗收標準。當 goal.md 梳理清楚後，就會運行 /goal Follow docs/goals/goal.md 這條指令，背後的邏輯跟方法一是一樣的，區別就是方法一是以 prompt 形態去梳理 goal，這裏是用 markdown 文件去承載 goal。

所以 GoalBuddy 並不替代原生 /goal。這是項目作者也寫在 README文檔裏的，“GoalBuddy 為它（原生 /goal）準備本地看板和交接提示，但它不啓用也不取代原生的 /goal。”

state.yaml ：用來共享當前任務做到哪一步了（實時狀態），呈現形態就是前面提到的實時滾動看板。

在任務運行時，你可以通過這個看板清晰地看到整體計劃、當前正在進行的任務、工作證明、子目標以及驗證狀態，而不需要在聊天記錄裏翻找。 AI 每輪循環都會先讀 goal.md，再結合 state.yaml 決定下一步怎麼做。

方法三：結合你之前的常用的 Plan 或 Spec 工具

通過方法一和方法二理解了 /goal 的本質後，那我們也不一定要用這些 Goal Skills，而是可以沿用我們之前常用的 Plan 或 Spec 工具，去梳理出 goal 所需的目標和驗收標準。

比如你可以用 Codex 或 Claude Code 自帶的 Plan 模式，通過對話將自己的模糊需求一步步梳理清楚，記得要追問確認 Done when 和 Stop if 這兩組邊界問題。最後就可以退出 Plan 模式， 用 /goal 執行上面的開發計劃。

一定要記得先退出 Plan 模式再執行 /goal ，因為處於 Plan 模式試無法編輯和創建文件的，這樣 /goal 也就失效了。

也可以用 openspec 這類 Spec 工具， 因為它們會輸出這麼些規格文檔，包括：

• proposal.md：提案文檔。用於說明為什麼要進行此項變更，以及具體會改變什麼內容。

• specs/：規範文件夾。包含具體的需求和使用場景。

• design.md：設計文檔。詳細說明實現該功能的技術方案和途徑。

• tasks.md：任務清單。提供用於實際編碼階段的實施檢查列表。

這些規格文檔，基本就是比較標準的 goal 指令，可以直接啓動 /goal，然後讓 AI 嚴格按照規格文檔實現，基本類似方法二的實現了。

還可以用 Superpower 裏的 brainstorming ＋ writing-plans、或者用 Matt Pocock 的 grill-with-doc ＋ to-prd 等工具。工具不是問題，只要你是常用的能形成類似的需求執行文檔的都可以。

最後，如果你之前還沒用過 /goal 的話，可以將 Codex 或 Claude Code 更新到最新版，它一般就會出現在斜槓命令列表中。

如果沒有出現，可以直接讓 Codex 或 Claude Code 幫你啓用，這種功能開啓、工具安裝或者問題排查，現在都可以用 AI First 的原則去快速得到解決。

開啓 /goal 後，就用上面任意一種方法去試試 /goal 吧，相信會給你帶來全新的 AI 體驗。