# 當 AI 開始學習你的工作方式：我與 Claude Skills 的相遇


那天早上打開 Claude 桌面應用的時候，我其實沒期待會有什麼驚喜。你知道的，每天例行性地打開工具，準備處理一堆待辦事項。但當我點開設定頁面，看到一個新出現的選項「Skills」時，我停下了手邊的咖啡。

欸，這是什麼?

## 那個讓我眼睛一亮的瞬間

說實話，最開始我以為又是一個需要寫複雜配置文件的功能。這幾年用過太多工具了，什麼 API 配置啊、JSON 設定檔啊，見得多了。但當我點開 Skills 的設定頁面，看到的畫面讓我愣了一下。

那裡列出了一系列已經準備好的「技能包」——Canvas Design、MCP Builder、Slack GIF Creator、還有文檔創建工具。每個旁邊都有個簡短的說明，告訴你這個技能是做什麼的。沒有複雜的安裝流程，沒有要你去讀的長篇文檔,就只是問你:要不要啟用?

我當下就想,這會不會只是個噱頭?

抱著試試看的心態,我啟用了 Canvas Design。然後隨便給了個任務:「幫我設計一個關於永續能源的簡報封面。」

接下來發生的事情,讓我重新思考了 AI 工具該是什麼樣子。

Claude 先是花了幾秒鐘讀取這個 Skill 的內容——我能看到它在載入設計原則、字體資源、還有一些我看不太懂的技術文件。然後它開始跟我講它的設計理念:為什麼選擇這個色調、這個排版為什麼能傳達永續的概念、字體的選擇又代表了什麼。

這不是那種制式的「我幫你生成了一個圖片」。它像是一個真的設計師在跟你解釋設計思路。

等它真的生成出 PDF 檔案的時候,我看著那個設計,突然意識到一件事:這不只是圖片生成,這是一整套工作流程的封裝。

## 原來我們一直用錯方式在跟 AI 溝通

你有沒有遇過這樣的情況?每次要 Claude 做類似的任務時,都得重新解釋一次你的需求、你的偏好、你的工作方式。寫一個超長的 prompt,然後祈禱它這次能理解你的意思。

我就是這樣過來的。我有個文件夾專門存各種 prompt 模板,每次要用的時候就複製貼上,然後微調。累嗎?累。有更好的方法嗎?當時我覺得沒有。

直到我看到 Skills 的運作方式,我才明白過來:我們一直在做重複性的工作,而 AI 本該幫我們省去這些重複。

Skills 的邏輯其實很簡單。你把你的工作方式、你的標準、你的偏好,一次性地整理成一個「技能包」。這個包裡面有指令文件(叫做 SKILL.md)、可能有一些腳本、可能有參考資料。然後呢?就這樣。

下次當你需要 Claude 做類似的事情時,它會自動識別出哪個 Skill 適用,然後載入那個 Skill 的內容,按照你之前定義好的方式來工作。

不用再複製貼上 prompt。不用再每次都重新解釋。你只需要說出你的需求,剩下的 Claude 自己搞定。

這聽起來好像沒什麼,但當你實際用起來,那種感覺完全不一樣。

## 我第一次上傳自己的 Skill(還搞砸了一次)


看到那些內建的 Skills 之後,我就在想:欸,我可不可以把我每週要寫的專案進度報告做成一個 Skill?

我每週都要整理團隊的工作進度、問題追蹤、下週計畫,每次都是一樣的格式,只是內容不同。這不就是最適合用 Skill 來處理的場景嗎?

說幹就幹。我去看了 GitHub 上 Anthropic 釋出的範例 Skills,想說照著做應該不難。

第一次,我興致勃勃地創建了一個文件夾,寫了 SKILL.md,把我的報告格式和要求都寫進去。打包成 zip,上傳。

失敗。

Claude 找不到這個 Skill。

後來我才發現,原來 zip 檔案的結構有要求。你不能直接把所有文件塞進 zip 就算了,你得先建一個跟 Skill 同名的目錄,然後把 SKILL.md 和其他資源放進這個目錄,最後再打包。

而且——這點我覺得很重要——你在 SKILL.md 最上面定義的名字,必須跟目錄名稱一模一樣。不然 Claude 會搞不清楚到底要載入什麼。

第二次,我按照正確的結構重新打包,上傳,成功了。

那種感覺還蠻爽的,像是你終於破解了某個遊戲的隱藏關卡。

更爽的是,當我下次要寫週報時,我只要跟 Claude 說「幫我整理這週的專案進度」,它就會自動套用我的 Skill,產生符合格式的報告。我不用再去想「欸,我上次的 prompt 是怎麼寫的」,也不用再調整格式。

