一文吃透 /goal 指令：讓 AI 自動打工

可能你喺 AI 編程嘅過程入面都遇到過呢啲情況。

叫 AI 幫你寫 Code，佢寫兩行就停咗等你確認；
叫佢幫你改個 Bug，改咗半日又返返去原點；
叫 AI 做一件稍微複雜啲嘅事，佢就卡咗喺度唔鬱，等你一步步話佢知下一步點做。

呢個唔係你嘅問題，亦都唔係 AI 太蠢，呢個係 AI 工作嘅預設模式。

你講一句，佢做一句，你再批准，佢再做下一步。

呢種模式喺簡單任務入面冇問題，但係如果要搞個稍微複雜啲嘅嘢，人就變成最大嘅瓶頸。你要一直睇實，逐次批准，逐次話「繼續」。

今日要介紹嘅呢個 /goal 功能，就係為咗解決呢個問題。

/goal 係乜嘢

簡單講，/goal 就係你話畀 AI 一個明確嘅「完成條件」，然後 AI 自己持續做嘢，直到佢覺得條件滿足咗先停低揾你。

唔使你一步步批准，更加唔使你逐次話「繼續」。

就好似你對一個實習生講：「呢份報告寫完先叫我，格式跟公司範本，內容要覆蓋 Q1 嘅所有產品數據。」實習生寫完自然會嚟揾你。

/goal 嘅工作原理稍微解釋嚇：

以 Claude 為例，每次 AI 完成一步操作之後，會有一個細模型（速度好快，體積好細，例如 Haiku）嚟檢查。「佢做到嘅條件，而家滿足咗未？」如果滿足咗，AI 就自動停低；如果未滿足，佢就會繼續做。

呢個設計好關鍵。

唔係 AI 自己判斷自己做咗未，而係有一個獨立嘅「裁判」喺度判斷。

咁樣 AI 就唔會自說自話咁宣佈「做完了」，亦都唔會因為唔確定而不停卡喺度。

所以你見到嘅狀態係：/goal 激活之後，AI 喺度行啊行，你間中會見到佢匯報進展，但佢唔會成日停低等你。你只需要等佢話「搞掂咗」，或者你主動問嚇佢而家進展成點。

點樣用 /goal

喺唔同嘅 AI 工具入面，/goal 嘅開啟方式有少少唔同。你用邊個，就睇邊段。

Claude Code CLI
呢個最簡單。裝好咗 Claude Code，直接喺對話入面輸入 /goal 就得，唔需要額外設置。

Codex CLI
需要兩步。第一，喺設置入面確認 goals = true；第二，如果想減少每次操作之後嘅確認彈窗，可以加一個啟動參數，喺終端入面輸入：

codex --approval-mode full-auto

Codex 桌面版
一樣嘅邏輯，打開 Settings，揾到 Configuration，將 goals 開咗就得。

如果你用嘅係 Claude Code 嘅網頁版或者桌面版，基本上都係直接用得 /goal，唔需要額外配置。

萬一你輸入咗 /goal 但佢冇反應，好大可能係因為你仲喺一個未確認過信任協議嘅工作空間入面，因為 /goal 係需要喺已確認信任嘅環境先至運行到。呢點要注意！

點樣寫好 /goal 提示詞

呢個係最關鍵嘅部分。

/goal 用起嚟簡單，但效果好唔好嘅關鍵在於：你點樣描述呢個「完成條件」。

好多人用唔好 /goal，唔係工具嘅問題，係提示詞寫得唔啱。

講白咗，寫 /goal 提示詞有個基本模板，你記住呢個就夠：

/goal [你要 AI 做的事] 直到 [可衡量怎麼才算完成了] 且 [過程中必須遵守的約束]

呢種格式解決咗一個核心問題「點樣先算做完」。

舉個例子：

/goal 修復所有失敗的測試，直到 npm test 返回 0，且不修改 /auth 目錄以外的任何文件

呢個目標清晰啩？

「npm test 返回 0」就係可量度嘅完成狀態，「唔修改 /auth 目錄以外嘅任何文件」就係約束。

AI 好清楚自己應該點行，亦都知道幾時應該停低。

