Codex goal 指令怎麼寫？AI agent 做不好，八成不是模型笨，是你的目標沒寫成可驗證的合約

「幫我做一份上個月的成效報告。」

這句話你對同事講，他大概知道要幹嘛。他知道要抓哪幾個平台的數字、知道老闆只看轉換不看曝光、知道格式要跟上一份一樣、知道遇到帳號沒權限要先來問你。

同一句話你丟給 AI agent，你會拿回一份東西。

那份東西可能格式全新、可能自己去撈了不該撈的資料、可能少了兩個平台但它沒說、也可能它卡住之後自己發明了一個做法繼續往下跑，跑了四十分鐘，最後你全部要重來。

然後你的反應通常是：我 prompt 寫得不夠清楚，下次寫長一點。

如果你問我，這就是整件事開始走歪的地方。

最近我看到一份開源專案，把這個問題拆得很乾淨。它叫 qiaomu-goal-meta-skill，作者是向陽喬木（X: @vista8），MIT 授權，目前在 GitHub 上有 800 多顆星。它做的事情很單純：把你一句模糊的需求，轉成一份 Codex 可以直接執行的 /goal 指令。

但真正值錢的不是這個工具。

是它背後那句沒有明講、但整份設計都在講的話：你的 agent 做不好，八成不是模型笨，是你給的目標根本沒辦法被驗證。

先說清楚，我知道不是每次都這樣。有時候真的是權限沒開、資料本身就髒、或是模型能力還沒到。但在日常的行銷任務裡，我看到最常見的狀況，是根本沒人幫它畫一條終點線。

人話對 agent 缺的三件事：怎麼驗證、哪裡不能碰、什麼時候該停

我先講一件我自己踩過的事。

我現在寫部落格、跑數據、做圖，很多環節都交給 agent 在跑。有一次我派了一批任務出去，派工單寫得很順，讀起來完全沒問題。結果收回來的時候，有幾篇文章的狀態被改掉了，還有幾條站內連結，是 agent 自己「猜」出來的網址。

它不是亂來。它是照著我寫的東西做的。

問題在於我寫的那份派工單裡，沒有一句話說「已經排好的狀態不要動」，也沒有一句話說「連結要去資料庫查真實網址，不准用資料夾名稱推測」。這兩件事對我來說是常識，我根本沒想過要寫。

對 agent 來說，沒寫就等於沒有。

這件事跟我早年在雨傘產業帶工廠的經驗，其實一模一樣。你跟做了十年的老師傅說「這批做得挺一點」，他知道你在說傘骨的張力。你跟一個新來的說同一句話，他可能把顏色改深了。老師傅腦袋裡有一整套你沒講出來的規格，新人沒有。

AI agent 就是那個聰明得不得了、但完全沒有你們公司常識的新人。

向陽喬木這份 skill 的做法，是把一句人話補成七個欄位。我把它翻成行銷團隊聽得懂的版本：

• Outcome（成果）：要交出什麼，用結果寫，不要用動作寫
• 驗證（Verification）：怎麼證明它真的做到了，要指名具體的證據
• 約束（Constraints）：什麼絕對不能改、不能加
• 邊界（Boundaries）：只准動哪些檔案、哪些範圍
• 迭代策略（Iteration policy）：失敗了怎麼修，最多修幾輪
• 完成條件（Stop when）：什麼情況算做完，可以收工
• 暫停條件（Pause if）：什麼情況必須停下來問人

我猜你看完這七項，第一個念頭是「這也太麻煩了吧」。

我懂。但你把「幫我做一份上個月的成效報告」照這七格填一次看看：

/goal 產出上個月的整合成效報告，涵蓋 Google Ads、Meta、GA4 三個來源，格式沿用專案內既有的月報範本。
驗證：先讀取專案裡現有的月報檔案確認欄位定義，跑完資料後把三個平台的花費加總與後台總數對帳，差異超過 1% 要標記出來，並附上截圖或匯出檔當證據。
約束：不新增範本沒有的指標，不自行更改歸因視窗，不修改任何原始資料表。
邊界：只寫入本月報告資料夾，不動歷史月份的檔案。
迭代策略：對帳不過先看日誌找出差異來源再重跑，最多三輪，還是對不起來就停下來報告。
完成條件：三個平台數字都對得起來，報告產出，或明確列出哪個平台缺權限。
暫停條件：需要新的帳號權限、需要動用付費 API、或需要判斷某筆異常花費該不該列入時，停下來問我。

差別在哪？

差別在第一個版本，你只能等它跑完再用眼睛檢查。第二個版本，它自己知道什麼叫做完，也知道什麼時候該回頭找你。