這才是我想要的工具。

## Skills 跟 MCP 是什麼關係?一開始我也搞混了

如果你也在用 Claude,你可能聽過 MCP(Model Context Protocol)。我一開始完全搞不懂 Skills 跟 MCP 有什麼不同,不都是擴充 Claude 的能力嗎?

後來我花了點時間研究,才理解它們之間的關係。

怎麼說呢,MCP 就像是給 Claude 裝了一堆「工具」。比如說,你可以用 MCP 讓 Claude 連接到你的資料庫、呼叫外部 API、讀取特定服務的資料。它解決的是「Claude 能做什麼」的問題——能讀什麼資料、能呼叫什麼服務。

Skills 呢,解決的是「Claude 該怎麼做」的問題。它不提供工具,它提供知識和流程。它告訴 Claude:當你要做這件事的時候,你應該遵循這個步驟、採用這個標準、注意這些細節。

舉個例子。假設你要讓 Claude 從公司資料庫裡抓資料並生成分析報告:

- MCP 負責「連接資料庫」這個動作,讓 Claude 能夠實際讀取資料
- Skills 負責「怎麼分析這些資料」和「怎麼寫報告」,讓 Claude 按照你們公司的標準來處理

它們不是競爭關係,而是互補的。MCP 給 Claude 手腳,Skills 給 Claude 腦袋。

更有趣的是,Anthropic 提供的範例 Skills 裡面就有一個叫「MCP Builder」的技能,專門教 Claude 如何創建高質量的 MCP 伺服器。這不就是最好的證明嗎?Skills 甚至可以用來教 Claude 如何更好地使用工具。

## 那個讓我驚訝的技術細節


這裡我想分享一個我覺得很聰明的設計。

你有沒有想過,如果你啟用了一大堆 Skills,Claude 會不會每次都要讀完所有 Skill 的內容才能開始工作?那不是超耗時間和資源的嗎?

Anthropic 的工程師想到了一個優雅的解決方案,叫做「漸進式披露」(Progressive Disclosure)。

簡單來說,每個 SKILL.md 檔案最上面都有一段 YAML 格式的資訊(叫做 frontmatter),裡面包含這個 Skill 的名字和簡短描述。當你開啟對話時,Claude 只會先讀取所有 Skills 的這段簡短資訊——每個 Skill 大概只占用幾十個 token。

就像翻開一本書的目錄,快速瀏覽一遍,看看哪個章節可能有你需要的資訊。

只有當 Claude 判斷某個 Skill 跟當前任務相關時,它才會真正載入那個 Skill 的完整內容。如果 Skill 裡面還引用了其他參考資料(比如 REFERENCE.md 或範例檔案),那些也是需要時才載入。

這個設計讓我想起了程式設計裡的「懶加載」(lazy loading)概念——不需要的東西就不要事先載入,等真的需要時再說。

結果就是,即使你有一堆 Skills,對話的啟動速度和運作效率也不會受影響。這才是工程上的美感啊。

## 從 Box 到 Notion,大家都在用 Skills 做什麼

看到官方公告後,我很好奇其他人都怎麼用 Skills。去翻了翻官網和社群的討論,發現有些應用場景還真是我沒想到的。

Box(那個雲端儲存服務)說他們用 Skills 讓 Claude 能夠把儲存的文件轉換成符合公司標準的簡報、試算表和文檔。想想看,這省了多少整理格式的時間。

Notion 的產品經理則提到,Skills 讓 Claude 跟 Notion 的整合變得更順暢。不用再寫一大堆 prompt 來說明你要的格式,Claude 直接就懂。

Simon Willison(就是那個 Datasette 的作者)在他的部落格裡說,Skills 可能比 MCP 還重要。他的理由是:MCP 連接外部服務固然重要,但如果 AI 不知道怎麼正確使用這些服務,連接了也沒用。Skills 就是在教 AI 正確的使用方式。

還有人分享說,他們公司把程式碼審查的標準做成了一個 Skill。現在只要讓 Claude 看 pull request,它就會自動按照公司的編碼規範來提建議。

也有人做了品牌設計指南的 Skill,確保所有 Claude 生成的對外文件都符合品牌形象。

看到這些例子,我突然意識到 Skills 的潛力遠超過我最初的想像。它不只是個提高效率的工具,它更是一種把隱性知識(tacit knowledge)轉化為顯性知識的方式。

你知道的那些「憑經驗」、「照慣例」的做法,現在可以具體化、標準化,然後讓 AI 學會並重複使用。

