前言¶

用 AI 編程助手改代碼時，最常見的翻車方式不是模型“不會寫”，而是目標本身寫得太糊。一句「把結賬接口弄快點」「看看這個 PR 評論」「繼續排查一下」，聽起來像任務，其實只是活動描述：沒有可驗證的完成態，沒有證據，也沒有範圍邊界。Agent 往往會先改一堆文件，再回頭問你“這樣算不算好了”。

OpenAI 在官方 Agent Skills 倉庫裏提供了一個精選 Skill：define-goal。它的職責很窄——只在開始幹活之前，把模糊意圖收成一條具體、可衡量、可驗證的目標；需要時再通過目標工具把它登記下來。本文按官方 SKILL.md 與 Codex Goals 相關說明，介紹它是什麼、怎麼裝、怎麼用。

這是什麼¶

define-goal 是 OpenAI 維護的 curated Skill，源碼目錄在：

https://github.com/openai/skills/tree/main/skills/.curated/define-goal

目錄裏主要有 SKILL.md（工作流與質量標準）、agents/openai.yaml（Codex 側展示名與默認提示）、以及 Apache 2.0 的 LICENSE.txt。Skill 的 frontmatter 名稱就是 define-goal，描述大意是：在用戶要求創建目標、澄清成功標準，或把模糊意圖變成可量化結果時，幫助定義具體、可衡量的目標；它只負責目標創建與打磨，不負責持久快照、決策日誌或長週期執行產物。

和 Codex 的 Goals 能力是配套關係。Codex 從 0.128.0 起支持持久目標：用戶可用 /goal 管理生命週期，模型側則有 get_goal / create_goal 等工具。define-goal 把「先把目標寫合格，再 create_goal」寫成可複用流程，避免一上來就開一個糊目標。

說明：openai/skills 倉庫 README 已標註該倉庫 deprecated，並指向 OpenAI Plugins 作爲當前 Codex skill/plugin 示例入口；但截至本文寫作時，define-goal 仍可在上述 curated 路徑直接查看與安裝。Agent Skills 本身是通用的 SKILL.md 格式，Cursor、Claude Code、Codex CLI 等支持該標準的工具都能加載同一套說明；其中 get_goal / create_goal 屬於 Codex Goals 工具面，其他環境主要複用「把目標寫合格」這一段流程。

核心工作流¶

官方 SKILL.md 把流程拆成六步，順序很清楚。

1、先確認是否真的需要定目標。
用戶顯式提到 $define-goal、要創建/設置目標、要用 goal 工具，或希望把意圖收成清晰目標時，才走這套流程。如果用戶只是在要普通實現（改個 bug、加個小功能），直接幹活，不要強行插一層 goal creation。

2、用具體語言重述目標。
一條可用目標至少要說清：完成後什麼會爲真；涉及哪個產物、系統、倉庫、環境或用戶可見行爲；如何驗證完成；範圍內是什麼；歧義會影響結果時，範圍外是什麼；以及什麼情況下應停下來問用戶，而不是繼續空轉。

3、能量化就量化。
優先寫代表真實成功的數字或二元條件，而不是裝飾性精度。官方舉的幾類證據包括：

• 通過/失敗類驗證：具體測試、檢查、CI job、eval、命令或驗收標準
• 質量閾值：延遲、錯誤率、成本、準確率/召回/精確率、覆蓋率、flaky 率、包體積、內存、可用性、完成率，或人工評審標準
• 產物約束：文件路徑、受影響模塊、允許的命令、輸出格式、目標環境、截止時間、最大改動半徑
• 證據計數：復現次數、連續成功 rerun、審過的樣例數、遷移記錄數、已處理評論數、已覈實用例數

4、弱目標先修再設。
本地上下文足夠時，把含糊目標改寫成可衡量目標；缺的細節會改變結果或驗證方式時，只問一個簡短澄清問題。純活動型表述——「推進一下」「繼續查」「改善一下」「弄弄 X」——除非能 sharpen 成可驗證結果，否則應拒絕當目標。

5、創建前先看當前目標狀態。
先調用 get_goal。沒有活躍目標且質量達標，再 create_goal；已有目標且仍匹配用戶意圖，繼續用，不要重複創建；已有目標與新請求衝突，則詢問用戶：先完成當前目標、若已完成則標完成，還是另開一條 goal-backed 線程。

6、質量過關後再創建。
目標用一條簡潔的 objective 字符串；驗證證據寫進目標本身；有約束就寫進範圍；僅當用戶明確要求時才帶 token budget。用戶沒有明確要求 goal-backed 工作時，不要因爲任務有多步就擅自 create_goal。

目標質量標準：好目標與弱目標¶

創建前，objective 應能回答這五個問題：完成後什麼具體事實爲真？用什麼證據證明？成功的量化或二元閾值是什麼？哪些範圍邊界重要？什麼情況該停下來問人？

官方給出的好例子類似下面這樣——結果、改動半徑、驗證命令和重複次數都寫在同一句話裏：

Reduce checkout API p95 latency below 250 ms for the documented slow path by making the smallest safe server-side change, then verify with `npm run test:checkout` and the existing local latency benchmark showing p95 under 250 ms across 3 consecutive runs.

再比如處理 PR 評論：

Resolve the open review comments on PR 123 that request code changes, update only the affected auth files and tests, and verify with the targeted auth test command plus `gh pr view 123` showing no unresolved change-request threads.

弱目標則是「Make checkout faster.」「Keep investigating the PR comments.」——有動作，沒有完成態。