相反，如果你嘅目標係模糊嘅，例如「將 Code 優化嚇」，會發生乜嘢？

AI 唔知道「優化」到咩程度先算好。佢可能改兩下就覺得差唔多，然後停低同你報告。又可能改咗半日仲喺度糾結邊度可以再優化，然後一路行落去。

兩種情況都幾頭痛。

所以，寫 /goal 提示詞嘅核心原則就係：將「完成」變成一件事可以量度嘅嘢。

如果你想做嘅任務本身係模糊嘅，點算？

例如「將呢篇論文改做某個期刊嘅格式」。呢件事似乎冇明確嘅完成點。但其實你可以轉嚇思路，畀佢一個清單，叫 AI 逐項檢查。

例如你將目標寫成：根據提供嘅 checklist.md，將論文格式調整成 ICML 風格，而且唔改變論文嘅技術內容。

然後你提供一個檢查清單，裏面列咗 N 多條格式要求，例如字體嘅、行距嘅、引用格式嘅、頁邊距嘅...等等）。

AI 每完成一條就勾一條，佢只需要判斷「我已經勾咗幾條」就得。咁樣就將一個模糊嘅任務變成可以數數、可以量度嘅具體操作。

再講一個常見嘅錯誤：約束寫太多或者寫太少。

約束太少，AI 喺做嘢嘅過程中可能會順便改咗一啲你唔希望佢改到嘅地方。而約束太多呢，AI 又有可能根本行唔起，揾唔到滿足所有約束嘅解題方法。

一個好嘅約束標準，佢係「必須保持不變嘅嘢」，而唔係「你想佢做嘅事」。

例如「唔修改 /auth 目錄以外嘅文件」係約束；但「叫佢考慮多啲代碼可讀性」就唔係約束。呢啲係你想佢做嘅事，唔係必須保持嘅邊界。

令 /goal 效率翻倍嘅三個習慣

識用 /goal 之後，仲有三件事可以令佢嘅效果明顯提升。

呢三點係我睇過大量實際使用案例之後提煉出嚟嘅，你跟住做就得。

習慣一：反饋循環越快越好

/goal 能夠持續工作嘅原因，係佢每一步都得到反饋。例如我咁樣做啱唔啱？離目標近咗未？

反饋越快，AI 修正錯誤嘅速度就越快，效率就越高。相反，如果反饋好慢，例如每次驗證要等幾分鐘，AI 就要花大量時間喺等待入面消耗。

呢點喺編程任務入面特別明顯。

例如你要 AI 優化一個機械學習模型，唔好叫佢一開始就用完整嘅訓練數據集同完整嘅模型參數嚟測試。行一次要幾日，咁 AI 每次試一個方案都要你苦等幾日先知道結果，邊個受得了。

更好嘅做法係用一個細數據集加上一個細模型，令反饋週期由「幾日」變成「幾分鐘」。等 AI 揾到有效嘅方向之後，先用完整嘅數據同模型嚟行。咁樣就可以慳返好多時間。

你喺用 /goal 嘅時候都可以咁樣思考：呢一步可唔可以快啲得到反饋？如果而家呢一步要等好耐，有冇更細嘅驗證方法？

習慣二：畀 AI 準備「工作日誌」文件

如果你叫 /goal 行一個需要幾小時甚至幾日嘅複雜任務，單靠 AI 嘅「腦袋」記住曬所有上下文係好難嘅。佢喺呢個過程中會不斷忘記，會混淆，會喺長對話入面遺失重要資訊。

所以，喺複雜任務入面，建議你畀 AI 提供三個 Markdown 文件嚟跟蹤進度：

PLAN.md
記錄整體計劃。AI 喺開始之前先叫佢計劃好自己打算點做，你可以喺呢度預先放低你嘅一啲思路，咁 AI 做嘢會更有方向感。

EXPERIMENTS.md
記錄每次嘗試。AI 每次試咗一個方案，就會將方案內容、點解揀呢個方案、結果係點記錄喺入面。呢個文件最重要，因為佢令 AI 可以回顧「上次試咗咩？效果如何？」，而唔係盲目重複行唔通嘅路。