## 如果要自己做一個 Skill,該注意什麼?

經過幾次嘗試後,我整理了一些心得,或許對你有幫助。

**Description 真的很重要**

SKILL.md 裡面的 description(描述)不是寫好玩的。這是 Claude 判斷要不要使用這個 Skill 的主要依據。

我犯過的錯誤是,寫得太籠統。比如「幫助處理 Excel 工作」——這太模糊了,Claude 不知道什麼情況該用。

後來我改成:「創建包含樞紐分析表和圖表的財務報表。適用於季度財報、預算分析、成本追蹤等場景。」

你看到差別了嗎?後者明確說明了功能和使用場景,Claude 就能準確判斷了。

**範例勝過千言萬語**

在 SKILL.md 裡面放幾個實際的輸入輸出範例,比你寫一大堆說明有用得多。

我在我的週報 Skill 裡面放了兩個實際的報告範例,標註了每個部分該包含什麼內容、該用什麼格式。這比我用文字描述「報告應該包含工作進度、遇到的問題、下週計畫」要清楚太多了。

**資源文件要善用**

如果你的 Skill 需要很多背景資訊或參考資料,不要全塞進 SKILL.md。可以建一個 resources 目錄,把詳細的參考資料、術語解釋、更多範例放進去。

然後在 SKILL.md 裡面註明:「詳細的術語定義請參考 resources/GLOSSARY.md」。

Claude 會在需要時才去讀那些文件。這樣既保持了 SKILL.md 的簡潔,又提供了足夠的深度資訊。

**版本管理別偷懶**

每次修改 SKILL.md 或添加新文件時,記得創建新版本。特別是在正式環境中使用的 Skills,你會希望能固定使用某個穩定版本,而不是每次都用「latest」。

我就有一次改壞了我的週報 Skill,結果當週的報告格式全亂了。幸好我有保留之前的版本,才能快速回滾。

## 這不只是個功能,這是一種新的工作方式

寫到這裡,你可能會問:Skills 到底解決了什麼問題?

對我來說,Skills 解決的不是技術問題,而是協作問題。

過去,AI 就像是個超級聰明但不了解你的實習生。每次交代任務都要從頭解釋一遍,還要擔心它會不會理解錯誤。你可能比較快自己做完。

Skills 改變了這個狀況。現在,AI 可以真正「學習」你的工作方式。不是透過機器學習那種黑箱訓練,而是透過你明確定義的規則和流程。

更重要的是,這些知識是可以分享的。

你整理出來的 Skill,可以直接給團隊其他人用。新人不用花時間摸索「我們的報告應該怎麼寫」、「我們的程式碼審查標準是什麼」,直接用相應的 Skill 就行了。

這才是 Skills 最有價值的地方:它把個人的工作方式轉化為團隊的共同資產。

我現在已經養成習慣了,每當發現自己在重複做類似的事情時,就會想:欸,這個可以做成 Skill 嗎?

有時候答案是可以,有時候不行。但這個思考過程本身就很有意思——它讓你重新審視自己的工作流程,思考哪些部分是可以標準化的,哪些部分需要保留彈性。

## 還有什麼可能性?

Anthropic 說他們還在持續開發新功能,包括簡化 Skill 創建流程、企業級的部署能力、團隊之間分享 Skills 的機制。

我很期待他們會怎麼做。

也許以後會有一個 Skills 市場,大家可以分享和下載別人做的 Skills?就像應用程式商店那樣?

也許 Skills 會變得更智能,能夠根據使用情況自動優化?

也許我們會看到更多 Skills 跟 MCP 的整合,形成更強大的 AI 工作流程?

我不知道。但我知道的是,Skills 開啟了一個新的可能性:AI 不再只是一個被動回答問題的工具,它可以主動學習你的工作方式,成為真正的協作夥伴。

如果你還沒試過 Claude Skills,我建議你找個時間玩玩看。先從內建的 Skills 開始,感受一下它是怎麼運作的。然後想想看,你的工作中有哪些重複性的任務,可以封裝成一個 Skill?

誰知道呢,也許你會發現一種全新的工作方式。

就像我那天早上,喝著咖啡,意外地發現了 Skills。

---

## 參考資料

- [Claude Skills 官方公告](https://www.anthropic.com/news/skills)
- [Agent Skills 工程技術部落格](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
- [Anthropic Skills GitHub 代碼庫](https://github.com/anthropics/skills)
- [Simon Willison: Claude Skills are awesome](https://simonwillison.net/2025/Oct/16/claude-skills/)
- [Claude Skills API 文檔](https://docs.claude.com/en/api/skills-guide)

---