# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：黄小木 (@ai_xiaomu) · 平台：X (Twitter) · 日期：2026-05-24

> 原始來源：https://x.com/ai_xiaomu/status/2058360688293331143

## 中文摘要

# Skill 小白完整入門教學（做出你的第一個 Skill）

每個用 AI 工作的人都遇過這個問題：

你教會它一件事，隔天開新對話，一切歸零。

你花三天調好一套工作流程，跟 Claude 來回對話搞定了，隔天又要從頭解釋。

你把 prompt 存在筆記裡每次貼，但一段 500 字的指令，每天貼一次，貼一個月，你開始懷疑，這真的是 AI 該有的用法嗎？

Skill 就是為了專門解決該問題而誕生的。

它在 2025 年 10 月由 Anthropic 推出，12 月成為開放標準。

如今全網都在喊「Skill 改變生產力」，但大多數人只是聽說過，沒真正搞懂它跟提示詞、跟知識庫、跟 MCP、跟 Agent 到底有什麼區別，更沒動手做一個出來。

本文一次講透。

先理解一件事：Skill 不綁定任何 AI

很多人聽到 Claude Skills 就以為這是 Claude 專屬功能，其實完全不是。

Agent Skills 是 Anthropic 推出的開放標準，Claude 只是帶頭實現者。

同一個 Skill 資料夾，既可以放在 `~/.claude/skills/` 給 Claude Code 用，也可以放在 `~/.cursor/skills/` 給 Cursor 用，還能給 OpenAI Codex、Gemini CLI、VS Code Copilot、JetBrains Junie 用。

你今天寫的 Skill，明天可以無縫搬到另一個 Agent 上，投入不會被鎖死在一家。

文章下面會以 Claude Code 為主舉例（因為它是標準制定者，生態最全），但所有原理、寫法、避坑經驗，對所有支援 Agent Skills 的 AI 工具都通用。

看到「Claude Skill」時，你心裡要等同於「Agent Skill」。

---

## 一、Skill 到底是什麼

一句話定義

Skill 就是一個資料夾，核心是一個叫 `SKILL.md` 的 Markdown 檔案，告訴 AI 按你定義的 SOP 穩定執行某類專業工作。

它把「某類事情應該怎麼做」封裝成可複用、可自動觸發的能力模組。

它的本質是給通用 AI 裝上的「擴充包」。

通用 AI 像出廠的裸機，智力夠但不懂你的領域。Skill 是即插即用的功能模組——裝上一個「小紅書風格 Skill」，AI 立刻變成懂你品牌的小編；

裝上一個「週報 Skill」，AI 立刻按你公司格式出週報。

而且這個「擴充包」不挑 AI：Claude Code、Codex、Cursor、Gemini CLI、Junie 都認得同一種格式。

你做的是 Agent Skill，不是 Claude 專屬腳本。

和四個東西的邊界

很多人把 Skill 和提示詞、知識庫、MCP、Agent 混著說，其實分得很清：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629327-diaHIfFr3agAAuMJVjpg.jpg)

通俗類比：

- 提示詞 = 你給員工發了一條訊息，說完就忘
- Skill = 你給員工寫了一本工作手冊放他桌上，還附帶工具箱
- 知識庫 = 圖書館，告訴你世界上有什麼
- MCP = 廚房裡的各種廚具，解決「能不能做」
- Agent = 整個員工系統，有記憶能決策，Skill 只是它身上的一個零件

這四件事不是互斥的。

實際工作裡經常組合用：

MCP 讓 Claude 連到 Reddit 抓資料，Skill 教它抓到資料後怎麼篩選/分類/推薦，知識庫提供品牌資料庫，Agent 是整個跑通的系統。

---

## 二、架構與運作機制

檔案結構

```
skill-name/
├── SKILL.md          (必需：YAML 元資料 + Markdown 指令)
├── scripts/          (可選：可執行程式碼，確定性任務)
├── references/       (可選：按需載入的參考文件)
└── assets/           (可選：輸出用的模板/素材)
```

