別把整個 GitHub 裝進 Skills，Skills 的正確用法
整理版優先睇
Skills 嘅正確用法係因需而建、可組合、可迭代，唔係將成個 GitHub 塞曬入去
呢篇文章係作者 baoyu 分享佢喺維護 baoyu-skills 嘅過程中，對 Skills 嘅重新理解。佢發現好多人（包括佢自己）都容易陷入「有咗 Skills 就四圍揾釘子」嘅陷阱，以為將所有嘢封裝成 Skill 就係最好。但作者想講清楚：Skills 唔係萬能，只要 Agent 本身識做或者可以搜到，就唔需要整成 Skill；過度封裝只會增加複雜度，唔會帶嚟額外價值。
作者認為 Skills 嘅「最正確用法」唔係將所有酷炫嘅 Skill 都裝入 Claude，而係先做實事——做到某個步驟成日卡住，先用最小嘅上下文封裝成 Skill 嚟解決呢個痛點。而且呢個 Skill 要可以同其他 Skill 組合，好似樂高咁；同時要容許持續迭代，因為好嘅 Skill 係用出嚟、改出嚟，唔係冥想出嚟。
總結一句：Skills 係俾 Agent 補充佢本身唔具備、但你成日需要嘅資訊。真正值得整成 Skill 嘅地方，係你反覆踩坑嘅位置；而一個 Skill 好唔好，睇佢係咪可以組合、可以隨住用嘅經驗不斷改進。
- 唔好為咗用 Skills 而整 Skills；Agent 本來識做或搜到嘅嘢，唔值得封裝成 Skill。
- Skills 嘅甜蜜點係多步驟串聯但又未值得開發成系統；例如文章配圖、發布流程等。
- 每個 Skill 應該專注做好一件事，而且可以同其他 Skill 組合，避免整成「巨無霸」。
- 好嘅 Skill 係用出嚟嘅：用 Agent 做任務時，令佢反覆迭代經驗，先會越用越準。
- 正確用法係「因需而建、可組合、可迭代」—唔係一次過塞曬所有嘢，而係邊用邊加。
小心：Skills 唔係萬能，唔好為用而用
嗰篇《Skills 嘅最正確用法》雖然講得幾好，但作者想指出：呢種將 GitHub 壓縮成 Skills 嘅諗法，仲未算得上「最」正確。佢唔係抬槓，而係想提醒大家：Skills 就好似一把電鋸，切西瓜雖然爽，但用返西瓜刀仲順手。
Skills 係用嚟補充 Agent 本身唔具備、而你又要成日重複嘅資訊。如果 Agent 已經識得做，或者透過搜索就搞掂到，就冇必要整成 Skill。例如下載 YouTube 影片，直接同佢講「幫我下載呢條片」加條 Link 就搞掂，唔使俾成個 Repo 佢。
過度封裝只會增加複雜度，唔會帶嚟額外價值
真正值得整成 Skill 嘅場景，係你反覆踩坑之後，發現某個位次次都要解釋一次。好似作者每次發布 baoyu-skills 前，都要教佢寫 Changelog、更新 README、寫 Commit Message 咁，幾次之後就封裝成 release-skills。
幾時先需要 Skills？甜蜜點係唔大唔細
Skills 最啱用嘅位係「多步驟任務串聯，但又未值得為佢開發一套系統」。如果淨係用提示詞就做到，咁提示詞就夠；如果一定要寫個 Web App 先跑得通，成本又太高。Skills 嘅甜蜜點就喺中間。
提示詞解決唔到、系統成本太高——呢個就係 Skills 發揮嘅地方
例如文章配圖，提示詞只能幫你分析文章、生成畫圖 Prompt，但最後都要人手逐張生成同插入。用配圖 Skill 就可以全程自動化：分析需要幾多張圖、生成 Prompt、調 API、插入合適位置，你只需要驗收。如果用程式做又太麻煩，Skills 幾句話就搞掂。
- 1 提示詞方案：只能分析文章同生成 Prompt，仲要人手做圖
- 2 配圖 Skills：自動完成整個流程，由分析到生成到插入
- 3 自訂系統：成本高，要建立 Web App + 接 API，未必值得
組合先係真正力量：每個 Skill 做好一件事
Skills 嘅設計初衷係模塊化：每個 Skill 專注做好一件事，然後好似樂高咁拼埋一齊。單點方案同可組合方案嘅分別，唔係第一次用嗰陣體現，而係之後複用嗰時先拉開差距。
一個孤立嘅 Skill 解決一個問題；一組可組合嘅 Skills 解決一類問題
例如寫作風格呢樣嘢，如果淨係將提示詞放喺 Gemini 做 Gem，係單點方案，冇得組合。但如果將佢整成一個 Style Skill，之後寫訪問稿、發 Tweet 都可以重用。甚至可以組合埋：素材 → 分析 Skill → 提綱 Skill → 寫作 Skill。
所以設計 Skill 嗰陣要避免「巨無霸」衝動。一個 Skill 包攬曬所有野，表面睇好似好方便，但其實堵死咗組合嘅可能性。
每個 Skill 做好一件事，先可以靈活組合
好嘅 Skill 係用出嚟，唔係冥想出嚟
呢點同傳統寫提示詞完全唔同。提示詞係你坐喺度諗 AI 需要知道咩，然後一次過寫曬；Skills 係你同 Agent 一齊做嘢，做嚇做嚇就會沉澱經驗出嚟。用 Agent 完成任務嘅時候，叫佢將成功做法同踩過嘅坑總結成 Skill；行歪咗就叫佢反思邊度出問題。
Skills 係透過實戰迭代出嚟，唔係一次過諗好
好似作者嘅小紅書 Skill，由最初一個簡單 Prompt，一路迭代到而家有唔同風格、Layout 選項、大綱提煉、多版本選擇，甚至水印支援。每次用嘅時候發現問題，即刻叫 Agent 幫手優化，連重現同描述都唔使。
迭代成本極低，係 Skills 相比傳統代碼嘅獨特優勢
總結：三個詞記住 Skills 正確用法
唔好將成個 GitHub 裝入 Skills，嗰啲只會令 Claude 啟動慢咗，仲影響判斷。亦唔好見咩功能就諗住封裝成 Skill，咁係過度設計。
因需而建、可組合、可迭代——呢三個詞就係 Skills 嘅正確用法
作者希望呢篇分享可以幫大家唔好再盲目追求 Skills 數量，而係真正用得其所。
呢篇《Skills 嘅最正確用法，係將成個 Github 壓縮成你自己嘅超級技能庫》絕對係一篇絕佳嘅入門指南，但都要注意：呢種用法，仲當唔起「最」正確用法。
我唔係嚟抬槓嘅，而係想傾嚇：點樣更好咁使用 Skills，而唔係有咗把錘子就周圍揾釘子。
你真係需要 Skills 咩？
Skills 好型，就好似切西瓜攞電鋸，感覺真係爽😂
但如果你只係切西瓜嘅話，西瓜刀更順手。
Skill 係用嚟補充 Agent 本身冇、而你又成日需要嘅資訊。
呢個意味住，如果 Agent 已經知道點做，或者可以透過搜尋自己搞掂，咁就冇必要整成 Skill。過度封裝只會增加複雜程度，但係帶嚟唔到額外價值。
例如下載 YouTube 影片呢樣嘢，真係唔需要畀佢一個 GitHub Repo。流行嘅開源項目，只要唔係最近半年嘅，佢都訓練過；就算冇，佢都會去搜。你每次只需要講「幫我下載呢條片」，然後俾連結就得喇。
真正需要 Skill 嘅場景係：你不斷踩坑之後，發現某個位每次都要解釋一次。
就好似我喺維護 baoyu-skills 時發現嘅：每次發佈前，我都要教佢寫 changelog、更新 README、寫 commit message、根據改動大小決定版本號。幾次之後我就將呢個流程封裝咗做 release-skills。
軟件工程強調避免過度設計，Skills 都一樣：先解決當下嘅真問題，唔好為咗可能永遠用唔到嘅未來需求過度設計。
Skills 係呢個任務嘅最佳方案咩？
Skill 嘅優勢在於：令 Agent 可以自主完成多個步驟嘅任務，仲唔使點寫代碼或者用少量腳本就得。
如果一個任務用提示詞就可以解決，咁提示詞就夠曬；如果一定要寫個 Web 應用先至行得通，咁成本又太高。Skill 嘅甜蜜點喺中間：任務需要多個步驟串聯，但又唔值得為咗呢個開發一套系統。
例如幫文章配圖。淨係靠提示詞做唔到，因為提示詞只能幫你分析文章、生成畫圖提示詞，但都係要人逐張生成、逐張插入適當位置。
用配圖 Skill 就唔同喇。Agent 分析文章需要幾多張配圖，逐張生成提示詞，逐張 call 圖像 API，最後仲幫你插入到適當位置。全程自動化，你只需要驗收。
呢件事寫程式都做到，但你要搭 Web 應用，後台駁 LLM API 同畫圖 API，成本比 Skills 高好多。用 Skills 呢？幾句說話接入一個畫圖 Skill，件事就搞掂。冇任何代碼，寫好咗仲可以分享畀其他人用。
你嘅 Skill 可以同其他 Skills 組合咩？
Skill 嘅設計初衷係模塊化：每個 Skill 做好一件事，然後好似樂高咁拼埋一齊。
單點方案同可組合方案嘅差別，往往唔喺第一次使用時顯現，而係喺後續重用時拉開差距。一個孤立嘅 Skill 解決一個問題；一組可組合嘅 Skills 可以解決一類問題。
例如寫作風格呢樣嘢，其實就係提示詞，說明你鍾意用乜、唔鍾意用乜。完全可以放喺 Gemini 入面整成一個 Gem，將素材 send 過去就可以潤色。但佢係單點嘅，冇得組合。
如果我將佢變成一個 Skill，之後寫影片採訪稿可以用呢個風格 Skill，出 tweet 都用得。本來單個 Style 作為提示詞模板都用得，但係有咗 Skills，我可以組合起來：
素材 → 分析 Skill → 提綱 Skill → 寫作 Skill
寫 PPT 時又可以重用分析 Skill 同提綱 Skill。
所以設計 Skill 時要避免做「巨無霸」嘅衝動。一個 Skill 包曬所有嘢好似好省事，實際上係封死咗組合嘅可能性。
呢個 Skill 值得你不斷迭代咩？
好嘅 Skill 唔係寫出嚟嘅，係用出嚟嘅。
呢個同傳統寫提示詞完全唔同。提示詞係你坐喺度諗 AI 需要知道啲乜，然後一次過寫完；Skill 係你同 Agent 一齊做嘢，一路做一路將經驗沉澱落嚟。
喺用 Agent 完成任務嘅過程中，等佢將成功嘅做法、踩過嘅坑自己總結成 Skill。行歪咗就等佢反思邊度出咗問題。用嚇用嚇，Skill 就越來越準。
如果一個 Skill 做完之後就再都唔想掂，咁大概呢個 Skill 本身唔應該做。
就好似我發布嘅小紅書 Skill，一個版本一個版本疊代到今日：
• 最開始係小互叫我幫手寫一個小紅書嘅提示詞 • 然後我發布咗做 Skill • 後來發現樣式太單一，加咗唔同嘅樣式風格 • 接着發現資訊密度太低，加咗 Layout 選項 • 然後發現內容長咗質量唔夠，就加咗分析並提煉大綱 • 有大綱之後發現有時唔係我想要嘅，索性等佢一次過出多個版本畀我揀 • 今日又加咗水印嘅支援
最有趣嘅係，用嘅過程中發現問題，即刻叫 Agent 幫你優化，連重現同描述都慳返。疊代成本極低，呢個係 Skill 相比傳統代碼嘅獨特優勢。
咩嘢先至係最正確用法？
唔係將 GitHub 上所有型爆嘅 Skill 都裝入嚟。咁只會令 Claude 啓動時加載一大堆放喺度冇用嘅元數據，反而影響判斷。
亦都唔係睇到咩功能就諗住封裝成 Skill。咁樣係過度設計。
Skills 嘅正確用法係：先做嘢，做到某個位不斷卡住，然後用最小嘅上下文解決呢個卡住位，最後令呢個解決方案可以同其他 Skill 組合、可以持續疊代。
三個詞：因需而建、可組合、可疊代。
畀 Agent 寫 Skill，就好似畀新員工寫入職指南。你唔會喺第一日就將公司所有文件都塞畀佢，而係根據佢要做嘅事，畀佢最需要嗰幾份。
這篇《Skills 的最正確用法，是將整個 Github 壓縮成你自己的超級技能庫》絕對是一篇絕佳的入門指南，但也要注意：這種用法，還當不起“最”正確用法。
我不是來抬槓的，而是想聊聊：怎麼更好地使用 Skills，而不是有了把錘子就到處找釘子。
你真的需要 Skills 嗎？
Skills 很酷，就像切西瓜拿電鋸，感覺是真的爽😂
但你只是切西瓜的話，西瓜刀更順手。
Skill 是用來補充 Agent 本身不具備、而你又反覆需要的信息。
這意味着，如果 Agent 已經知道怎麼做，或者能通過搜索自己搞定，那就沒必要做成 Skill。過度封裝只會增加複雜度，卻不帶來額外價值。
比如下載 YouTube 視頻這事，真不需要給它一個 GitHub Repo。流行的開源項目，只要不是最近半年的，它都訓練過；就算沒有，它也會去搜。你每次只需要說“幫我下載這個視頻”，然後給連結就行了。
真正需要 Skill 的場景是：你反覆踩坑之後，發現某個地方每次都要解釋一遍。
就像我在維護 baoyu-skills 時發現的：每次發佈前，我都要教它寫 changelog、更新 README、寫 commit message、根據變更大小決定版本號。幾次之後我就把這個流程封裝成了 release-skills。
軟件工程強調避免過度設計，Skills 也一樣：先解決當下的真問題，別為可能永遠用不上的未來需求過度設計。
Skills 是這個任務的最佳方案嗎？
Skill 的優勢在於：讓 Agent 能自主完成多步驟任務，還不用怎麼寫代碼或者少量腳本就可以。
如果一個任務用提示詞就能解決，那提示詞就夠了；如果必須寫個 Web 應用才能跑通，那成本又太高。Skill 的甜蜜點在中間：任務需要多個步驟串聯，但又不值得為此開發一套系統。
比如給文章配圖。單純靠提示詞做不了，因為提示詞只能幫你分析文章、生成畫圖提示詞，但還是要人去一張張生成、一張張插入合適位置。
用配圖 Skill 就不一樣了。Agent 分析文章需要多少配圖，一張張生成提示詞，一張張調圖像 API，最後還給你插入到合適位置。全程自動化，你只需要驗收。
這事寫程序也能做，但你得搭 Web 應用，後台接 LLM API 和畫圖 API，成本比 Skills 高得多。用 Skills 呢？幾句話接入一個畫圖 Skill，事就成了。沒有任何代碼，寫好了還能分享給其他人用。
你的 Skill 能和其他 Skills 組合嗎？
Skill 的設計初衷是模塊化：每個 Skill 做好一件事，然後像樂高一樣拼起來。
單點方案和可組合方案的差別，往往不在第一次使用時顯現，而在後續複用時拉開差距。一個孤立的 Skill 解決一個問題；一組可組合的 Skills 能解決一類問題。
比如寫作風格這事，其實就是提示詞，說明你喜歡用什麼、不喜歡用什麼。完全可以放到 Gemini 裏做成一個 Gem，把素材發過去就能潤色。但它是單點的，無法組合。
如果我把它變成一個 Skill，後續寫視頻採訪稿可以用這個風格 Skill，發推文也能用。本來單個 Style 作為提示詞模板也能用，但有了 Skills，我可以組合起來：
素材 → 分析 Skill → 提綱 Skill → 寫作 Skill
寫 PPT 時又可以重用分析 Skill 和提綱 Skill。
所以設計 Skill 時要避免做“巨無霸”的衝動。一個 Skill 包攬所有看似省事，實則堵死了組合的可能性。
這個 Skill 值得你持續迭代嗎？
好的 Skill 不是寫出來的，是用出來的。
這和傳統寫提示詞完全不同。提示詞是你坐在那裏冥想 AI 需要知道什麼，然後一次性寫完；Skill 是你和 Agent 一起幹活，幹着幹着把經驗沉澱下來。
在用 Agent 完成任務的過程中，讓它把成功的做法、踩過的坑自己總結成 Skill。跑偏了就讓它反思哪裏出了問題。用着用着，Skill 就越來越準。
如果一個 Skill 做完之後就再也不想碰了，那大概率這個 Skill 本身就不該做。
就像我發佈的小紅書 Skill，一個版本一個版本迭代到今天：
• 最開始是小互讓我幫忙寫一個小紅書的提示詞 • 然後我發佈成了 Skill • 後來發現樣式太單一，添加了不同的樣式風格 • 接着發現信息密度太低，添加了 Layout 選項 • 然後發現內容長了質量不夠，就增加了分析並提煉大綱 • 有了大綱發現有時候不是我想要的，乾脆讓它一次性出多個版本讓我選 • 今天又加上了水印的支持
最有趣的是，用的過程中發現問題，馬上讓 Agent 幫你優化，都省了去重現去描述。迭代成本極低，這是 Skill 相比傳統代碼的獨特優勢。
什麼才是最正確用法？
不是把 GitHub 上所有酷炫的 Skill 都裝進來。那隻會讓 Claude 啓動時加載一堆用不上的元數據，反而影響判斷。
也不是看什麼功能就想着封裝成 Skill。那是過度設計。
Skills 的正確用法是：先幹活，幹到某個地方反覆卡殼，然後用最小的上下文解決這個卡殼，最後讓這個解決方案能和其他 Skill 組合、能持續迭代。
三個詞：因需而建、可組合、可迭代。
給 Agent 寫 Skill，就像給新員工寫入職指南。你不會在第一天就把公司所有文檔都塞給他，而是根據他要做的事，給他最需要的那幾份。