核心答案：Claude Code Skill 是一個由 YAML frontmatter、System Prompt、References、Output Spec 四層組成的 AI Agent 模組，能被 Claude 自動觸發、可被組合串聯。學會做 skill，等於把 Claude 從「對話工具」升級成「自動駕駛工作流」。本文用真實範例拆解結構、帶你 5 步驟做出第一個能跑的 skill，並附上 3 個設計原則和 6 個我自己每天在用的 skill 範例。
快速摘要
| 重點 | 說明 |
|---|---|
| 什麼是 Skill | 可被觸發、可被組合的 AI Agent 模組（不是 prompt template） |
| 四層結構 | YAML Frontmatter → System Prompt → References → Output Spec |
| 第一個 Skill 怎麼做 | 5 步驟：定義輸入輸出 → 建目錄 → 寫 description → 寫 system prompt → 測試 |
| 三個設計原則 | 寫判斷標準（不寫頭銜）、Progressive Disclosure、明確處理 edge case |
| 進階威力 | 多 skill 串聯成 chain，搭配 MCP 連接外部資料源 |
| 實際效益 | Gucci 自用 6 個 skill，每週省 12 小時以上 |
開場：你每天都在重打同一份 prompt，這就是問題
老實說，我用 Claude Code 工作的第一個月，最常做的事情不是寫程式，是在重複打同樣的指令。
「幫我把這篇文章轉成 Facebook 長文，風格要像我之前那篇⋯然後 hook 要強一點⋯然後不要 markdown 符號⋯」
每次都要重打。每次都要解釋一次風格。每次都要把背景脈絡再講一遍。
直到有一天我意識到：我不是在使用 AI，我是在當 AI 的人工 RAG。
那一刻我才真正搞懂 Claude Code Skills 在解決什麼問題。
如果你還沒接觸過 Claude Code Skills，建議先讀我之前寫的入門介紹。這篇是進階版——看完你會：
- 知道 Skill 的四層結構，能拆解任何別人寫的 skill
- 跟著步驟做出第一個真的能在你工作流裡跑的 skill
- 掌握 prompt 設計的三個核心原則（這是 90% 的人會卡住的地方）
- 學會把多個 skill 串成 chain，讓 Claude 從副駕駛變成自動駕駛
→ Skill 不是 prompt template，是讓 Claude 從「對話工具」升級到「AI Agent」的關鍵一步。
一、Claude Code Skill 到底是什麼
很多教學會說 skill 是「進階的 prompt template」。這個說法不算錯，但會讓你低估它。
Skill 的真正定義：一個可被觸發、可被組合、有結構化輸入輸出的 AI Agent 模組。
關鍵字是「可被觸發」和「可被組合」。它不是你貼進 chat 窗的一段提示詞，而是 Claude Code 主動載入、主動調用的一個獨立元件。
跟其他常見概念的差別：
| 概念 | 本質 | 觸發方式 | 上下文 |
|---|---|---|---|
| Prompt Template | 一段可複製貼上的提示詞 | 手動貼上 | 每次都要重給 |
| Claude Code Skill | 模組化的 AI Agent 單元 | description 自動匹配 / 用戶 /skill-name |
Progressive Disclosure 動態載入 |
| MCP Server | 對外連接資料源/工具的協議層 | 工具呼叫（tool use） | 外部系統 |
| Agent | 完整的角色 + 工具 + 記憶 | 任務派發 | 獨立 context window |
說白一點：
→ Prompt template 是你帶在身上的小抄，skill 是 Claude 自己會去翻的工具箱。
差別在「主動性」。當 description 寫對了，Claude 會在合適的時機自己決定要用哪個 skill，不用你提醒。
這就是為什麼學會做 skill 之後，你的工作會發生一個質變：你不再是 prompt 的搬運工，你是系統的設計者。
二、Skill 的四層結構（用真實範例拆解）
每個 Claude Code Skill 都由這四層組成。我用我自己每天在用的 article-copilot skill 來拆給你看。
第一層：YAML Frontmatter（觸發層）
---name: article-copilot
description: Collaborative article writing assistant specialized in Gucci’s authentic, emotionally resonant style. Use when the user wants to write articles across various topics that aim for deep reader connection and viral potential.
---這層只有兩個欄位但決定一切：
- name：skill 的識別碼，用戶可以用
/article-copilot手動觸發 - description：這是整個 skill 最重要的一行字
description 不是寫給人看的，是寫給 Claude 看的。Claude 會根據用戶的訊息自動匹配相關 skill。
❌ 爛的 description：
“幫忙寫文章的 skill”
✅ 好的 description：
“Use when the user wants to write articles in Gucci’s style. Triggers: writing articles for blog/Facebook, articles on parenting/economics/AI, content needing emotional resonance.”
差別在哪？好的 description 說清楚了「在什麼情境下該用這個 skill」，並列出觸發關鍵字。Claude 會用這段話跟用戶輸入做語意比對。
→ description 寫得越精準，skill 越會在對的時候自動跳出來。
第二層：System Prompt（判斷層）
這是 skill 的主體。不是說「你是文章寫作專家」這種無意義的角色設定，而是寫判斷標準和執行流程。
<h2>Mandatory Load Order</h2>- view references/style-guide.md
- view references/personal-context.md
- view references/modular/01-triggers-and-stage-map.md
<h2>Core Invariants</h2>
- 真實性優先：不可編造身份、經歷、對話
- Stage Gate 必須遵守：未達標不得跳關
- 與內容發布相關流程必須遵守「WordPress draft -> 等 public URL」
注意這段的特徵：
- 動詞明確（view、不可、必須）
- 條件具體（未達標不得跳關）
- 沒有「請」「儘量」這種模糊詞
→ Skill prompt 是給機器讀的法律條文，不是給人讀的文案。
第三層：References（漸進揭露層）
這是 Claude Code Skills 最強大的設計，也是大部分中文教學沒講的部分：Progressive Disclosure（漸進揭露）。
簡單說：skill 主檔只放 index，詳細內容拆到 reference 檔，需要時才載入。
article-copilot 的目錄結構長這樣：
.claude/skills/article-copilot/├── SKILL.md # 主檔：精簡入口（1KB）
├── full-spec.md # 完整規範（保底）
└── references/
├── style-guide.md # 風格指南
├── personal-context.md # 個人背景
├── research-methodology.md # 研究方法
├── workflow-details.md # 工作流程
├── modular/
│ ├── 01-triggers-and-stage-map.md
│ ├── 02-stage-gates.md
│ └── 03-output-and-handoff.md
└── example-articles/ # 範例文章庫
├── parenting.md
└── marriage.md主檔只有「Mandatory Load Order」告訴 Claude 開工前要讀哪些檔。實際的風格細節、範例、檢核清單，全在 references。
為什麼要這樣設計？
因為 context window 是錢。
如果你把所有規範都塞進主檔，每次 skill 被觸發，Claude 都要載入整份。一個 skill 5KB，十個 skill 50KB——還沒開始工作就燒掉一半 context。
Progressive Disclosure 解法：主檔只放路徑，Claude 根據當下任務的需要動態 view。寫親子文章時才載入 parenting.md，寫投資文章時就不用。
→ Skill 設計的成熟度，看 references 拆得夠不夠細。
第四層：Output Specification（輸出層）
最後一層，定義 skill 要產出什麼、放在哪、用什麼格式。
<h2>Output Paths</h2>| 輸出類型 | 路徑 |
|---|---|
| 草稿 | content/drafts/{topic}-draft.md |
| Facebook 版本 | content/drafts/{topic}-fb.md |
| Blog 版本 | content/drafts/{topic}-blog.md |沒有這層，skill 會把產出散落在各處，下游流程接不起來。
→ 想清楚輸出，skill 才能變成生產線的一個節點。
三、實戰：從零做出「一週內容排程 Skill」
理論講完，動手做。
場景設定：你每週要規劃社群貼文排程。每次都要花一小時把主題庫翻一遍、決定哪天發哪個平台、配什麼 hook。我們把這件事 skill 化。
Step 1：定義輸入和輸出
開始寫之前，先想清楚兩件事：
輸入（用戶會給我什麼？）：
- 本週主題庫（3-5 個候選主題）
- 目標平台（Facebook、LinkedIn、Threads）
- 排程偏好（一週幾篇、哪幾天）
輸出（用戶會收到什麼？）：
- 一週貼文排程表（日期 / 平台 / 主題 / hook 草稿）
- 每篇貼文的字數預估
- 為什麼這樣排的策略說明
→ 設計 skill 的第一步永遠是：畫出輸入 → 輸出的最小工作流。
Step 2：建立目錄與檔案
mkdir -p .claude/skills/weekly-content-plannercd .claude/skills/weekly-content-planner
touch SKILL.mdStep 3：寫 description（觸發關鍵）
---name: weekly-content-planner
description: Generate a weekly social media content schedule from a topic bank. Use when the user wants to plan a week of posts across platforms (Facebook/LinkedIn/Threads), needs help deciding posting cadence, or asks for a content calendar based on their topic ideas. Triggers: 一週排程、weekly schedule、社群貼文計畫、內容排程表.
---注意這段的兩個關鍵：
- 明確列出觸發情境（”when the user wants to plan…”）
- 中英文觸發詞都列（你的用戶可能用中文也可能用英文呼叫）
Step 4：寫 System Prompt（判斷標準）
<h1>Weekly Content Planner</h1><h2>When to use this skill</h2>
Use when the user provides:
- A topic bank (3+ candidate topics)
- Target platforms (any of: Facebook, LinkedIn, Threads, X)
- Optional: posting frequency preference
If any of the above is missing, ASK before proceeding. Do not invent topics.
<h2>Core principles</h2>
- <strong>平台適配</strong>：Facebook 偏長文+情感 hook、LinkedIn 偏專業洞察、Threads 偏短句節奏感
- <strong>節奏分散</strong>：同一主題不在連續兩天發（避免疲勞）
- <strong>強弱搭配</strong>：每週至少 1 篇主打文 + 2 篇輕量互動
- <strong>Hook 草稿</strong>：每篇貼文都要附 1-2 句開頭 hook，不只給標題
<h2>Execution flow</h2>
- 讀取用戶提供的主題庫
- 評估每個主題的「平台適配度」（標記 strong / medium / weak）
- 按照節奏分散原則排入週曆
- 為每篇貼文起草 hook
- 輸出排程表 + 策略說明
<h2>Output format</h2>
markdown
本週社群排程
| 日期 | 平台 | 主題 | Hook 草稿 | 預估字數 |
|---|---|---|---|---|
| Mon | FB | … | … | 800 |
…
排程策略說明
[為什麼這樣排]
`注意三個重點：
- <strong>缺資料就問，不要假設</strong>（”If any of the above is missing, ASK”）——這條救過我無數次。Skill 自作主張瞎掰主題的後果，比沒有 skill 還慘。
- <strong>判斷標準寫得具體</strong>（同一主題不連續兩天發），不是「請合理安排」這種空話
- <strong>Output format 直接給範本</strong>，Claude 會照著生
<h3>Step 5：在 Claude Code 中測試</h3>
把 skill 放好之後，在 Claude Code 開新對話：你：這週我有三個主題：
- AI agent 工作流設計
- 為什麼一人創業不該寫日報
- Claude Code skill 製作
幫我排成 Mon/Wed/Fri 三篇，分別發 LinkedIn / Facebook / Threads
如果 description 寫對了，Claude 會自動匹配到 weekly-content-planner 並執行。如果沒匹配到，你可以手動 /weekly-content-planner 觸發。第一次跑出來的結果<strong>幾乎一定不夠好</strong>。這是正常的。
我做 article-copilot 改了 30+ 次。weekly-content-planner 你預期改 10 次起跳。
→ Skill 不是寫一次就完工，是用一次改一次。每次發現產出不對，就回去改 system prompt 的判斷標準。
<h2>四、Skill Prompt 設計的三個核心原則</h2>
這是我做了十幾個 skill 之後最痛的領悟。如果你只能記三件事，記這三條。
<h3>原則 1：寫判斷標準，不要寫角色頭銜</h3>
❌ 90% 的人寫的：
markdown
你是一位資深社群行銷專家，擅長為品牌創造高互動內容。
這句話對 Claude 來說等於沒說。✅ 真正有用的寫法：
markdown
評估貼文好壞的判斷標準：
- 前三行是否能讓滑手機的人停下來
- 是否有具體場景或數字（避免抽象口號）
- 結尾是否給讀者一個明確的下一步動作
當這三項任一項不符，重寫該段。
差別：前者是給人看的 LinkedIn 自我介紹，後者是給機器執行的判斷邏輯。→ Claude 不需要你給它身份，它需要你給它<strong>標準</strong>。
<h3>原則 2：用 Progressive Disclosure 控制 context 成本</h3>
新手最常犯的錯：把所有東西塞進一個 SKILL.md，最後變成 5000 行的怪物。
正確做法：主檔只放 index 和 mandatory load list，細節拆 references。
判斷某段內容該不該拆出去：
- 這段內容<strong>每次都要用</strong>嗎？→ 留在主檔
- 這段內容<strong>特定情境才用</strong>嗎？→ 拆到 reference
- 這段內容是<strong>範例庫</strong>嗎？→ 一定拆出去
我自己的 article-copilot，主檔只有 1KB，但 references 加起來超過 50KB。Claude 每次只載入需要的部分。
→ 一個 skill 寫超過 200 行還沒拆，就是設計品質警訊。
<h3>原則 3：明確處理 edge case</h3>
skill 跑久了你會發現，最常出問題的不是核心流程，是「用戶輸入不完整」「輸入超出預期」「中途要中斷」這些邊界情況。
每個 skill 都該有這三類規則：
markdown
Edge cases
缺資料
如果用戶沒提供 [必要欄位]，停下來問，不要編造。
超出範圍
如果用戶的需求超出本 skill 的設計範圍（例如：要求生成圖片），
明確告訴用戶「這需要另一個 skill」，不要勉強做。
中斷恢復
如果上一次執行被中斷，先確認當前狀態（哪一步做完了），
再決定要從哪裡繼續，不要從頭重跑。
→ Edge case 處理寫得好，skill 才能進入生產環境。寫不好，就是 demo 等級。<h2>五、進階：Skill Chain 與 MCP 整合</h2>
單一 skill 已經夠用，但真正的 leverage 來自串聯。
<h3>多 Skill 串聯（Skill Chain）</h3>
我自己的內容生產線就是一條 chain：
weekly-content-planner（規劃）
↓
article-copilot（撰寫）
↓
kie-thumbnail-generator（生縮圖）
↓
publish-to-wordpress（上稿）
↓
mixpost-scheduler（排程社群）
↓
newsletter-to-kit（轉電子報）
每個 skill 各管一段，輸出餵給下一個。原本一篇文章從規劃到全平台發布要 3-4 小時，現在 30 分鐘搞定。→ <strong>單一 skill 是工具，skill chain 是工廠。</strong>
要讓 chain 跑得順，關鍵在「輸出格式統一」。前一個 skill 的輸出路徑，必須是後一個 skill 的預設輸入路徑。我用一個 output-paths.md 檔集中管理所有 skill 的路徑規範，避免每個 skill 自己決定。
<h3>與 MCP Server 整合</h3>
Skill 自己只能讀寫本機檔案。當你需要連接外部資料源（Notion、Supabase、n8n、Gmail），就需要 MCP（Model Context Protocol）。
MCP 是 Claude 對外連接的協議層。Skill 可以在 system prompt 裡指定「需要時使用某個 MCP tool」，Claude 會自動調用。
實際範例：我的 weekly-content-planner 升級版會直接讀我 Notion 裡的「主題庫」資料庫——用戶連主題都不用打，skill 自己去抓。
markdown
Data sources
主題庫存在 Notion 資料庫 ID xxx。執行時：
- 用 mcpclaudeaiNotionnotion-fetch 取得主題庫
- 篩選 status=”ready” 的項目
- 排入排程
`
→ Skill + MCP = 你的私人 AI Agent 真的能「動手做事」，不只是「給建議」。
關於 Claude 的記憶系統如何跟 skill 配合，可以延伸讀我寫的 OpenClaw 三層記憶架構。skill 是任務模組，記憶系統是長期狀態，兩者搭配才是完整的 AI Agent。
Claude Code Skills 與 OpenClaw Skills 的關係
這是很多人問的問題：兩者是同一個東西嗎？
簡單對照：
| 維度 | Claude Code Skill | OpenClaw Skill |
|---|---|---|
| 執行環境 | Claude Code（terminal / IDE） | OpenClaw 平台 |
| 觸發方式 | description 自動匹配 | 任務指派 |
| 適合場景 | 個人工作流、本機檔案操作 | 多人協作、跨系統流程 |
| 學習門檻 | 低（一個 markdown 檔就能跑） | 中（需懂 OpenClaw 架構） |
我的建議：先把 Claude Code Skill 用熟，再進 OpenClaw。Claude Code Skill 是入口，OpenClaw 是把同一套思維放大到團隊規模。
六、我的真實工作流：目前用了哪些 Skill
寫到這裡，你可能想問：「Skill 真的有用到值得花時間做嗎？」
我列我目前每天在跑的 skill：
| Skill | 用途 | 一次省的時間 | 一週用幾次 |
|---|---|---|---|
| article-copilot | 寫文章（這篇就是它寫的） | ~60 min | 5-10 |
| kie-thumbnail-generator | 生縮圖 | ~20 min | 5-10 |
| publish-to-wordpress | 上稿 + AEO 優化 | ~30 min | 5-10 |
| mixpost-scheduler | 多平台社群排程 | ~40 min | 3-5 |
| newsletter-to-kit | 轉電子報並上 ConvertKit | ~30 min | 2-3 |
| article-image-generator | 文內配圖 | ~25 min | 5-10 |
粗算：一週用 25 次以上，每次平均省 30 分鐘 = 每週省 12 小時以上。
這不是吹牛。這就是我從「全職寫文章一週只能出 1 篇」到「一週穩定出 3-5 篇 + 全平台發布」的關鍵。
→ Skill 不是讓你做事更快，是讓你能做以前做不到的量級。
我踩過最大的坑：過度設計
第一個 skill 我做了三天，寫了 800 行，最後發現有 60% 的功能根本用不到。
現在我做 skill 的鐵律：先做 MVP，用一週，再優化。
具體做法：
- 第一版只寫 50 行：description + 三個核心原則 + 輸出格式，停。
- 用一週：每次發現產出不對，記下來。
- 第二版才補 references：把這週遇到的 edge case、需要的範例，補進 reference 檔。
- 第三版才考慮拆模組：當 reference 累積到讓主檔讀起來吃力，才動拆分。
→ Skill 跟產品一樣：可用比完美重要，反覆修改比一次到位重要。
下一個我想做的是「YouTube 影片 → 文章 + 推廣全包」的 chain。如果你也在做類似的，歡迎進聯盟社群交流，我會把過程開源。
關於更大規模的 AI 工作系統設計，可以看我之前寫的 OpenClaw Mission Control——那是把 skill 思維放大到「一人 AI 公司」層級的實作。
結尾：從工具使用者，到系統建造者
回到開頭的那個痛點。
我不再每天重打同樣的 prompt 了。不是因為我變勤勞，是因為我做了一件懶人才會做的事——把重複的事情 skill 化。
老實說，這個轉變的影響比我想像中大很多。
→ 從前我用 Claude，像在請一個臨時工：每次工作前都要交代一遍背景。
→ 現在我用 Claude，像在指揮一個工作室：每個 skill 都是一個常駐員工，知道自己的崗位。
差別不在 Claude 變強，差別在我從「使用者」變成「建造者」。
這是 AI Agent 時代最關鍵的身份轉換。
如果你已經在用 Claude Code 但從沒做過 skill：
從你今天最常重複的那件事開始。打開 .claude/skills/，建一個資料夾，寫一份 50 行的 SKILL.md。不要追求完美，追求「能跑起來」。
如果你還沒開始用 Claude Code：
先看入門教學，把 Claude Code 裝起來、用一週。等你自己感受到「我每天在重複」的痛，再回來這篇。
→ 沒有那個痛點，skill 就只是個炫技玩具。有了那個痛點，skill 就是你工作的方向盤。
如果你想看更多實戰案例、跟一群也在做 skill 的人交流，可以加入 AI 效率革命聯盟，我每週會在裡面分享我新做的 skill 跟踩到的坑。
把 Claude 從副駕駛升級成自動駕駛。從你的第一個 skill 開始。
FAQ
Q1：Claude Code Skill 跟一般 prompt template 最大的差別是什麼？
Skill 是「Claude 主動載入的模組」，prompt template 是「你手動貼上的提示詞」。Skill 透過 description 跟用戶輸入做語意比對，自動在合適時機觸發；prompt template 每次都要你自己記得。差別在主動性。
Q2：做一個 skill 大概要花多久？
第一個 skill 從零到能用，預期 2-4 小時（包含學習曲線）。第二個之後會快很多，通常 30-60 分鐘可以做出 MVP。但「做出 MVP」跟「真的好用」是兩回事——好用通常需要用 1-2 週後反覆迭代。
Q3：Skill 寫得不好會發生什麼？
最常見的兩個問題：(1) description 寫得太籠統，Claude 不會自動觸發，等於白做；(2) system prompt 寫角色頭銜不寫判斷標準，產出品質不穩。建議照本文「三個核心原則」對照檢查。
Q4：Skill 要放在哪個目錄？
專案層 skill 放 .claude/skills/{skill-name}/SKILL.md，全域 skill 放 ~/.claude/skills/{skill-name}/SKILL.md。專案層只在該專案生效，全域層在所有專案都能用。建議：通用工具放全域，專案專屬流程放專案層。
Q5：Skill 跟 MCP Server 我該先學哪個？
先 skill。Skill 只需要寫 markdown，門檻最低；MCP 需要寫 server 程式碼、處理協議、部署。先用 skill 把工作流跑起來，等你需要連接外部系統（Notion、資料庫、API）時，再加 MCP。
作者介紹
追日 Gucci，一人創業者、AI 自動化教育者，《AI 效率革命聯盟》創辦人。前美光（Micron）大數據工程師，2019 年離職創業，從美股投資內容轉向 AI 自動化教育。每天在 Claude Code 裡工作，目前自用 6 個以上 skill 跑完整內容生產線。YouTube 頻道「AI效率革命聯盟」6 萬+ 訂閱。
