Claude Skills 完整指南：從入門到打造專屬 AI 工作流的實戰教學

Claude Skills 是什麼？把工作流程打包給 AI 的技能模組

Claude Skills 是一種把工作流程、規則與知識打包成可重複載入的技能模組；當 Claude 遇到相關任務時，會自動讀取這份手冊，按你設定的方式執行，省去每次重新說明流程、品質又不穩定的痛點。它最大的特色是採用按需載入的分層設計，第一層只讀約 100 tokens 的 metadata 做判斷，不相關完全不占空間（根據 Anthropic 官方文件的說明）。講白一點，Skills 真正的作用是把你已經跑順的那套做事方式存成一個檔案，下次要用的時候 Claude 直接讀進來。在〈Claude AI 完整使用教學〉裡我們談過 Claude 的基本定位，而 Skills 處理的是另一個問題：它記得住你平常怎麼做事，不用你每次重講一遍。

重點先看：Claude Skills 成敗的關鍵落在 description 這一行夠不夠精準，會不會建檔反而是次要的；官方建議主體控制在約 5000 tokens 以內，靠三層載入省 context（Anthropic 官方文件亦如此建議）。

很多人在用 AI 工具時都有同一個困擾：每次都要把流程、規則重新講一遍，前後落差還很大。今天叫它寫一篇貼文，語氣跟昨天對不上；這週請它審一段程式碼，檢查重點跟上週完全不同。這種不穩定來自模型根本沒有你的工作脈絡可以參考，跟它強不強關係不大。Skills 就是衝著這件事來的。它讓 Claude 擁有一份「你的工作習慣」，而且是可以重複載入、跨對話調用的那種。如果你過去習慣把指令存成筆記、每次複製貼上，現在可以想想，這些指令是不是已經多到該模組化了。這跟單純把提示詞丟給模型不同，更接近 RAG 檢索增強生成 的精神：需要的時候才把對的知識調進來。

Skills 到底解決了哪兩件事

把 Skills 的價值拆開看，它其實就是衝著兩個痛點設計的：省 context 與穩定品質。先看 context。Claude 和所有大型語言模型一樣都有 Context Window 限制，一次能讀的資訊量有上限。你如果把所有規則、流程、參考資料一次塞進去，不但很快爆掉，還會讓模型分不清重點。Skills 的設計是「需要時才載入」，當任務跟某個 Skill 有關才讀進來，不相關就完全不占空間（此設計來自 Anthropic 官方文件）。這對長期使用 ChatGPT 或 Gemini 之類工具、已經累積一堆提示詞的人來說，感受特別明顯。

再來是穩定品質。有了 Skills 等於你有了一份標準 SOP，Claude 每次都會按同一套流程走，不會因為你這次說法不同、或漏掉哪個細節就跑出截然不同的結果。這對需要品質一致的工作特別關鍵：固定格式的內容產出、Code Review、定期報告、品牌貼文。很多團隊請 網路行銷公司 代操，真正的問題是沒有人把「我們的標準」固化下來，跟模型本身關係不大。門檻也不高：免費、Pro、Max、Team、Enterprise 方案都能用，前提是 Settings > Capabilities 開啟 Code execution and file creation（依 Anthropic 官方定價與 Skills 文件）；工程師、內容工作者、一般知識工作者，任何有重複性流程的人都受惠。

Skills 與 CLAUDE.md 的分工：模組化 vs 全部載入

CLAUDE.md 是每次進專案就全部載入的設定檔，規模一大就難維護又浪費 context；Skills 則是模組化、按需觸發的獨立單元，能跨專案重複使用，只有相關時才會被讀進來。兩者看起來都是「給 Claude 看的指示」，但設計邏輯差很多。換個角度想，CLAUDE.md 像貼在辦公室門口的公告，每個人進門都看得到；Skills 則像是抽屜裡的工作手冊，要做那件事才拿出來翻。如果你正在研究 AI Agent 自動化代理 的記憶機制，這個對比會很好懂。順帶一提，這類把能力拆給 AI 調用的設計，跟 MCP 讓模型接上外部工具 的精神其實互通。

CLAUDE.md 的問題出在「每次全部載入」。只要 Claude Code 進入專案，不管這次的任務有沒有用到，所有內容都會占 context。專案小時沒感覺，一旦規則越寫越多、流程越拆越細，CLAUDE.md 就會變得又長又雜，既難維護，也容易把 context 塞滿不相關的東西。而 Skills 是模組化設計，每個 Skill 都是獨立單元，只有在任務跟它相關時才會被觸發與載入，而且可以 跨專案重複調用，做一次就能在不同場景反覆用，維護成本大幅降低。

