Claude Code Skill 怎麼建才會被自己用？9 個從實戰學到的原則

Claude Code Skill 怎麼建才會被自己用？多數人建了 skill 結果都沒在用、廢成本超高。這篇從我自己建 8 個 skill 一年的實戰、整理出 9 個原則：觸發詞要狹窄、失敗回饋必須內建、用真實案例不用抽象、Skill 跟 Memory 邊界、短而精、上下游關係、紅線比規範重要、定期 review、紀錄觸發次數。附 3 個真實 skill 案例拆解 + 什麼時候不該建 skill。

Claude Code Skill 一年下來、我建了 8 個（5 個自己寫、3 個從 plugin 裝）。回頭看、有些 skill 我每週都用、有些建了之後三個月碰一次、有些已經完全忘了它存在。

這篇從「事後檢討」的角度寫：為什麼有的 skill 會活、有的死。寫過《Claude Code Skill 規劃方法論》是規劃層、這篇是建造層。兩篇互補、配著看更完整。

想直接看實戰原則的、跳到第二段。想知道為什麼多數人 skill 都廢的、從第一段看。

為什麼多數人的 Claude Code Skill 後來都沒在用

三個常見死因：

9 個建立好 Claude Code Skill 的實戰原則

原則 1：觸發詞要狹窄專一、不要貪

跟死因 1 對應。觸發詞列表越長、false positive 越多。目標是「不該觸發時不觸發」優先於「該觸發時都觸發」。

具體做法：列觸發詞時、每個都問自己「這個詞單獨出現時、有沒有 80%+ 機率使用者真的要這個 skill」。低於 80% 就剔除。寧可漏觸發、不要錯誤觸發。

原則 2：失敗回饋機制必須內建

Skill 要在 SKILL.md 顯眼位置寫一段「失敗回饋」、告訴 Claude 看到使用者哪些回饋時、要把學到的東西寫回這份 skill。

例子：「使用者說『這條太硬』、就把那個情境寫回 skill 對應段落」。沒有這條、skill 永遠停在初版。我的「九黎月多平台發文」skill 有這條、結果現在累積了 5 條真實演算法觀察、是初版沒有的價值。

原則 3：用真實案例當 ground truth、不用抽象範例

Skill 裡舉例的時候、用你真實做過的事、不要編「假設我們有一個 X 案例」。AI 模型對抽象範例的學習效果遠不如對真實具體案例的。

例子：寫「Threads 演算法觀察」時、列「2026-05-15 那篇 1734 views、做了 X」比「假設一篇貼文得到不錯觸及」強 10 倍。

原則 4：Skill 跟 Memory 的邊界要清楚

Skill = 流程跟方法論。Memory = 點狀事實、偏好、密碼路徑這類資料。混在一起會雙方都廢。

判斷標準：如果這個內容是「下次遇到 X 情境、按 Y 流程做」、放 skill。如果是「Z 這個東西放在 /Users/leo/abc」、放 memory。

原則 5：短而精勝過長而全

Skill 越長、Claude 載入越慢、context 越貴。目標是 5-15 KB（中文 2000-6000 字），多寫反而扣分。

壓縮技巧：刪除「為什麼」改成「怎麼做」、用表格取代段落、把細節 link 到外部檔案而非寫進 skill 主體。

原則 6：上下游關係明說

好的 skill 知道自己在 workflow 哪個位置、會主動 mention 下游 skill。例如我的「週期發文」skill 在 Daily Step 4 會說「給可動建議後等使用者拍板、確認後叫『多平台發文』skill 接手」。

這樣 Claude 不會在多個 skill 之間斷裂、使用者也不需要記住「下一步要叫哪個 skill」。

原則 7：紅線比規範重要

Skill 裡列「該做什麼」十條、不如列「不要做什麼」三條。

原因：Claude 預設會生成合理內容、不需要你列規範。但 Claude 預設沒辦法知道你的「絕對不能踩的雷」是什麼。「不要用破折號」「不要工商連發」「不要簡體中文」這種紅線、Claude 不知道你就會踩。