EXPERIMENT_NOTES.md
實時思考筆記。你可以將佢視為 AI 嘅「草稿紙」，佢可以喺入面寫而家諗緊咩、打算點做、遇到咩問題。呢個文件主要係令你可以睇明 AI 做緊咩，方便你有需要嘅時候介入指導。

呢三個文件唔需要你手動創建，你可以叫 AI 自己創建並寫入。你只需要喺 /goal 嘅提示詞入面加一句「請喺 PLAN.md、EXPERIMENTS.md、EXPERIMENT_NOTES.md 入面記錄你嘅進度」就得。

習慣三：配合呢啲配套命令使用

/goal 唔係孤立存在嘅，佢有幾個配套嘅命令，用得好效率翻倍：

/plan —— 查看 AI 而家嘅計劃。如果你想知道佢打算點做、進展到邊一步，輸入呢個。

/pause —— 暫停當前嘅目標。AI 會停喺原地，等你繼續指令。

/goal clear —— 重置目標。如果你改變咗想法，想轉個方向，就用呢個清除當前目標。

一個常見嘅用法：例如你設置咗一個 /goal，然後用 /plan 睇嚇佢嘅計劃係咪你想嗰個方向；如果方向偏咗，你用 /goal clear 清咗佢重新嚟過；確認方向啱咗之後，再叫佢繼續行。

一啲真實示例

講咗咁多，嚟啲直接用得嘅例子。你將任務描述換成你自己想做嘅嘢就得，結構可以直接照套。

場景一：幫項目加一個深色/淺色主題切換

/goal 給當前項目加一個深色/淺色主題切換功能。把用戶的選擇保存到 localStorage 裏，更新 UI 樣式以支持兩種主題，並在瀏覽器裏驗證功能正常工作

呢個任務包含三個動作：加功能、保存設置、驗證工作。AI 會自己行曬成個流程，最後話你知搞掂咗未。

場景二：改進項目嘅 README

/goal 改進當前項目的 README，讓一個新人能夠快速完成安裝、運行、測試、理解項目這四件事

呢個適合接手人哋嘅開源項目，或者令自己好耐之前嘅項目 README 重新用得。AI 會由新手視角審視現有文檔，補返缺失嘅說明。

場景三：做行業研究

/goal 研究最近關於 /goal 命令的所有最新信息，整理成一份結構清晰的報告

呢個唔限於技術，可以用喺你需要了解某個話題嘅場景。AI 會自己去搜索、整理、總結，最後畀你一份報告。

甚至可以直接為 AI 設定目標，叫佢研究最近關於 Codex 應用內瀏覽器升級嘅所有最新資訊，並使用 /hyperframes 製作成一個影片。

當目標設定非常清晰嘅時候，完全唔需要你幹預，佢做完嘢就會揾你。由全網搜索到影片製作完成，整體用時不過 5 分鐘。

場景四：清理冇用嘅代碼同依賴

/goal 找出項目中不再使用的代碼、未被引用的依賴和過時的文件，然後告訴我哪些可以安全刪除

呢個好實用，特別係維護咗好耐嘅項目。AI 會分析代碼依賴，列出可以清理嘅嘢，但刪除嘅動作會等你確認，防止誤刪。

場景五：修復所有失敗嘅測試

/goal 修復所有失敗的測試，直到 npm test 返回 0，且不修改 /auth 目錄以外的任何文件

呢個例子喺文章開頭都有講到。呢個係程序員最常用嘅場景之一，AI 會自己行測試、定位問題、修改代碼、再次驗證，直到所有測試通過。

而對於複雜嘅項目，可以跟隨以下呢個 /goal 終極提示詞（記得收藏起嚟~），放入 Claude Code 或 Codex 中，Agent 可以連續運行幾小時，零人工幹預。

/goal [最終交付成果 — 用一句話描述「完成」嘅標準]

一、背景信息
項目：[你正在構建的內容]
技術棧：[編程語言、框架、基礎設施]
當前狀態：[目前已有的基礎]
工作目錄：[本地路徑或代碼倉庫]
限制條件：[預算、時間、不可觸碰的紅線]
目標受眾：[該項目的面向對象]