CLAUDE.md 與 Skills 比較

維度	CLAUDE.md	Skills
層級	專案層級設定檔	獨立模組
載入方式	每次全部載入	按需觸發
context 占用	不分任務全占	相關才占、否則為零
重複使用	單一專案內	跨專案可重複調用
維護成本	規模大後難維護	模組化、成本較低
適合放什麼	常駐型專案背景	可攜式工作流程 SOP

決策建議很直接：常駐型、跟專案綁定的規則放 CLAUDE.md，例如這個專案用的是哪個框架、部署到哪台伺服器；可重複使用的工作流程則打包成 Skills，例如寫文章的固定格式、Code Review 的檢查清單。兩者是分工關係：一個管專案背景，一個管可攜式工作流程。如果你連 Vibe Coding 都還沒摸熟，先把 CLAUDE.md 跟 Skills 的分工想清楚，會少走很多冤枉路。

還有一點容易被忽略：Skills 是 Claude 生態的一部分，要用 Skills 就要先有 Claude 的使用環境，而 Claude 是 Anthropic 開發的 AI 助理，能寫作、分析、寫程式、回答問題。它跟 Perplexity 這類搜尋導向工具定位不同，Skills 目前最常見的使用情境是搭配 Claude Code 運作，在終端機裡直接讀寫檔案、執行指令，這也是 Skills 發揮最完整效果的地方。如果你對命令列還有點陌生，先把 CLI 命令列的基本概念 摸熟，操作起來會順很多。如果你心裡冒出「那它跟一般提示詞差在哪」，可以想想提示詞是拋棄式的，Skill 則是可被 Claude 重複觸發、分層讀取的資產。

Skill、Prompt、Projects、MCP 與 GPTs：五種客製化機制的層次差異

把 Skills 跟 CLAUDE.md 分清楚之後，還有另一組更容易讓人卡在第一步的混淆：Skills、prompt、Projects、MCP、GPTs／Gems 到底誰是誰。這五者層次不同，互補而非替代。prompt 是臨時指令，Projects 是背景知識庫，MCP 是外部工具接點，GPTs 是另開一個專用助手，Skills 則是同一個 Claude 裡按需載入的工作流模組。完整工作流通常是 Skill 定流程、加 MCP 接工具、加 Projects 當背景。

先把最常被混淆的兩組拆開。Skills 跟 Projects 的差別用一句話分：Projects 偏「告訴 Claude 你知道什麼」（背景資料），Skills 偏「告訴 Claude 遇到這類任務該怎麼做」（工作流程）。Skills 跟 MCP 也不是替代關係：MCP 負責把 Claude 接到外部系統與資料來源，Skills 負責定義在這個流程裡怎麼用這些工具，是流程加工具的互補。

項目	本質	載入時機	是否切換人格	與 Skills 的關係
prompt	臨時指令	每次手動貼	否	Skill 是 prompt 的模組化升級
Projects	背景知識庫	該專案全程常駐	否	互補：Projects 給背景，Skills 給做法
MCP	外部工具接點	呼叫工具時連線	否	互補：Skills 用流程，MCP 給工具
GPTs／Gems	另開專用助手	明確進入該助手	是（換角色）	思路不同：GPTs 選人，Skills 選做法
Skills	工作流模組	靠 description 按需載入	否（同一個 Claude）	—

真正會影響你日常體感的差別，在 Skills 跟 GPTs／Gems 之間。用 GPTs 時，你會明確切換到另一個助手，它有自己的設定、知識與人格，每個回答都帶著那個角色；用 Skills 時，你還是在跟同一個 Claude 聊天，只是它背後偷偷換了一套 SOP。OpenAI 把客製化做成「助手」，Anthropic 把客製化做成「工作流模組」：用 GPTs 像在公司裡選一個同事，用 Skills 像同一個同事桌上放了好多本 SOP、事情來了自己翻對的那一本。對決策者來說，這直接決定你該把心力放哪裡：要穩定、可重複、能被團隊共享的輸出格式，Skills 投入報酬比明顯較高；要截然不同的對話風格與獨立人格，GPTs 反而更順手。

SKILL.md 結構拆解：frontmatter、SOP 主體與子資料夾