原則 8：每月 review 一次、過時的部分要砍

Skill 寫完不能就放著。每月底打開看一次、問自己「這條規則現在還對嗎」。砍掉過時的、加上新學到的。

操作：在 CLAUDE.md 加一條「每月底跑一次 skill review」、列出所有自建 skill 的路徑、Claude 看到觸發詞會逐一打開讓你掃。

原則 9：從第一天就紀錄觸發次數

你不知道一個 skill 有沒有真的被用、就沒辦法判斷它是好是壞。最低成本做法：skill 在被觸發後、做一句「[skill-name] loaded」的 console log。

一個月後看次數：超過 10 次 = 真的有在用、值得繼續維護。低於 3 次 = 可能該砍。

3 個真實 Claude Code Skill 案例拆解

案例 1：「九黎月寫文章」(18 KB) — 為什麼是這個長度

九黎月部落格從 SEO 規劃、metadata 設計、內文 SEO 結構、AI 感檢查、commit 流程、社交平台導讀文都涵蓋。長度 18 KB、超過原則 5 的建議上限。

為什麼還是這麼長：寫部落格的所有步驟都互相依賴（SEO 影響 metadata、metadata 影響 commit message、commit 影響部署）。拆成多個 skill 反而會在 skill 之間斷裂、漏掉細節。

取捨：接受 context 成本、換完整性。每次觸發載 18 KB 是貴、但確保流程不漏。

案例 2：「九黎月多平台發文」— 怎麼整合外部方法論

原本只涵蓋 5 平台版本生成。最近偷學 Hao0321 開源的「7 套爆款公式 + 14 天內容日曆」、整合進 skill 底部。

整合原則：與其直接複製，更該做「九黎月版」改寫 — 每個公式標註九黎月適配度、補上九黎月版題目範例、連到既有實測紀錄。

結果：原 skill 9 KB、整合後 12 KB、增加值遠大於成本。外部方法論變成自己的方法論。

案例 3：「九黎月週期發文」— 日級 vs 週級觸發詞分離

這個 skill 一開始只有「週計畫」、「下週發什麼」這種週級觸發詞。後來發現我每天會問「今天該做什麼」、但 skill 沒中。

解法：description 加日級觸發詞（「今天該做什麼」、「今日策略」、「日常 check-in」），內文加 Daily Step 0-3 流程（自動 refresh AK tracker → 給可動建議）。

學到的事：使用者實際說話的詞、跟你想像中的觸發詞、常常不一樣。第一版觸發詞不要綁死、保留擴充空間。

什麼時候不該建 Claude Code Skill

我的想法 — 九黎月怎麼看建 Claude Code Skill 這件事

建 skill 這件事、我想到江湖。

九黎月寫過幾首江湖題的歌、那個世界裡每個門派都有自己的劍譜。但好的劍譜從來都是寫給「會用劍的人」、不是寫給「劍譜收集者」。 多數人建 skill 的方式像在收集劍譜 — 看到一個酷的就寫一份、寫完放著、後來連自己都忘了。 真正會用的劍譜、寫的時候就在想「下週我練劍的時候、這份譜要怎麼幫我」。

所以原則 9 最關鍵 —紀錄觸發次數。 不被自己用的 skill 就是不存在。一個月超過 10 次的 skill 才值得繼續打磨、低於 3 次的該砍就砍。

對 AI 工作流的人具體一句話：別當 skill 收集者、當 skill 使用者。 建之前先問「下個月我會用幾次」、答不出來就先別建。

結論

Claude Code Skill 是強大的工具、但強大的前提是「真的會被用」。9 個原則裡如果只能選一個記住、就選原則 1：觸發詞要狹窄專一。 這條是其他 8 條的根本 — 觸發詞錯了、後面寫得再好都浪費。

接著看《Claude Code Skill 規劃方法論》補規劃層、看《Claude Code 指令救命集》補日常使用、看《Claude Chat、Code、Cowork 三者差別》補 Claude 產品線選擇。四篇形成完整的 Claude 工作流系列。