二、成功標準（必須全部滿足）
1. [具體的、可量化的結果]
2. [具體的、可量化的結果]
3. [具體的、可量化的結果]
4. 最終交付物運行無報錯
5. 能夠提供證明（屏幕截圖、測試輸出結果、URL 連結）

三、操作守則（絕不妥協）
1. 規劃先行。在編寫任何代碼之前，輸出帶有編號的任務列表。
2. 自主推進。除非真正遇到阻礙，否則不要詢問澄清性問題。
3. 自我驗證。在每一步之後運行測試，檢查輸出，確認其有效。
4. 自主調試。如果運行失敗，自行診斷並修復。不要將問題拋回給我。
5. 善用工具。使用 MCP、終端、網絡搜索、代碼執行、拉取真實數據。
6. 拒絕佔位符。不留 TODO 註釋，不寫 stubs，必須是真實的組件 + 真實的狀態。
7. 進度日誌。記錄已完成項、進行中項、架構決策、阻礙因素。
8. 緊扣目標。發現規範之外的問題？記錄下來並繼續推進當前任務。
9. 遇阻對策。記錄遇到的「死衚衕」，繼續執行所有可並行處理的任務。
10. 停前自查。重新閲讀成功標準，確認每一項均已達成。

四、質量紅線
代碼：整潔、強類型、遵循項目規範
設計：媲美資金充裕的初創公司發佈的產品標準
產出：能夠通過資深工程師的代碼審查
文檔：記錄每一個新的模式 / 環境變量 / 架構決策

五、最終交付清單
- 確認已滿足所有成功標準
- 列出所有已創建 / 修改的文件
- 提供運行 / 測試 / 部署的指南
- 提供證明材料（屏幕截圖、測試輸出結果、URL 連結）
- 記錄已做出的決策 + 其他需要知曉的事項
- 列出已知限制 + 後續待辦事項
- 首先輸出你的執行計劃。然後端到端執行到底，直到任務完成或真正遇到阻礙前，不要停下來與我確認。

呢個就係設定目標，你轉身離開，之後返嚟驗收 AI 交付嘅成果。

可能會遇到嘅問題

一個 session 只能行一個 /goal

如果你設置咗新嘅 /goal，之前嘅就會自動被取代。所以唔好同時行兩個目標，想轉就清咗舊嘅先。

目標唔可以太模糊

如果你寫嘅目標連你自己都唔知「點樣先算完成」，AI 就更加唔知啦。

呢種情況下 AI 可能會行好耐然後最終放棄，或者一直停唔低，Token 白白被消耗。

所以，記得寫完目標之後自己喺腦入面先過一過，諗嚇：如果我嚟做呢件事，點樣先算交到差？如果呢個問題你自己都答唔到或者好模糊，咁就繼續將目標寫得具體啲。

評估依賴 AI 嘅輸出內容

/goal 嘅檢查機制本質上係睇「對話記錄入面有冇達到條件嘅證據」，佢唔能夠自己去行命令或者讀文件。

所以寫條件嘅時候要諗住「AI 完成呢件事之後，會喺對話入面留低啲咩可以檢查嘅結果？」

例如「npm test 返回 0」係得嘅，因為測試結果會顯示喺對話入面。但如果你嘅條件需要 AI 去讀某個外部系統先可以驗證，就唔太適合用 /goal 啦。

唔係所有任務都適合用 /goal

一個好明顯好快就完成到嘅細任務，直接講就得，唔使同自己揾麻煩，特登繞個圈用 /goal。

/goal 嘅優勢在於可以慳返你一步步批准嘅過程，適合需要多步驟、長時間運行嘅任務。

如果你只係叫 AI 幫你查嚇嘢或者寫個一句話嘅回覆，正常對話就夠曬。

寫喺最後

/goal 功能嘅本質就係為瞭解決「人成為咗 AI 工作嘅瓶頸」呢個好實在嘅問題。

佢令 AI 可以持續做嘢，唔需要你一步步批准，將「講一聲就自己做完再揾你」變成現實。

用好佢嘅關鍵就係三句話：

第一，設定清晰、可量度嘅完成條件。 模糊嘅目標係令 /goal 失效最常見嘅原因。

