重點一：技能不是提示詞，而是三層結構的 SOP 系統，摘要、流程、知識庫必須分開管理，才能逐步調校。
重點二：技能描述模糊時，Claude 正確啟動率只有約 20%；裝 500 個劣質技能，比養 20 個精良技能更傷效率。
重點三：AI 技能是「人類流程的放大器」，SOP 若寫得含糊，AI 只會更快複製混亂。
隨著 Claude 訂閱大爆發，目前公開可安裝的 Claude Code Skills，光是第三方索引站 skillsmpp，就號稱從 GitHub 上抓了超過 28 萬個技能。另一個市集 skillhub 也收錄了上萬個技能。
於是網路上開始出現各種「炫耀清單」：一次裝載 500 個、甚至 1,000 個技能，彷彿數字越大，AI 就越強。
YouTube 頻道 Simon Scrapes 近期一支影片，直接用實測數字打臉了這個迷思。
據 Simon Scrapes 引用的一項非公開實驗，當 Claude Code 技能只有「基礎設定＋模糊描述」時，模型能正確啟動對應技能的機率最低僅約 20%，等於是同一個任務連續嘗試五次，平均只有一次會真正叫對工具。
相反地，在技能描述明確、觸發條件與 hooks 設計完整的情況下，啟動率最高可提升到約 84%，但仍代表平均每五次互動就會有一次沒有成功啟動目標技能。
值得注意的是，這組數字是在僅包含四到五個精心設計技能的實驗環境下得到的；當實際部署的技能數量暴增到數百甚至上千個，而且描述彼此重疊、職能範圍模糊時，啟動失誤與「啟動錯技能」的風險只會進一步放大。
那問題到底出在哪裡？為何在網路上搜刮過來安裝的Skills，未必能幫到你？
技能不是「好一點的提示詞」
先從觀念回答起：多數人對技能的直覺是：一段更長、更精緻的 system prompt。 這個理解從根本上就偏了。
Simon Scrapes強調，真正能穩定運作的技能，是有三層結構的資料夾系統。第一層是 YAML 頭部：只有幾行，定義技能的名稱與觸發條件，決定 Claude 在掃描清單時會不會想到要用它。
第二層是 skill.md 的流程正文：告訴 Claude 啟動後按什麼順序執行，哪個節點需要停下來確認，遇到模糊輸入時怎麼追問；而第三層才是知識本體：references（細節知識庫）、assets（樣板格式）、scripts（可被呼叫的程式碼）。
這三層分開，帶來一個關鍵好處：出問題時，你知道要查哪裡。是流程描述不夠清楚？還是知識庫內容過時了？還是觸發條件寫得太模糊？三者拆開管理，才能逐步改良。
因此，把所有東西混在一個大提示詞裡，等同於把 SOP 手冊、操作說明書和程式碼，全部列印在同一張紙上，改起來無從下手。
這也是為什麼瞎裝一堆 skills，或是單純認為問題出在提問的 prompt，很難真正解決 AI 工作流的結構性問題。
漸進揭露：讓模型只看當下需要的東西
要先認知到的關鍵是，技能系統的核心設計原則叫做「漸進揭露」（progressive disclosure）。
技能清單的 YAML 頭部加總有一個 15,000 字元的上限。每次執行任務時，Claude 先掃描這份摘要清單，判斷需要啟動哪個技能；確定後，才把對應技能的流程正文載入上下文；流程中若需要查某份 reference 資料，再把那份文件讀進來。
Anthropic 官方把這個邏輯稱為「point, don't dump」：流程的作用，是在正確時機指向對的知識區塊，而不是一開始就把所有東西倒進去。
數據說明了差異。根據 Anthropic 官方指南的對比數據，同一個任務沒有技能時需要 15 輪往返對話、消耗約 12,000 個 tokens；有技能後減少到 2 個確認問題、6,000 個 tokens，執行成本減半，輸出穩定性同步提升。
更重要的是，這個架構讓技能可以組合使用。一個工作流程可以依序觸發「文件解析技能」→「資料整理技能」→「報表輸出技能」，每個技能只在需要時載入，不互相干擾。這比把所有流程塞進一個大提示詞要靈活得多。
真正值得用的技能是哪些？
技能生態的規模成長非常快，但訊號雜訊比很差。Indie Hackers 上有一位測試者花數個月評估了約 200 個技能，最後只推薦 20 個。他的篩選標準很具體：
- 第一次使用時輸出有沒有明顯超越不用技能的結果？
- 使用兩週後有沒有繼續用？
- 遇到邊界情況時會不會直接失效？
結果發現，按照上述**三個條件，大多數技能全數落榜。
當前Skills市集上重疊的情況十分嚴重。光是「SEO 寫稿」相關的技能，就有各種命名變體：SEO writer、long-form blog writer、content optimizer……。描述高度相似、觸發條件互相踩踏。把這些一次裝進來，Claude 在每次執行時都要從模糊的清單裡做選擇，選錯的機率自然升高。
反過來，養好 20 到 30 個針對自己工作流程設計的技能，讓每個技能的 YAML 描述清晰、觸發條件互不重疊，穩定啟動率可以維持在 80% 以上。這就是Skill「少而精」帶來的實際結果。
流程先於工具
技能系統最核心的現實，可以總結成依一句話：AI 是放大器，不是修復器。
一個能穩定產出的技能，背後必須先有寫清楚的 SOP、整理過的知識庫、以及對「什麼叫做完成」的明確定義。這些東西不是 AI 會幫你補上的，它們必須由人寫出來。如果一開始流程就含糊，技能只會讓混亂跑得更快。
對剛嘗試導入AI的工作者來說，有一個值得正視的慣性：習慣嘗試新工具、安裝新平台，卻很少停下來問「我們自己的流程是什麼」。
而技能系統恰好把這個問題強制搬上檯面，你必須先能說清楚自己怎麼做事，才能把它轉化成可重複呼叫的模組。
上萬個公開技能裡，真正值得用的可能不超過幾十個。但那幾十個養好了，會比 500 個裝好看的技能，更接近「組織知識的軟體化」。
資料來源：Simon Scrapes
本文初稿為AI編撰，整理．編輯/ 李先泰
