大家好，我是 Maple，上星期三很榮幸地能夠到 Generative AI 年會小聚分享自己對 skills 的一些見解。這次我第一次參加小聚 XD 短短的 10 分鐘要講一件事，真的是比花 60 分鐘講一件事還要困難，因為塞了太多想講的東西，基本上從頭到尾語速都是用飆的，但也是因為有這次的經驗，讓我知道短講該呈現什麼樣的東西，很感謝 Muyueh Lee 給我這個機會，也認識了一些新朋友和前輩
2026 年的 4 月，對大家而言 Skills 早已不是什麼新東西，但為什麼還要特地為 skills 開專場？除了看大家怎麼把自己的工作流變成 skills 之外，我想從 skills 的本質出發，再帶大家比較少被提到的 skills 的機制
這篇文章整理的是簡報後半段的內容，完整簡報放在文章開頭可以直接播放，如果你對 skills 的出現、本質和機制有興趣的話，歡迎你把這篇讀下去：）
skills 是什麼？
Skills 從 2025 年底出現迄今，大家多多少少都有一些自己的 skills ，應該也很熟悉了。但當被問到 skills 是什麼的時候，該怎麼解釋呢？我想大家的認知會是，skills 可能是一系列的 markdown 文件、重複指令的 shortcuts、或是別人寫好的 workflow。但我想先帶大家回到 skills 出現之前，那時候如果你有在使用 Claude Code 開發的話，當時有一件經常令人詬病的事：Claude 非常的愛寫 .md 以及一次性的 scripts。
為什麼要提 skills 出現之前 Claude 的行為？因為把 .md 和 scripts 拼起來，不就是我們現在的 skills 嗎？既然 skills 好像不是什麼新東西，那 skills 的本質是什麼？
skills = Context Engineering
我認為 skills 的本質是 Context Engineering，再加上一點點的機制。前面提到 skills 就是把 AI 很愛寫 .md 跟 scripts 打包成一起，還有加上一點點的機制（像是漸進式揭露），但為什麼這樣就說是 Context Engineering？可以從很愛寫 .md 跟 scripts 開始談起
AI 會一直寫 .md 的原因是 context window 終究有限，所以 LLM 想透過 .md 作為外部記憶紀錄下來，日後有個東西可以查看，避免忘記要怎麼做，做了什麼，以及為什麼這樣做。還有與其讓 AI 自己寫 .md 檔；至於 scripts，則是因為 AI 終究有隨機性，但 scripts 是穩定的，與其自己每次都重新生成指令，還有可能寫錯要重寫一次，不如寫成執行檔案，只要呼叫檔案，每次都能得到穩定的結果
所以 skills 的出現，只是將這件事情交還給使用者，因為與其讓 AI 自己寫一堆的 .md 跟 scripts 搭配，自己決定「哪些是重要的所以要記下來」，不如讓使用者有意識地去做這件事情，因為使用者絕對比 AI 來的清楚哪些事情是需要記錄的重點
想要把 skills 玩好，本質上就是把 Context Engineering 給玩好
skills 的機制
但具體來說該怎麼透過 skills 來完成 Context Engineering 呢？承前所述，skills 的本身有一些機制，我認為要先從認識這個機制開始。大家在寫 skills 的時候，大部分都是只寫 name 以及 descriptions，包含 superpowers 這個相當知名的 skills 也是。
但其實 skills 可以寫的欄位遠遠不止這兩個，可以設定要不要讓 AI 觸發，或是只能使用者觸發，要不要設定 hooks、或是在特定路徑才能看到 skills，甚至可以把 skills 當成一個任務，只要設定 context: fork 以及 model，就能透過 sub-agent 去執行，執行完再把結果回傳給 parent agent
fork agent skills 跟單純的 skills 有什麼差別？
前面提到，Skills 的本質我認為是 Context Engineering，我以 code review 來舉這兩個的差異。
如果今天單純設定 skills，最直接的問題是污染上下文和球員兼裁判。可能整個對話前面都在討論跟開發，現在要接著做 code review，等同在自己找自己的問題，有時候會有盲點，就像要自己檢查自己的數學算式一樣，效果可能不比別人來檢查的好，就像沒有 AI 的時候，改 code 發 PR 的人，跟 review approved 的人通常也是不同的
如果是透過 fork agent skills 的話，就像你開了一個新的 session 跑 code review，效果我認為會比較好，也能隔離上下文，避免上下文污染。但當然缺點是比較燒 token，畢竟多起了一個 sub-agent。
兩者的使用情境差異
以我自己來說，一般的 skills 我通常會用在
- 我很常下重複一直下的 prompt，比如「幫我寫一個清楚的 commit message」
- 幫 Claude 做能力擴充，比如我有 reddit-search 以及 dcard-search 兩個 skills ，讓 Claude 能像人類一樣去逛論壇幫我找看法
- 按需載入才需要的背景知識，比如怎麼寫出好的 prompt，這是需要下指令給 sub-agent 才需要用到的，一直存在就佔用 context
而 fork agent skills 我會用在通用性的重複任務，跟不在意過程只在意結果的狀況，就像 code review，通常我只在意我的 code 哪邊有問題，但是過程中讀了哪些檔案我其實不太在乎，就好比我們平常跟 Claude 溝通時，也只會問「這個 feature 在做什麼？」，我們只在乎答案，其實不太在意他讀了什麼
要隔離上下文那不如 sub-agent？
Sub-agent 跟 fork agent skills 其實可以搭配使用，skills 有一個 agent，就是用來指定用的，以我自己來說，sub-agent 會是一個帶有 domain knowledge 的設定，也就是有你先寫好的 system prompt，直接讓 Claude 用來呼叫就像你在下 prompt 一樣，每次都不太一樣；但搭配 fork agent skills，會變成像一組預設好的指令+預設好的專家，只要你想呼叫這個 sub-agent，透過這個 skills 去觸發（不論是使用者還是 Claude），下的 prompt 都會相同
結語
最後想大家分享的是，skills 是需要管理的，鼓勵你用完別人的 skills 然後爆改成自己的，畢竟 skills 也可以視為工作流的一部份，每個人都一定有自己最適合的工作流，像我自己就有把官方的 simplify 改成比較適合自己的版本
以及 JB Lau 在曼谷的 Claude Code Meetup 時分享的一句話：「未來或許我們不再 Import Library，而是 Import Skills」，我覺得這件事情正在發生，也是未來會持續進行的，我推薦大家去看原片，有一些跟 Claude 還有 Context Engineering 的技巧
這句話其實也可以用來回答一些跟 skills 有關的疑問，像是可能會想知道「skills 裝越多越好嗎，還是必要再裝」、「安裝 skills 建議只從官方來嗎？還是開源的也可以裝？」，如果我們把這兩個問題的「skills」換成「套件」，我認為答案就很顯而易見了！
最後，謝謝大家讀到這裡，如果你有任何不同的想法或是意見，歡迎跟我分享，或是有錯誤的地方也請不吝指教：）