每個子目錄解決的是不同問題，但服務於同一件事——省 context、穩品質：

- scripts/ 不佔 context 又算得準
- references/ 按需載入不浪費空間
- assets/ 讓輸出格式標準化

三層漸進式披露（Progressive Disclosure）——Skill 設計的靈魂

Skill 的核心機制是三層載入，這是它能在十幾個並存卻不爆 context 的根本原因：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629611-diaHIfGiOaMAAWp0pjpg.jpg)

打個比方：

Claude 啟動時只翻所有 Skill 的「封面」，決定該用哪一本；

真要做事了才打開正文；

遇到需要查附錄時才翻附錄。

這套機制讓你同時掛 17 個 Skill 也不會塞爆 200K 的 context 視窗。

YAML 元資料

```yaml
---
name: your-skill-name
description: 這個技能做什麼以及何時使用。包括觸發上下文、檔案類型、
  任務類型和使用者可能提及的關鍵字。
license: MIT
allowed-tools: Bash, Read, Grep
trigger_keywords:
  - 關鍵字1
  - keyword2
version: 1.0
---
```

欄位說明：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629455-diaHIfHZmbIAABDNCjpg.jpg)

Description 決定生死

三層架構裡，L1 的 description 是最關鍵的——它決定你的 Skill 會不會被觸發。

幾個核心事實：

1. Claude 啟動時只讀所有 Skill 的 description
2. 根據 description 做語意判斷，不是關鍵字比對
3. Claude 傾向保守：不確定就不觸發，實測描述模糊時觸發準確率只有 55%

反例（永遠不會被觸發）：

```yaml
description: 幫助處理日常工作。
```

正例（Anthropic 官方推薦「pushy」風格）：

```yaml
description: 每日工作規劃流程。當使用者說「規劃今天」「daily planning」
  「今日規劃」「開工」時使用。即使使用者沒明確說「規劃」二字，
  只要在早晨問「今天做什麼」，也務必觸發此 skill。
```

寫好 description 的三條鐵律：

1. WHAT + WHEN 一起寫：既說做什麼，又說什麼時候用
2. 觸發詞中英文雙語都列：使用者怎麼說就比對什麼
3. 寧可 pushy 不要保守：Anthropic 官方明確說，主流問題是欠觸發

---

## 三、寫好 Skill 的核心原則

三大原則

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629088-diaHIfItdbUAAldBfjpg.jpg)

自由度怎麼把握：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629671-diaHIfJzXagAAwhowjpg.jpg)

五種設計模式

Anthropic 從早期使用者歸納出五種 Skill 設計模式：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629544-diaHIfLNDbkAAjxTdjpg.jpg)

好用的 Skill 通常混用多種模式。

你不用刻意套，但知道有這些可能性，設計時會更有結構。

黃金法則：用「為什麼」代替「必須」

這是 skill-creator（Anthropic 官方做 Skill 的元 Skill）原始碼裡的原話：

> "Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs."

> （與其用一堆死板的 MUST 來壓模型，不如跟它解釋為什麼這件事重要。）

反例：

```
ALWAYS 在執行指令前顯示指令內容。NEVER 直接執行。
```

正例：

```
執行指令前先顯示內容，因為使用者需要確認安全性。
未經確認就執行可能造成不可逆的損害。
```

第一種寫法，Claude 只會照做這兩條規則，規則沒覆蓋的情境（比如一個看起來安全但其實有風險的指令）它就傻了。

第二種寫法，Claude 理解了「為什麼是保護安全」，遇到灰色地帶也會傾向謹慎。

原因讓模型舉一反三，規則只能覆蓋你想得到的情境。

唯一的例外是輸出格式：「輸出一定要用這個模板」這種機械要求，沒有「為什麼」可解釋，直接寫死。

資訊歸屬：別重複

skill-creator 還有一條鐵律：

> "資訊應該存在於 SKILL.md 或 references 中——不能同時存在。"