對不同任務，官方還給了量化啓發式：修 bug 時儘量「先復現、再修復」，最好有失敗後變通過的驗證器；寫測試要寫清命令與通過條件；做性能要寫清指標、閾值、測法與跑幾次；做質量要有可觀察驗收條（樣例評審、lint/typecheck/test、或用戶認可的產物）；做研究要寫清研究要支撐什麼決策、資料範圍與證據標準；做運維要寫清健康態、觀測窗口、失敗閾值與回滾/升級觸發條件。

澄清問題時也要剋制。只有「合理改寫可能追錯方向」時才問，問題要短，對準缺失的驗證器或範圍邊界。官方建議的問法包括：成功用延遲、成本、準確率還是用戶可見行爲定義？在 local、staging 還是 production 驗證？最少要看到什麼證據才能標完成？用戶給不出指標時，提出當前最誠實的二元驗證器，請對方確認即可。

安裝與啓用¶

在 Codex 中安裝¶

按 openai/skills 倉庫 README，curated Skill 可用系統自帶的 $skill-installer 按名稱安裝（默認對應 skills/.curated）：

$skill-installer define-goal

也可以直接指向 GitHub 目錄 URL：

$skill-installer install https://github.com/openai/skills/tree/main/skills/.curated/define-goal

安裝後需要重啓 Codex，新 Skill 纔會被加載。Codex 側 UI 元數據在 agents/openai.yaml：展示名爲 Define Goal，短描述爲 Shape clear measurable goals，默認提示會引導先用 $define-goal 把意圖收成可衡量目標再開工。

若要配合 Goals 能力，確認 Codex 版本至少爲 0.128.0。用戶側常用 /goal、/goal pause、/goal resume、/goal clear；若 slash 列表裏沒有 /goal，可按官方說明啓用 features.goals（例如在 config.toml 中配置，或執行 codex features enable goals）。

在 Cursor / Claude Code 等工具中使用¶

define-goal 遵循通用 Agent Skills 目錄結構：一個文件夾 + SKILL.md。把官方目錄拷到各工具會掃描的 skills 路徑即可，例如：

• Cursor：項目內 .cursor/skills/define-goal/SKILL.md，或用戶級 ~/.cursor/skills/define-goal/SKILL.md
• Claude Code：.claude/skills/define-goal/ 或 ~/.claude/skills/define-goal/
• Codex：除 $skill-installer 外，也可放到其 skills 目錄（具體以當前 Codex 文檔爲準）

文件夾名建議與 frontmatter 的 name: define-goal 一致。加載後，可用 $define-goal / 工具對應的 skill 調用方式觸發，或直接說「幫我把這個意圖定義成可衡量目標」。需要強調的是：沒有 Codex Goals 工具時，Skill 仍可約束 Agent「先寫清目標再動手」；真正調用 get_goal / create_goal 登記活躍目標，仍依賴宿主是否提供這些工具。

典型用法示例¶

場景一：你只有一句糊需求。
可以對 Codex / 支持該 Skill 的助手說：

用 $define-goal：我想把結賬接口弄快點，先把目標定清楚，先不要改代碼。

按工作流，Agent 應重述成帶指標、驗證命令與範圍的 objective；缺關鍵閾值時只問一個短問題；質量達標且你明確要 goal-backed 工作時，再 get_goal → create_goal。

場景二：PR 評論很多，怕 Agent 改飛。
可以這樣開場：

$define-goal
請把「處理 PR 123 裏要求改代碼的 review 評論」收成一條可驗證目標，範圍限制在 auth 相關文件和測試。

對照官方好例子，最終目標應同時包含：處理哪些評論、改哪些文件、用哪條測試命令、以及如何用 gh pr view 確認沒有未解決的 change-request。

場景三：普通實現任務不要硬套。
如果你說的是「給這個函數加個空指針檢查並補單測」，按 Skill 說明應直接實現，而不是先強制 create_goal。Goal 適合路徑不確定、但完成線清晰的長程工作；一次性小改動用普通提示往往更合適。

適用場景與注意事項¶

適合：性能優化、flaky 排查、依賴遷移、需要先復現再修復的 bug、benchmark 驅動調參、以及必須交付可檢查產物的研究/審計類任務——也就是「有清晰終點，但中間路徑要邊做邊看」的工作。

不適合或需謹慎：用戶只要普通多步實現、並未要求 goal-backed 時，不要擅自建目標；不要把「推進進度」類活動描述直接塞進 create_goal；本 Skill 明確不創建中間計劃產物、持久快照、ledger、決策日誌或 resume 文件——那些屬於別的規劃/執行機制。

另外，create_goal 的 objective 應是單條簡潔字符串，驗證與範圍寫在裏面；token budget 僅在用戶明確要求時附加。已有活躍目標時先處理衝突，避免重複目標把線程狀態攪亂。

小結¶

define-goal 做的事很剋制：在 Agent 動手前，把意圖收成「結果 + 證據 + 閾值 + 範圍 + 停問條件」。它和 Codex Goals（/goal、get_goal、create_goal）對齊，也把「先定目標再執行」固化成可移植的 SKILL.md 流程。

官方地址：https://github.com/openai/skills/tree/main/skills/.curated/define-goal

若關注 Codex 當前 skill/plugin 分發方式，也可同時查看 OpenAI 的 Plugins 倉庫與 Using skills in Codex 文檔；Goals 用法可參考 Using Goals in Codex。