以前你要把人教會，靠的是他坐在你旁邊三個月。現在你要把 agent 教會，靠的是你把那三個月的常識，寫進一份它看得懂的合約。

模糊詞不要刪掉，要翻譯成驗證條件（我要修正自己七月講過的話）

接下來這段，我看完是有被打臉的感覺。因為它推翻了我自己七月才寫過的一個說法。

我在〈用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」〉那篇裡講過，別用「吸引人」「有質感」這種模糊詞，改成可量化的清單。

向陽喬木的做法不一樣。他在 SKILL.md 裡寫的原則是：「高級」「有質感」「專業」不是壞詞，壞的是把它們當完成標準。

所以不要刪掉它們。

要把它們翻譯成驗證條件。

原始碼裡的講法是，遇到這類詞，要轉成「截圖檢查、執行時檢查、審查標準、或迭代規則」。README 給的例子更具體：把「有質感」拆成看層級、間距、字體、可讀性，然後加一句「最多做三輪聚焦視覺改進」。

這個轉念我覺得很重要，你知道為什麼嗎？

因為「刪掉模糊詞」這個建議，實際上做不到。

你去問任何一個老闆他要什麼，他就是會說「做得高級一點」。你去問品牌端窗口，她就是會說「這版看起來不夠有質感」。這些是他們腦中真實的評判標準，你把它刪掉，等於把唯一的方向感也刪掉了，最後做出一個每個數字都達標、但沒人想按下上線的東西。

我做百貨專櫃那幾年，主管講的話幾乎都是這種等級的。「陳列要有精品感。」你不會回他「請給我量化定義」，你會自己翻譯成：主色不超過三個、高低差要拉出來、燈打在主推款、走道兩公尺外看得到品名。

翻譯，不是刪除。

現在你要對 agent 做的，是同一件事，只是你要把翻譯的結果寫下來。

實際操作起來長這樣。假設你要 agent 做一封「有質感的品牌 EDM」，你不要刪掉「有質感」，你把它翻成驗證條件：

驗證：首屏三秒內看得到主賣點；字級至少三個層次，內文不小於 15px；CTA 按鈕與背景對比度符合無障礙標準；用手機截圖檢查按鈕沒有被折到；全文比對品牌禁用語清單；最多做三輪視覺修改，第三輪還不行就把版本交給我看。

「有質感」還在標題裡，它是方向。下面那六條才是判準。

這件事本質上是把你腦中的品味，變成一份別人也能照著打分的標準。我之前寫過一篇 怎麼把 AI 的品質評分校準到能信，講的是同一個動作的下一步：當你要打分的東西變多，這份翻譯表就得變成正式的評分表。

預設先推進，高風險才煞車：讓 AI 不那麼卡的那個心法

還有一個設計，我覺得是這份 skill 最實用、但最容易被略過的地方。

很多人用 agent 覺得卡，是因為它動不動就停下來問你。你要它做個網頁，它問你要用什麼框架、要不要響應式、配色有沒有指定，你光回答就花了十分鐘，還不如自己做。

這份 skill 的內建原則寫得很直白：低風險的不確定性，不要攔用戶填表。做出明確假設，給最佳預設值，往下走，然後用一句話告訴你為什麼這樣選。

那什麼時候該停？它列了六類：

• 憑證、帳號、付費
• 生產資料、破壞性操作
• 法律、醫療、金融判斷
• 版權素材、官方授權
• 上架發布、真實部署
• 所有權或產品方向不清

你把這六類對照一下自己的工作，會發現它幾乎精準命中了行銷團隊所有會出事的地方：廣告帳號、正式環境的資料、素材版權、還有「按下發布」這個動作。

如果你熟悉「雙向門與單向門」的決策分類，這其實就是同一套邏輯搬到 AI 身上：可以回頭的決定，讓它自己走；推出去就收不回來的決定，一律停下來等人。（這個分類我在 決策疲勞那篇 寫得比較完整。）

我自己的規矩很簡單，也建議你照抄：AI 可以寫、可以做、可以生成，但按下發布的那一下，永遠是人。

這份 skill 的邊界寫得也很老實，它自己聲明：只負責生成 /goal 指令，不會替你執行；不會幫你繞過版權、帳號、付費、生產資料；陌生領域不會把專業規則編造成事實。

會把自己不做什麼寫清楚的工具，通常比較可靠。

它附了一支 linter，會把你寫壞的 goal 指令直接退件

這個專案還附了一支自動退件的小程式，會直接判你的目標寫得夠不夠格。

它擋的東西很好猜：七欄缺一欄、留著沒填的占位符、寫了「隨便改」「keep trying」「直到滿意」這種話、或是驗證欄裡完全沒有具體證據字眼。