每個 Skill 的核心是一個 SKILL.md，分成 YAML frontmatter（name、description 等基本資訊）與 SOP 主體（步驟、判斷規則、範例），再搭配 scripts、references、assets 子資料夾做分層管理。知道結構，才知道每個部分要放什麼、怎麼寫才不會浪費 context。它是一份可以重複載入、跨對話使用的模組，跟聊天記錄或每次都要重貼的指令不一樣。

SKILL.md 的兩大區塊

文件最上方是 YAML frontmatter，用來描述這個 Skill 的基本資訊，讓 Claude 判斷要不要啟動它。兩個最重要的欄位是 name 與 description。name 就是 Skill 的名稱，建議簡短清楚，讓人一眼知道用途；description 則是最關鍵的欄位，它要清楚說明「這個 Skill 在什麼情況下應該被使用」，Claude 就是根據這個描述來判斷相關性。description 寫得準不準，直接決定這個 Skill 會不會在對的時機被觸發（Anthropic 官方文件明確指出這點）。frontmatter 之後則是 SOP 主體，你可以用編號步驟說明流程、列出判斷規則、提供範例格式，甚至加入條件判斷邏輯，內容越清楚、越有結構，執行就越穩定。

一個完整的 Skill 除了 SKILL.md 主體，通常還會包含幾個子資料夾做分層管理。scripts 放可執行的腳本或命令，這些內容不會直接占 context，需要時才被呼叫執行；references 放參考文件、知識庫、規格說明等較長的資料，同樣是按需載入，避免浪費空間；assets 放模板、範例素材，讓每次輸出的格式保持一致。這樣的設計讓主體保持輕量，需要時才調用豐富的補充資料。如果你做過 用 AI 快速建立網站架構圖 之類的專案，就會理解把長文件拆出去、主體只留核心邏輯的好處。

資料夾	放什麼	何時載入
SKILL.md 主體	核心規則、步驟、判斷邏輯	確認相關就讀
scripts/	可執行腳本、命令	SOP 指示需要時呼叫
references/	長參考文件、知識庫、規格	需要深入參考時載入
assets/	模板、範例素材	輸出格式需要時載入

常見的錯誤是把所有東西都塞進 SKILL.md 主體，結果主體又長又雜，Claude 讀起來效率很差，也容易忽略細節。正確做法是：常用的核心規則放主體，較長的參考資料放 references，可執行的腳本放 scripts。這跟寫 內容行銷策略 一樣，主體是綱領，細節要分層收納，才不會把重點淹沒。

三層載入機制：Skills 如何按需觸發

Skills 採用 Progressive Disclosure 分層載入：第一層只讀約 100 tokens 的 metadata 做快速判斷，確認相關後才讀第二層 SKILL.md 主體（建議 5000 tokens 內），最後在 SOP 明確指示時才讀第三層 scripts、references、assets（Anthropic 官方文件稱之為 Progressive Disclosure）。這是整個 Skills 設計最精妙的地方，也是決定 context 用得聰不聰明的核心。

Claude 不會一開始就把整個 Skill 完整讀進來，而是先看最前面的 metadata，判斷這個 Skill 跟當前任務有沒有關係；只有在覺得相關時，才會進一步把完整內容載入。這個漸進式的設計在官方文件裡稱為 Progressive Disclosure，用白話講就是「分層載入」，每一次的 context 使用都盡可能精準（見 Anthropic 官方文件）。Context Window 是使用 AI 時最珍貴的有限資源，你塞進去的每一行文字都在消耗它，Skills 的分層設計讓 Claude「用多少拿多少」，而不是一開始就把所有東西全讀進來。

三層載入對照

層級	內容	規模	何時讀
第一層 Metadata	name + description	約 100 tokens	啟動時預先載入，判斷關聯性
第二層 Instructions	SKILL.md 主體 SOP	建議 5000 tokens 以內	確認相關後載入
第三層 Resources	scripts / references / assets	視內容而定	SOP 明確指示時才載入

第一層是 Claude 啟動時就會預先載入的部分，主要就是 name 與 description，大約只占 100 tokens。Claude 用這層來快速判斷「這個 Skill 跟現在的任務有沒有關係」。確認相關之後，才會把 SKILL.md 的主體內容讀進來，這一層是完整的 SOP 指示，建議控制在 5000 tokens 以內，讓 Claude 能清楚消化又不占太多空間（Anthropic 官方文件如此建議）。只有在 SOP 主體明確指示需要時，Claude 才會去讀取 scripts、references 或 assets，這些資料需要時才載入，不用的時候完全不占 context。

