火爆全網的Skill自己怎麼做？老金來教你！（含避坑指南）
整理版優先睇
老金教你整Skill：6步流程＋避坑指南，搞掂Anthropic官方技能製作
呢篇文章係由老金寫嘅，佢親身跟住Anthropic官方文檔anthropics/skills整Skill，結果踩咗唔少坑，花咗一晚先搞掂。佢想解決嘅問題係：官方文檔寫得太簡略，實際做嗰陣好多細節冇講清楚，導致新手好易失敗。整體結論係，只要跟住佢拆解嘅6步流程，留意description、scripts測試同references精簡呢啲關鍵位，零基礎都整到一個符合標準、Token高效嘅Skill。
文章先介紹咗Skill嘅核心概念「漸進式展示」（Progressive Disclosure），即係三層架構：第一層元數據（name+description）決定技能幾時觸發，第二層SKILL.md主體係核心指令，第三層捆綁資源（scripts/references/assets）按需加載。呢個設計係為咗慳上下文Token，唔會一次過塞曬所有資訊畀Claude。跟住老金詳細拆解咗6步流程：理解技能、規劃內容、初始化、編輯、打包同迭代，每個步驟都附加咗實測時間成本同注意事項。
最後老金對比咗官方文檔同佢實測嘅差距，發現官方Skills自己有66.7%格式錯誤，所以建議唔好100%照搬。佢仲總結咗5個實戰建議，尤其強調description係生死線，要用「技能功能＋使用場景＋觸發條件（數字編號）」嘅公式。文章適合想整專業Skills嘅開發者或團隊，但個人簡單用就未必需要咁複雜。
- 核心結論：高質量Skill等於精準description、精簡SKILL.md、測試scripts同優化references，再持續迭代。
- 製作方法：跟住6步流程走：理解技能→規劃內容→初始化→編輯→打包→迭代，每步有明確驗證標準。
- 關鍵差異：官方文檔寫得太理想，實際踩坑位包括description字數要求、scripts權限、SKILL.md長度限制，新手要特別留意。
- 啟發：Progressive Disclosure架構係核心設計哲學，Token消耗公式係100詞metadata加5000詞body再加按需資源，要按呢個邏輯優化。
- 可行動點：整Skill嗰陣先用description公式寫好觸發條件，scripts一定要測試，references精簡到3個以內，大文件加grep搜尋模式。
Anthropic Skills 官方GitHub倉庫
官方文檔所在位置，包含SKILL.md同初始化/打包腳本。
init_skill.py 初始化腳本
一行命令自動創建Skill目錄結構，生成模板文件。
package_skill.py 打包腳本
自動驗證並打包Skill成.my-skill文件（實際係zip），可分享。
description公式
技能功能＋使用場景＋具體觸發條件（數字編號），長度50-200詞。
內容結構
skill-name/├──
SKILL.md (必需)│ ├── YAML frontmatter (必需)│ │ ├── name: (必需)│ │ └── description: (必需)│ └── Markdown instructions (必需)└── Bundled Resources (可選) ├── scripts/
- 可執行代碼 ├── references/
- 參考文檔 └── assets/
- 資源文件核心機制：三層架構與漸進式展示
A社設計咗Progressive Disclosure（漸進式展示）作為Skills系統嘅核心架構，意思係唔好一次過塞曬資訊畀Claude，而係分三層逐步加載。
- 1 第一層 Metadata（元數據）：name + description，永遠喺上下文，約100詞。作用係決定技能幾時觸發。
- 2 第二層 SKILL.md body（技能主體）：具體指令、使用指南，<5000詞（建議<500行）。觸發後加載，係核心工作流程。
- 3 第三層 Bundled resources（捆綁資源）：scripts/、references/、assets/，按需加載。scripts可執行而不讀入上下文，token好高效。
老金洞察：呢個架構反映出官方嘅設計哲學——metadata決定生死，body要精簡，資源要按需。
description必須包含技能功能、使用場景同具體觸發條件，用數字編號列舉，避免模糊
body建議<5000詞，超過要拆分到references/，防止context bloat
scripts可執行但不讀入上下文，係Token高效嘅關鍵
6步完整流程（老金實測＋時間成本）
A社將技能製作拆成6步，老金用大白話翻譯，仲加入咗實測時間成本同避坑要點。
- 1 第一步：理解技能（30分鐘-1小時）：先想清楚要做咩技能，用具體例子測試，問自己支援咩功能、用戶會點講、幾時觸發。驗證標準係有3-5個具體場景。
- 2 第二步：規劃內容（30分鐘-1小時）：決定需要scripts、references、assets，唔好咩都加，只加必要嘅。
- 3 第三步：初始化技能（5分鐘）：用init_skill.py一鍵生成目錄結構，之後喺模板上修改就得。
- 4 第四步：編輯技能（2-4小時，最耗時）：準備可重用資源（scripts要測試、references要精簡），然後編寫SKILL.md嘅frontmatter同body，最後刪除唔需要嘅示例文件。
- 5 第五步：打包技能（5分鐘）：用package_skill.py打包，會自動驗證格式、description質量、文件組織等，唔合格唔俾過。
- 6 第六步：迭代（持續進行）：喺真實任務中使用，根據反饋優化，例如老金測試10次發現3個問題，然後返去改SKILL.md。
description字數太少會直接導致打包失敗，老金實測至少50詞先得
scripts一定要先測試先打包，否則使用時報錯要返工1小時
references太長會令加載變慢，建議精簡到3個核心文檔，大文件加grep模式
老金踩坑實錄＋實戰建議
老金對比官方文檔同實測，發現三個大差距：description字數官方冇提最低要求；scripts權限文檔冇講；SKILL.md長度限制原因冇解釋。另外，老金自己整公眾號寫作技能嗰陣踩咗三個坑。
scripts權限好易忽略：放咗Python腳本但冇加執行權限，使用時報錯
新手版Skills常見錯誤：description模糊、SKILL.md>500行、有README.md等輔助文件、scripts未測試
專業版Skills特徵：description詳細精確含場景編號、SKILL.md<500行、只有必要資源、scripts已測試
老金總結咗五個實戰建議，最緊要係description呢條生死線。
- 1 建議1：description用公式寫，唔好懶。
- 2 建議2：SKILL.md保持精簡，<500行，用分層原則將變體細節移到references。
- 3 建議3：Token優化三原則：Context係公共資源，默認Claude已經好聰明，按自由度匹配精細度。
- 4 建議4：scripts測試要過基本測試、輸出驗證、邊界測試。
- 5 建議5：references精簡策略：刪重複、拆大文件、加grep模式、按需加載。
最終評價同核心總結
老金認為A社呢個官方文檔好嚴謹專業，唔係教人快速整Skill，而係教人整符合標準、Token高效、可維護嘅Skill。優點係權威系統有自動化驗證；侷限係技術門檻高，初次製作要4-8小時。
官方限制SKILL.md 5000詞，可能係假設「好的Skill唔需要長篇大論」
老金自己嘅公眾號寫作技能SKILL.md寫咗800詞，覺得啱啱好。佢建議團隊使用或整專業技能嘅話，強烈跟足6步流程，雖然初次要4-8小時，但掌握之後就得心應手。
加我入AI討論學習羣，公眾號右下角「聯絡方式」
文末有老金嘅 開源知識庫地址·全部免費
老金我一直想寫官方嘅Skill說明書，佢叫anthropics/skills。
記得老金我第一次跟住官方文檔整技能，打包直接失敗。
老金我查咗錯誤日誌，發現官方文檔寫得「好似好輕鬆」，實際「多鑊到爆」。
老金我花咗成晚踩曬所有雷，終於成個流程行得通。
今日呢篇文章，老金我會將呢個6步流程拆解俾你睇。
讀完你會明：
點解A社要設計三層架構。
點解description係技能嘅生死線。
點解scripts一定要測試，references要精簡。
6步完整流程究竟點行。
skill-creator
先講清楚，skill-creator唔係一個獨立嘅工具或軟件，而係Claude Code官方嘅技能創建指南文檔。
喺GitHub倉庫：anthropics/skills
位置：skills/skill-creator/SKILL.md
GitHub地址：https://github.com/anthropics/skills
佢教你點樣整一個「Skill」——即係俾Claude Code裝一個「專業插件」。
例如你想令Claude擅長寫Python代碼，或者擅長做數據分析，或者擅長寫公眾號文章，呢啲都可以整成Skill。
以前老金我以為Skills好複雜，要識好多技術先做到。
睇完呢個文檔，老金我發現：只要跟住6步行，零基礎都做到。
但老金我要講清楚：呢個指南有啲技術門檻，需要花時間理解。
三層架構核心機制（Progressive Disclosure）
A社喺skill-creator文檔入面提出咗一個核心概念。
Progressive Disclosure（漸進式展示）
呢個係Skills系統嘅核心架構設計。
老金我翻譯一下：唔係將所有信息一次過塞俾Claude，而係分三層加載，根據需要逐步展示。
三層加載架構：
第一層：Metadata（元數據）
內容：name + description
加載時機：永遠喺上下文入面
Token配額：約100詞
作用：決定技能幾時觸發
第二層：SKILL.md body（技能主體）
內容：具體指令、使用指南、注意事項
加載時機：技能觸發後
Token配額：<5000詞（建議<500行）
作用：核心工作流程
第三層：Bundled resources（捆綁資源）
內容：scripts/、references/、assets/
加載時機：按需加載
Token配額：無限（scripts可執行而唔讀入上下文）
作用：詳細參考同可執行代碼
老金嘅洞察：
由呢三層架構可以清楚睇到官方嘅設計哲學：
1. 元數據決定生死
得100詞嘅配額，但呢100詞決定咗技能幾時俾Claude揀中。
description一定要精煉、準確、全面。
2. 主體要精簡
建議<5000詞（<500行），超過限制就要拆分到references/。
避免context bloat（上下文膨脹）。
3. 資源按需加載
scripts可執行但唔讀入上下文（token高效）。
references淨係需要時先加載。
assets用嚟輸出，唔佔用上下文。
核心公式：
總Token消耗 = 100詞（metadata） + 5000詞（body） + 按需資源（scripts/references/assets）優化建議：
基於呢個公式，老金我總結出優化Skills嘅三個原則：
1. Metadata層：精準觸發
description一定要包含：技能功能 + 使用場景 + 具體觸發條件。
避免模糊描述，用數字編號列出場景。
2. Body層：核心流程
只保留核心工作流程同選擇指導。
變體細節、示例、配置搬到references/。
保持<500行。
3. Resources層：按需拆分
scripts：重複執行嘅代碼（token高效）。
references：文檔、API說明（按需加載）。
assets：模板、圖標（輸出用）。
Skills嘅文件結構（三層架構版）
Anthropic喺文檔入面明確規定咗一個Skill嘅標準結構：
skill-name/
├── SKILL.md (必需)
│ ├── YAML frontmatter (必需)
│ │ ├── name: (必需)
│ │ └── description: (必需)
│ └── Markdown instructions (必需)
└── Bundled Resources (可選)
├── scripts/ - 可執行代碼
├── references/ - 參考文檔
└── assets/ - 資源文件老金我用大白話翻譯一下：
SKILL.md（必需）：
Frontmatter（YAML元數據）：name + description
name：技能名稱（小寫，連字符分隔）
description：詳細說明（最重要嘅觸發機制）
Body（Markdown指令）：使用指南、注意事項、代碼示例
scripts/（可選）：
用途：存放可執行代碼（Python/Bash等）
幾時包含：相同代碼重複重寫，或者需要確定性可靠性
例子：rotate_pdf.py（PDF旋轉腳本）
優勢：token高效，確定性，可執行而唔讀入上下文
注意：Claude可能仍需讀取嚟進行修補或環境調整
references/（可選）：
用途：文檔同參考材料（按需加載到上下文）
幾時包含：Claude應該引用嘅文檔
例子：finance.md（財務模式）、mnda.md（NDA模板）、policies.md（公司政策）
優勢：保持SKILL.md精簡，淨係需要時先加載
最佳實踐：如果文件>1萬詞，喺SKILL.md入面加入grep搜索模式
避免重複：信息應該喺SKILL.md或者references/，唔好兩邊都有
assets/（可選）：
用途：輸出中使用嘅文件（唔讀入上下文），幾時包含：技能需要用嚟最終輸出嘅文件。
例子：logo.png（品牌資產）、slides.pptx（PPT模板）、frontend-template/（HTML/React樣板）。
優勢：分離輸出資源同文檔，令Claude用文件而唔加載到上下文。
唔應該包含嘅內容：
A社明確指出，技能唔應該包含額外嘅文檔或輔助文件。
包括：README.md、INSTALLATION_GUIDE.md、QUICK_REFERENCE.md、CHANGELOG.md等。
技能應該只包含AI代理完成工作所需嘅信息，唔應該包含創建過程嘅輔助上下文、設置同測試程序、面向用戶嘅文檔等。
建立額外嘅文檔文件只會增加混亂同困惑。
6步完整流程（老金實測+時間成本）
A社將技能製作拆成6步，老金我用大白話翻譯一下，再加埋實測時間成本。
第一步：理解技能（Understanding the Skill）
時間成本：30分鐘-1粒鐘（取決於複雜度）
先諗清楚你想做咩技能。
建議你先用具體嘅例子嚟測試，例如「我想令Claude幫我做PDF處理」。
然後問自己幾個問題：
呢個技能要支援咩功能（編輯PDF、轉換格式、提取文字）
用戶會點講（「幫我旋轉呢個PDF」、「將PDF轉做Word」）
咩情況下會觸發呢個技能
老金我覺得呢步好重要，諗唔清後面全部白做。
驗證標準：
有3-5個具體使用場景，每個場景有明確嘅用戶講法，可以清楚描述技能嘅邊界（咩唔做）。
第二步：規劃內容（Planning the Contents）
時間成本：30分鐘-1粒鐘
諗清楚技能需要咩資源：
需要邊啲腳本（例如PDF處理嘅代碼）
需要邊啲參考資料（例如PDF格式說明文檔）
需要邊啲素材（例如Word模板）
唔好乜都加，只加必要嘅。
老金我特別認同呢點，加得太多反而會令Claude混亂。
規劃清單：
scripts列表：每個腳本嘅目的、輸入輸出、測試方法
references列表：每個文檔嘅用途、大小、搜索模式
assets列表：每個資源嘅使用場景、格式要求
第三步：初始化技能（Initializing the Skill）
時間成本：5分鐘（自動化）
A社提供咗一個腳本：init_skill.py。行一行命令，佢會自動建立Skill嘅目錄結構：
python scripts/init_skill.py my-skill --path ./skills老金我試過，呢個腳本會生成：
my-skill/SKILL.md（模板文件，帶TODO佔位符）
my-skill/scripts/（示例腳本）
my-skill/references/（示例參考）
my-skill/assets/（示例素材）
你只需要係呢個基礎上修改就得。
跳過條件：如果技能已存在，只需要迭代或打包，可以跳過呢步。
第四步：編輯技能（Editing the Skill）
時間成本：2-4粒鐘（最花時間）
呢步係最花時間嘅，老金我花咗大約3粒鐘。
你要做3件事：
1. 準備可重用資源（scripts/references/assets）
scripts/：
編寫代碼並實際執行測試，確保無bug。如果好多相似腳本，只需測試代表性樣本。刪除唔需要嘅示例文件。
references/：
存放文檔、API說明、領域知識。如果文件>100行，喺頂部加目錄。避免同SKILL.md重複。
assets/：
準備模板、圖標、樣板代碼。確保格式正確（PPT、Word、圖片等）。
2. 編寫SKILL.md
Frontmatter部分（YAML元數據）：
---
name: pdf-editor
description: 綜合PDF編輯、轉換和文本提取技能。當Claude需要處理PDF文件時使用：(1)編輯內容，(2)轉換格式，(3)提取文本，或其他PDF任務
---重要說明：
name：技能名稱（小寫，連字符分隔）
description：呢個係技能嘅主要觸發機制，一定要包含：技能功能 + 幾時用 + 具體觸發條件
用數字編號列出場景，唔好將「幾時用」放喺body（body淨係觸發後先加載）
A社特別強調：description一定要寫清楚，因為Claude係根據呢個嚟決定幾時加載技能。
Body部分（Markdown指令）：
用命令式/不定式形式（Use the pdf-editor skill to...，而唔係You should use...），寫具體嘅使用指南、注意事項、代碼示例等。
寫作規範：
用命令式動詞（Rotate the PDF, Extract text, etc.）
保持簡潔（<500行）
避免冗餘解釋
提供具體示例而唔係空泛講法
3. 刪除唔需要嘅示例文件
初始化腳本建立咗示例文件，但大多數技能唔需要曬所有呢啲文件。
驗證清單：
scripts：已測試，無bug，輸出符合預期
references：無重複，同SKILL.md互補，大文件有grep模式
assets：格式正確，可用於輸出
SKILL.md：<500行，description詳細，body用命令式
第五步：打包技能（Packaging the Skill）
時間成本：5分鐘（自動化）
全部搞掂之後，用package_skill.py打包：
python scripts/package_skill.py ./skills/my-skill可選輸出目錄：
python scripts/package_skill.py ./skills/my-skill ./dist呢個會生成一個.my-skill文件（實際係.zip文件），可以分享俾人用。
自動驗證流程：
打包腳本會自動驗證技能，檢查：
YAML frontmatter格式同必需字段
Skill命名約定同目錄結構
Description完整性同質量
文件組織同資源引用
如果驗證失敗，腳本會報告錯誤並退出，唔建立包。老金我第一次打包就失敗咗，因為description寫得太簡單，唔符合標準。
驗證標準（老金總結）：
Frontmatter驗證：
name字段存在且格式正確（小寫，連字符）
description字段存在且完整
無額外字段（只允許name同description）
Description質量：
包含技能功能說明
包含幾時用嘅指導
用數字編號列出具體場景
長度適中（通常50-200詞）
文件組織：
SKILL.md存在且喺根目錄
scripts/references/assets目錄結構正確
無README.md等輔助文件
資源引用：
SKILL.md中引用嘅文件實際存在
references/大文件包含grep搜索模式
第六步：迭代（Iterating）
時間成本：持續進行
根據實際使用反饋優化技能。
迭代工作流：
喺真實任務入面用技能，留意困難或低效嘅地方，識別SKILL.md或捆綁資源應該點樣更新，實行更改並再次測試。
老金實測：
老金我測試咗10次，發現3個問題，然後返去修改SKILL.md。
測試清單：
技能係咪正確觸發（description係咪準確）
技能係咪正確引用scripts/references
輸出係咪符合預期
有冇錯誤或幻覺
Token使用係咪高效
如果對你有幫助，記得關注一波~
官方文檔 vs 老金實測（差距有幾大）
老金我跟住官方文檔行咗一遍6步流程，發現咗一個問題。
官方文檔寫得「好似好輕鬆」，實際「多鑊到爆」。
差距1：description字數
官方文檔話：建立metadata.json，寫name同description就得。
老金我跟住做咗，寫咗10個字嘅description，結果打包直接失敗。
老金我查咗錯誤日誌，發現description少過50詞直接打包失敗。
官方文檔點解唔提「50詞」呢個最低要求？
差距2：scripts權限
官方文檔話：scripts/可選，有就放。
老金我放咗Python腳本入去，打包成功咗，結果使用時報錯，話腳本冇執行權限。
老金我返去查文檔，文檔入面隻字未提「權限」呢個關鍵細節。
差距3：SKILL.md長度
官方文檔話：SKILL.md核心文檔，<5000詞。
老金我寫咗一個800詞嘅SKILL.md，覆蓋曬全部流程。
老金我諗：
官方點解要限制5000詞？
係為咗保證Claude嘅上下文效率？
定係為咗強制創作者「精簡表達」？
或者話，Anthropic設計呢個系統時，本身就假設「好嘅Skill唔需要長篇大論」？
老金我嘅統計：
官方12個Skills，老金我逐個檢查咗：
- 格式錯誤：8個（66.7%）
- 腳本缺失：7個（58.3%）
- 文檔唔清：5個（41.7%）
呢個說明咩？
說明連官方自己嘅Skills，都冇完全跟官方文檔嘅標準嚟做。
或者話，官方文檔係「理想狀態」，實際使用係「另一回事」。
老金我嘅建議：
唔好100%照搬官方文檔。
要結合實際，靈活調整。
老金踩過嘅雷（老金實測）
老金我用呢個流程做咗個公眾號寫作技能，踩過3個雷。
第一個雷：description寫得唔清楚
嚴重程度：5星（打包直接失敗）
時間損失：返工30分鐘
老金原版：「公眾號寫作技能」
失敗原因：description太簡單，唔符合標準
修復版：
description: 專業公眾號寫作技能，基於82篇爆款文章數據和三層架構系統。支持標題生成、內容寫作、質量檢測。使用場景：(1)寫公眾號文章，(2)生成爆款標題，(3)文章質量評分A社要求：技能係做咩、幾時用、具體使用場景（用數字編號）
第二個雷：scripts冇測試
嚴重程度：3星（用嗰陣先發現）
時間損失：返工1粒鐘
老金錯誤：寫咗個Python腳本，直接打包咗
失敗原因：腳本有語法錯誤，第一次用就報錯
A社建議：所有scripts一定要先測試，確保行到
修復方法：編寫後即刻執行測試，驗證輸出符合預期
第三個雷：references太長
嚴重程度：2星（性能問題）
時間損失：返工30分鐘
老金錯誤：放咗10幾個文檔喺references/，加載好慢。
失敗原因：references太多，搞到context膨脹。
Anthropic建議：references只放必要嘅，如果>1萬詞，要喺SKILL.md寫清楚grep搜索模式。
修復方法：精簡到3個核心文檔，為大文件加grep模式。
老金避雷公式：
坑點風險 = description不清楚(5星) + scripts未測試(3星) + references過長(2星)避雷優先級：
- description（最高優先級）：直接影響打包成功
- scripts測試（高優先級）：影響使用體驗
- references精簡（中優先級）：影響性能
新手版 vs 專業版對比
老金我總結咗一個對比表，令你一眼睇出分別：
description：
- 新手版：簡短模糊
- 專業版：詳細精確，有場景編號
SKILL.md長度：
- 新手版：>500行，冗長
- 專業版：<500行，精簡
文件組織：
- 新手版：有README.md等輔助文件
- 專業版：只有SKILL.md + 必要資源
scripts：
- 新手版：未測試，有bug
- 專業版：已測試，無bug
references/：
- 新手版：同SKILL.md重複，無grep模式
- 專業版：同SKILL.md互補，大文件有grep
assets/：
- 新手版：混埋喺references/
- 專業版：獨立目錄，輸出用
打包驗證：
- 新手版：一次唔過
- 專業版：一次通過
Token效率：
- 新手版：低（重複信息）
- 專業版：高（按需加載）
核心差異：
新手版：行到就算，唔考慮效率
專業版：符合A社標準，Token高效，可維護
老金嘅實戰建議
基於A社官方文檔同老金我自己嘅經驗，總結出以下實戰建議。
建議1：description係生死線
老金我再次強調：description係技能嘅主要觸發機制，一定要精煉、準確、全面。
description公式：
description = 技能功能 + 使用場景 + 具體觸發條件（數字編號）示例：
# 錯誤示範
description: PDF編輯技能
# 正確示範
description: 綜合PDF編輯、轉換和文本提取技能。當Claude需要處理PDF文件時使用：(1)編輯內容，(2)轉換格式，(3)提取文本，或其他PDF任務驗證標準：
- 包含技能功能說明（Comprehensive PDF editing...）
- 包含幾時用嘅指導（Use when Claude needs...）
- 用數字編號列出場景（(1) editing, (2) converting, (3) extracting）
- 長度適中（50-200詞）
建議2：保持SKILL.md精簡
SKILL.md長度建議：<500行，<5000詞
老金我發現，好多新手容易將所有信息塞曬入SKILL.md，搞到context膨脹。
精簡公式：
SKILL.md內容 = 核心工作流程 + 選擇指導 + 資源引用分層原則：
核心流程：留喺SKILL.md
變體細節：搬去references/
示例代碼：搬去references/examples.md
配置選項：搬去references/config.md
Pattern 1：高層級指導 + references
Pattern 2：領域特定組織
bigquery-skill/
├── SKILL.md (概覽和導航)
└── references/
├── finance.md (收入、計費指標)
├── sales.md (銷售機會、管道)
├── product.md (API使用、功能)
└── marketing.md (營銷活動、歸因)當用戶問銷售指標時，Claude只讀取sales.md。
Pattern 3：條件性細節
建議3：Token優化三原則
老金我總結出Token優化嘅三個原則：
原則1：Context係公共資源
Anthropic原話：「The context window is a public good.」
Skills同system prompt、conversation history、other Skills' metadata、user request共享context window。
優化公式：
Token總預算 = 200K (Claude 3.5) - system prompt - conversation history - other skills metadata - user request原則2：預設Claude已經好聰明
A社建議：「Only add context Claude doesn't already have.」
對每條信息挑戰：「Claude真係需要呢個解釋咩？」同「呢個段落值唔值得佢嘅token成本？」
優先簡潔示例而唔係冗長解釋。
原則3：匹配自由度級別
根據任務嘅脆弱性同可變性匹配specificity級別：
高自由度（文本指令）：
多種方法有效時
決策依賴上下文時
啓發式指導方法時
中自由度（偽代碼或帶參數腳本）：
存在首選模式時
一啲變化可接受時
配置影響行為時
低自由度（特定腳本，少參數）：
操作脆弱且易錯時
一致性關鍵時
必須跟隨特定序列時
老金嘅自由度選擇表：
創意寫作：
- 自由度：高
- 示例：「寫一篇關於...」
代碼重構：
- 自由度：中
- 示例：提供偽代碼框架
PDF旋轉：
- 自由度：低
- 示例：特定腳本，少參數
建議4：scripts測試標準
老金我發現，scripts嘅bug係新手最容易犯嘅錯誤。
測試標準：
基本測試：行腳本，確保無語法錯誤
輸出驗證：輸出符合預期格式
邊界測試：測試邊界情況（空文件、大文件等）
樣本測試：多個相似腳本，測試代表性樣本
測試公式：
scripts可信度 = (基本測試通過 + 輸出驗證通過 + 邊界測試通過) / 3建議5：references精簡策略
老金我發現，references膨脹係性能殺手。
精簡策略：
刪除重複：確保信息只喺SKILL.md或references/，唔重複
大文件拆分：>100行嘅文件，拆成多個細文件
加grep模式：>1萬詞嘅文件，喺SKILL.md寫清楚grep搜索模式
按需加載：淨係需要時引用特定文件
精簡公式：
references效率 = (必要文件數 / 總文件數) × (小文件數 / 總文件數)目標：接近100%嘅文件都係必要且細嘅。
老金嘅最終評價
A社呢個官方文檔，老金我讀完最大嘅感受係：嚴謹同專業。
佢唔係教你「快脆做一個Skill」，而係教你「做一個符合標準、Token高效、可維護嘅Skill」。
優點：
1. 權威性：Anthropic官方出品 2. 系統性：6步完整流程，由理解到迭代 3. 自動化：init_skill.py同package_skill.py腳本 4. 驗證嚴格：打包時自動驗證，唔符合標準唔通過 5. Token高效：Progressive Disclosure架構，按需加載
侷限性：
1. 技術門檻：需要理解YAML、Markdown、命令行 2. 時間成本：初次製作需要4-8粒鐘（老金實測） 3. 迭代成本：需要持續測試同優化
適用場景：
老金我強烈建議喺以下情況用呢個6步流程：
團隊共享嘅專業技能
長期使用嘅生產力工具
分享俾人嘅完整技能
需要高Token效率嘅複雜技能
唔適用場景：
個人簡單使用（可能用唔著咁複雜）
臨時性任務（投入產出比唔高）
快速原型（可以用簡化版先）
核心總結
Skills製作核心公式：
高質量Skill = (精準description + 精簡SKILL.md + 測試scripts + 優化references) × 持續迭代老金建議嘅優先級：
description（最高優先級，直接影響觸發）
SKILL.md精簡（高優先級，影響Token效率）
scripts測試（高優先級，影響使用體驗）
references優化（中優先級，影響性能）
持續迭代（持續進行，提升質量）
老金建議：
如果你係團隊使用或需要專業技能，老金我強烈建議跟住呢個6步流程整Skill。
雖然初次要4-8粒鐘，但一旦掌握咗，以後做任何技能都得心應手。
但老金我有個疑問：
官方點解要限制SKILL.md喺5000詞以內？
從技術角度睇，係為咗保證Claude嘅上下文效率。
從設計角度睇，係為咗強制創作者「精簡表達」。
或者話，A社設計呢個系統時，本身就假設「好嘅Skill唔需要長篇大論」？
老金我傾向於最後一個假設。
但你點睇？
留言區話俾我聽，你對「5000詞限制」嘅理解。
或者話，你認為一個好嘅Skill，應該控制在幾多詞以內？
老金我自己嘅公眾號寫作技能，SKILL.md寫咗800詞，覆蓋曬全部流程。
老金我覺得800詞啱啱好，唔多唔少。
但呢個係老金我嘅個人體驗，你嘅體驗可能唔同。
歡迎喺留言區分享你嘅Skills製作經驗。
或者轉發俾你嘅開發者朋友，等佢哋都睇睇呢個官方6步教程。
老金我之後會繼續研究A社嘅其他官方文檔，關注我，第一時間收到最新發現。
每次都提一提，呢個唔係凡爾賽，係希望有想法嘅人勇敢去衝。
我唔識寫程式，我英文都唔好，但我整咗好多嘢出嚟，喺文末嘅開源知識庫可以見到。
我真心希望可以影響更多人去嘗試新技巧，迎接新時代。
多謝你睇我嘅文章。
如果覺得唔錯，順手俾個讚、睇嚇、分享三連啦🙂
如果想第一時間收到推送，都可以俾我個星標⭐～多謝你睇我嘅文章。
開源知識庫地址：
https://tffyvtlai4.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf
加我進AI討論學習羣，公眾號右下角“聯繫方式”
文末有老金的 開源知識庫地址·全免費
老金我一直想寫一下官方的Skill說明書，它叫anthropics/skills。
記得老金我第一次照着官方文檔做技能，打包直接失敗。
老金我查了錯誤日誌，發現官方文檔寫得"雲淡風輕"，實際"坑得一塌糊塗"。
老金我花了一晚上踩完所有坑，終於把整套流程跑通了。
今天這篇文章，老金我會把這個6步流程拆解給你看。
讀完你會明白：
為什麼A社要設計三層架構。
為什麼description是技能的生死線。
為什麼scripts必須測試，references要精簡。
6步完整流程到底怎麼走。
skill-creator
先說清楚，skill-creator不是一個獨立的工具或軟件，而是Claude Code官方的技能創建指南文檔。
它位於GitHub倉庫：anthropics/skills
位置：skills/skill-creator/SKILL.md
GitHub地址：https://github.com/anthropics/skills
它教你怎麼做一個"Skill"——也就是給Claude Code裝一個"專業插件"。
比如你想讓Claude擅長寫Python代碼，或者擅長做數據分析，或者擅長寫公眾號文章，這些都可以做成Skill。
以前老金我以為Skills很複雜，要懂很多技術才能做。
看完這個文檔，老金我發現：只要跟着6步走，零基礎也能做。
但老金我要說清楚：這個指南有點技術門檻，需要花時間理解。
三層架構核心機制（Progressive Disclosure）
A社在skill-creator文檔裏提出了一個核心概念。
Progressive Disclosure（漸進式展示）
這是Skills系統的核心架構設計。
老金我翻譯一下：不是把所有信息一次性塞給Claude，而是分三層加載，根據需要逐步展示。
三層加載架構：
第一層：Metadata（元數據）
內容：name + description
加載時機：始終在上下文中
Token配額：約100詞
作用：決定技能何時觸發
第二層：SKILL.md body（技能主體）
內容：具體指令、使用指南、注意事項
加載時機：技能觸發後
Token配額：<5000詞（建議<500行）
作用：核心工作流程
第三層：Bundled resources（捆綁資源）
內容：scripts/、references/、assets/
加載時機：按需加載
Token配額：無限（scripts可執行而不讀入上下文）
作用：詳細參考和可執行代碼
老金的洞察：
從這三層架構可以清晰看出官方的設計哲學：
1. 元數據決定生死
只有100詞的配額，但這100詞決定了技能何時被Claude選中。
description必須精煉、準確、全面。
2. 主體要精簡
建議<5000詞（<500行），超過限制要拆分到references/。
避免context bloat（上下文膨脹）。
3. 資源按需加載
scripts可執行但不讀入上下文（token高效）。
references僅在需要時加載。
assets用於輸出，不佔用上下文。
核心公式：
總Token消耗 = 100詞（metadata） + 5000詞（body） + 按需資源（scripts/references/assets）優化建議：
基於這個公式，老金我總結出優化Skills的三個原則：
1. Metadata層：精準觸發
description必須包含：技能功能 + 使用場景 + 具體觸發條件。
避免模糊描述，用數字編號列出場景。
2. Body層：核心流程
只保留核心工作流程和選擇指導。
變體細節、示例、配置移到references/。
保持<500行。
3. Resources層：按需拆分
scripts：重複執行的代碼（token高效）。
references：文檔、API說明（按需加載）。
assets：模板、圖標（輸出用）。
Skills的文件結構（三層架構版）
Anthropic在文檔裏明確規定了一個Skill的標準結構：
skill-name/
├── SKILL.md (必需)
│ ├── YAML frontmatter (必需)
│ │ ├── name: (必需)
│ │ └── description: (必需)
│ └── Markdown instructions (必需)
└── Bundled Resources (可選)
├── scripts/ - 可執行代碼
├── references/ - 參考文檔
└── assets/ - 資源文件老金我用大白話翻譯一下：
SKILL.md（必需）：
Frontmatter（YAML元數據）：name + description
name：技能名稱（小寫，連字符分隔）
description：詳細說明（最重要的觸發機制）
Body（Markdown指令）：使用指南、注意事項、代碼示例
scripts/（可選）：
用途：存放可執行代碼（Python/Bash等）
何時包含：相同代碼重複重寫，或需要確定性可靠性
例子：rotate_pdf.py（PDF旋轉腳本）
優勢：token高效，確定性，可執行而不讀入上下文
注意：Claude可能仍需讀取以進行修補或環境調整
references/（可選）：
用途：文檔和參考材料（按需加載到上下文）
何時包含：Claude應該引用的文檔
例子：finance.md（財務模式）、mnda.md（NDA模板）、policies.md（公司政策）
優勢：保持SKILL.md精簡，僅在需要時加載
最佳實踐：如果文件>1萬詞，在SKILL.md中包含grep搜索模式
避免重複：信息應該在SKILL.md或references/中，不要兩者都有
assets/（可選）：
用途：輸出中使用的文件（不讀入上下文），何時包含：技能需要用於最終輸出的文件。
例子：logo.png（品牌資產）、slides.pptx（PPT模板）、frontend-template/（HTML/React樣板）。
優勢：分離輸出資源和文檔，讓Claude使用文件而不加載到上下文。
不應該包含的內容：
A社明確指出，技能不應該包含額外的文檔或輔助文件。
包括：README.md、INSTALLATION_GUIDE.md、QUICK_REFERENCE.md、CHANGELOG.md等。
技能應該只包含AI代理完成工作所需的信息，不應該包含創建過程的輔助上下文、設置和測試程序、面向用戶的文檔等。
創建額外的文檔文件只會增加混亂和困惑。
6步完整流程（老金實測+時間成本）
A社把技能製作拆成了6步，老金我用大白話翻譯一下，並加入實測時間成本。
第一步：理解技能（Understanding the Skill）
時間成本：30分鐘-1小時（取決於複雜度）
先想清楚你要做什麼技能。
建議你先用具體的例子來測試，比如"我想讓Claude幫我做PDF處理"。
然後問自己幾個問題：
這個技能要支持什麼功能（編輯PDF、轉換格式、提取文字）
用戶會怎麼說（"幫我旋轉這個PDF"、"把PDF轉成Word"）
什麼情況下會觸發這個技能
老金我覺得這一步很重要，想不清楚後面全白搭。
驗證標準：
有3-5個具體使用場景，每個場景有明確的用戶說法，能清楚描述技能的邊界（什麼不做）。
第二步：規劃內容（Planning the Contents）
時間成本：30分鐘-1小時
想清楚技能需要什麼資源：
需要哪些腳本（比如PDF處理的代碼）
需要哪些參考資料（比如PDF格式說明文檔）
需要哪些素材（比如Word模板）
不要什麼都加，只加必要的。
老金我特別認同這一點，加太多反而會讓Claude困惑。
規劃清單：
scripts列表：每個腳本的目的、輸入輸出、測試方法
references列表：每個文檔的用途、大小、搜索模式
assets列表：每個資源的使用場景、格式要求
第三步：初始化技能（Initializing the Skill）
時間成本：5分鐘（自動化）
A社提供了一個腳本：init_skill.py。運行一行命令，它會自動創建Skill的目錄結構：
python scripts/init_skill.py my-skill --path ./skills老金我試過，這個腳本會生成：
my-skill/SKILL.md（模板文件，帶TODO佔位符）
my-skill/scripts/（示例腳本）
my-skill/references/（示例參考）
my-skill/assets/（示例素材）
你只需要在這個基礎上修改就行。
跳過條件：如果技能已存在，只需要迭代或打包，可以跳過這一步。
第四步：編輯技能（Editing the Skill）
時間成本：2-4小時（最耗時）
這一步是最花時間的，老金我花了大概3小時。
你要做3件事：
1. 準備可重用資源（scripts/references/assets）
scripts/：
編寫代碼並實際運行測試，確保無bug。如果有很多類似腳本，只需測試代表性樣本。刪除不需要的示例文件。
references/：
存放文檔、API說明、領域知識。如果文件>100行，在頂部添加目錄。避免與SKILL.md重複。
assets/：
準備模板、圖標、樣板代碼。確保格式正確（PPT、Word、圖片等）。
2. 編寫SKILL.md
Frontmatter部分（YAML元數據）：
---
name: pdf-editor
description: 綜合PDF編輯、轉換和文本提取技能。當Claude需要處理PDF文件時使用：(1)編輯內容，(2)轉換格式，(3)提取文本，或其他PDF任務
---重要說明：
name：技能名稱（小寫，連字符分隔）
description：這是技能的主要觸發機制，必須包含：技能功能 + 何時使用 + 具體觸發條件
用數字編號列出場景，不要把"何時使用"放在body裏（body只在觸發後加載）
A社特別強調：description一定要寫清楚，因為Claude是根據這個來決定什麼時候加載技能的。
Body部分（Markdown指令）：
使用命令式/不定式形式（Use the pdf-editor skill to...，而不是You should use...），寫具體的使用指南、注意事項、代碼示例等。
寫作規範：
使用命令式動詞（Rotate the PDF, Extract text, etc.）
保持簡潔（<500行）
避免冗餘解釋
提供具體示例而非泛泛而談
3. 刪除不需要的示例文件
初始化腳本創建了示例文件，但大多數技能不需要所有這些文件。
驗證清單：
scripts：已測試，無bug，輸出符合預期
references：無重複，與SKILL.md互補，大文件有grep模式
assets：格式正確，可用於輸出
SKILL.md：<500行，description詳細，body使用命令式
第五步：打包技能（Packaging the Skill）
時間成本：5分鐘（自動化）
全部搞定後，用package_skill.py打包：
python scripts/package_skill.py ./skills/my-skill可選輸出目錄：
python scripts/package_skill.py ./skills/my-skill ./dist這會生成一個.my-skill文件（實際是.zip文件），可以分享給別人用。
自動驗證流程：
打包腳本會自動驗證技能，檢查：
YAML frontmatter格式和必需字段
Skill命名約定和目錄結構
Description完整性和質量
文件組織和資源引用
如果驗證失敗，腳本會報告錯誤並退出，不創建包。老金我第一次打包就失敗了，因為description寫得太簡單，不符合標準。
驗證標準（老金總結）：
Frontmatter驗證：
name字段存在且格式正確（小寫，連字符）
description字段存在且完整
無額外字段（只允許name和description）
Description質量：
包含技能功能說明
包含何時使用的指導
用數字編號列出具體場景
長度適中（通常50-200詞）
文件組織：
SKILL.md存在且在根目錄
scripts/references/assets目錄結構正確
無README.md等輔助文件
資源引用：
SKILL.md中引用的文件實際存在
references/大文件包含grep搜索模式
第六步：迭代（Iterating）
時間成本：持續進行
根據實際使用反饋優化技能。
迭代工作流：
在真實任務中使用技能，注意困難或低效的地方，識別SKILL.md或捆綁資源應該如何更新，實施更改並再次測試。
老金實測：
老金我測試了10次，發現3個問題，然後回去修改SKILL.md。
測試清單：
技能是否正確觸發（description是否準確）
技能是否正確引用scripts/references
輸出是否符合預期
有無錯誤或幻覺
Token使用是否高效
如果對你有幫助，記得關注一波~
官方文檔 vs 老金實測（差距有多大）
老金我按着官方文檔走了一遍6步流程，發現了一個問題。
官方文檔寫得"雲淡風輕"，實際"坑得一塌糊塗"。
差距1：description字數
官方文檔說：創建metadata.json，寫name和description就行。
老金我照做了，寫了10個字的description，結果打包直接失敗。
老金我查了錯誤日誌，發現description少於50詞直接打包失敗。
官方文檔為什麼不提"50詞"這個最低要求？
差距2：scripts權限
官方文檔說：scripts/可選，有就放。
老金我放了Python腳本進去，打包成功了，結果使用時報錯，說腳本沒有執行權限。
老金我回去查文檔，文檔裏隻字未提"權限"這個關鍵細節。
差距3：SKILL.md長度
官方文檔說：SKILL.md核心文檔，<5000詞。
老金我寫了一個800詞的SKILL.md，覆蓋全部流程。
老金我就在想：
官方為什麼要限制5000詞？
是為了保證Claude的上下文效率？
還是為了強制創作者"精簡表達"？
或者說，Anthropic設計這個系統時，本身就假設"好的Skill不需要長篇大論"？
老金我的統計：
官方12個Skills，老金我逐個檢查了：
- 格式錯誤：8個（66.7%）
- 腳本缺失：7個（58.3%）
- 文檔不清：5個（41.7%）
這說明什麼？
說明連官方自己的Skills，都沒有完全按照官方文檔的標準來做。
或者說，官方文檔是"理想狀態"，實際使用是"另一回事"。
老金我的建議：
不要100%照搬官方文檔。
要結合實際，靈活調整。
老金踩過的坑（老金實測）
老金我用這個流程做了個公眾號寫作技能，踩過3個坑。
第一個坑：description寫得不清楚
嚴重程度：5星（打包直接失敗）
時間損失：返工30分鐘
老金原版："公眾號寫作技能"
失敗原因：description太簡單，不符合標準
修復版：
description: 專業公眾號寫作技能，基於82篇爆款文章數據和三層架構系統。支持標題生成、內容寫作、質量檢測。使用場景：(1)寫公眾號文章，(2)生成爆款標題，(3)文章質量評分A社要求：技能是幹嘛的、什麼時候用、具體使用場景（用數字編號）
第二個坑：scripts沒測試
嚴重程度：3星（使用時才發現）
時間損失：返工1小時
老金錯誤：寫了個Python腳本，直接打包了
失敗原因：腳本有語法錯誤，第一次用時報錯
A社建議：所有scripts必須先測試過，確保能運行
修復方法：編寫後立即運行測試，驗證輸出符合預期
第三個坑：references太長
嚴重程度：2星（性能問題）
時間損失：返工30分鐘
老金錯誤：放了10多個文檔在references/，加載特別慢。
失敗原因：references太多，導致context膨脹。
Anthropic建議：references只放必要的，如果>1萬詞，要在SKILL.md寫清楚grep搜索模式。
修復方法：精簡到3個核心文檔，為大文件添加grep模式。
老金避坑公式：
坑點風險 = description不清楚(5星) + scripts未測試(3星) + references過長(2星)避坑優先級：
- description（最高優先級）：直接影響打包成功
- scripts測試（高優先級）：影響使用體驗
- references精簡（中優先級）：影響性能
新手版 vs 專業版對比
老金我總結了一個對比表，讓你一眼看出差異：
description：
- 新手版：簡短模糊
- 專業版：詳細精確，含場景編號
SKILL.md長度：
- 新手版：>500行，冗長
- 專業版：<500行，精簡
文件組織：
- 新手版：有README.md等輔助文件
- 專業版：只有SKILL.md + 必要資源
scripts：
- 新手版：未測試，有bug
- 專業版：已測試，無bug
references/：
- 新手版：與SKILL.md重複，無grep模式
- 專業版：與SKILL.md互補，大文件有grep
assets/：
- 新手版：混在references/
- 專業版：獨立目錄，輸出用
打包驗證：
- 新手版：一次不過
- 專業版：一次通過
Token效率：
- 新手版：低（重複信息）
- 專業版：高（按需加載）
核心差異：
新手版：能跑就行，不考慮效率
專業版：符合A社標準，Token高效，可維護
老金的實戰建議
基於A社官方文檔和老金我自己的經驗，總結出以下實戰建議。
建議1：description是生死線
老金我再次強調：description是技能的主要觸發機制，必須精煉、準確、全面。
description公式：
description = 技能功能 + 使用場景 + 具體觸發條件（數字編號）示例：
# 錯誤示範
description: PDF編輯技能
# 正確示範
description: 綜合PDF編輯、轉換和文本提取技能。當Claude需要處理PDF文件時使用：(1)編輯內容，(2)轉換格式，(3)提取文本，或其他PDF任務驗證標準：
- 包含技能功能說明（Comprehensive PDF editing...）
- 包含何時使用的指導（Use when Claude needs...）
- 用數字編號列出場景（(1) editing, (2) converting, (3) extracting）
- 長度適中（50-200詞）
建議2：保持SKILL.md精簡
SKILL.md長度建議：<500行，<5000詞
老金我發現，很多新手容易把所有信息都塞進SKILL.md，導致context膨脹。
精簡公式：
SKILL.md內容 = 核心工作流程 + 選擇指導 + 資源引用分層原則：
核心流程：保留在SKILL.md
變體細節：移到references/
示例代碼：移到references/examples.md
配置選項：移到references/config.md
Pattern 1：高層級指導 + references
Pattern 2：領域特定組織
bigquery-skill/
├── SKILL.md (概覽和導航)
└── references/
├── finance.md (收入、計費指標)
├── sales.md (銷售機會、管道)
├── product.md (API使用、功能)
└── marketing.md (營銷活動、歸因)當用戶問銷售指標時，Claude只讀取sales.md。
Pattern 3：條件性細節
建議3：Token優化三原則
老金我總結出Token優化的三個原則：
原則1：Context是公共資源
Anthropic原話："The context window is a public good."
Skills與system prompt、conversation history、other Skills' metadata、user request共享context window。
優化公式：
Token總預算 = 200K (Claude 3.5) - system prompt - conversation history - other skills metadata - user request原則2：默認Claude已經很聰明
A社建議："Only add context Claude doesn't already have."
對每條信息挑戰："Claude真的需要這個解釋嗎？"和"這個段落是否值得它的token成本？"
優先簡潔示例而非冗長解釋。
原則3：匹配自由度級別
根據任務的脆弱性和可變性匹配 specificity 級別：
高自由度（文本指令）：
多種方法有效時
決策依賴上下文時
啓發式指導方法時
中自由度（偽代碼或帶參數腳本）：
存在首選模式時
一些變化可接受時
配置影響行為時
低自由度（特定腳本，少參數）：
操作脆弱且易錯時
一致性關鍵時
必須遵循特定序列時
老金的自由度選擇表：
創意寫作：
- 自由度：高
- 示例："寫一篇關於..."
代碼重構：
- 自由度：中
- 示例：提供偽代碼框架
PDF旋轉：
- 自由度：低
- 示例：特定腳本，少參數
建議4：scripts測試標準
老金我發現，scripts的bug是新手最容易犯的錯誤。
測試標準：
基本測試：運行腳本，確保無語法錯誤
輸出驗證：輸出符合預期格式
邊界測試：測試邊界情況（空文件、大文件等）
樣本測試：多個相似腳本，測試代表性樣本
測試公式：
scripts可信度 = (基本測試通過 + 輸出驗證通過 + 邊界測試通過) / 3建議5：references精簡策略
老金我發現，references膨脹是性能殺手。
精簡策略：
刪除重複：確保信息只在SKILL.md或references/中，不重複
大文件拆分：>100行的文件，拆分成多個小文件
添加grep模式：>1萬詞的文件，在SKILL.md寫清楚grep搜索模式
按需加載：只在需要時引用特定文件
精簡公式：
references效率 = (必要文件數 / 總文件數) × (小文件數 / 總文件數)目標：接近100%的文件都是必要的且小的。
老金的最終評價
A社這個官方文檔，老金我讀完最大的感受是：嚴謹和專業。
它不是教你"快速做一個Skill"，而是教你"做一個符合標準、Token高效、可維護的Skill"。
優點：
1. 權威性：Anthropic官方出品 2. 系統性：6步完整流程，從理解到迭代 3. 自動化：init_skill.py和package_skill.py腳本 4. 驗證嚴格：打包時自動驗證，不符合標準的不通過 5. Token高效：Progressive Disclosure架構，按需加載
侷限性：
1. 技術門檻：需要理解YAML、Markdown、命令行 2. 時間成本：初次製作需要4-8小時（老金實測） 3. 迭代成本：需要持續測試和優化
適用場景：
老金我強烈建議在以下情況使用這個6步流程：
團隊共享的專業技能
長期使用的生產力工具
分享給別人的完整技能
需要高Token效率的複雜技能
不適用場景：
個人簡單使用（可能用不着這麼複雜）
臨時性任務（投入產出比不高）
快速原型（可以先用簡化版）
核心總結
Skills製作核心公式：
高質量Skill = (精準description + 精簡SKILL.md + 測試scripts + 優化references) × 持續迭代老金建議的優先級：
description（最高優先級，直接影響觸發）
SKILL.md精簡（高優先級，影響Token效率）
scripts測試（高優先級，影響使用體驗）
references優化（中優先級，影響性能）
持續迭代（持續進行，提升質量）
老金建議：
如果你是團隊使用或需要專業技能，老金我強烈建議按照這個6步流程製作Skill。
雖然初次需要4-8小時，但一旦掌握，以後做任何技能都得心應手。
但老金我有個疑問：
官方為什麼要限制SKILL.md在5000詞以內？
從技術角度看，是為了保證Claude的上下文效率。
從設計角度看，是為了強制創作者"精簡表達"。
或者說，A社設計這個系統時，本身就假設"好的Skill不需要長篇大論"？
老金我傾向於最後一個假設。
但你怎麼看？
評論區告訴我，你對"5000詞限制"的理解。
或者說，你認為一個好的Skill，應該控制在多少詞以內？
老金我自己的公眾號寫作技能，SKILL.md寫了800詞，覆蓋全部流程。
老金我覺得800詞剛剛好，不多不多。
但這是老金我的個人體驗，你的體驗可能不同。
歡迎在評論區分享你的Skills製作經驗。
或者轉發給你的開發者朋友，讓他們也看看這個官方6步教程。
老金我後續還會繼續研究A社的其他官方文檔，關注我，第一時間獲取最新發現。
每次我都想提醒一下，這不是凡爾賽，是希望有想法的人勇敢衝。
我不會代碼，我英語也不好，但是我做出來了很多東西，在文末的開源知識庫可見。
我真心希望能影響更多的人來嘗試新的技巧，迎接新的時代。
謝謝你讀我的文章。
如果覺得不錯，隨手點個贊、在看、轉發三連吧🙂
如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章。
開源知識庫地址：
https://tffyvtlai4.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf