最近開發圈很熱鬧。OpenAI 的 Codex CLI 和 Anthropic 的 Claude Code，先後都推出了一個叫做 /goal 的功能。
官方說法聽起來很厲害：設定一個目標，AI agent 就會自主迭代、反覆嘗試，跑十幾個小時也不停——a16z 的合夥人 Andrew Chen 甚至讓它跑了 14 個小時來處理裝置驅動程式，整夜沒有人工介入。
聽到這裡，很多人的反應是：「哇，程式開發終於有自動駕駛了！」
我的第一個反應也差不多，但隨即冒出另一個念頭——
「等一下，目的地呢？」
自動駕駛再厲害，你總得先知道要開去哪裡吧。而且不是那種「往北開」的模糊方向，是要有確切地址、預估到達時間、以及「到了」的判斷標準。
這讓我開始琢磨：/goal 真正的使用門檻，大概不是技術，而是——你有沒有能力定義目的地？
先試一次：跟司機說「帶我去一個好地方」
我試著寫了一個 /goal 的提示詞：
/goal 修正「登入」功能中，session 機制沒有正常運作的問題。看起來很合理對吧？仔細一想——什麼叫「沒有正常運作」？
是登入後根本沒建立 session？還是建立了但下一個 request 就消失？還是 session 存在但權限判斷讀不到？這三種是完全不同的 bug，修法也不一樣。怎麼驗證「修好了」？可以動到哪些檔案？如果 AI 為了修 session 去把整個認證架構重寫了呢？
這些，全部沒定義。
等於上了車跟司機說：「帶我去一個好地方。」司機可能帶你去他覺得好的地方，但那不一定是你要的。更慘的是，你到了之後搞不好也不確定「這到底算不算好」。
然後我發現，如果真要把目標、邊界、驗證方式、停止條件全部寫清楚，像這樣：
/goal 修正登入功能的 session 問題。
現象：POST /api/login 回傳 200 並設定 session，
但下一個 GET /api/profile 回傳 401。
驗證方式：執行 tests/auth/ 目錄下的測試，
特別是 test_session_persistence.py 必須通過。
限制：只能修改 src/middleware/session.js 和 src/routes/auth.js。
停止條件：上述測試全部通過，且 git diff 只涉及允許修改的檔案。寫完的瞬間我愣了一下——這不就是一份 spec 嗎？
等一下，那跟 SDD 有什麼不同？
如果 /goal 需要的前置定義跟 SDD（Spec-Driven Development）差不多，那它到底幫我省了什麼？Spec 都寫好了，照著做就好了啊。
仔細拆開來看，兩者的差異在於「誰需要理解什麼」。
SDD 的 spec 描述的是「要做什麼＋為什麼這樣做」，讀它的人需要理解意圖，然後運用工程判斷把它變成程式碼。Spec 到實作之間有一段需要人類智慧的距離。
/goal 的契約描述的是「做到什麼狀態算完成」，讀它的 agent 不需要理解為什麼，只需要反覆嘗試直到驗證通過。
好，差異我懂了。但更根本的問題是粒度。
一個完整 MVP 的 spec 對 /goal 來說太大了。這個司機只會很有耐心地重複「開一段路→看看到了沒→沒到就繼續開」的迴圈。你給他一整本旅遊指南，他大概會在第三個十字路口開始打轉。
社群裡也有人提醒：「/goal 會把 prompt 中的模糊性放大，跨越數小時的運算。」意思是——如果你的方向本來就有點模糊，跑 14 小時只會讓它用 14 小時的 token 去放大那個模糊。
所以 /goal 需要的不是一份完整的 spec，而是粒度剛好的標準——比一個 prompt 大，但比一整個 backlog 小。
問題是：什麼東西的粒度剛好？
你手邊已經有地圖了
這是我整個思考過程中最關鍵的一個轉彎。
我回頭看自己在日常開發過程中累積的那些 Skill——程式碼風格、錯誤處理 規範、文件標準、架構原則。這些東西本來是為了對話模式而寫的，讓 AI 在開發當下就能產出符合我品味的程式碼。
然後突然意識到：咦！？這些 Skill 裡面，不就已經包含了 /goal 需要的大部分契約要素了嗎？
什麼該做、什麼不該動、品質標準是什麼——全部都定義好了。差的只有一件事：Skill 沒有寫「停止條件」和「驗證方式」。
但這只需要在 /goal 的 prompt 裡面補三行就夠了：掃哪裡、怎麼驗證、什麼時候停。
回到旅行的隱喻來想——
你不需要為了 /goal 從零開始規劃行程。你早就在累積旅行經驗了。那些「我喜歡什麼、不喜歡什麼、什麼對我重要」的品味，已經沉澱在你的 Skill 裡面。你沒有注意到它們可以拿來當 /goal 的參照，只是因為你原本不是為了這個目的而寫的。
但仔細想想——目的地，本來就是行程規劃的必然結果。
你不會先買機票再想去哪裡（正常情況下啦…）。你是先有了興趣、累積了偏好、做了功課，然後目的地自然就浮現了。Skill 就是那些累積的偏好，/goal 只是最後那張機票。
開發時預防，開發後矯正
到這裡，/goal 在整個開發工作流裡的角色就清楚了。它跟 Skill 不是同一層的東西，而是同一個品味體系的兩個時間面：
| Skill | /goal | |
|---|---|---|
| 時間軸 | 開發當下（前向） | 開發完成後（後向） |
| 功能 | 生成時的品質引導 | 生成後的品質稽核 |
| 性質 | 預防——從一開始就做對 | 矯正——找出不一致並修正 |
Skill 是「生成時的品質引導」——開發當下，確保 AI 產出的程式碼從一開始就符合規範。這是前向的、即時的、在對話模式中自然發生的。
/goal 是「生成後的品質稽核」——程式碼已經存在了，用 /goal 拿著 Skill 當標準，回頭去掃描和修正不符合規範的部分。這是後向的、批次的、自主迴圈。
一個是預防，一個是矯正。Skill 是主體，/goal 是 Skill 的執行手臂。
實際操作時，/goal 的 prompt 變得很精簡：
/goal 根據 error-handling skill 的規範，
檢查 src/routes/ 下所有 route handler。
每修正一個檔案後執行對應測試。
全部通過時停止。你不需要在 /goal 裡重新解釋什麼叫「統一的錯誤處理格式」——那已經寫在 Skill 裡了。/goal 只負責定義「掃哪裡、掃到什麼程度算完成」。
品味的定義是困難的，但品味定義完之後的部署，可以是很輕鬆的。
一個大家沒注意到的缺口
講到這裡，可能有人會說：「Code review 不就是在做這件事嗎？我們團隊一直都有 review 流程啊。」
沒錯。但大家平常說的 code review，和我這裡說的稽核，其實是兩件不同的事。
PR review 是關卡式的——每一筆 PR 提交時，由人（或 AI）根據規則檢查一道，通過了才能合併。這個流程在很多團隊裡運作得很成熟，也確實能攔住一部分品質問題。
但關卡式 review 有一個結構性的盲區：它只作用在增量上，對存量沒有效果。
你今天定義了一份 錯誤處理 的 Skill，但三個月前寫的程式碼，是在這份 Skill 還不存在的時候寫的。PR review 只能確保「從今天起」新程式碼符合標準，不會回頭去修正過去的不一致。而且團隊成員更替、規範理解不同、趕 deadline 時 review 品質下降——這些都會讓不一致性持續累積。
那些不一致性以「技術債」的形式默默存在著。大家都知道該處理，但要一個一個檔案打開、對照規範、修正、測試——成本太高了，所以永遠排在「下次再說」。
| 關卡式（PR Review） | 回溯式（Skill + /goal） | |
|---|---|---|
| 作用時機 | 每一筆新提交 | 需要時主動觸發 |
| 覆蓋範圍 | 這一筆 PR 的變更 | 指定範圍的全部既有程式碼 |
| 處理的問題 | 未來的品質問題（攔截） | 過去的不一致性（清償） |
Skill + /goal 讓回溯式稽核的成本降到可接受的程度。/goal 真正解決的不是「讓已經在做的事更快」，而是**「讓之前成本太高所以沒人做的事，變得可行了」**。
它不是效率工具。它是技術債清償工具。
不過這裡有一個信任邊界要留意。AI 稽核能確保的是一致性（程式碼是否符合規範），不是正確性（業務邏輯是否正確）。一個函數可以完美符合所有命名規範和 錯誤處理 規範，但計算邏輯是錯的。確定性工具（測試、編譯器、型別檢查）負責回答「是不是」，人負責定義「是什麼」，AI 負責在兩者之間跑腿。三者的角色不該混淆。
順序對了，一切就順了
回到一開始的問題：你的 AI 司機知道要開去哪嗎？
現在我的答案是：如果你有一直在累積行程筆記（Skill），目的地（Goal）會自然浮現。你不需要為了自動駕駛而臨時發明一個目的地。
品味先行，執行隨後。先在對話中養成判斷力，把它沉澱成 Skill。等到某天你發現有一整片程式碼需要對齊你的標準時，/goal 就是那個幫你跑完全程的自動駕駛。
不是每條路都需要自動駕駛。但當你確實知道要去哪的時候，不用自己握方向盤，挺好的。
本文的觀點來自對 /goal 功能限制條件的邏輯推演，搭配社群早期使用者的經驗佐證。DOFI 本人目前尚未進行大量的 /goal 實作，但 25 年的開發經驗告訴我——工具會一直變，但「先搞清楚自己要什麼」這件事，從來沒變過。
參考資訊：
- OpenAI Codex /goal 官方文件：
https://developers.openai.com/codex/use-cases/follow-goals - OpenAI Codex Best Practices（「如果工作流仍需要很多引導，先把它變成 skill」）：
https://developers.openai.com/codex/learn/best-practices - Ralphable 的 /goal 深度分析（「Skills 是詞彙，goals 是工作」）：
https://ralphable.com/blog/codex-goal-command-ralph-loop-openai-built-in-autonomous-coding-agent-2026 - agentskills.io — 跨平台 SKILL.md 開放標準：
https://agentskills.io/home
