Skill 是什麼？跟提示詞、斜線指令、MCP 差在哪

先講結論：Skill 就是一個資料夾

這個詞聽起來很玄，但它的本體非常樸素。Anthropic 官方在公告裡的原話是：「Skill 是包含指示、腳本與資源的資料夾，Claude 需要時可以載入」。

文件裡的定義更完整一點：「Agent Skills 是擴充 Claude 功能的模組化能力。每個 Skill 包裝了指示、後設資料，以及選用的資源（腳本、範本），Claude 在相關時會自動使用」。

所以它不是一個外掛市集、不是一種模型能力，就是你放在檔案系統上的一疊文件。

它解決什麼問題

如果你常用 AI 做同一類工作，會遇到一件很煩的事：每次開新對話，你都要重新交代一遍。

「我們公司的報價單格式是這樣」「數字要這樣四捨五入」「客戶名稱一律去識別化」。講一次它照做，下次開新視窗它又不知道了。

官方文件把這個差別講得很直接：提示詞是「對話層級、一次性任務的指示」，而 Skill 是按需載入的，所以你不必在每一場對話裡重複同樣的交代。

一個 Skill 長什麼樣

只有 SKILL.md 是必要的，其他都是選配。官方用的比喻是「你幫新同事準備的上手手冊」，先有目錄，再有章節，最後才是附錄。

漸進式揭露：為什麼裝很多也不會吃掉額度

這是 Skill 設計上最聰明的一點，也是它跟「把所有規矩寫進一份超長指示」的根本差別。

它把內容分三層，每一層在不同時間才進到脈絡裡。沒被叫到的 Skill，只有名稱與說明佔位置，官方給的數字是每個 Skill 約 100 個 token。

description 那一欄是整個 Skill 最重要的地方

很多人把時間花在寫內文，結果 Skill 從來沒被觸發過。原因幾乎都出在 description。

因為 Claude 是拿你的請求去比對 description，決定要不要把這個 Skill 叫出來。官方文件寫得很明白：description「必須同時說明這個 Skill 做什麼、以及什麼時候該用它」。

看官方自己的範例就懂了。它不只寫功能，後半段直接列出觸發情境：

• 只寫做什麼（容易不被觸發）：「從 PDF 抽取文字與表格」
• 做什麼＋什麼時候用（官方寫法）：「從 PDF 抽取文字與表格、填表單、合併文件。當你在處理 PDF 檔案、或使用者提到 PDF、表單、文件抽取時使用」
• 格式限制：name 只能小寫字母、數字與連字號，最多 64 字，而且不能含 anthropic 或 claude 這兩個保留字。description 最多 1024 字

Skill、提示詞、斜線指令、MCP 的分工

這幾個很容易混。它們不是互相取代，是負責不同的事。

最關鍵的一條分界是誰決定什麼時候用：斜線指令是你打 /xxx 主動叫，Skill 是它看你要做什麼、自己判斷要不要拿出來。

Skill 跟 MCP 不是二選一

這是最常被問的一組。用一句話分：MCP 給的是「連得到什麼」，Skill 給的是「怎麼做」。

MCP 讓 AI 接得到你的資料庫、行事曆、公司系統（詳見 MCP 是什麼）。但接得到不等於會用得好。它不知道你們公司的報表口徑，也不知道哪些欄位不能動。那些「怎麼做」的知識就是 Skill 的內容。

Anthropic 的工程部落格也是這樣定位的，原話是 Skill 「可以補足 MCP 伺服器，教會代理更複雜的、涉及外部工具與軟體的工作流程」。所以實務上常常是兩個一起用：MCP 接通管道，Skill 教它規矩。

三個地方都能用，但不會互相同步

Skill 的格式三邊通用，官方的說法是「Build once, use across Claude apps, Claude Code, and API」。但格式通用不等於檔案會同步，這點很多人踩到。

什麼東西適合做成 Skill

判斷標準很簡單：你是不是已經重複交代過三次以上？ 是的話就值得寫下來。

• 有固定做法的產出：報價單、月報、貼文、簡報的格式與語氣規範
• 你們公司的口徑：毛利怎麼算、哪個欄位才是真相、哪些數字不能對外
• 踩過的雷：「這個表的日期欄是民國年」「匯出前要先關掉自動篩選」這種只有你知道的事
• 需要精準、不能讓它自由發揮的步驟：包成腳本放進 Skill，讓它去執行而不是每次重新寫一份

什麼東西不該做成 Skill

這段官方文件沒有明講，是我自己用下來的判斷，寫出來給你當參考：

• 只做一次的事：直接在對話裡講就好，寫成 Skill 是多做工
• 全域性的規矩：「回我中文」「不要用破折號」這種每次都適用的，放專案指示或記憶比較對。Skill 是「特定任務才拿出來」的東西
• 會一直變的資訊：價目表、庫存這類，塞進 Skill 會過期。那是 MCP 或 API 該做的事
• 你自己都講不清楚的流程：Skill 只是把你的做法寫下來。如果那件事你本來就沒有穩定做法，先把它做穩再寫

安全：裝 Skill 等於裝軟體

這段一定要看。Skill 裡面可以放可執行腳本，而 Claude 會用 bash 去跑它。

官方的警告寫得很重：「只使用來自可信來源的 Skill，也就是你自己寫的、或從 Anthropic 取得的」。因為「Skill 透過指示與程式碼賦予 Claude 新能力，這也意味著惡意的 Skill 可以指揮 Claude 以不符合其宣稱用途的方式呼叫工具或執行程式碼」。

官方特別點名幾個風險，值得逐條記住：

• 要逐檔審過：SKILL.md、腳本、圖片、其他資源全部看，找有沒有不符合用途的網路呼叫或檔案操作
• 會去外部抓資料的 Skill 風險特別高：抓回來的內容可能含惡意指示，而且就算今天可信，它的外部依賴以後可能被換掉
• 當成裝軟體看待：接進有敏感資料或關鍵操作的正式系統時要格外小心
• ⚠️ 另外一個容易忽略的點：官方文件明載 Agent Skills 不在零資料留存（ZDR）的涵蓋範圍內，Skill 定義與執行資料依標準政策留存。放公司機密進去前要想清楚

我自己怎麼用

我把重複的工作流程都寫成 Skill，放在專案的 .claude/skills/ 裡跟著 repo 走，換電腦 pull 下來就在。

最有感的是那些「我知道但每次都要重講」的事。例如某個產出一定要先轉成圖片親眼看過才算完成、某個系統的排程不能設太密否則會咬到費用。這些以前只存在我腦袋裡，寫進 Skill 之後，它自己就會照做。

另一個意外的好處是：寫 Skill 的過程會逼你把自己的流程講清楚。 有幾次我寫到一半發現「原來我這步是憑感覺做的」，那本身就是個值得處理的問題。

怎麼寫出真的會被用到的 Skill

把上面的東西收成一份可以照做的順序：

• 先找出你重複交代最多次的那一件事，不要一次想把所有流程都寫完。官方的建議也是「從已經發現的能力缺口開始，而不是預先設想需求」
• description 寫兩段：做什麼、什麼時候用。後半段直接寫出使用者可能說的詞
• 內文寫成步驟，不要寫成說明書。它是拿來執行的，不是拿來讀的
• 內文控制在 5k token 以內，細節往外拆成獨立檔案，讓它需要時再讀
• 能寫死的就寫成腳本。腳本的程式碼不進脈絡，只有輸出進，又快又準
• 寫完真的去用一次，看它有沒有被觸發。沒被觸發九成是 description 的問題，不是內文