這裡藏著一個很多人沒想通的關鍵：description 寫得好不好，直接決定 Skill 會不會被正確觸發。因為第一層的 Metadata 就是 Claude 做判斷的唯一依據。description 太模糊，Claude 不知道要不要用，整個 Skill 等於沒做；description 寫得太廣泛，又可能什麼任務都觸發，反而干擾正常對話。所以把時間花在把 description 這一行寫到精準，會比雕格式更值得。這跟做 SEO 搜尋引擎優化 一樣，title 與 description 寫歪了，內容再好也沒人點進來。很多實作者會在 Ahrefs 陪跑班 裡反覆練這種把條件收窄的直覺，也有人用 Ahrefs Brand Radar 追蹤品牌被引用的狀況，背後是同一套把觸發條件寫清楚的思維。其實這也是為什麼很多團隊在導入 AI 搜尋時代的 SEO 時會卡住，卡的多半是觸發條件設得不夠清楚，工具本身多半沒問題。

這個三層機制也回答了一個常見疑問：為什麼 Skills 不會把 context 吃光？因為它根本不會一次把所有東西讀進來。第一層是常駐的輕量索引，第二、第三層都是按需展開。這對 生成式 AI 應用來說是很重要的設計，尤其在處理長流程、多步驟任務時，能把 context 留給真正需要的環節。也因為這樣，Skills 在需要 把固定流程自動化的工作 裡特別能發揮價值，這類長鏈任務最怕 context 被雜訊吃掉。

建立第一個 Skill 前要先想清楚的三件事

動手前先想清楚三件事：要解決哪種重複性任務（越具體越好，是每次都要重說的寫作格式，還是固定的程式碼審查邏輯，這件事想清楚 description 就好寫了）、流程裡有哪些固定規則（把每次都要注意的事列出來，這些就是 SOP 主體的核心）、以及哪些知識常駐哪些按需讀取（常用規則放 SKILL.md 主體，偶爾才用到的參考資料放 references，context 才不會被塞滿）。這三個問題想清楚之後，再選官方 Skill Creator 或從現有 SOP 回推兩種方法之一執行即可。你不需要先變成很會寫規格文件的人，重點是動手前把這幾個問題想清楚，做出來的 Skill 才不會又模糊又難用。

方法一，用官方的 Skill Creator。如果你已經知道自己要做什麼、不想從頭手寫格式，可以直接用官方提供的工具。在 Claude 介面進入 Customize > Skills，找到並點擊 skill-creator，點「＋」> Create with Claude，開一個新對話後，告訴 Claude「幫我做技能包」，接著照引導一步步走，Claude 會幫你產出 SKILL.md 的內容（操作路徑以官方介面為準）。這個方法適合知道自己要什麼、但不想自己手寫格式的人，可以省下不少整理時間。

方法二，從實際工作流程回推。如果你已經有一套成熟的工作方式，先把你的 SOP 整理出來，不需要很完整，把步驟和規則列清楚就行；再把整理好的內容貼給 Claude，請它幫你轉換成 SKILL.md 的格式；最後自己檢查一遍 description 是否精準、步驟是否完整。這個方法適合有成熟工作流程、想把現有知識打包起來的人，因為你已經有實際運作過的 SOP，只是需要轉換格式而已，品質通常也比較扎實。這跟把 文案寫作與銷售文案技巧 變成可重複執行的流程是同一個道理。

安裝、更新與備份 Skill

做好 SKILL.md 之後，到 Claude 的 Customize > Skills 介面，點「＋」> Create skill 新增，會有三種安裝方式：Create with Claude（讓 Claude 引導你建立）、Write skill instructions（自己直接在介面輸入內容）、Upload a skill（把 Skill 資料夾打包成 ZIP 檔或.md 上傳），實際選項以官方介面為準。安裝完成後，可以用一個相關任務測試看看是否正確觸發。

修改方面，如果當初是用 Create with Claude 或 Write skill instructions 建立的，到 Customize > Skills 找到該 Skill，點「…」選擇 Edit 直接編輯，或 Edit with Claude 與 Claude 對話修改，或 Replace 上傳更新的檔案都可以。如果當初是用 Upload a skill 上傳的，直接在本機修改 SKILL.md，刪除舊的 Skill 再重新上傳就好。如果你用 Claude Code，Skill 是存在本機資料夾裡的實體檔案，可以用任何文字編輯器直接開啟 SKILL.md 修改，存檔後重新載入即可。這也是為什麼建議養成在本機保留原始檔的習慣，修改起來最方便，搭配 WordPress 備份與還原 之類的版本觀念一起看會更踏實。