SKILL.md 只留基本程式，詳情移到 references。重複存放會導致後續維護時改一處忘另一處，產生不一致。

不要放的檔案

Skill 是給 AI 看的，不是給人看的：

別加 README.md、INSTALLATION_GUIDE.md、QUICK_REFERENCE.md、CHANGELOG.md 這些人類文件，它們只會浪費 context。

---

## 四、動手做第一個 Skill

Anthropic 官方六步

skill-creator 內部定義的標準流程：

1. Capture Intent：讓使用者說清做什麼 / 何時觸發 / 輸出格式 / 是否需要測試
2. Interview & Research：邊角案例 / 輸入輸出格式 / 範例檔案 / 依賴
3. Write SKILL.md：寫草稿
4. Test Cases：寫 2-3 個真實測試用例
5. Run & Evaluate：同時跑 with-skill 和 baseline 雙盲對比，生成 benchmark
6. Iterate：根據回饋改，重跑，直到滿意

普通人的四條快速路徑

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629292-ediaHIfL7bAAA3BXyjpg.jpg)

skill-creator：寫 Skill 的元 Skill

強烈推薦先裝 Anthropic 官方的 skill-creator。

它是一個專門用來幫你做 Skill 的 Skill，啟動後 Claude 會像訪談一樣問你問題——你的工作流長什麼樣、什麼時候該觸發、有哪些邊界條件——然後自動生成 SKILL.md 和資料夾結構。

安裝指令：

```
幫我安裝這個 skill，網址：https://github.com/anthropics/skills/tree/main/skills/skill-creator
複製到 ~/.claude/skills
```

它不只是產出，還能幫你：

- Eval：自動生成測試案例，驗證 Skill 能不能正確觸發。
- Improve：根據測試結果自動優化 description 和指令，用 60/40 train/test split 防止過擬合。
- Benchmark：追蹤成功率、token 用量，甚至能跑 A/B test 兩個版本盲測對決。

一個最小範例

假設你是做小紅書的美食部落客，要把普通食譜改寫成小紅書風格：

```yaml
---
name: xiaohongshu-recipe
description: 把普通食譜改寫成小紅書風格的美食筆記。
  當使用者說「轉小紅書版」「改成小紅書風格」時使用。
trigger_keywords:
  - 轉小紅書版
  - 小紅書風格
  - 改成筆記
---

# 小紅書食譜改寫

## 執行規則

### 標題
- 必須帶數字，比如「3 步做出」「5 分鐘搞定」
- 控制在 20 字以內
- 要有懸念或反差感

### 正文
- 開頭一句話說清楚這道菜的亮點
- 食材列表用 emoji 標註
- 步驟用數字序號，每步不超過兩行
- 語氣活潑，像跟朋友聊天
- 禁止「首先」「其次」「綜上所述」這類書面語

### 結尾
- 引導互動：「你們一般怎麼做？評論區告訴我」
- 加 2-3 個相關話題標籤
- 字數控制在 500 字以內
```

放到 `~/.claude/skills/xiaohongshu-recipe/SKILL.md`，以後說「轉小紅書版」就自動觸發。

從新建檔案到能用，不超過 20 分鐘。

---

## 五、安裝、存放與跨工具

載入優先級（4 級）

Claude Code 按以下順序查找，越具體的位置優先級越高：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629156-diaHIfMr5bYAAWQ8Qjpg.jpg)

經驗：除非專案特定，都放個人級 `~/.claude/skills/` 統一管理，避免忘記自己有哪些 Skill。

三種安裝方式：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629509-diaHIfNmBa8AAyTTljpg.jpg)

裝完記得重啟 Claude Code。

跨工具相容（再強調一次）

引子裡講過 Skill 不綁定 Claude，這裡看具體路徑對照：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629168-diaHIfOZQbwAAvnh8jpg.jpg)

操作上的意義：

同一個 SKILL.md，把資料夾軟連結到不同工具的目錄下就能用，不用為每個 AI 重寫一遍。這是 Agent Skills 作為開放標準最大的紅利。

國內使用者痛點

