Skill 不是教程 · 寫過幾百個 skill 之後才悟出的 5 條鐵律
整理版優先睇
寫 SKILL 唔係寫教程，而係設計一個畀 AI 睇嘅觸發器。5 條鐵律教你把觸發率從 30% 拉到 95%。
呢篇文章係由一個寫過 80+ 個 skill 嘅開發者分享嘅實戰總結。佢用自己嘅 gzh-pipeline 做例子，開頭寫咗 200 行教程式說明，但 AI 觸發率只得 30%；後來改成 30 行觸發器格式，觸發率升到 95%。作者想解決嘅問題係：點解寫咗 skill 但 AI 總係唔識自動觸發？佢嘅整體結論係：SKILL.md 嘅角色唔係畀 AI 睇嘅教程，而係喺用戶開口瞬間決定係咪進入呢個 skill 嘅觸發器。
文章圍繞 5 條鐵律展開，每一條都對應一個常見嘅踩坑位：前 200 字決定一切、觸發詞要具象唔好抽象、洋葱結構（SKILL.md 做到最薄，細節放子文件）、一定要寫反向觸發清單、命名係第一觸發器。作者仲公開咗一個隱藏事實：佢寫嘅 80+ 個 skill 入面，真正經常用嘅得 6 個，共通點就係呢 5 條鐵律做得好。
最後作者提供咗一份開工 checklist，畀人寫每個新 skill 之前過一過，確保 7 項檢查全部通過，先有機會成為嗰 20% 用得到嘅 skill。
- SKILL.md 嘅前 200 字決定 AI 會唔會觸發呢個 skill，必須用 frontmatter 清楚講明功能、觸發詞、輸入輸出。
- 觸發詞要用用戶真實會講嘅口語詞，例如「公眾號」「改文案」「csv 整理」，唔好用「內容創作」呢類抽象詞。
- 用洋葱結構：SKILL.md 得 30-50 行做觸發器，詳細步驟放子文件，實現 lazy loading，慳 token 又精準。
- 必須寫明「不用於」嘅反向觸發清單，避免誤觸發浪費對話；正反兩面先可以幫 AI 準確決策。
- 命名要包含領域同動作線索（例如 gzh-pipeline），唔好用 helper/tool/utils 呢類通用字，令 AI 一眼明。
寫 Skill 開工 Checklist
1. 名字係「領域 + 動作」組合？唔係 helper/tool/utils？ 2. description 第一句話能令用戶 5 秒睇明做乜？ 3. 觸發詞寫咗 ≥ 5 個「用戶嘴裏真係會彈出來」嘅具象詞？ 4. 寫咗「唔用於」反向觸發清單？ 5. SKILL.md ≤ 50 行（細節都喺子文件）？ 6. 自己模擬 5 種用戶表達，每種都被觸發到？ 7. 模擬 5 種「應該唔觸發」嘅表達，驗證唔會誤觸發？
一個案例：從 200 行教程到 30 行觸發器
作者做咗一個叫 gzh-pipeline 嘅 skill，用嚟將口播錄音轉成公眾號成稿。最初佢寫咗 200 行詳細教程，結果發現 AI 觸發率得 30%，而且好多真實表達例如「幫我寫公眾號」都觸發唔到。
佢之後將 SKILL.md 砍到 30 行，淨保留 一句話功能描述、具象觸發詞清單、反向觸發清單同埋子文件索引。修改之後觸發率飆到 95%。
鐵律 1 & 2：前 200 字決定一切，觸發詞要講人話
Claude Code 每輪對話會將所有 skill 嘅 SKILL.md 前部分注入系統提示詞，AI 睇完呢段就決定當前任務係咪匹配。所以 前 200 字等於你嘅招牌，寫得唔好 AI 永遠唔會推門入嚟。
觸發詞一定要 具象，即係用戶口語真係會講嘅詞，例如「公眾號」、「改文案」、「csv 整理」。唔好用「內容創作」、「數據處理」呢類抽象詞，因為用戶實際表達入面出現率 < 5%。
- 一句話講明做乜（例如「把口播轉公眾號」）
- 列出場景化觸發詞（公眾號、寫推文、跑流水線...）
- 指明輸入形態（.txt 文稿）
- 暗示輸出（粘入公眾號後台嘅成品）
鐵律 3 & 4：洋葱結構 + 反向觸發
所有邏輯塞入 SKILL.md 係第二個常見錯誤，每輪對話都嘥 token 讀 200 行。正確做法係 洋葱結構：SKILL.md 得 30-50 行做觸發器，詳細步驟放子文件，用到先加載，慳 80% token。
gzh-pipeline/
├─ SKILL.md ← 最薄，只放觸發器 + 索引（30-50 行）
├─ 01-洗稿.md ← 進入後先讀
├─ 02-邏輯梳理.md
├─ 03-大標題.md
├─ 04-小標題.md
├─ 05-加粗圖位.md
├─ 06-配圖卡.md
└─ examples/
└─ ...唔好忽略 反向觸發——即係寫明「唔用於」乜嘢場景。誤觸發比唔觸發更糟糕，會浪費 30+ 輪對話。例如 gzh-pipeline 寫明唔用於單段文案優化、視頻腳本、標題黨等。
鐵律 5 + 隱藏事實：命名係人臉，80% skill 用唔到
命名係 AI 第一眼見到嘅嘢，比 description 更加先。錯嘅命名例如 my-helper-1、content-tool-v2，AI 根本唔知你做乜。啱嘅命名要包含 領域線索、動作線索同唯一性，例如 gzh-pipeline、style-decomposition。
作者透露一個殘酷事實：佢寫咗 80+ 個 skill，但真正經常用嘅得 6 個，用過 ≥100 次嘅得 3 個。寫 skill 嘅成本遠低過令 AI 真係反覆觸發佢嘅成本。大多數人卡喺第二步——寫完但從未真正生效。
6 個常用 skill 嘅共通特徵包括：名字一睇就明、觸發詞係口語、SKILL.md 係觸發器、有反向觸發、子文件清晰。而嗰 70+ 個用唔到嘅就係呢 5 條全部做錯曬。
開工 Checklist：寫每個新 Skill 前過一過
- 名字係「領域 + 動作」組合？唔係 helper/tool/utils？
- description 第一句話能令用戶 5 秒睇明做乜？
- 觸發詞寫咗 ≥ 5 個「用戶嘴裏真係會彈出來」嘅具象詞？
- 寫咗「唔用於」反向觸發清單？
- SKILL.md ≤ 50 行（細節都喺子文件）？
- 自己模擬 5 種用戶表達，每種都被觸發到？
- 模擬 5 種「應該唔觸發」嘅表達，驗證唔會誤觸發？
如果發現 AI 總係唔觸發你嘅 skill，99% 係呢 5 條入面有 1-2 條未做對。寫完之後仲要打磨「被觸發概率」，後者比前者重要 5 倍。
致讀者： 呢篇文章有4400+字，預計閲讀時間14分鐘。寫SKILL最大嘅誤區係當佢係「AI睇嘅教程」——其實佢係「AI決定用唔用你」嘅觸發器。如果你寫過SKILL（無論係Claude Code、Cursor、定係其他agent框架）超過5個，建議睇曬。
01. 一個令我反覆改咗7次嘅skill
舊年我做咗一個skill叫 gzh-pipeline——將口播錄音轉成公眾號稿件嘅6步流程。
我自己用咗一個禮拜覺得「完美」——洗稿/邏輯梳理/大標題/小標題/加粗圖位/配圖卡，每一步邏輯都打磨得好清楚。SKILL.md寫咗200行教程級別嘅說明。
然後我觀察AI嘅實際行為——
90%嘅真實表達AI觸發唔到。
我以為係觸發詞唔夠——加咗5個。都係唔得。
加到第10個——AI反而開始誤觸發：用戶講「寫一段話」都觸發咗gzh-pipeline。
嗰陣我崩潰咗。我以為自己喺度寫skill，結果我喺度寫一份AI睇唔明嘅產品手冊。
後來我將SKILL.md 由200行斬到30行——只保留4樣嘢： - skill做咩（一句話） - 幾時觸發（具體觸發詞清單） - 幾時唔觸發（反向觸發清單） - 內部子文件索引（「詳細見X.md」）
觸發率由30%飆到95%。
嗰日我先明白——
SKILL.md唔係教程，係觸發器。
寫錯嘅人90%係將佢寫成咗「AI睇完做得嘢」嘅教程，但SKILL.md真正嘅功能係——令AI喺用戶開口嘅瞬間，決定用唔用呢個skill。
呢篇文章講嘅就係呢一年我寫過80+個skill之後悟出嘅5條鐵律。每一條都對應一個我反覆踩嘅坑。
02. 鐵律1 · SKILL.md前200字決定一切
先講機制。
Claude Code（同埋大多數agent框架）加載skill嘅方式係——
每輪對話開始，將
~/.claude/skills/入面所有skill嘅SKILL.md 前部分注入到系統提示詞入面。AI睇完呢一段，決定當前任務係咪匹配某個skill。
留意幾個關鍵詞——
"前部分「——唔係全部 "注入到系統提示詞「——係每一輪都加載 "決定係咪匹配「——AI唔讀後面嘅實現細節，直到決定要用呢個skill
呢個意味住——
前200字 ≈ 你嘅招牌。AI企喺出面睇到嘅就係呢200字。寫得唔好，AI永遠唔會推門入嚟。
200字之後寫得幾靚、幾詳細——AI根本冇機會睇到。
我第一版gzh-pipeline嘅SKILL.md係咁樣——
# gzh-pipeline · 公眾號生產流水線
## 概述
本 skill 是為"把口播錄音轉成公眾號成稿"設計的 6 步流水線工具，
集成洗稿、邏輯梳理、大標題、小標題、加粗圖位、配圖卡 6 個能力，
通過精心設計的步驟化流程，可以穩定產出公眾號格式的內容...
## 詳細流程
### Step 1 · 洗稿
... [200 行詳細教程]
前200字淨係「概述+自我介紹」——AI睇完根本唔知幾時觸發我。
正確嘅寫法——
---
name: gzh-pipeline
description: Shawn.C 公眾號提示詞流水線，把口播錄音轉錄稿一鍵
走完"洗稿→邏輯梳理→大標題→小標題→加粗圖位→配圖卡"6 步，
產出可直接粘進公眾號後台的成品。
觸發詞：公眾號、寫推文、把這篇文稿做成公眾號、跑流水線、
gzh-pipeline、鱸魚公眾號。
輸入一般是一份 .txt 口播文稿路徑。
---
# 內部實現見下方各 step
...
這是真實觸發率95%嘅版本。前200字（其實係frontmatter）做咗4件事——
- 一句話講清楚做咩
（「將口播轉公眾號」） - 列出場景化觸發詞
（公眾號/寫推文/行流程...） - 指明輸入形態
（.txt文稿） - 暗示輸出
（貼入公眾號後台嘅成品）
AI睇完呢200字即刻知道——
「用戶講『幫我寫公眾號』？呢個同我描述入面嘅『寫推文/公眾號』匹配——進入。」
實現細節AI係進入之後先讀嘅——前200字嘅工作只有一件：令佢推門入嚟。
寫SKILL.md第一條鐵律——先將「被發現」做啱，再將「做得嘢」做啱。
03. 鐵律2 · 觸發詞要「具體」，唔好「抽象」
承接鐵律1——既然前200字咁重要，觸發詞點寫就係核心。
好多人嘅觸發詞寫法——
❌ 抽象觸發詞： - 「內容創作」 - 「文案優化」 - 「數據處理」 - 「圖像生成」
每一個聽落都「好啱」——但對AI嚟講幾乎等於冇寫。
點解？因為呢啲詞太寬泛——用戶實際表達嘅句子入面，「內容創作」呢啲詞出現率<5%。用戶講嘅係——
「幫我寫一篇公眾號」 「呢段文案改一下」 「將呢個csv整理成表格」 「出一張賽博朋克風格嘅圖」
✅ 具體觸發詞： - 「公眾號」/「寫推文」/「改文案」/「csv整理」/「出圖」/「賽博朋克」
具體觸發詞 = 用戶把口真係會爆出嚟嘅詞。
我而家寫觸發詞嘅方法係——
想像10個用戶用10種講法表達同一個意圖——將呢10種講法嘅關鍵詞抽曬出嚟，全部列上去。
舉個例，公眾號skill我列嘅觸發詞清單——
公眾號、推文、做成公眾號、寫公眾號、改公眾號、跑公眾號、
gzh-pipeline、鱸魚公眾號、把這篇做成公眾號、文稿轉公眾號、
口播轉公眾號、洗稿、做成成稿
13個具體觸發詞——覆蓋90%用戶真實表達。
留意我唔寫「內容生產」、「文章創作」呢啲——佢哋統計上好少出現喺用戶嘅實際口語入面。
觸發詞唔係關鍵詞列表——係「用戶把口嘅真實句子」。
寫錯觸發詞，AI就永遠喺你skill門口路過但係入唔到嚟。
04. 鐵律3 · 洋葱結構——SKILL.md最薄，能力喺子文件入面
講完觸發，講實現。
寫skill最容易犯嘅第二個錯——將所有邏輯塞入SKILL.md。
我以前嘅gzh-pipeline 200行SKILL.md就係咁—— - 6步詳細操作 - 每步嘅prompt模板 - 每步嘅輸出格式 - 每步可能嘅邊界情況 - 每步嘅參考案例
AI加載呢200行每一輪都要花token讀——但90%嘅對話根本用唔到呢個skill。
呢個就係第18篇講嘅「Skills黑洞」——sleep模式下嘅skill都喺度燒token。
正確嘅結構係洋葱——
gzh-pipeline/
├─ SKILL.md ← 最薄，只放觸發器 + 索引（30-50 行）
├─ 01-洗稿.md ← 進入後才讀
├─ 02-邏輯梳理.md
├─ 03-大標題.md
├─ 04-小標題.md
├─ 05-加粗圖位.md
├─ 06-配圖卡.md
└─ examples/
└─ ...真實案例
SKILL.md係咁樣——
---
name: gzh-pipeline
description: [觸發部分見鐵律 1]
---
# 公眾號 6 步流水線
## 觸發後的執行流程
1. 讀 `01-洗稿.md` 跑洗稿
2. 讀 `02-邏輯梳理.md` 跑邏輯
3. 讀 `03-大標題.md` 起大標題
...
具體每一步的 prompt 和示例見對應的子文件。
剩低30行。每個step嘅細節收埋喺子文件入面——AI進入呢個skill之後，按需要讀對應文件，而唔係一開始就將200行全部加載。
呢個同軟件工程入面嘅lazy loading完全一樣——用到先加載。
好處——
- 每輪節省80% token
（SKILL.md由200行→30行） - AI注意力更集中
（只喺執行某step時讀嗰個step嘅文檔） - 維護更清晰
（改某一步嘅prompt唔影響其他）
鐵律3——
SKILL.md係目錄，唔係百科。
子文件先係百科。
05. 鐵律4 · 反向觸發——清楚寫「唔用於咩」
呢條最被忽略，但誤觸發嘅代價非常高。
我啱開始寫skill時只寫「幾時用」——結果——
用戶講「寫一段話」→ AI誤觸發gzh-pipeline 用戶講「分析一下數據」→ AI誤觸發某個文檔處理skill 用戶講「睇下呢張圖」→ AI誤觸發出圖skill
誤觸發比唔觸發更糟—— - 唔觸發：用戶重新講一次就得 - 誤觸發：AI進入咗skill跑完一整套流程先發現唔啱，浪費30+輪對話
正確嘅SKILL.md必須包含反向觸發清單——
---
name: gzh-pipeline
description: ...
不用於：
- 單段文案優化（用 copywrite-polish 即可）
- 視頻腳本（用 video-script skill）
- 標題黨/營銷文（用 viral-writer skill）
- 不是"成稿"級別的需求（先跟用戶對齊）
---
呢個等於畀AI一份否決清單——佢喺判斷「用唔用呢個skill」時，先掃一次否決清單，命中就排除。
我寫好嘅skill一定會有「唔用於」section。呢個係幫AI 縮小搜索空間——而唔係只係話畀佢知「擴大搜索空間」。
反向觸發係觸發器嘅對偶——一正一反，AI決策更準。
鐵律4——
話畀AI知幾時用你 ≈ 話畀AI知幾時唔好用你。
後者同樣重要。
06. 鐵律5 · 命名係第一觸發器——呢條決定其他四條都白做
最後呢條最隱蔽。
skill命名係AI路過你skill 第一眼睇到嘅嘢——比description更先。
錯嘅命名——
my-helper-1
content-tool-v2
shawn-utils
new-skill
test-skill
AI睇到呢啲名——根本唔知你做咩。就算你description寫得幾好，第一眼「我同呢個名冇關係」就跳過咗。
啱嘅命名——
gzh-pipeline ← 一看就知道是公眾號流水線
style-decomposition ← 風格拆解
qiaomu-anything-to-notebooklm ← 多源轉 NotebookLM
better-icons ← 圖標搜索
fix-claudian ← 修 claudian
context-search ← 內容搜索
每個名都做咗3件事——
- 領域線索
（gzh=公眾號/icons=圖標） - 動作線索
（pipeline/decomposition/search/fix） - 唯一性
（唔同系統詞衝突）
命名規則——
用 領域+動作 嘅組合（gzh-pipeline/claude-api/claude-hud） 唔好用通用詞（helper/tool/utils/handler） 中文領域可以用拼音（gzh/scys）—— 比英文翻譯更穩陣 - 3-30個字符
，太短信息量唔夠，太長AI加載曬token
我寫過最差嘅命名係 content-pipeline-v3——三個月後我自己都唔記得佢做咩。後來改名 gzh-pipeline，每次見到都知道係咩。
鐵律5——
命名係skill嘅人臉——AI見到嘅第一眼，決定佢使唔使繼續睇落去。
07. 一個隱藏嘅事實 · 80%嘅skill寫完冇人用——包括我自己寫嘅
講完5條鐵律，畀一個令人唔舒服嘅統計——
我自己寫過80+個skill。一年落嚟——
80%嘅skill寫完用唔到幾次。
點解？因為寫skill嘅成本遠低過「令AI真係觸發佢」嘅成本。
寫一個skill：1個鐘 令AI真係反覆觸發佢：要打磨5-10輪（寫錯觸發詞/名/反向觸發/描述）
大多數人卡喺第二步——寫完咗，但從來冇真正生效過。
真正喺度用嘅6個skill 我列喺下面（數據嚟自Claude Code嘅transcript統計）——
gzh-pipeline（公眾號生產）—— 月用40+次 style-decomposition（風格拆解）—— 月用20+次 提示詞鍛造工坊（自定義skill）—— 月用30+次 context-search（內容搜索）—— 月用50+次 claude-hud（狀態欄）—— 持續運行 gzh-pipeline嘅6個子step——跟主skill一齊觸發
呢6個嘅共同特徵—— - 名一睇就知做咩 - 觸發詞全部係「我把口真係會爆出嚟嘅話」 - SKILL.md係觸發器唔係教程 - 反向觸發清單寫清楚 - 子文件結構清晰
嗰70+個用唔到嘅skill嘅共同特徵—— - 名含糊（「helper」/「v2」/「tool」） - 觸發詞抽象（「內容創作」/「數據處理」） - SKILL.md寫成200行教程 - 冇反向觸發 - 冇子文件結構
寫skill唔係技術問題——係「AI觸發概率」問題。
鐵律5條=觸發概率優化嘅5個槓桿。
08. 一份開工checklist · 寫每個新skill前過一次
將5條鐵律壓成checklist——
7條全部過關=呢個skill大概率會成為「用得到嗰20%」。
任何一條唔過=寫完佢會成為「用唔到嗰80%」。
09. 收個尾 · 寫skill係工程，唔係創作
返到開頭——
SKILL.md唔係教程，係觸發器。
呢句話聽落好簡單，但90%嘅人寫SKILL時第一反應都係寫教程——因為我哋習慣「寫文檔畀人睇」。
畀AI睇嘅文檔同畀人睇嘅文檔邏輯完全唔同——
寫skill嘅核心，係切換思維模式——由「寫文檔」到「設計觸發器」。
每一條鐵律都係呢個思維切換嘅一個具體落點——
- 觸發器思維
：前200字決定一切 - 用戶語言思維
：用具體詞，唔用抽象詞 - lazy loading思維
：SKILL.md係目錄，子文件係百科 - 否決思維
：話畀AI知幾時唔好用你 - 第一眼思維
：命名決定AI仲睇唔睇落去
如果你正在寫skill但發現「AI總係唔觸發」——
99%係呢5條入面有1-2條未做啱。
唔係AI蠢，係你嘅skill喺佢嘅視角下冇咁明顯。
最後講一句——
Skill唔係寫完就完事——寫完之後仲要打磨「被觸發概率」。
後者比前者重要5倍。
致讀者： 本篇文章 4400+ 字，預計閲讀時間 14min。寫 SKILL 最大的誤區是把它當成"AI 看的教程"——其實它是"AI 決定要不要用你"的觸發器。如果你寫過 SKILL（不管是 Claude Code、Cursor、其他 agent 框架）超過 5 個，建議讀完。
01. 一個讓我反覆改 7 遍的 skill
去年我做了一個 skill 叫 gzh-pipeline——把口播錄音轉成公眾號成稿的 6 步流水線。
我自己用了一週覺得"完美"——洗稿 / 邏輯梳理 / 大標題 / 小標題 / 加粗圖位 / 配圖卡，每一步邏輯都打磨得清清楚楚。SKILL.md 寫了 200 行教程級別的說明。
然後我觀察 AI 的實際行為——
90% 的真實表達 AI 觸發不到。
我以為是觸發詞不夠——加了 5 個。還是不行。
加到第 10 個——AI 反而開始誤觸發：用戶說"寫一段話"也觸發了 gzh-pipeline。
那時候我崩潰了。我以為自己在寫 skill，結果我在寫一份 AI 看不懂的產品手冊。
後來我把 SKILL.md 從 200 行砍到 30 行——只保留 4 件事： - skill 幹什麼（一句話） - 什麼時候觸發（具象觸發詞清單） - 什麼時候不觸發（反向觸發清單） - 內部子文件索引（"詳細見 X.md"）
觸發率從 30% 飆到 95%。
那天我才明白——
SKILL.md 不是教程，是觸發器。
寫錯的人 90% 是把它寫成了"AI 看完能做事"的教程，但 SKILL.md 真正的功能是——讓 AI 在用戶開口的瞬間，決定要不要進入這個 skill。
這篇文章講的就是這一年我寫過 80+ 個 skill 之後悟出的 5 條鐵律。每一條都對應一個我反覆踩的坑。
02. 鐵律 1 · SKILL.md 前 200 字決定一切
先講機制。
Claude Code（以及大多數 agent 框架）加載 skill 的方式是——
每輪對話開始，把
~/.claude/skills/裏所有 skill 的 SKILL.md 前部分注入到系統提示詞裏。AI 看完這一段，決定當前任務是否匹配某個 skill。
注意幾個關鍵詞——
"前部分"——不是全部 "注入到系統提示詞"——是每一輪都加載 "決定是否匹配"——AI 不讀後面的實現細節，直到決定要用這個 skill
這意味着——
前 200 字 ≈ 你的招牌。AI 站在外面看到的就是這 200 字。寫不好，AI 永遠不會推門進來。
200 字之後寫得多漂亮、多詳細——AI 根本沒機會看到。
我第一版 gzh-pipeline 的 SKILL.md 長這樣——
# gzh-pipeline · 公眾號生產流水線
## 概述
本 skill 是為"把口播錄音轉成公眾號成稿"設計的 6 步流水線工具，
集成洗稿、邏輯梳理、大標題、小標題、加粗圖位、配圖卡 6 個能力，
通過精心設計的步驟化流程，可以穩定產出公眾號格式的內容...
## 詳細流程
### Step 1 · 洗稿
... [200 行詳細教程]
前 200 字淨是"概述 + 自我介紹"——AI 看完根本不知道什麼時候觸發我。
正確的寫法——
---
name: gzh-pipeline
description: Shawn.C 公眾號提示詞流水線，把口播錄音轉錄稿一鍵
走完"洗稿→邏輯梳理→大標題→小標題→加粗圖位→配圖卡"6 步，
產出可直接粘進公眾號後台的成品。
觸發詞：公眾號、寫推文、把這篇文稿做成公眾號、跑流水線、
gzh-pipeline、鱸魚公眾號。
輸入一般是一份 .txt 口播文稿路徑。
---
# 內部實現見下方各 step
...
這是真實觸發率 95% 的版本。前 200 字（其實是 frontmatter）做了 4 件事——
- 一句話說清幹什麼
（"把口播轉公眾號"） - 列出場景化觸發詞
（公眾號 / 寫推文 / 跑流水線...） - 指明輸入形態
（.txt 文稿） - 暗示輸出
（粘進公眾號後台的成品）
AI 看完這 200 字立刻知道——
"用戶說'幫我寫公眾號'？這跟我描述裏的'寫推文 / 公眾號'匹配——進入。"
實現細節 AI 是進入之後才讀的——前 200 字的工作只有一件：讓它推門進來。
寫 SKILL.md 第一條鐵律——先把"被發現"做對，再把"能做事"做對。
03. 鐵律 2 · 觸發詞要"具象"，不要"抽象"
承接鐵律 1——既然前 200 字這麼重要，觸發詞怎麼寫就是核心。
很多人的觸發詞寫法——
❌ 抽象觸發詞： - "內容創作" - "文案優化" - "數據處理" - "圖像生成"
每一個都聽起來"很對"——但對 AI 來說幾乎等於沒寫。
為什麼？因為這些詞太寬泛——用戶實際表達的句子裏，"內容創作"這種詞出現率 < 5%。用戶說的是——
"幫我寫一篇公眾號" "這文案改一下" "把這個 csv 整理成表格" "出一張賽博朋克風的圖"
✅ 具象觸發詞： - "公眾號" / "寫推文" / "改文案" / "csv 整理" / "出圖" / "賽博朋克"
具象觸發詞 = 用戶嘴裏真的會蹦出來的詞。
我現在寫觸發詞的方法是——
想象 10 個用戶用 10 種說法表達同一個意圖——把這 10 種說法的關鍵詞摳出來，全列上去。
舉個例子，公眾號 skill 我列的觸發詞清單——
公眾號、推文、做成公眾號、寫公眾號、改公眾號、跑公眾號、
gzh-pipeline、鱸魚公眾號、把這篇做成公眾號、文稿轉公眾號、
口播轉公眾號、洗稿、做成成稿
13 個具象觸發詞——覆蓋 90% 用戶真實表達。
注意我不寫"內容生產"、"文章創作"這種——它們統計上很少出現在用戶的實際口語裏。
觸發詞不是關鍵詞列表——是"用戶嘴裏的真實句子"。
寫錯觸發詞，AI 就永遠在你 skill 門口路過卻進不來。
04. 鐵律 3 · 洋葱結構——SKILL.md 最薄，能力在子文件裏
講完觸發，講實現。
寫 skill 最容易犯的第二個錯——把所有邏輯塞進 SKILL.md。
我以前的 gzh-pipeline 200 行 SKILL.md 就是這樣—— - 6 步詳細操作 - 每步的 prompt 模板 - 每步的輸出格式 - 每步可能的邊界情況 - 每步的參考案例
AI 加載這 200 行每一輪都要花 token 讀——但 90% 的對話根本用不到這個 skill。
這就是第 18 篇講的"Skills 黑洞"——sleep 模式下的 skill 也在燒 token。
正確的結構是洋葱——
gzh-pipeline/
├─ SKILL.md ← 最薄，只放觸發器 + 索引（30-50 行）
├─ 01-洗稿.md ← 進入後才讀
├─ 02-邏輯梳理.md
├─ 03-大標題.md
├─ 04-小標題.md
├─ 05-加粗圖位.md
├─ 06-配圖卡.md
└─ examples/
└─ ...真實案例
SKILL.md 長這樣——
---
name: gzh-pipeline
description: [觸發部分見鐵律 1]
---
# 公眾號 6 步流水線
## 觸發後的執行流程
1. 讀 `01-洗稿.md` 跑洗稿
2. 讀 `02-邏輯梳理.md` 跑邏輯
3. 讀 `03-大標題.md` 起大標題
...
具體每一步的 prompt 和示例見對應的子文件。
只剩 30 行。每個 step 的細節藏在子文件裏——AI 進入這個 skill 之後，按需讀對應文件，而不是一開始就把 200 行全部加載。
這跟軟件工程裏的 lazy loading 完全一樣——用到才加載。
收益——
- 每輪節省 80% token
（SKILL.md 從 200 行 → 30 行） - AI 注意力更集中
（只在執行某 step 時讀那個 step 的文檔） - 維護更清晰
（改某一步的 prompt 不影響別的）
鐵律 3——
SKILL.md 是目錄，不是百科。
子文件才是百科。
05. 鐵律 4 · 反向觸發——明確寫"不用於什麼"
這條最被忽略，但誤觸發的代價非常高。
我剛開始寫 skill 時只寫"什麼時候用"——結果——
用戶說"寫一段話" → AI 誤觸發 gzh-pipeline 用戶說"分析一下數據" → AI 誤觸發某個文檔處理 skill 用戶說"看看這個圖" → AI 誤觸發出圖 skill
誤觸發比不觸發更糟糕—— - 不觸發：用戶重說一遍就行 - 誤觸發：AI 進入了 skill 跑完一整套流程才發現不對，浪費 30+ 輪對話
正確的 SKILL.md 必須包含反向觸發清單——
---
name: gzh-pipeline
description: ...
不用於：
- 單段文案優化（用 copywrite-polish 即可）
- 視頻腳本（用 video-script skill）
- 標題黨/營銷文（用 viral-writer skill）
- 不是"成稿"級別的需求（先跟用戶對齊）
---
這等於給 AI 一份否決清單——它在判斷"要不要進入這個 skill"時，先掃一遍否決清單，命中即排除。
我寫好的 skill 一定會有"不用於"section。這是在幫 AI 縮小搜索空間——而不是隻告訴它"擴大搜索空間"。
反向觸發是觸發器的對偶——一正一反，AI 決策更準。
鐵律 4——
告訴 AI 什麼時候用你 ≈ 告訴 AI 什麼時候別用你。
後者同等重要。
06. 鐵律 5 · 命名是第一觸發器——這一條決定其他四條都白做
最後這條最隱蔽。
skill 命名是 AI 路過你 skill 第一眼看到的東西——比 description 更先。
錯的命名——
my-helper-1
content-tool-v2
shawn-utils
new-skill
test-skill
AI 看到這種名字——根本不知道你是幹嘛的。哪怕你 description 寫得再好，第一眼"我跟這名字沒關係"就跳過了。
對的命名——
gzh-pipeline ← 一看就知道是公眾號流水線
style-decomposition ← 風格拆解
qiaomu-anything-to-notebooklm ← 多源轉 NotebookLM
better-icons ← 圖標搜索
fix-claudian ← 修 claudian
context-search ← 內容搜索
每個名字都做了 3 件事——
- 領域線索
（gzh = 公眾號 / icons = 圖標） - 動作線索
（pipeline / decomposition / search / fix） - 唯一性
（不與系統詞衝突）
命名規則——
用 領域 + 動作 的組合（gzh-pipeline / claude-api / claude-hud） 別用通用詞（helper / tool / utils / handler） 中文領域可以拼音（gzh / scys）—— 比英文翻譯更穩 - 3-30 字符
，太短信息量不夠，太長 AI 加載費 token
我寫過最差的命名是 content-pipeline-v3——三個月後我自己都忘了它幹嘛。後來改名 gzh-pipeline，每次看到都知道是什麼。
鐵律 5——
命名是 skill 的人臉——AI 看到的第一眼，決定它要不要繼續看下去。
07. 一個隱藏的事實 · 80% 的 skill 寫完沒人用——包括我自己寫的
講完 5 條鐵律，給一個讓人不舒服的統計——
我自己寫過 80+ 個 skill。一年下來——
80% 的 skill 寫完用不到幾次。
為什麼？因為寫 skill 的成本遠低於"讓 AI 真的觸發它"的成本。
寫一個 skill：1 小時 讓 AI 真的反覆觸發它：要打磨 5-10 輪（寫錯觸發詞 / 名字 / 反向觸發 / 描述）
大多數人卡在第二步——寫完了，但從來沒真正生效過。
真正在用的 6 個 skill 我列在下面（數據來自 Claude Code 的 transcript 統計）——
gzh-pipeline（公眾號生產）—— 月用 40+ 次 style-decomposition（風格拆解）—— 月用 20+ 次 提示詞鍛造工坊（自定義 skill）—— 月用 30+ 次 context-search（內容搜索）—— 月用 50+ 次 claude-hud（狀態欄）—— 持續運行 gzh-pipeline的 6 個子 step —— 跟主 skill 一起觸發
這 6 個的共同特徵—— - 名字一看就知道在做什麼 - 觸發詞全是"我嘴裏真的會蹦出來的話" - SKILL.md 是觸發器不是教程 - 反向觸發清單寫明白 - 子文件結構清晰
那 70+ 個用不到的 skill 的共同特徵—— - 名字含糊（"helper" / "v2" / "tool"） - 觸發詞抽象（"內容創作" / "數據處理"） - SKILL.md 寫成 200 行教程 - 沒有反向觸發 - 沒有子文件結構
寫 skill 不是技術問題——是"AI 觸發概率"問題。
鐵律 5 條 = 觸發概率優化的 5 個槓桿。
08. 一份開工 checklist · 寫每個新 skill 前過一遍
把 5 條鐵律壓成 checklist——
7 條全過 = 這個 skill 大概率能成為"用得到的那 20%"。
任何一條不過 = 寫完它會成為"用不到的那 80%"。
09. 收個尾 · 寫 skill 是工程，不是創作
回到開頭——
SKILL.md 不是教程，是觸發器。
這句話聽起來很簡單，但90% 的人寫 SKILL 時第一反應都是寫教程——因為我們習慣"寫文檔給人看"。
給 AI 看的文檔跟給人看的文檔邏輯完全不同——
寫 skill 的核心，是切換思維模式——從"寫文檔"到"設計觸發器"。
每一條鐵律都是這個思維切換的一個具體落點——
- 觸發器思維
：前 200 字決定一切 - 用戶語言思維
：用具象詞，不用抽象詞 - lazy loading 思維
：SKILL.md 是目錄，子文件是百科 - 否決思維
：告訴 AI 什麼時候別用你 - 第一眼思維
：命名決定 AI 還看不看下去
如果你正在寫 skill 但發現"AI 總是不觸發"——
99% 是這 5 條裏有 1-2 條沒做對。
不是 AI 笨，是你的 skill 在它的視角下沒那麼明顯。
最後說一句——
Skill 不是寫完就完事——寫完之後還要打磨"被觸發概率"。
後者比前者重要 5 倍。