Claude Skills 教學：如何建立與使用技能包

本文重點

• Skill 是一份說明文件加上相關資源，Claude 依情境自動判斷要不要載入。
• 它解決的是「流程」問題，和解決「連得上什麼系統」的 MCP 是互補關係，不是取代。
• 建立 Skill 不需要寫程式，會清楚描述步驟就能做。
• 寫完先實際測，觀察它有沒有在該觸發時觸發，再回頭修描述。

先搞清楚 Skill 在解決什麼

如果你常常在對話一開始重複打同一段指示——「幫我用這個格式整理」「照公司的這套規則檢查」——這就是 Skill 該出場的時候。

把這套流程寫成 Skill 之後，你不用每次重講一遍。Claude 看到任務內容對得上，會自己把完整指示載入進來用；對不上的時候，這份 Skill 完全不出現在對話裡，不佔位置也不影響其他任務。

這和只是把常用指示存成一個文字檔不同。文字檔要你自己記得貼、自己判斷這次用不用得到；Skill 的判斷這件事，是 Claude 自己做的。

什麼時候該寫成 Skill，什麼時候不必

值得寫成 Skill：

• 有固定格式或固定檢查項目的重複性工作，例如週報整理、文案審稿標準、程式碼風格規範。
• 團隊裡多人使用 Claude，需要統一輸出風格或流程時。
• 流程有好幾個步驟、彼此有先後順序，臨場描述容易漏掉步驟。

不需要：

• 只做一次的任務，寫 Skill 反而比直接講清楚更花時間。
• 需要精確計算、每次結果必須完全一致的工作——這種該交給真正的程式或工具，Skill 提供的是指示，不是保證一致輸出的機制。

Skill 的基本結構

一個 Skill 是一個資料夾，核心是一份說明文件（慣例上命名為 SKILL.md）：

1. 1

   開頭：名稱與一句話描述

   這一小段是 Claude 判斷要不要載入的依據，寫得越具體、越貼近實際使用情境，觸發的準確度就越高。避免寫得太籠統，例如「幫忙寫作」這種描述幾乎什麼任務都可能誤觸發。

2. 2

   本文：完整操作指示

   把流程、步驟、格式要求、要避免的事情寫清楚。可以想像成在教一個新同事怎麼做這件事——它不知道你公司的慣例，你得從頭講。

3. 3

   （選用）附帶資源

   範本檔案、範例輸出、參考資料，甚至一小段腳本，都可以放進同一個資料夾，在說明文件裡引用它們。

在不同地方分別怎麼用

在 Claude Code 裡： Skill 放在專案或使用者層級的目錄下，開發時 Claude Code 會自動掃描可用的 Skill 列表。適合放團隊共用的程式風格規範、專案特定的工作流程。

在 claude.ai 裡： 可以在設定中上傳、啟用 Skill，日常對話中符合情境就會自動用上，不需要每次手動指定。

透過 API 使用時： Skill 作為一種可掛載的資源提供給模型，行為和前兩者一致——由模型依任務內容判斷是否載入。實際的啟用方式請以 Anthropic 官方文件為準，因為介面和參數可能隨版本調整。

建立完之後要做的事

寫完 Skill 不代表結束。實際拿幾個真實情境去測：

• 該觸發的時候有沒有觸發？如果沒有，通常是開頭那句描述寫得不夠具體。
• 不該觸發的時候有沒有誤觸發？同樣是描述的問題，可能寫得太籠統。
• 照著 Skill 產出的結果，是不是你原本想要的？如果不是，問題通常出在本文的指示不夠清楚，而不是模型能力不夠。

這個調整過程和寫文件差不多——第一版很少是最終版，跑幾次真實案例、回頭修，比一開始就想寫到完美更有效率。

常見誤解

「Skill 是自動化腳本」——不是。 Skill 提供的是指示和資源，實際執行仍然是 Claude 依當下情境判斷產生內容。需要每次結果完全固定、不能有變動的工作，該用真正的程式去做，不該靠 Skill。

「裝了越多 Skill 越好」——不是。 描述彼此重疊或太籠統的 Skill 放在一起，反而會讓觸發判斷變得不準。與其囤一堆用不到的 Skill，不如把真正常用的幾個寫清楚。

「Skill 能取代 MCP」——不是同一層的東西。 MCP 讓 Claude 接得上外部系統，Skill 是接上之後該怎麼做的流程說明。兩者是互補，不是二選一。