第二，保持反饋循環緊密。 驗證越快，AI 效率越高。

第三，幫複雜任務準備工作日誌。 令 AI 可以記住自己行到邊度，亦令你可以睇明佢做緊咩。

而家，就可以打開你常用嘅 AI Coding Agent 工具，由一個最簡單嘅細任務開始，睇嚇 /goal 係點行曬成個流程。

試完一次你就明曬。

既然睇到呢度，如果覺得唔錯，幫手順手㩒個「讚」、「睇緊」、「轉發」三連；如果想第一時間收到推送，都可以幫我加個星標★，多謝曬！

可能你在 AI 編程的過程中也遇到過這些情況。

讓 AI 幫你寫代碼，它寫兩行就停下來等你確認；
讓它幫你改個 bug，改了半天又回到原點；
讓 AI 做一件稍微複雜點的事兒，它就卡在那裏不動，等你一步步告訴它下一步怎麼做。

這不是你的問題，也不是 AI 太笨，這是 AI 工作的默認模式。

你說一句，它做一句，你再批准，它再做下一步。

這種模式在簡單任務裏沒問題，但要是搞個稍微複雜點兒的事，人就成了最大的瓶頸。你得一直盯着，一遍遍批准，一遍遍說"繼續"。

今天要介紹的這個 /goal 功能，就是來解決這個問題的。

/goal 是什麼

簡單說，/goal 就是你告訴 AI 一個明確的「完成條件」，然後 AI 自己持續幹活，直到它覺得條件滿足了才停下來找你。

不用你一步步批准，更不用你一遍遍說"繼續"。

就像你對一個實習生說："這個報告寫完再叫我，格式按照公司模板來，內容要覆蓋 Q1 的所有產品數據。"實習生寫完了自然會來找你。

/goal 的工作原理稍微解釋一下：

以 Claude 為例，每次 AI 完成一步操作之後，會有一個小模型（速度很快，體積很小，比如 Haiku）來檢查。"它做到的條件，現在滿足了嗎？"如果滿足了，AI 就自動停下來；如果沒滿足，它就會繼續往下。

這個設計很關鍵。

不是 AI 自己判斷自己有沒有做完，而是有一個獨立的"裁判"在判斷。

這樣 AI 就不會自說自話地宣佈「做完了」，也不會因為不確定而一直卡在那裏。

所以你看到的狀態是：/goal 激活後，AI 在那裏跑啊跑，你偶爾能看見它彙報進展，但它不會動不動就停下來等你。你只需要等着它說「搞定了」，或者你主動去詢問一下它的當前進展。

如何使用 /goal

在不同的 AI 工具裏，/goal 的打開方式略有不同。你用的是哪個，就看哪一段兒。

Claude Code CLI
這個最簡單。裝好了 Claude Code，直接在對話裏輸入 /goal 就行，不需要額外設置。

Codex CLI
需要兩步。第一，在設置裏確認 goals = true；第二，如果想減少每次操作後的確認彈窗，可以加一個啓動參數，在終端裏輸入：

codex --approval-mode full-auto

Codex 桌面端
一樣的邏輯，打開 Settings，找到 Configuration，把 goals 打開就行。

如果你用的是 Claude Code 的網頁版或者桌面版，基本也是直接就能用 /goal，不需要額外配置。

萬一你輸入了 /goal 但它沒反應，大概率是因為你還在一個沒確認過信任協議的工作空間裏，因為 /goal 是需要在已確認信任的環境裏才能運行。這個要注意！

怎麼寫好 /goal 提示詞

這是最關鍵的部分。

/goal 用起來簡單，但效果好不好的關鍵在於：你怎麼描述這個「完成條件」。

很多人用不好 /goal，不是工具的問題，是提示詞寫得不對。

說白了，寫 /goal 提示詞有個基礎模板，你記住這個就夠了：

/goal [你要 AI 做的事] 直到 [可衡量怎麼才算完成了] 且 [過程中必須遵守的約束]

這樣的格式解決了一個核心問題「怎麼才算幹完了」。

舉個例子：

/goal 修復所有失敗的測試，直到 npm test 返回 0，且不修改 /auth 目錄以外的任何文件