- 官方 Claude 貴：用中轉 API 性價比高，或用 GLM 4.7 划算
- CC Switch：開源工具管理多 API 設定一鍵切換 github.com/farion1231/cc-switch
- 原生安裝比 npm 穩：`curl -fsSL https://claude.ai/install.sh | bash`

---

## 六、進階——多 Skill 協作架構

拆分粒度

> 核心原則：每個 Skill 一個明確任務，不要做「萬能 Skill」。

粒度太粗，description 寫不清楚，觸發不精準；粒度太細，管理成本上來。

一個合理的顆粒度是：一個 Skill 解決一類問題，大約 200-500 行的 SKILL.md 主體。

實戰案例：部落格寫作 Skill 套件。

不要做一個「全能寫作 Skill」，拆成 5 個協作：

```
~/.claude/skills/
├── blog-outline/       # 生成大綱
├── blog-writer/        # 寫初稿（可呼叫 blog-outline）
├── blog-editor/        # 編輯潤飾
├── blog-seo/           # SEO 檢查（用腳本算客觀資料）
└── blog-meta/          # 生成元資訊（標籤/描述/社群文案）
```

協作模式：主 Skill 在 ## 步驟 裡顯式呼叫其他 Skill：

```markdown
## 步驟

1. 如果使用者沒提供大綱，先呼叫 `blog-outline` skill 生成
2. 按 reference/style-guide.md 的風格規範寫作
3. 使用 templates/article.md.tpl 作為基礎模板
4. 輸出完整 Markdown，含 frontmatter
```

這套拆分的好處：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629393-diaHIfPbkbAAAv8NJjpg.jpg)

五條工程經驗

1. 粒度要細：每個 Skill 一個明確任務
2. 協作顯式化：主 Skill 用 ## 步驟 顯式呼叫其他 Skill
3. 腳本承擔計算：SEO 字元數、連結統計這類需要客觀資料的部分一定用腳本，不要讓模型估算
4. 風格指南獨立：把穩定的知識（寫作風格/品牌規範）單獨放 references/，改風格只動一個檔案
5. 模板兜底：模板提供「最差也不至於太離譜」的下限保證

---

## 七、專業級評測與迭代

Eval 體系：

skill-creator 給的標準流程：

1. 在 evals/evals.json 寫測試 prompts
2. 同時跑 with_skill 和 baseline（無 skill），雙盲對比
3. 通過 agents/grader.md 給每個斷言打分
4. 用 aggregate_benchmark 出 pass_rate / time / tokens 報告

```json
{
  "skill_name": "example-skill",
  "evals": [
    {
      "id": 1,
      "prompt": "User's task prompt",
      "expected_output": "Description of expected result",
      "files": []
    }
  ]
}
```

Description 自動優化

skill-creator 裡最值錢的一段是 Description Optimization：

- 寫 20 條 trigger eval queries（8-10 條應觸發 + 8-10 條不該觸發）
- 難點：不該觸發的要寫「近 miss」——共享關鍵字或概念但實際需要別的工具，不要寫「寫個 fibonacci」這種太明顯的反例
- 自動優化腳本：60% train + 40% held-out test，防止過擬合
- 跑 5 輪，選 test 分數最高的描述

應觸發的好例子：不是簡單寫「提取 PDF 表格」，而是寫得像真實使用者：

> "ok so my boss just sent me this xlsx file (it's in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage."

包含檔案路徑、個人背景、欄位值、隨意的口語、可能的拼字錯誤。

迭代心法

skill-creator 原文有四條：

1. 從回饋中泛化：不要為單個 case 加 fiddly 規則，如果某問題反覆出現，試試換個比喻或工作模式
2. 保持精簡：看 transcript 找浪費時間的指令，刪掉不出力的部分
3. 解釋 why：LLM 有 theory of mind，會舉一反三
4. 看 transcript 找重複工：如果每個 case 子代理都獨立寫了 create_docx.py，說明應該 bundle 進 scripts/

第一版必然不完美