版本備份的基本觀念是：Skills 本質上就是文件，最簡單的方式就是用資料夾搭配日期命名，例如 skill-v1-20250420，或用 Git 做版本控制（這是 Anthropic 官方文件建議的做法）。隨著 Skill 不斷優化，留下歷史版本會讓你在出問題時有東西可以回溯。這套做法跟 WordPress 搬家外掛 或 WordPress 備份外掛 背後的邏輯一致，本質都是幫可變動的資產留下可回溯的快照。

description 決定 Skill 的觸發準確度

有些 Skill 做了卻不會被觸發，原因多半出在 description 寫得太模糊或太廣泛，格式倒不是主因。description 是 Claude 判斷要不要用這個 Skill 的唯一依據，必須明確列出觸發情境、關鍵字，甚至反例，才會在對的時機被啟動。這行字模糊，整個 Skill 等於沒做。

寫 description 有三個核心原則：明確列出觸發情境（寫清楚什麼情況下要用這個 Skill）、列關鍵字與使用場景（具體到工作類型、輸出需求）、加上反例（哪些情況不適用）。這三個原則疊起來，才能讓 Claude 在對的時候讀、在不對的時候完全不碰。反面教材很容易辨認：「幫我處理各種任務」太模糊，Claude 不知道要不要用，容易被忽略；「任何有關工作的事」太廣泛，什麼任務都觸發，反而干擾正常對話。

好的 description 大概是這樣：「當使用者要求撰寫部落格文章、整理內容大綱或改寫文案時，載入此 Skill，依照品牌語氣與固定格式執行。」這句話明確點出觸發情境（撰寫文章、整理大綱、改寫文案）、執行方式（品牌語氣、固定格式），讓 Claude 一看就知道該不該用。如果你在做 讓主流 AI 主動引用網站的實戰心法，這種精準度觀念其實是相通的：把觸發條件收窄，會比把範圍拉大更有效。這也正是 SEO 排名攻略學 這類系化課程反覆強調的重點。

SOP 主體的步驟化與條件邏輯

SOP 主體也一樣關鍵。把一大段文字敘述拆成編號步驟，會讓 Claude 有明確的順序可以跟隨。加入判斷條件會讓 Skill 更有彈性，例如「如果使用者提供了文章長度要求，依照指定長度撰寫；如果沒有，預設 800 字」，這樣的條件邏輯讓 Claude 在各種情況下都能做出合理判斷，而不是遇到邊緣狀況就卡住。內容分層也要做對：常用核心規則放 SKILL.md 主體，較長參考資料放 references，可執行腳本放 scripts。這跟規劃 關鍵字佈局 一樣，主體是方向，細節分層收納，重點才不會被淹沒。想找切入點時，可以參考 台灣熱門搜尋關鍵字榜單，看看哪些詞的流量結構值得拆成獨立 Skill 處理。

以一個同時裝了數個 Skills 的內容團隊為例，常見的狀況是每個 Skill 單獨看起來都沒問題，但 description 寫得太接近、觸發情境互相重疊，Claude 在判斷時就會出現該啟動 A 卻開到 B、或兩個都不開的狀況。依這類團隊的典型表現，description 真正需要回頭收窄的 Skill 通常約落在全部的三到五成之間，多數其實不必整支重寫，只要動那少數幾支用了「各種」「任何」這類太廣措辭、拉高了重疊率的就好。實務上比較穩的做法是先把每支 description 列成清單相互比對，鎖定重疊的那幾支單獨收窄並補上反例，避免一次整批重做反而打亂原本能正常觸發的設定。要誠實提醒的是，這層除錯多半沒有一次性完美的版本， Skills 一旦持續增加，新成員又寫了相近的 description，重疊問題會再回來，把「定期比對 description 清單」當成維護項目會比追求一次到位更實際。

可以回頭看一個容易踩的坑：很多人把 Skills 講成「功能介紹」，以為重點在會不會建檔，於是拼命做多、做複雜。但真正的成敗關鍵落在 description 這一行寫得多精準，數量多寡沒那麼重要。先把一個能穩定觸發的小 Skill 做好，驗證完整個流程再擴張，會比一次做十個半調子來得實在。這跟 把資源押在少數高價值動作 的思路一致：先求單點跑通，再求規模化。

Skills 能解決的實際工作場景