這個目標清晰吧？

「npm test 返回 0」就是可衡量的完成狀態，「不修改 /auth 目錄以外的任何文件」是約束。

AI 很清楚自己該往哪走，也知道什麼時候該停下來。

反過來，如果你的目標是模糊的，比如「把代碼優化一下」，會發生什麼？

AI 不知道「優化」到什麼程度算好。它可能改兩下就覺得差不多了，然後停下來跟你報告。也可能改了半天還在糾結哪裏還能再優化一下，然後一直跑下去。

兩種情況都挺讓人頭疼的。

所以，寫 /goal 提示詞的核心原則就是：把「完成」變成一件可以測量的事兒。

如果你想做的任務本身是模糊的怎麼辦？

比如「把這個論文改成某個期刊的格式」。這事兒似乎沒有明確的完成點。但其實你可以換個思路，給它一個清單，讓 AI 逐項檢查。

比如你把目標寫成：根據提供的 checklist.md，把論文格式調整成 ICML 風格，且不改變論文的技術內容。

然後你提供一個檢查清單，裏面列了 N 多條格式要求，比如字體的、行距的、引用格式的、頁邊距的...等等）。

AI 每完成一條就勾掉一條，它只需要判斷「我已經勾完了幾條」就行了。這樣就把一個模糊的任務變成了可以數數、可以測量的具體操作。

再說一個常見的錯誤：約束寫太多或者寫太少。

約束太少，AI 在幹活兒的過程中可能會順便改了一些你不希望它改到的地方。而約束太多呢，AI 又有可能根本跑不起來，找不到滿足所有約束的解題方式。

一個好的約束標準它得是「必須保持不變的東西」，而不是「你希望它做的事」。

比如「不修改 /auth 目錄以外的文件」是約束；但「讓它多考慮一下代碼可讀性」就不是約束。這是你希望它做的事兒，不是必須保持的邊界。

讓 /goal 效率翻倍的三個習慣

會用 /goal 之後，還有三件事兒能讓它的效果明顯提升。

這三點是我看過了大量實際使用案例之後提煉出來的，你照着做就行。

習慣一：反饋循環越快越好

/goal 能持續工作的原因，是它每一步都能得到反饋。比如我這樣做對嗎？離目標近了嗎？

反饋越快，AI 修正錯誤的速度就越快，效率就越高。反過來，如果反饋很慢，比如每次驗證需要等好幾分鐘，AI 就要花大量時間在等待中消耗。

這在編程任務裏特別明顯。

比如你要 AI 優化一個機器學習模型，不要讓它一開始就用完整的訓練數據集和完整的模型參數來測試。跑一次要幾天，那 AI 每次試個方案都得讓你苦等好幾天才知道，這誰受得了。

更好的做法是用一個小數據集加上一個小模型，讓反饋週期從「幾天」變成「幾分鐘」。等 AI 找到有效的方向了，再用完整的數據和模型來跑。這樣就能省出很多的時間。

你在用 /goal 的時候也可以這樣思考：這一步能不能更快得到反饋？如果現在這一步要等很久，有沒有更小的驗證方式？

習慣二：給 AI 準備「工作日誌」文件

如果你讓 /goal 跑一個需要幾小時甚至幾天的複雜任務，光靠 AI 的「腦子」記住所有上下文是很難的。它在這個過程中會不斷忘記，會混淆，會在長對話裏丟失重要信息。

所以，在複雜任務裏，建議你給 AI 提供三個 Markdown 文件來跟蹤進度：

PLAN.md
記錄整體計劃。AI 在開始之前先讓它計劃好自己打算怎麼做，你也可以在這裏提前放進你的一些思路，這樣 AI 做事兒會更有方向感。

EXPERIMENTS.md
記錄每次嘗試。AI 每次試了一個方案，就會把方案內容、為什麼選這個方案、結果怎麼樣記錄在裏面。這個文件最重要，因為它讓 AI 能回顧「上次試了什麼？效果如何？」，而不是悶頭兒重複走不通的路。

