很多程序員的Skill數量已經失控了
整理版優先睇
Skill庫應該控制在30個以內，核心在於分類同觸發，而唔係數量。
呢篇文章係由作者可可耐特寫嘅，佢係一個程序員，最近見到朋友圈好多人瘋狂囤Skill，數量多到六七十甚至過百，令佢反思Skill管理嘅本質。作者認為Skill唔係越多越好，而係要講分類同觸發。佢引用咗一篇論文嘅數據，指出Skill庫超過30個之後，準確率就會開始暴跌，去到200個嘅時候準確率得返20%，Token亦會爆漲。
作者分享咗自己嘅做法：佢嘅Skill庫長年壓喺30個以內，呢條線唔輕易破。佢仲舉咗一個實例——將NanoBanana API包裝成一個叫「圖片生成」嘅Skill，入面拆開幾個分支嚟應付唔同場景（例如公眾號封面、小紅書封面、PPT配圖等），冇為每個場景各自開一個獨立Skill，呢個就係分類學嘅應用。
整體結論係：Skill管理嘅本質係分類學，要參考生物學嘅界門綱目科屬種，喺每一層揾最合適嘅顆粒度。評判一個Skill值唔值得留低，要睇場景邊界清唔清晰、頻率夠唔夠高、可唔可以掛到現有Skill下。最後仲要記住奧卡姆剃刀——如無必要，勿增實體。作者提醒大家要建立自己嘅分類系統，分清CLAUDE.md、Skill同MCP。
- Skill庫超過30個會令準確率大跌同Token爆漲，最佳數量應控制在30個以內。
- 用分類學思維設計Skill，將高頻場景按類別合併，再拆分支，避免各自開獨立Skill。
- 封面圖同PPT配圖嘅差異唔值得各自開一個Skill，但圖片生成同服務器管理就必須分開。
- Skill本質係分類學，參考生物學界門綱目科屬種，要喺每一層揾最合適嘅顆粒度。
- 建立清晰嘅分類系統，分清CLAUDE.md、Skill同MCP，跟住奧卡姆剃刀原則，唔好亂塞Skill。
Skill數量失控嘅現象
最近唔知係咪Skills大爆發嘅餘温未散，朋友圈裏囤skill嘅風颳得幾離譜。順手睇咗幾個朋友嘅skill庫，少嘅六七十個，多嘅一個哥們直接破咗一百。作者話睇完一度懷疑係咪自己裝少咗。
六七十個
破咗一百
囤skill嘅風颳得有點離譜
Skill嘅命門：分類同觸發
作者評判一個skill得唔得，就係睇兩個詞：分類同觸發。Claude之前更新過skill生成器，最重要嘅動作就係教人用反饋循環磨準觸發條件。Skill喺咩時候被叫起、能否被對嘅人喺對嘅時候叫起、叫起之後做到啲咩，呢三件事先係命門。
分類，觸發
反饋循環磨準觸發條件
30個以內
實戰：將圖片生成整合成一個Skill
作者舉咗自己嘅例子：佢想將NanoBanana API封成一個被Agent調起嘅skill，因為日常生圖需求太碎——公眾號封面、小紅書封面、PPT配圖、產品演示圖，風格都唔同。佢冇為每個需求開獨立skill，而係只起咗一個叫「圖片生成」嘅skill，內部將幾個高頻場景拆成分支，Agent先讀上下文再揀分支，其餘需求就由通用分支兜底。
一個叫「圖片生成」嘅skill
分支兜底
- 1 封面圖同PPT配圖之間嘅差異，唔值得各自喺最頂層佔一個skill，佢哋只係「圖片生成」呢一類嘅變種。
- 2 但圖片生成同服務器管理之間嘅差異好大，必須各起一個skill，唔能夠糊弄。
呢個做法嘅本質就係分類學——參考生物學嘅界門綱目科屬種，唔係越細越光榮，而係喺每一層揾最合適嘅顆粒度。
判斷Skill嘅三件事同奧卡姆剃刀
作者判斷一個skill值唔值得留低，就睇三件事：佢對應嘅場景邊界夠唔夠清晰？場景頻率夠唔夠高？佢可唔可以直接掛到現有某個skill下面？
三件事
仲要疊多一條奧卡姆剃刀——如無必要，勿增實體。日常用唔到嘅skill就唔好塞落個庫度。比刪skill更重要嘅係設計一套清晰嘅分類系統，諗清楚咩事行CLAUDE.md、咩事行skill、咩事行MCP。
奧卡姆剃刀
邊界夠唔夠清晰
頻率夠唔夠高
最近唔知係唔係Skills大爆發嘅餘温未散，朋友圈入面囤skill嘅風吹得有啲離譜。 順手睇咗幾個朋友嘅skill庫，少嘅六七十個，多嘅一個兄弟直接超過一百。 睇完我一度懷疑係咪我裝少咗。 琴日出完Harness嗰篇，入面加咗一句"skill本質就係分類學"，點知嗰段被轉得最犀利，私訊都衝住呢句嚟問可唔可以講多少少。 咁今日就再講幾句啦。 我評判一個skill做得好唔好，就睇兩個詞： 分類，觸發。 Claude一個多月前仲專門更新過佢哋嘅skill生成器，當時我寫過一篇詳細講。嗰次更新最重要嘅動作，就係教你點樣用反饋循環去將觸發條件磨準。 講白啲，skill喺咩時候被叫出嚟、可唔可以被啱嘅人喺啱嘅時候叫出嚟、叫出嚟之後又可以做到啲乜——呢三件事，先係skill真正嘅命門。 之前睇到一篇論文入面嘅實驗數據，睇完真係好揪心。 skill庫喺20個以內嘅時候，準確率可以維持喺90%以上，基本上唔出錯。 一過30個，即刻就開始跌。 裝到200個嘅時候，準確率得返20%，仲有明顯嘅慢、明顯嘅Token爆炸。 呢個同我自己嘅感覺對得幾準。我嘅skill庫長年限喺30個以內，呢條線我唔會隨便破。 舉我自己一個例子。 我之前想將NanoBanana嘅API封裝成一個可以俾Agent調用嘅skill。原因好簡單——我日常生圖嘅需求實在太散。 公眾號封面要一種風格，小紅書封面要另一種，PPT配圖要第三種，產品演示圖又係第四種。 咁問題嚟啦。 每個需求各自建立一個獨立skill，定係塞入同一個skill入面？ 我最終揀咗後者。 只開咗一個叫"圖片生成"嘅skill，內部將幾個高頻場景拆分做分支。Agent調用之後，先讀上下文，再判斷應該行邊個分支，剩低未覆蓋到嘅需求就行通用分支包底。 呢個做法，本質就係分類學嘅思路。 生物學嗰套界門綱目科屬種，從來唔係越細越光榮。 佢做嘅事，係喺每一層揾最合適嘅顆粒度。 你諗下，如果將界門綱目科屬全部抹走，地球上所有生物就得返"種"呢一層。 嗰種災難感你諗像下——每隻貓同每條細菌平起平坐，每棵橡樹同每個愛滋病毒分庭抗禮。 返返去skill。 封面圖同PPT配圖之間嗰啲差異，根本唔配各自喺最上層佔一個skill。佢哋就係"圖片生成"呢一類下面嘅唔同變種。 但係圖片生成同伺服器管理之間嘅差異，真係好大。大到必須各開一個skill，唔可以求其。 所以我判斷一個skill值唔值得喺我庫入面存在，就睇三件事：
再加多條奧卡姆剃刀——如無必要，勿增實體。 翻譯過嚟就係，你日常根本用唔到嘅skill，就唔好放入庫入面。 但係比"刪幾個skill"更要緊嘅事，係你要為自己設計一套清晰嘅分類系統。 邊啲事用CLAUDE.md，邊啲事用skill，邊啲事用MCP，要自己想清楚。 唔係嘅話裝得幾多，都只係一個塞滿捷徑嘅雜亂桌面。 生物學係咁。 你嘅skill庫，都應該係咁。  以上，既然睇到呢度，如果覺得唔錯，順手點個讚、在看、轉發三連啦，如果想第一時間收到推送，都可以俾我個星標⭐～多謝你睇我嘅文章，我哋，下次再見。
|
最近不知道是不是Skills大爆發的餘温還沒散，朋友圈裏囤skill的風颳得有點離譜。 順手翻了幾個朋友的skill庫，少的六七十個，多的一個哥們直接破了一百。 看完我一度懷疑是不是我裝少了。 昨天發完Harness那篇，裏頭夾了一句"skill本質就是分類學"，沒想到那一段被轉得最猛，私信也都奔着這句來問能不能多說幾句。 那今天就再聊幾句。 我評判一個skill做得行不行，就盯兩個詞： 分類，觸發。 Claude一個多月前還專門更新過他們的skill生成器，當時我寫過一篇細聊。那次更新最重要的動作，就是教你怎麼用反饋循環去把觸發條件磨準。 說白了，skill在什麼時候被叫起來、能不能被對的人在對的時候叫起來、叫起來之後又能幹點啥——這三件事，才是skill真正的命門。 之前刷到過一篇論文裏的實驗數據，看完真的挺扎心。 skill庫在20個以內的時候，準確率能穩在90%以上，基本不出錯。 一過30個，立馬就開始掉。 裝到200個的時候，準確率只剩20%，外加肉眼可見的慢、肉眼可見的Token爆炸。 這跟我自己的體感對得相當準。我的skill庫常年壓在30個以內，這條線我不輕易破。 舉我自己一個例子。 我之前想把NanoBanana的API封成一個能被Agent調起來的skill。原因很簡單——我日常生圖的需求實在太碎。 公眾號封面要一種風格，小紅書封面要另一種，PPT配圖要第三種，產品演示圖又是第四種。 那問題來了。 每個需求各起一個獨立skill，還是塞進同一個skill裏？ 我最後選的是後者。 只起了一個叫"圖片生成"的skill，內部把幾個高頻場景拆成分支。Agent調起來之後，先讀上下文，再判斷該走哪個分支，剩下沒覆蓋到的需求就走通用分支兜底。 這個做法，本質就是分類學的思路。 生物學那套界門綱目科屬種，從來不是越細越光榮。 它做的事，是在每一層找最合適的顆粒度。 你想想，要是把界門綱目科屬全抹了，地球上所有生物就剩"種"這一層。 那種災難感你腦補一下——每隻貓跟每根細菌平起平坐，每棵橡樹跟每個艾滋病毒分庭抗禮。 回到skill。 封面圖和PPT配圖之間那點差異，根本不配各自在最頂層佔一個skill。它們就是"圖片生成"這一類下的不同變種。 但圖片生成和服務器管理之間的差異，那真的大。大到必須各起一個skill，不能糊弄。 所以我判斷一個skill值不值得在我庫裏活着，就盯三件事:
再疊一條奧卡姆剃刀——如無必要，勿增實體。 翻譯過來就是，你日常壓根用不到的skill，就別往庫裏塞。 但比"刪幾個skill"更要命的事，是你得給自己設計一套清晰的分類系統。 哪些事走CLAUDE.md，哪些事走skill，哪些事走MCP，得自己想明白。 不然裝得再多，也只是個塞滿快捷方式的雜亂桌面。 生物學如此。 你的skill庫，也應如此。 以上，既然看到這裏了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標⭐～謝謝你看我的文章，我們，下次再見。
|