Skills 最有價值的地方是省下重複交代、反覆確認的時間。常見場景包含網站開發與架設流程、每日工作規劃自動化、Code Review 標準化，以及內容製作流程打包。這些場景的共同特色是：流程重複性高、細節多、出錯成本不低，剛好是 Skills 最能發揮的地方。

網站開發與架設

如果你有固定的建站流程，Skills 可以讓 Claude 每次協助你時都按同一套方式走，不需要每次重新說明你用的框架、命名規則或部署流程。以 WordPress 為例，你可以把慣用的 WordPress 頁面編輯 設定方式、WordPress 必裝外掛 配置邏輯、WordPress 架站與 SEO 優化 的基本步驟，全部打包成一個 Skill，讓 Claude 在協助你架站或修改時，都清楚你的習慣與標準。前提是你自己要先有一套成熟的建站流程，Skills 才有東西可以承接；如果你還沒架站經驗，也可以先從 WordPress 架站新手教學 或 WordPress 部落格架站教學 把基本功打好。搭配 AI 網站建立工具 一起用，建站流程會更順。

每日工作規劃自動化

你可以做一個每日工作規劃 Skill，裡面寫好你的規劃邏輯：先整理今日待辦、按優先度排序、預估時間、找出可以批次處理的任務等步驟。設定好之後，只要輸入「開始今日規劃」，Claude 就會自動跑完整個流程，輸出一份符合你習慣的規劃清單，完全不需要每次重新說明。這對需要每天處理大量重複任務的 社群媒體行銷 或 EDM 電子報行銷 工作者來說特別有感，把固定流程交給 Skill，自己只專注在判斷與決策。如果你連輸入指令都想再快一步，Typeless 這類輸入工具 能幫你把常用的 Skill 啟動詞變成一鍵觸發。

Code Review 標準化

如果你的團隊有一套 Code Review 的規則，例如命名規範、安全性檢查、效能標準、文件要求等，可以把這些全部打包成一個 Code Review Skill。往後只要請 Claude 幫你看 code，它就會按照你們的標準來審查，不會每次因為沒有上下文而遺漏重要審查點，也不用每次重新貼一次規範。這對需要在團隊內統一 效能與品質標準 或 Figma 中文完整教學 之類協作規範的團隊，是很好上手的應用。把它跟 AI 繪圖與網頁設計 的流程規範結合，輸出一致性會再往上拉一階。

內容製作流程打包

內容工作者可以把完整的內容製作 SOP 打包成一個 Skill，包含文章結構要求、品牌語氣規範、標題寫法、CTA 放置位置、SEO 基本要求等。這樣無論是你自己在用 Claude 寫作，或讓團隊成員也能用 Claude 產出符合品牌標準的內容，都能有一套共同依循的標準，輸出品質自然更穩定。如果你在做 社群貼文與廣告文案、短影音行銷 或 線上課程開課，這個 Skill 能讓不同人產出的內容調性趨於一致。把它跟 AI 內容檢測工具 串在一起，還能在產出後快速把關品質。

應用場景	Skill 打包什麼	主要價值
網站開發架設	框架、命名規則、外掛、部署步驟	每次按同一套方式協助
每日工作規劃	待辦整理、排序、預估時間、批次處理	一句指令跑完整流程
Code Review	命名、安全、效能、文件要求	按團隊標準審查不遺漏
內容製作	結構、語氣、標題、CTA、SEO	團隊輸出更一致

Skills 的核心價值在於讓你的工作流程可以被複製、被沿用。過去累積的做事方式、踩過的坑、建立起來的標準，本來都只在你的腦袋中，每次換工具、換對話就消失了。Skills 讓這些知識有地方落地，成為可以跨對話、跨專案反覆調用的模組。從一個 Skill 開始做、慢慢累積，前幾次一定會踩到 description 寫太廣或分層沒拆乾淨的問題，這很正常，調一輪就會順。這也呼應了 LLM 與 LLMO 對 SEO 的影響 與 GEO 生成式搜尋優化 的趨勢：當 AI 成為內容的主要讀者，能不能把你的標準寫成機器讀得懂的格式，會直接影響被引用的機會。這也是為什麼像 Claude Fable 5 這類強調結構化敘事的模型，越來越需要背後有一份寫得清楚的 Skill 支撐。

如果你還在猶豫要不要花時間做 Skill，我會建議先做一個就好。不是因為它難，而是因為做第一個的時候，你才會真正體會到 description 跟分層載入在實務上長什麼樣子。做完一個能穩定觸發的小 Skill，再回頭看這篇，很多觀念會串得起來。這段過程跟剛接觸 AI 幻覺成因與避免 或 GA4 追蹤 AI 流量 時類似：先有觀念框架，實作時才知道每一步在解什麼問題。等 Skill 跑順了，也可以進一步試試 Claude Cowork 多人協作模式，把這套流程交給團隊一起用。