EXPERIMENT_NOTES.md
實時思考筆記。你可以把它看作是一個 AI 的「草稿紙」，它可以在裏面寫當前正在想什麼、打算怎麼做、遇到了什麼問題。這個文件主要是讓你能看懂 AI 在做什麼，方便你在需要的時候介入指導。

這三個文件不需要你手動創建，你可以讓 AI 自己創建並寫入。你只需要在 /goal 的提示詞里加一句「請在 PLAN.md、EXPERIMENTS.md、EXPERIMENT_NOTES.md 裏記錄你的進度」就行。

習慣三：配合這些配套命令使用

/goal 不是孤零零存在的，它有幾個配套的命令，用好了效率翻倍：

/plan —— 查看 AI 當前的計劃。如果你想知道它打算怎麼做、進展到哪一步了，輸入這個。

/pause —— 暫停當前的目標。AI 會停在原地，等你繼續指令。

/goal clear —— 重置目標。如果你改變了想法，想換個方向，就用這個清除當前目標。

一個常見的用法：比如你設置了一個 /goal，然後用 /plan 查看它的計劃是不是你想的那個方向；如果方向偏了，你用 /goal clear 清掉重來；確認方向對了之後，再讓它繼續跑。

一些真實示例

說了這麼多，來點能直接用的例子。你把任務描述換成你自己想做的事兒就行，結構可以直接套用。

場景一：給項目加一個深色/淺色主題切換

/goal 給當前項目加一個深色/淺色主題切換功能。把用戶的選擇保存到 localStorage 裏，更新 UI 樣式以支持兩種主題，並在瀏覽器裏驗證功能正常工作

這個任務包含三個動作：加功能、保存設置、驗證工作。AI 會自己跑完整個流程，最後告訴你搞定了沒。

場景二：改進項目的 README

/goal 改進當前項目的 README，讓一個新人能夠快速完成安裝、運行、測試、理解項目這四件事

這個適合接手別人的開源項目，或者讓自己很久以前的項目 README 重新可用。AI 會從新手視角審視現有文檔，補上缺失的說明。

場景三：做行業研究

/goal 研究最近關於 /goal 命令的所有最新信息，整理成一份結構清晰的報告

這個不限於技術，可以用在你需要了解某個話題的場景。AI 會自己去搜索、整理、總結，最後給你一份報告。

甚至可以直接為 AI 設定目標，讓它研究最近關於 Codex 應用內瀏覽器升級的所有最新信息，並使用 /hyperframes 製作成一個視頻。

當目標設定非常清晰的時候，完全不需要你干預，它幹完活兒就會找你。從全網搜索到視頻製作完成，整體用時不過 5 分鐘。

場景四：清理無用的代碼和依賴

/goal 找出項目中不再使用的代碼、未被引用的依賴和過時的文件，然後告訴我哪些可以安全刪除

這個很實用，特別是維護了很久的項目。AI 會分析代碼依賴，列出可以清理的東西，但刪除的動作會等你確認，防止誤刪。

場景五：修復所有失敗的測試

/goal 修復所有失敗的測試，直到 npm test 返回 0，且不修改 /auth 目錄以外的任何文件

這個例子在文章開頭也有說到。這是程序員最常用的場景之一，AI 會自己跑測試、定位問題、修改代碼、再次驗證，直到所有測試通過。

而對於複雜的項目，可以遵循以下這個 /goal 終極提示詞（記得收藏起來~），放入 Claude Code 或 Codex 中，Agent 可連續運行數小時，零人工干預。

/goal [最終交付成果 — 用一句話描述"完成"的標準]

一、背景信息
項目：[你正在構建的內容]
技術棧：[編程語言、框架、基礎設施]
當前狀態：[目前已有的基礎]
工作目錄：[本地路徑或代碼倉庫]
限制條件：[預算、時間、不可觸碰的紅線]
目標受眾：[該項目的面向對象]

二、成功標準（必須全部滿足）
1. [具體的、可量化的結果]
2. [具體的、可量化的結果]
3. [具體的、可量化的結果]
4. 最終交付物運行無報錯
5. 能夠提供證明（屏幕截圖、測試輸出結果、URL 連結）

