編按：你用過 Claude Agent Skills 了嗎？它就像是一份預先定義好的 AI 工作說明書，讓你不必每次重新交代格式、流程與注意事項。如果你想嘗試 Skill，卻還不清楚它到底能解決什麼問題？本文將釐清 Skill 與幾個常見概念的差異以及限制。

從雇一個助理說起

想像你雇了一個新助理，第一週每件事都要手把手教，格式、邏輯、注意事項逐一說明。如果你能把這些全部寫成一份說明書，下一個助理直接照做，不用重教——Agent Skill 就是那份說明書，只是對象換成了 AI。

更具體一點，想像你去星巴克點咖啡，如果每次都要從頭說一遍：「我要大杯、燕麥奶、少糖、不加糖漿、冰的、拿鐵」，點個咖啡要花三十秒，店員也容易聽錯。但如果你是常客，跟店員說一句「老樣子」，對方就知道要幫你做什麼了。

Skill 就是那句「老樣子」。它是你幫 AI 預設好的一套「遇到這類任務，你該這樣做」的指令包。不用每次重新說明背景、格式、注意事項，AI 看到任務就知道怎麼跑。

這跟我一般跟 AI 對話有什麼差？

大多數人使用 ChatGPT 或 Claude 網頁版的方式大概是這樣：打開新的對話視窗，重新說一遍「請幫我用這個格式整理以下內容……」，然後把資料貼上去。

這沒什麼問題，但有幾個成本在裡面：每次要記得那段指令長什麼樣子、換個人用就要重新交代一遍、指令一長就很難維護。更關鍵的是，你上次花十分鐘調好的輸出格式，下次開新對話又得從頭來。

Skill 做的事，就是把那段你每次都要重複說的話，變成一個可以重複呼叫的標準作業流程。你建好一次，之後每個人、每次用，執行品質都是一樣的。

跟把指令存在記事本有什麼不一樣？

有人會說：「我把指令存在記事本，要用的時候貼過去，不就一樣？」

概念上類似，但 Skill 多做了幾件事。
第一，Skill 可以被 AI 自動識別觸發，不用你每次手動貼，AI 看到任務就自動套用。
第二，Skill 是結構化的，定義了適用情境、工具、步驟，不是一段純文字。
第三，Skill 可以直接分享給同事用，一個人建好，所有人執行品質一致。

我已經有 ChatGPT 的 GPT 或 Gemini Gem，Skill 還有必要嗎？

這個問題很常見，因為表面上 GPT 和 Gem 也可以讓你把背景資料、偏好設定、參考文件塞進去，AI 之後回應時會參考這些東西。

但用一陣子就會發現一個根本限制：每個 GPT 或 Gem 是獨立的對話入口，你要用哪個功能，就要點進那個對話。整理週報要點週報 GPT，回覆 email 要點 email GPT，分析競品要點競品 Gem ——每件事都是一個獨立的視窗，任務切換就是在不同對話之間跳來跳去。

Skill 的運作邏輯不一樣。你在同一個對話裡，可以依照任務需要，隨時呼叫不同的 skill，甚至在一個任務裡同時用到好幾個。

舉個例子：你在一個對話裡說「幫我整理這份會議記錄，然後根據會議結論草擬一封給客戶的 email」。AI 可以在同一個對話裡先呼叫「會議紀錄整理 skill」，整理完之後接著呼叫「客戶 email 撰寫 skill」，一氣呵成。用 GPT 或 Gem，你得點進兩個不同的入口分別做這兩件事。

再來是共用的問題。ChatGPT 和 Gemini 的設定綁在你個人帳號上，很難把一套好用的工作流程直接給同事用。Skill 可以在團隊內共用，一個人建好，所有人都跑同樣的標準流程。

GPT / Gem 是「一個功能一個入口」，Skill 是「在同一個對話裡，按需求隨時切換或疊加多個功能」。這對需要跨任務協作的工作場景來說，差異很明顯。

來看一個真實場景

假設你每週都要整理一份給主管看的週報：把這週做的事、碰到的問題、下週計畫整理成三段，語氣要簡潔不廢話，最後附上「需要主管決定的事項」欄位。

沒有 Skill： 每次打開 AI 對話視窗，重新說一遍格式要求，貼上這週的筆記。每次輸出品質不太一樣，有時忘記說「不要廢話」，輸出就來了一堆廢話。

有了 Skill： 你只要說「幫我整理這週週報」，把筆記丟進去。AI 自動套用你之前定義好的格式、語氣、欄位，輸出幾乎不用再改。同事也可以用同一個 skill，不用重新交代格式。