四種高代表性 Skill 範例：從品牌規範到手動修 issue

光講原則容易空泛，這裡給四個高代表性的範例涵蓋最常見的 Skill 類型：品牌規範統一對外格式、固定格式研究 memo 固定輸出結構、explain-code 封裝開發流程、以及只能手動觸發的 fix-issue 處理有 side effect 的動作型任務。照著這四個改，就能做出第一個可用的 Skill。

第一種是品牌規範 Skill。frontmatter 寫明用於 external-facing materials，內容含色票、字型、logo 使用規則。色票例如 Primary #0B57D0、Secondary #111827、Accent #14B8A6；字型例如 Header 用 Noto Sans TC Bold、Body 用 Regular；logo 規則是淺底用彩色、深底用白色、四周保留最小安全留白。這類 Skill 很適合拿來統一 對外內容 的品牌格式，把這些規範一次固定下來，省去每次重複提醒。

第二種是固定格式的研究 memo。固定把 Executive summary、Key findings、Risks、Recommendation 拆成幾段，重點不是讓 Claude 知道更多，而是讓它每次吐出來的結構一致。一句 description 收攏：產出固定格式的研究 memo，用於競品分析、供應商評估、產業掃描。常做 關鍵字佈局 或搜尋意圖分析的人，這個結構幾乎可以直接套。

第三種 explain-code，規定先給生活化類比、ASCII 圖、逐步走讀、點出 gotcha，適合團隊教學與 Code Review 導讀。與其每次重新要求 Claude 用某種方式解釋，不如直接把這套解釋方法封進工作流。

第四種 fix-issue，設 disable-model-invocation: true 強制手動觸發。會動到系統、檔案、部署的流程都該保留手動開關，description 寫成「根據 issue 編號修復問題、用於明確指定要處理的單一 issue」。內部流程是讀 issue、理解需求、修改程式、補測試、準備 commit。原則一句話：不要把「什麼時候該動手」交給模型自己猜。

範例類型	核心訴求	觸發方式	適用對象
品牌規範	統一對外格式	可自動觸發	內容、行銷團隊
研究 memo	固定輸出結構（一致性重於資訊量）	可自動觸發	顧問、研究、PM
explain-code	封裝解釋方法	可自動觸發	團隊教學、review 導讀
fix-issue	side effect 大，需人工把關	強制手動觸發	開發、維運

官方預建與社群 Skills：哪些可以直接拿來用

不想從零開始，也可以先從官方預建 Skills 下手。官方預建涵蓋 pdf、xlsx、pptx、docx 四大辦公格式，官方 repo 另有 doc-coauthoring、internal-comms、frontend-design、theme-factory、webapp-testing、claude-api 等範例（見 Anthropic 官方 skills repo）。最該開始用的，是會反覆使用 Claude、已感受到重複操作與格式飄移的內容工作者、顧問、研究者、PM 與工程團隊。

辦公文件四件套

• pdf：讀取、文字與表格抽取、合併、拆分、旋轉、表單處理，適合把合約、報價單、財報抽出來整理。
• xlsx：處理 .xlsx／.xlsm／.csv／.tsv 的讀取、格式化、公式計算、資料清理，適合髒資料清理與基本分析。
• pptx：只要任務涉及 .pptx、slides、deck、presentation 就屬於它，可建簡報、改版型、抽 speaker notes。
• docx：做 .docx 的建立、讀取、編修、重整，可做 report、memo、template，也能處理目錄與 tracked changes。

開發與寫作向

frontend-design 用來生成有完整設計方向、可運作、而且不像制式 AI 版面的 UI，適合做 landing page、dashboard、React component；webapp-testing 用 Playwright 測試本機 web app；claude-api 專門給 Claude API 與 Anthropic SDK 開發；theme-factory 把 artifact 套上主題風格，讓配色、字體與整體氣質一次對齊。寫作與溝通向則有 doc-coauthoring 與 internal-comms：前者是結構化寫作 skill，專門共同撰寫 proposal、technical spec、decision doc、PRD、RFC；後者支援 3P updates、status reports、newsletter、FAQ、incident reports 等格式，常寫週報或給管理層 update 的人很容易立刻省時間。