三、操作守則（絕不妥協）
1. 規劃先行。在編寫任何代碼之前，輸出帶有編號的任務列表。
2. 自主推進。除非真正遇到阻礙，否則不要詢問澄清性問題。
3. 自我驗證。在每一步之後運行測試，檢查輸出，確認其有效。
4. 自主調試。如果運行失敗，自行診斷並修復。不要將問題拋回給我。
5. 善用工具。使用 MCP、終端、網絡搜索、代碼執行、拉取真實數據。
6. 拒絕佔位符。不留 TODO 註釋，不寫 stubs，必須是真實的組件 + 真實的狀態。
7. 進度日誌。記錄已完成項、進行中項、架構決策、阻礙因素。
8. 緊扣目標。發現規範之外的問題？記錄下來並繼續推進當前任務。
9. 遇阻對策。記錄遇到的「死衚衕」，繼續執行所有可並行處理的任務。
10. 停前自查。重新閲讀成功標準，確認每一項均已達成。

四、質量紅線
代碼：整潔、強類型、遵循項目規範
設計：媲美資金充裕的初創公司發佈的產品標準
產出：能夠通過資深工程師的代碼審查
文檔：記錄每一個新的模式 / 環境變量 / 架構決策

五、最終交付清單
- 確認已滿足所有成功標準
- 列出所有已創建 / 修改的文件
- 提供運行 / 測試 / 部署的指南
- 提供證明材料（屏幕截圖、測試輸出結果、URL 連結）
- 記錄已做出的決策 + 其他需要知曉的事項
- 列出已知限制 + 後續待辦事項
- 首先輸出你的執行計劃。然後端到端執行到底，直到任務完成或真正遇到阻礙前，不要停下來與我確認。

這就是設定目標，你轉身離開，之後回來驗收 AI 交付的成果。

可能會遇到的問題

一個 session 只能跑一個 /goal

如果你設置了新的 /goal，之前的就會自動被替換。所以不要同時跑兩個目標，想換就清掉舊的再說。

目標不能太模糊

如果你寫的目標連你自己都不知道「怎麼才算完成」，AI 就更不知道了。

這種情況 AI 可能會跑很久然後最終放棄，或者一直停不下來，Token 白白被消耗。

所以，記得寫完目標之後自己在腦子裏先過一遍，思考一下：如果我來做這件事兒，該怎麼才算交差？如果這個問題你自己都回答不上來或者非常模糊，那就繼續把目標寫得更具體些。

評估依賴 AI 的輸出內容

/goal 的檢查機制本質上是看「對話記錄裏有沒有達到條件的證據」，它不能自己去跑命令或者讀文件。

所以寫條件的時候要想着「AI 完成這件事兒之後，會在對話裏留下什麼可檢查的結果？」

比如「npm test 返回 0」是可以的，因為測試結果會顯示在對話裏。但如果你的條件需要 AI 去讀取某個外部系統才能驗證，就不太適合使用 /goal 了。

不是所有任務都適合用 /goal

一個很明顯就能完成的小任務，直接說就行，不用給自己找麻煩，非得繞一圈用 /goal。

/goal 的優勢在於能省去你一步步批准的過程，適合需要多步驟、長時間運行的任務。

如果你只是讓 AI 幫你查個東西或者寫個一句話的回覆，正常對話就夠了。

寫在最後

/goal 功能的本質上就是解決「人成為了 AI 工作的瓶頸」這個很實在的問題。

它讓 AI 能夠持續幹活兒，不需要你一步步批准，把「說一聲就自己幹完再找你」變成了現實。

用好它的關鍵就是三句話：

第一，設定清晰、可衡量的完成條件。 模糊的目標是讓 /goal 失效最常見的原因。

第二，保持反饋循環緊密。 驗證越快，AI 效率越高。

第三，給複雜任務準備工作日誌。 讓 AI 能記住自己走到哪兒了，也讓你能看懂它在做什麼。

現在，就可以打開你常用的 AI Coding Agent 工具，從一個最簡單的小任務開始，看看 /goal 是怎麼跑完整個流程的。

試完一次你就懂了。

既然看到這兒了，如果覺得還不錯，幫忙隨手點個「贊」、「在看」、「轉發」三連；如果想第一時間收到推送，也可給我加個星標★，非常感謝！