一個 Skill 長什麼樣子？

每個 skill 的核心，是一份純文字的 Markdown 檔案。

Markdown 是什麼？你可以把它想成「有暗語的記事本」。一般記事本的文字沒有結構，AI 看到一整段文字不知道哪句是標題、哪句是步驟、哪句是注意事項。Markdown 用一些簡單的符號幫 AI 看懂文字的層次和意圖，就像給食譜加上「材料」「步驟」「備注」的小標題，讓讀的人一眼就知道哪段是什麼。

這個檔案通常叫做 SKILL.md，裡面回答三個核心問題：

一、這個 skill 叫什麼名字、什麼時候出現？這決定 AI 在哪些情況下會用它——可以是你手動說出 skill 名稱叫出來，也可以設定關鍵詞讓 AI 自動識別觸發。

二、它能用哪些工具？有些 skill 只讀文字就夠了，有些任務需要連到 Google Drive 抓資料、查網路資訊、產出特定格式的檔案，這些都可以在 skill 裡定義。

三、它的執行流程是什麼？遇到任務的時候，按哪個順序做事、要注意什麼、輸出格式長什麼樣子——這就是你的 SOP。

一個完整的 skill 資料夾大概長這樣：
weekly-report-skill/
SKILL.md（必要) ← 主設定：名稱、觸發時機、工具、執行流程
reference.md (如果需要) ← 補充參考：格式範本、專有名詞、填寫範例
template/ (如果需要) ← 輸出模板（需要固定格式時才需要）
scripts/ (如果需要) ← 執行過程需要跑的程式碼

大多數簡單情況下，你只需要一個 SKILL.md 就夠了。裡面用清楚的語言把流程說明白，AI 就能按著跑。不需要會寫程式，裡面就是用自然語言寫的，說清楚任務背景、步驟、注意事項即可。

Skill 能呼叫工具，這件事有多重要？

光是「整理你貼進去的文字」這件事，其實一段指令就夠了。Skill 真正的威力在於它可以定義 AI 有哪些工具可以用。

例如，你建了一個「週報整理 skill」，裡面定義 AI 可以存取 Google Drive，它就能直接去抓你這週存在雲端的筆記，不用你手動複製貼上。如果還授權它可以查網路，它可以在整理的同時補充相關資訊。你定義它能產出 Word 格式，輸出就直接是一份可以寄出去的文件。

另一個很實用的設計是「按需加載」。AI 不會一次把你所有的 skill 都讀進去、全部同時運作——它是根據你的任務，判斷要不要啟動哪個 skill，需要的時候才加載，不需要的就不碰。

你可以把它想成手機的 app：裝了二十個 app，但同一時間只有你在用的那幾個是打開的，其他的不會跑在背景裡搶資源、互相影響。Skill 的邏輯也是這樣。

補充：MCP 是什麼？和 Skill 有什麼關係？

用到這裡你可能開始聽到 MCP 這個詞，很多人把它跟 skill 混在一起，但其實是兩件事。

MCP（Model Context Protocol）是 AI 連接外部工具的接口。你可以把它想成餐廳後台的進貨通道 - 廚師（AI）要拿食譜 (skill) 做菜，食材得從外面送進來，MCP 就是讓外部資料進得來的管道。沒有它，AI 只能用你直接貼進去的東西；有了它，AI 可以即時拉取 Google Drive 的文件、查 Slack 的訊息、連到 Notion 的資料庫。

另一個比喻：MCP 像手機的 app 授權。當你允許某個 app 存取你的相簿或位置，它才能用那些資料。MCP 就是在告訴 AI「你可以去拿這些東西」——Google Drive、Gmail、Slack 各自是一個授權，打開了 AI 才碰得到。

分工很清楚：MCP 解決「AI 能不能拿到那個資料」，Skill 解決「拿到資料之後該怎麼處理」。一個負責進貨，一個負責出菜流程，各司其職。

怎麼建一個 Skill？不需要自己手打 Markdown

很多人聽到「要寫一份設定檔」就卻步了，覺得這是工程師在做的事。其實不是。建 skill 有兩條路，你不需要碰任何技術。

第一條路：用官方提供的 Skill Creator。Skill Creator 本身就是一個 skill，是「幫你建 skill 的 skill」。你只要跟它描述你想做的事——任務是什麼、輸出要長什麼樣、有什麼注意事項——它就幫你把 SKILL.md 整個生出來，格式、結構都處理好，你直接放進指定資料夾就能用。