但我讀原始碼的時候，發現兩個 README 沒提的門檻，滿有意思的：

• 目標正文少於 20 個字元，判定「太短，不可執行」
• 七欄裡任何一欄少於 12 個字元，判定「太單薄」

換句話說，你不能用「驗證：確認可用」這種話交差。機器會直接算長度把你打回票。

一支小程式，把「你的派工單寫得夠不夠好」這件很主觀的事，變成一個可以自動跑的關卡。（同樣的做法我也寫過怎麼在 Claude Code 裡把手動檢查變成驗證關卡。）

不過講句實話，你不裝這個 skill 也沒關係。

七個欄位你抄下來貼在記事本，效果有九成。

給行銷／成長團隊的四個行動建議

► 第一：挑一個你這禮拜真的會派給 AI 的任務，現在就改寫。 不要挑假想的任務，挑那個你已經派過、而且結果讓你不太滿意的。

► 第二：那份改寫，先只寫三欄：驗證、邊界、暫停條件。 七欄第一次不用寫滿，但這三欄缺一不可。「驗證」決定它知不知道自己做完沒，「邊界」決定它會不會亂動別的東西，「暫停條件」決定它闖不闖得了禍。

► 第三：挑一個你們團隊最常講的模糊詞，翻成五條可檢查的條件。 「有質感」「高級一點」「像官網那種」，選一個就好。這份翻譯表對新來的實習生一樣有用，不是只寫給 AI 看的。

► 第四：把會花錢、會寄出去、會動到正式資料的動作，永遠釘在暫停條件裡。 廣告上線、EDM 寄出、貼文發佈、資料庫寫入。不管你多信任你的 agent，這四件事都讓它停下來等你點頭。

常見問題

Q：Codex 的 /goal 指令到底要寫什麼？
A：把任務寫成「成果」而不是「動作」，再補上六項：驗證方式、約束、可寫入的邊界、迭代規則、完成條件、暫停條件。最關鍵的是驗證欄要指名具體證據，例如要跑哪個檢查、要看哪個日誌、要截哪張圖，不能只寫「確認可用」。

Q：我每天只是叫 AI 寫寫文案、拉個報表，也需要搞七欄這麼麻煩嗎？
A：不用每次都寫。一次性的小任務直接講就好。但只要這個任務你會重複派、或是做錯了要花時間收拾，就值得寫一次存起來當範本。判斷標準是「錯了我要花多久補救」，不是任務大小。

Q：品牌感、質感這種東西，到底要怎麼驗證？
A：不要刪掉那個詞，把它翻譯成可檢查的項目。「有質感」可以翻成字級層次、間距、對比度、手機上截圖確認沒破版，再加一條「最多改三輪」。方向感留在形容詞裡，判準寫在下面那幾條。

Q：哪些事情可以讓 agent 自己決定，哪些一定要停下來問我？
A：可以回頭的讓它自己走，收不回來的一律停。實務上這六類要停：帳號憑證、付費、正式環境資料、破壞性操作、版權素材、以及任何「按下發布」的動作。

Q：我不用 Codex，用 Claude Code 或 ChatGPT，這套還適用嗎？
A：適用。七欄的本質是派工，不是寫程式，你貼在任何一個對話框裡都有效。至於原作者提供的安裝方式是 npx skills add joeseesun/qiaomu-goal-meta-skill（npx skills 是第三方開源的 agent skill 安裝器，npm 套件名為 skills，由 Vercel Labs 維護，拿 GitHub 當套件庫，會串進 Claude Code、Codex、Cursor 各自的 skills 資料夾，需要先有 Node.js）。不熟 Agent Skills 的話，可以先看我整理的 Andrew Ng 課程重點。

寫更長的 prompt，不如寫更可驗證的目標

我覺得這幾年最大的認知轉變，是從「怎麼把 prompt 寫得更長」，換成「怎麼把目標寫得可以被驗證」。

長度不等於明確度。

能被判定通過或失敗，才等於明確度。

你手上的模型，很可能已經比你會用的強很多了。真正卡住你的，是你還在用交代同事的方式，交代一個沒有你們公司常識的新人。

把那份常識寫下來。就從「驗證」跟「暫停條件」這兩欄開始。

本文解碼的開源專案為 qiaomu-goal-meta-skill，作者向陽喬木（X: @vista8、GitHub: joeseesun），採 MIT 授權釋出。文中對運作方式的描述以該專案 SKILL.md 與 scripts/lint_goal_command.py 原始碼為準。感謝作者把這套方法開源出來。

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。