> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # Codex goal 指令怎麼寫？AI agent 做不好，八成不是模型笨，是你的目標沒寫成可驗證的合約 - URL: https://growthhackers.tw/blog/codex-goal-command-verifiable-contract/ - Published: 2026-08-06T01:00:00.000Z - Updated: 2026-08-06T01:00:00.000Z - Description: 「幫我做一份報告」這句話對人有感覺，對 AI agent 卻缺三件事：怎麼驗證、哪裡不能碰、什麼時候該停。解碼向陽喬木的開源 skill，把模糊任務寫成七欄合約，並修正我七月講過的一句話：模糊詞不該刪掉，該翻譯成驗證條件。 - Author: Lewis wang - Tags: AI agent, Agent Skills, Codex, AI 協作, 工作流 「幫我做一份上個月的成效報告。」 這句話你對同事講，他大概知道要幹嘛。他知道要抓哪幾個平台的數字、知道老闆只看轉換不看曝光、知道格式要跟上一份一樣、知道遇到帳號沒權限要先來問你。 同一句話你丟給 AI agent，你會拿回一份東西。 那份東西可能格式全新、可能自己去撈了不該撈的資料、可能少了兩個平台但它沒說、也可能它卡住之後自己發明了一個做法繼續往下跑，跑了四十分鐘，最後你全部要重來。 然後你的反應通常是：我 prompt 寫得不夠清楚，下次寫長一點。 如果你問我，這就是整件事開始走歪的地方。 最近我看到一份開源專案，把這個問題拆得很乾淨。它叫 [qiaomu-goal-meta-skill](https://github.com/joeseesun/qiaomu-goal-meta-skill?ref=growthhackers.tw)，作者是向陽喬木（X: [@vista8](https://x.com/vista8?ref=growthhackers.tw)），MIT 授權，目前在 GitHub 上有 800 多顆星。它做的事情很單純：把你一句模糊的需求，轉成一份 Codex 可以直接執行的 `/goal` 指令。 但真正值錢的不是這個工具。 是它背後那句沒有明講、但整份設計都在講的話：**你的 agent 做不好，八成不是模型笨，是你給的目標根本沒辦法被驗證。** 先說清楚，我知道不是每次都這樣。有時候真的是權限沒開、資料本身就髒、或是模型能力還沒到。但在日常的行銷任務裡，我看到最常見的狀況，是根本沒人幫它畫一條終點線。 --- ## 人話對 agent 缺的三件事：怎麼驗證、哪裡不能碰、什麼時候該停 我先講一件我自己踩過的事。 我現在寫部落格、跑數據、做圖，很多環節都交給 agent 在跑。有一次我派了一批任務出去，派工單寫得很順，讀起來完全沒問題。結果收回來的時候，有幾篇文章的狀態被改掉了，還有幾條站內連結，是 agent 自己「猜」出來的網址。 它不是亂來。它是照著我寫的東西做的。 問題在於我寫的那份派工單裡，沒有一句話說「已經排好的狀態不要動」，也沒有一句話說「連結要去資料庫查真實網址，不准用資料夾名稱推測」。這兩件事對我來說是常識，我根本沒想過要寫。 對 agent 來說，沒寫就等於沒有。 這件事跟我早年在雨傘產業帶工廠的經驗，其實一模一樣。你跟做了十年的老師傅說「這批做得挺一點」，他知道你在說傘骨的張力。你跟一個新來的說同一句話，他可能把顏色改深了。老師傅腦袋裡有一整套你沒講出來的規格，新人沒有。 AI agent 就是那個聰明得不得了、但完全沒有你們公司常識的新人。 向陽喬木這份 skill 的做法，是把一句人話補成七個欄位。我把它翻成行銷團隊聽得懂的版本： - **Outcome（成果）**：要交出什麼，用結果寫，不要用動作寫 - **驗證（Verification）**：怎麼證明它真的做到了，要指名具體的證據 - **約束（Constraints）**：什麼絕對不能改、不能加 - **邊界（Boundaries）**：只准動哪些檔案、哪些範圍 - **迭代策略（Iteration policy）**：失敗了怎麼修，最多修幾輪 - **完成條件（Stop when）**：什麼情況算做完，可以收工 - **暫停條件（Pause if）**：什麼情況必須停下來問人 ![AI 任務合約的七個欄位：成果、驗證、約束、邊界、迭代策略、完成條件、暫停條件](https://growthhackers.tw/content/images/2026/08/inline-seven-fields-v1.png) 我猜你看完這七項，第一個念頭是「這也太麻煩了吧」。 我懂。但你把「幫我做一份上個月的成效報告」照這七格填一次看看： > `/goal` 產出上個月的整合成效報告，涵蓋 Google Ads、Meta、GA4 三個來源，格式沿用專案內既有的月報範本。 > **驗證**：先讀取專案裡現有的月報檔案確認欄位定義，跑完資料後把三個平台的花費加總與後台總數對帳，差異超過 1% 要標記出來，並附上截圖或匯出檔當證據。 > **約束**：不新增範本沒有的指標，不自行更改歸因視窗，不修改任何原始資料表。 > **邊界**：只寫入本月報告資料夾，不動歷史月份的檔案。 > **迭代策略**：對帳不過先看日誌找出差異來源再重跑，最多三輪，還是對不起來就停下來報告。 > **完成條件**：三個平台數字都對得起來，報告產出，或明確列出哪個平台缺權限。 > **暫停條件**：需要新的帳號權限、需要動用付費 API、或需要判斷某筆異常花費該不該列入時，停下來問我。 差別在哪？ 差別在第一個版本，你只能等它跑完再用眼睛檢查。第二個版本，它自己知道什麼叫做完，也知道什麼時候該回頭找你。 以前你要把人教會，靠的是他坐在你旁邊三個月。現在你要把 agent 教會，靠的是你把那三個月的常識，寫進一份它看得懂的合約。 --- ## 模糊詞不要刪掉，要翻譯成驗證條件（我要修正自己七月講過的話） 接下來這段，我看完是有被打臉的感覺。因為它推翻了我自己七月才寫過的一個說法。 我在〈[用 AI 的高手不寫更長的 prompt，他們設計「驗收迴圈」](https://growthhackers.tw/blog/ai-agent-verification-workflow/)〉那篇裡講過，別用「吸引人」「有質感」這種模糊詞，改成可量化的清單。 向陽喬木的做法不一樣。他在 SKILL.md 裡寫的原則是：**「高級」「有質感」「專業」不是壞詞，壞的是把它們當完成標準。** 所以不要刪掉它們。 要把它們**翻譯**成驗證條件。 原始碼裡的講法是，遇到這類詞，要轉成「截圖檢查、執行時檢查、審查標準、或迭代規則」。README 給的例子更具體：把「有質感」拆成看層級、間距、字體、可讀性，然後加一句「最多做三輪聚焦視覺改進」。 ![模糊詞不刪掉而是翻譯成驗證條件：有質感翻成層級、間距、字體、可讀性，加上最多三輪](https://growthhackers.tw/content/images/2026/08/inline-translate-vague-v1.png) 這個轉念我覺得很重要，你知道為什麼嗎？ 因為「刪掉模糊詞」這個建議，實際上做不到。 你去問任何一個老闆他要什麼，他就是會說「做得高級一點」。你去問品牌端窗口，她就是會說「這版看起來不夠有質感」。這些是他們腦中真實的評判標準，你把它刪掉，等於把唯一的方向感也刪掉了，最後做出一個每個數字都達標、但沒人想按下上線的東西。 我做百貨專櫃那幾年，主管講的話幾乎都是這種等級的。「陳列要有精品感。」你不會回他「請給我量化定義」，你會自己翻譯成：主色不超過三個、高低差要拉出來、燈打在主推款、走道兩公尺外看得到品名。 翻譯，不是刪除。 現在你要對 agent 做的，是同一件事，只是你要把翻譯的結果寫下來。 實際操作起來長這樣。假設你要 agent 做一封「有質感的品牌 EDM」，你不要刪掉「有質感」，你把它翻成驗證條件： > **驗證**：首屏三秒內看得到主賣點；字級至少三個層次，內文不小於 15px；CTA 按鈕與背景對比度符合無障礙標準；用手機截圖檢查按鈕沒有被折到；全文比對品牌禁用語清單；最多做三輪視覺修改，第三輪還不行就把版本交給我看。 「有質感」還在標題裡，它是方向。下面那六條才是判準。 這件事本質上是把你腦中的品味，變成一份別人也能照著打分的標準。我之前寫過一篇 [怎麼把 AI 的品質評分校準到能信](https://growthhackers.tw/blog/ai-evals-quality-calibration/)，講的是同一個動作的下一步：當你要打分的東西變多，這份翻譯表就得變成正式的評分表。 --- ## 預設先推進，高風險才煞車：讓 AI 不那麼卡的那個心法 還有一個設計，我覺得是這份 skill 最實用、但最容易被略過的地方。 很多人用 agent 覺得卡，是因為它動不動就停下來問你。你要它做個網頁，它問你要用什麼框架、要不要響應式、配色有沒有指定，你光回答就花了十分鐘，還不如自己做。 這份 skill 的內建原則寫得很直白：**低風險的不確定性，不要攔用戶填表。**做出明確假設，給最佳預設值，往下走，然後用一句話告訴你為什麼這樣選。 那什麼時候該停？它列了六類： - 憑證、帳號、付費 - 生產資料、破壞性操作 - 法律、醫療、金融判斷 - 版權素材、官方授權 - 上架發布、真實部署 - 所有權或產品方向不清 ![預設先推進與高風險才暫停的分流：低風險直接假設往下走，六類高風險踩煞車](https://growthhackers.tw/content/images/2026/08/inline-pause-risk-v1.png) 你把這六類對照一下自己的工作，會發現它幾乎精準命中了行銷團隊所有會出事的地方：廣告帳號、正式環境的資料、素材版權、還有「按下發布」這個動作。 如果你熟悉「雙向門與單向門」的決策分類，這其實就是同一套邏輯搬到 AI 身上：可以回頭的決定，讓它自己走；推出去就收不回來的決定，一律停下來等人。（這個分類我在 [決策疲勞那篇](https://growthhackers.tw/blog/decision-fatigue-two-way-door-sbi-scqa/) 寫得比較完整。） 我自己的規矩很簡單，也建議你照抄：**AI 可以寫、可以做、可以生成，但按下發布的那一下，永遠是人。** 這份 skill 的邊界寫得也很老實，它自己聲明：只負責生成 `/goal` 指令，不會替你執行；不會幫你繞過版權、帳號、付費、生產資料；陌生領域不會把專業規則編造成事實。 會把自己不做什麼寫清楚的工具，通常比較可靠。 --- ## 它附了一支 linter，會把你寫壞的 goal 指令直接退件 這個專案還附了一支自動退件的小程式，會直接判你的目標寫得夠不夠格。 它擋的東西很好猜：七欄缺一欄、留著沒填的占位符、寫了「隨便改」「keep trying」「直到滿意」這種話、或是驗證欄裡完全沒有具體證據字眼。 但我讀原始碼的時候，發現兩個 README 沒提的門檻，滿有意思的： - 目標正文**少於 20 個字元**，判定「太短，不可執行」 - 七欄裡任何一欄**少於 12 個字元**，判定「太單薄」 換句話說，你不能用「驗證：確認可用」這種話交差。機器會直接算長度把你打回票。 一支小程式，把「你的派工單寫得夠不夠好」這件很主觀的事，變成一個可以自動跑的關卡。（同樣的做法我也寫過怎麼在 [Claude Code 裡把手動檢查變成驗證關卡](https://growthhackers.tw/blog/claude-code-skill-verification-loop/)。） 不過講句實話，你不裝這個 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 課程重點](https://growthhackers.tw/blog/agent-skills-andrew-ng-course/)。 --- ## 寫更長的 prompt，不如寫更可驗證的目標 我覺得這幾年最大的認知轉變，是從「怎麼把 prompt 寫得更長」，換成「怎麼把目標寫得可以被驗證」。 長度不等於明確度。 能被判定通過或失敗，才等於明確度。 你手上的模型，很可能已經比你會用的強很多了。真正卡住你的，是你還在用交代同事的方式，交代一個沒有你們公司常識的新人。 把那份常識寫下來。就從「驗證」跟「暫停條件」這兩欄開始。 本文解碼的開源專案為 [qiaomu-goal-meta-skill](https://github.com/joeseesun/qiaomu-goal-meta-skill?ref=growthhackers.tw)，作者向陽喬木（[X: @vista8](https://x.com/vista8?ref=growthhackers.tw)、[GitHub: joeseesun](https://github.com/joeseesun/?ref=growthhackers.tw)），採 MIT 授權釋出。文中對運作方式的描述以該專案 `SKILL.md` 與 `scripts/lint_goal_command.py` 原始碼為準。感謝作者把這套方法開源出來。 --- **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。