SKILL.md 怎麼寫才好用？description 與五種設計模式一次搞懂
SKILL.md 怎麼寫才好用？很多人第一支 Skill 做出來，AI 卻不照做，問題通常不在格式，而在內容設計。這篇拆解兩個關鍵：description 怎麼寫才會被正確叫出、規則怎麼寫 AI 才照做，並用行銷情境改寫 Google Cloud 整理的五種 Skill 設計模式，附上一張寫 SKILL.md 的自我檢查表。
第一支 Skill 做出來，AI 卻不照做？問題通常不在格式，而在內容設計。這篇用行銷情境拆解 description 怎麼寫、規則怎麼下，以及五種好用的 Skill 設計模式。
格式對了，AI 卻還是不照做
很多行銷人做完第一支 Skill 會遇到同一個挫折：檔案格式明明照規範寫了，AI 卻沒在該用的時候叫出它，或者叫出來了卻沒照規則做。
問題通常不在格式。一支 Skill 通常是一個資料夾，裡面至少有一個 SKILL.md；它的格式規範其實很簡單，檔案最上方用一段 YAML frontmatter（也就是 SKILL.md 開頭那段寫名稱與用途的設定區）寫 name 和 description，下面用 markdown 寫指令就好。真正決定一支 Agent Skill 好不好用的，是內容設計：你有沒有把「什麼時候該用它」和「拿到資料後一步步該怎麼做」寫清楚。這篇就專門講這兩件事。
最多人卡住的地方，都不是技術
帶同事寫 Skill 的時候，我發現大家卡住的地方幾乎都一樣，不是搞不定檔案，而是寫得太籠統。
「幫我分析會員」「語氣專業一點」這種描述，人看得懂，AI 卻無從照做，因為它不知道「分析」要看哪些指標、「專業」長什麼樣。寫 Skill 的功夫，多半在於把這些模糊的話，翻成具體到不會誤解的規則。
第一個關鍵：description 決定 AI 要不要叫它出來
description 是 AI 判斷「要不要自動叫出這支 Skill」的主要依據。寫得好不好，直接決定它會不會在對的時候被叫出來。
Anthropic 官方對 description 的規範很明確：它必須說清楚這支 Skill 做什麼，以及什麼情境該用它。一個常見的錯誤是只寫「做什麼」、漏了「什麼時候用」。
| 寫法 | 範例 | 結果 |
|---|---|---|
| 太籠統 | 「製作報表」 | AI 不確定哪種報表、何時該用，容易漏叫或亂叫 |
| 只寫功能 | 「製作每月行銷報表」 | 知道做什麼，但不知道什麼情境觸發 |
| 功能＋情境（建議） | 「當使用者要從成效資料製作每月行銷報表，涵蓋流量、會員、廣告指標時使用」 | AI 比較能在對的任務自動對上 |
一個好記的 description 公式是：使用情境 ＋ 使用者意圖 ＋ 任務產物 ＋ 邊界條件。例如「當使用者要把會員、流量、活動資料整理成月報，並需要固定欄位、口徑與結論格式時使用」。
另外有幾個格式限制要記住：name 長度約在 1 到 64 字元，只能用小寫字母、數字和連字號，不要用連字號開頭或結尾，通常也要和資料夾名稱一致；description 介於 1 到 1024 字元、不能空白，並避開平台明列的保留字（例如有些平台不允許用 anthropic、claude 這類字當名稱）。把情境寫進 description，是讓 Skill 被正確叫出的第一步。如果你不確定怎麼起頭，經理人提到的 Skill Creator這類工具可以先幫你生一版 description，再由你補上情境細節。
第二個關鍵：用五種設計模式把規則寫對
description 解決「要不要叫出來」，接下來是「叫出來之後怎麼做對」。Google Cloud 的技術團隊整理過五種實用的 Skill 設計模式，以下用行銷情境改寫，並依行銷團隊常用度重新排序，你可以對照自己的工作挑一種來套。
模式一：生成器（Generator）。 用固定的輸出結構和模板，解決 AI 產出格式不一致的問題。適合月報、活動復盤、社群貼文這類需要穩定格式的產出。寫法重點是把「輸出長什麼樣」用範例釘死。
模式二：審查者（Reviewer）。 把檢查標準獨立寫成一支 Skill，重複用來審東西。適合文案合規檢查、品牌禁用詞把關。寫法重點是列出明確的檢查清單，讓 AI 逐項比對；同時要寫明 Reviewer 的工作是指出問題、風險等級與建議修法，而不是直接改成定稿。
模式三：先問清楚（Inversion）。 讓 AI 在動手前，先把缺的資訊一個一個問清楚，而不是急著產出。適合活動企劃、提案這種需要多個輸入的任務。寫法重點是寫明「資料不齊時要先問什麼」。
模式四：流水線（Pipeline）。 把複雜工作拆成明確步驟，每一步設一個過關條件。適合多階段的流程，例如先撈資料、再分析、最後產出建議。寫法重點是把步驟和過關門檻寫清楚；涉及預算、受眾排除、優惠策略時，最後一步要設人工確認。
模式五：工具包裝（Tool Wrapper）。 把某個服務或平台的使用規則封裝起來。對非工程團隊來說，它通常不是寫 API，而是把固定後台、報表工具或會員平台的標準操作規則封裝成這類 Skill。
多數行銷工作，用得最多的是生成器和審查者這兩種。
共通心法：能寫具體，就不要寫抽象
把這些拆開看會發現，寫好 Skill 的心法其實只有一條：把抽象的話翻成具體的規則。
「語氣專業」改成「用第三人稱、不用驚嘆號、結論放最前面」；「分析會員」改成「看主力客、新客、流失風險客三群，各列回購率與客單價」。AI 沒辦法猜你心裡的標準，你寫得越具體，它自由發揮的空間就越小，產出就越穩。這也是為什麼 當每個品牌都用得到 AI，真正的差距會回到「誰能把自己的判斷標準說清楚」。
一個實際案例：把檔案變成符合組織標準的產出
雲端內容平台 Box 在 Anthropic 官方分享的 Agent Skills 案例中提到，導入 Skills 後，使用者可以把存放的檔案，直接轉成符合公司標準格式的 PowerPoint、Excel 和 Word，省下大量手工整理。這正好印證這篇的重點：當你把品牌的格式規範寫進 Skill，也就是上面說的生成器模式，AI 產出的報表、簡報、文件第一版就照你的標準走，而不是每次重排。
要提醒的是，Box 是國際大型企業，情境和台灣中小行銷團隊不同，這個案例是「方向證據」，說明把格式標準寫進 Skill 確實能省下重工，不是可直接套用的成效保證。
數據類 Skill，規則要寫進口徑與分群定義
如果你的 Skill 牽涉數據分析，規則就要寫到口徑層級，否則 AI 很容易用錯數字。
月報該用哪一套 ROAS 算法、分群怎麼定義、比較基準是上月還是去年同期，這些都要明白寫進規則。如果團隊已經有 CDMP 或會員經營系統，就把既有的分群名稱、指標口徑與報表定義寫進 Skill，AI 產出的整理才會貼合你品牌的定義，而不是套用一般常識。這也呼應人機協作的分工：規則和口徑由人定義清楚，AI 負責照著穩定執行，最後的判讀和決策仍回到人手上。想看怎麼把第一支數據型 Skill 從零做起，可以參考月報 Skill 的手把手教學。
寫 SKILL.md 前，先過這張檢查表
動筆前用這幾項對照，能少走很多冤枉路。
| 檢查項 | 沒寫好的症狀 | 怎麼修 |
|---|---|---|
| description 有沒有寫情境 | Skill 沒在該用時被叫出 | 補上「當使用者要做……時使用」 |
| 規則夠不夠具體 | AI 每次產出都不一樣 | 把抽象形容詞翻成可檢查的條件 |
| 有沒有附輸出範例 | 格式飄移 | 放一份理想輸出貼進 Skill |
| 數據口徑有沒有定義 | 數字算錯或對不起來 | 每個指標附一句算法 |
| 有沒有設人工把關點 | AI 產出直接被當定稿 | 明訂哪些結論要人確認 |
關鍵心法是：Skill 不是寫給人看的說明，是寫給 AI 照做的規則。 凡是人需要「自己意會」的地方，對 AI 都要寫成明白的指令。想更系統地練習怎麼設計 Skill 內容，可以參考 Anthropic 與 DeepLearning.AI 的 Agent Skills 課程。
好的 Skill，是把你的判斷寫到 AI 不會誤解
回到開頭那個「格式對了卻不照做」的挫折。
答案幾乎都在內容設計：description 沒寫清楚情境，規則沒具體到不會誤解。把這兩件事做好，同一個 AI 的產出會更穩定，也比較容易被檢查與修正。寫 Skill 的過程，其實是逼自己把腦中那套做事方法講到一清二楚，這件事本身對團隊就有價值。下一次想改 Skill 時，別急著加更多指令，先回頭看 description 有沒有說清楚觸發情境，再看規則能不能被逐項檢查。
對行銷團隊來說，這是一個值得練的基本功。寫得出好 Skill 的人，不是最懂技術的人，是最能把自己的判斷講清楚的人。
品牌最常問的寫 SKILL.md 問題
Q1：SKILL.md 的格式很難嗎？ A1：格式很簡單，最上方一段 YAML frontmatter 寫 name 和 description，下面用 markdown 寫指令就好。真正花功夫的是內容設計，也就是把「什麼時候用」和「拿到資料後怎麼做」寫清楚，這才是決定 Skill 好不好用的關鍵。
Q2：為什麼我的 Skill 沒在該用的時候被叫出來？ A2：多半是 description 沒寫好。description 是 AI 判斷要不要用這支 Skill 的依據，要同時寫清楚「做什麼」和「什麼情境用」。只寫功能、漏了情境，AI 就不容易在對的任務對上它。
Q3：規則要寫到多細才夠？ A3：細到 AI 不需要自己意會為止。把「語氣專業」這種抽象描述，翻成「用第三人稱、不用驚嘆號、結論放最前面」這種可檢查的條件。涉及數據時，還要把指標口徑和分群定義寫進去，避免算錯。
Q4：Skill 設計模式那麼多種，行銷人該用哪個？ A4：多數行銷工作用得最多的是生成器（固定輸出格式，像月報、貼文）和審查者（固定檢查標準，像文案合規）。其他模式視任務而定，不用一次學完，先挑最貼近你手上工作的一種來套。
Q5：寫好的 Skill 之後要一直改嗎？ A5：會需要持續微調。第一版很難一次到位，通常要用真實任務試跑幾次，把 AI 跑歪的地方回頭補進規則。把它當成會隨需求演進的文件，而不是一次寫死的東西。
Q6：不會寫程式，能寫出好用的 Skill 嗎？ A6：可以寫出不需要程式的 Skill，重點是把規則寫清楚；只有當你要串接工具或自動處理檔案時，才可能需要工程協作。會不會寫好 Skill，比較取決於你能不能把自己的做事方法講具體，這正是行銷人本來就在做的事。
延伸閱讀
- 第一個 Agent Skill 怎麼做？行銷人的每月報表 Skill 手把手教學
- Agent Skill 能幫行銷團隊做什麼？10 個零售場景
- Agent AI Skill 是什麼？行銷人從 Prompt、MCP 到 Agent Skill 一次看懂
- 團隊怎麼導入與維護 Agent Skill？從個人玩具到團隊資產
- Skill、Prompt、MCP 差在哪？MCP 和 Skill 不同在哪？非工程師背景的你更要懂
- AI Agent 是什麼？和 Agent Skill 差在哪，行銷人一次搞懂
想把會員分群、報表口徑與活動檢討的判斷標準整理成可重複使用的團隊方法，不妨先從一件每週都會重複的工作開始。