一個真實的迭代案例：一位作者的 /daily skill 改到 v6 才穩定。

- v1：步驟不清楚、路徑寫錯、有些情況沒處理
- v2：加內容發現系統整合
- v3：發現週進度計算常出錯，加明確的計算規則
- v4：加自動觸發——週二提醒跑週會、月初提醒歸檔
- v5：加 iPhone 輕量模式（檢測環境，手機上跳過需要 Python 的步驟）
- v6：才算「好用」

Skill 不是寫完就丟的設定檔，它是你工作流的活檔案。每改一次，你對自己的工作流就多理解一層。

---

## 八、什麼時候才該做 Skill

不是所有事都值得做 Skill。只有以下三種訊號之一出現，才值得動手：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635628963-diaHIfQgdaIAEtnqdjpg.jpg)

反過來：什麼時候不要做

- 一次性任務：做完就不用了，直接 prompt 解決
- 過度封裝：三個用法就開始拆 Skill，維護成本遠大於收益
- 追求完美：想 v1 就完美，等真用起來才發現假想需求

---

## 九、避坑清單

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635629678-diaHIfXqXbEAAk5ZLjpg.jpg)

---

## 十、生態與必裝清單

Skill 資源地圖

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635628903-diaHIfYbKa0AA3aOcjpg.jpg)

必裝 Skill 清單

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1779635628969-diaHIfW9jbcAArmEPjpg.jpg)

---

## 十一、Skill 的商業潛力

Skill 不只是個人效率工具，它在重新定義 AI 應用的生產方式。

過去，開發一個垂直 AI 應用要漫長的開發週期、昂貴的研發成本、技術團隊的高門檻。

現在：

- 零程式碼門檻：不會寫程式也能造垂直 Agent
- 極速驗證：數週開發週期被壓到幾小時甚至幾分鐘
- API 服務化：把 Skill 封裝成 API，給現有產品快速賦能 AI
- Skill 可以當產品賣：本質和當年賣 Prompt 合集一樣，但門檻/價值都更高

幾個真實案例：

- Article-Copilot：一個 Skill 實現素材清洗→邏輯梳理→正文寫作的全鏈路 Agent，媲美獨立 AI 產品
- AI Partner Skill：讓通用 Agent 學會深度記憶，塑造真懂你的 AI 伴侶
- 面試準備 Skill：輸入公司名 + 崗位 + 履歷，自動抓公司資訊 + JD + 履歷差距分析，生成完整面試準備報告。有人用這個拿到了同花順的面試機會
- Super 黃的玩法：幾十個 Skill + 定時任務，凌晨 0/1/2/3/4 點各跑一個，早上起來幾份報告全部出來

任何深耕一個行業的人，把自己的經驗和方法論提煉成 Skill，既能自用省時間，也能打包成產品出售。

---

## 結語

如果說 Agent 是 AI 世界的軀體，Skill 就是注入其中的靈魂。

這就像 Steam 平台與創意工坊的關係，正是因為有了極具擴充性的設計架構，遊戲才擁有了無限生命力。

Skill 本身不難，就是 Markdown 加上一些結構。

但它代表的趨勢很重要：AI 從「你每次都要教它」變成「你教一次就好」。

而且這個標準是開放的。

你今天在 Claude Code 寫的 Skill，明天可以搬到 Cursor、Gemini CLI、Codex 上用，並不會被綁死在一個平台上。

這句話送給所有還在觀望的人：

> Skill 不是設計出來的，是從一次又一次重複勞動裡長出來的。

先跑通一件事，再封裝，好的工作流是迭代出來的，不是規劃出來的。

打開終端機，裝上 skill-creator，把你今天重複說了第三遍的那段話，寫成你的第一個 SKILL.md。

黃小木｜T11 級架構師｜《30天2萬粉2週2k刀》作者｜持續分享 AI 資訊、副業賺錢、程式設計師轉型 OPC 心得｜X：@ai_xiaomu

## 標籤

Skills, 教學資源, Claude, Anthropic, Claude