第二條路：直接跟 Claude 對話打包。你不用知道 SKILL.md 的格式長什麼樣子。把你的工作流程用白話說給 Claude 聽，跟它來回幾輪把細節講清楚，最後請它幫你整理成一份 SKILL.md 檔案就行了。這適合你有點想法但說不清楚格式的情況，讓 Claude 在對話過程中幫你把流程梳理出來再打包。

建完之後，把檔案放進對應平台的指定資料夾，skill 就啟用了。跑一次看看輸出對不對，不對再回來調整，通常一兩輪就穩定了。

Skill 的限制，還有它有時候會「打架」

Skill 不是萬能的，有幾個地方要知道。

首先是維護成本。Skill 建好之後不是放著不管就行，你的工作流程改了、輸出格式變了，skill 也要跟著更新，不然 AI 會按著舊的流程跑。這跟維護一份 SOP 文件是一樣的道理。

再來是記憶。Skill 不等於 AI 記住你說過的事。每次新的對話，AI 重新加載 skill，但不會記得你上次跟它說了什麼、改了什麼偏好——除非你另外開了記憶功能，或者把那些背景資訊寫進 skill 本身。

然後是所謂的「打架」問題。當你建了多個 skill，有時候它們的觸發條件或指令邏輯會重疊，AI 不確定該用哪個，可能會選錯，或者同時套用兩個互相矛盾的流程，輸出就會變得奇怪。

這種狀況最常發生在兩種情境：一是兩個 skill 的觸發說明太像，AI 可能判斷失誤。二是兩個 skill 裡對同一件事有不同指令，同時被載入就會互相干擾。

解決方式不複雜：讓每個 skill 的觸發說明盡量具體和有區別性，避免描述太泛。另外，如果某個任務明確只需要一個 skill，就手動指定呼叫，不要讓 AI 自己猜。

整體來說，Skill 最適合的場景是「流程清楚、重複發生、有固定輸出格式」的任務。太開放式、太需要臨場判斷的工作，還是直接跟 AI 對話比較靈活。

Agent Skills 不是 Claude 專屬的東西

很多人以為 skill 只能在 Claude 或 Cowork 裡用，其實不是。Agent Skills 現在已經是一個被主流 AI 工具廣泛採用的共同規格，背後的邏輯都一樣：把一份 SKILL.md 放進指定的資料夾，AI 工具就會自動讀取並載入它。

這裡有個很重要的概念：Skill 不是「安裝」，它就只是一個資料夾。你不需要跑任何安裝程式、不需要輸入授權碼，把設定好的 skill 資料夾放到對的地方，工具就認得它了。不同平台指定的資料夾位置不一樣，但格式標準是相同的——這就是為什麼你建的 SKILL.md 可以跨工具使用。

各平台的資料夾位置：
Claude Cowork → 由 Cowork 介面管理，透過設定頁面上傳
Claude Code → .claude/skills/ 資料夾
Gemini CLI → .gemini/skills/ 資料夾
OpenAI CLI → .openai/skills/ 資料夾

OpenAI 和 ChatGPT 這邊，官方 API 和 CLI 工具已經正式支援這個規格。ChatGPT 網頁端也開始整合 Skills 的概念，目前主要是官方內建技能，例如 PPT 和 PDF 處理。

Google Gemini 的整合更深。Gemini CLI 完整支援 SKILL.md 規範，甚至內建了 skill-creator 技能來幫你建立新的 skill。Google 的 Agent 開發套件（ADK）也使用與 Anthropic 標準相容的架構來定義 Skills。

開發工具這邊，Cursor 和 Windsurf 這兩款主流 AI 程式編輯器都支援在專案目錄下放置 SKILL.md 來擴展 AI 的能力。企業協作平台方面，Notion、Figma、Atlassian（Jira / Confluence）、Canva 都已經或正在整合 Skills 支援。自動化工具如 Zapier、Stripe，以及像 Manus 這類 AI Agent 平台，也都在這個方向上走。

你花時間建好一套 skill，不是只能在一個工具裡用。格式相同、換個資料夾路徑，同一份 SKILL.md 在 Claude、Gemini、Cursor 裡都能直接跑。

從哪裡開始？

想想你這個月重複做了三次以上的事，有沒有每次都要重新跟 AI 解釋格式或流程的？那個就是最值得先建成 skill 的任務。

一個 skill 就是一件事的 SOP，先從你最痛的那件重複工作開始，用 Skill Creator 或直接跟 Claude 對話打包，建起來用幾次，感覺自然就清楚了。

（本文出自張維峰）