使用官方或社群 Skills 前有幾個共通提醒：需啟用 code execution、先讀 SKILL.md 搞清楚它會做什麼、檢查腳本與依賴、確認是否連外、在自己的環境先測。這不是客套話，很多 Skill 裡的腳本會連外抓資料或執行命令，不檢查就用等於把環境的鑰匙交給陌生人。

實作時最常踩的雷與資安風險

做 Skill 最常犯五個錯：一是開局就做超大萬用 mega-skill；二是把重要規則埋在深層參考檔讓 Claude 讀不到；三是放太多選項卻沒有預設路徑；四是把會過期的資訊直接寫死；五是忽略 Skill 可含腳本與指令所帶來的資安風險。前三個其實前面已經談過拆小、分層與給預設做法的對應解，這裡特別把第四、第五種展開，因為它們最容易在你以為 Skill 跑得很順之後才爆開。

第四種要小心：把錯的或過期的資訊寫死，等於讓 Claude 每次都照著錯的講，這正是 AI 幻覺成因與避免 談到的典型來源之一。暫時性規則、工具版本、舊流程都不該直接寫死，定期維護或收進舊版區段才安全。

第五種在資安這端要特別強調。Skill 可以包含腳本、檔案與指令，所以本質上帶有安全風險。不要把 API keys、密碼或敏感設定硬編進 Skill；下載外部來源的 Skill 之前，要先檢查內容、是否連外、是否啟用 code execution，並在自己的環境先測試再正式使用。Skill 很強，但它強的地方，剛好也是風險來源。這點對會把商業機密或客戶資料放進流程的人尤其要緊。

Skill 類型	side effect	建議觸發方式	風險等級
解釋 code	低（唯讀）	可自動觸發	低
整理 PR	中（讀多檔）	可自動觸發	中
補測試	中（新增檔案）	建議確認後觸發	中
修 bug／改 production	高（動到主流程）	強制手動觸發	高
部署	極高（對外生效）	強制手動觸發	極高

把這張表跟前面的 disable-model-invocation 串起來看就會很清楚：side effect 越大的 Skill 越要保留手動觸發開關。在 會真的動到檔案與系統的環境 裡，Skill 不只是寫作模板，而是會影響開發流程的工作流自動化，寧可多按一次確認，也不要讓模型在某次對話裡自己決定要不要 deploy。

使用 Skills 前最該先確認的幾件事

這幾題，是在實際導入 Skills 時最常卡住、也最常被重複追問的細節，一次說清楚能省下不少試錯時間。

Claude Skills 免費方案可以用嗎？

可以，Skills 適用於免費、Pro、Max、Team 與 Enterprise 所有方案（依 Anthropic 官方定價與 Skills 文件）。前提是先到 Settings > Capabilities 確認 Code execution and file creation 功能已開啟，沒開這個開關，做好的 Skill 不會跑。

一個專案可以安裝多個 Skills 嗎？

可以。同一個專案能掛多個 Skills，每個負責不同功能模組，Claude 會依任務判斷哪些相關並載入。這也是為什麼每個 Skill 的 description 都要寫得精準，否則觸發邏輯會打架。如果你做的是 作品集網站製作 或 品牌官網架設，通常會同時裝好幾個 Skill 分管內容、技術、SEO。

Skills 只有 Claude Code 才能用嗎？

不是。Skills 是 Claude 整體功能的一部分，不限定只能在 Claude Code 環境下使用。不過目前 Skills 與 Claude Code 的工作流程結合最緊密，多數實際範例也以 Claude Code 為主。做 從主機到建站的完整自學指南 這類全程在 Claude Code 裡跑的專案，效果會最完整。

做完的 Skill 怎麼安裝、更新與備份？

安裝有三種：Create with Claude、Write skill instructions、Upload a skill（ZIP 或.md）。更新依建立方式不同，Edit、Edit with Claude 或重新上傳皆可。備份因為 Skills 本質是文件，用資料夾搭配日期命名或 Git 做版本控制最方便（Anthropic 官方文件如此建議），這套觀念跟 行銷人必備工具 的資產管理是同一條思路。

Skills 跟 CLAUDE.md 差在哪？

CLAUDE.md 是專案層級、每次全部載入的設定檔；Skills 是模組化、按需觸發、可跨專案重複使用的獨立單元。常駐規則放 CLAUDE.md，可攜式工作流程打包成 Skills。這題在做 聊天機器人流程設計 時特別常被追問，因為那類應用也需要區分常駐記憶與按需技能。