# 你寫的技能只在你自己的電腦上好用，那它就不叫團隊資產，叫個人習慣 一支技能如果只有你自己會用、用得好，那它的價值是有天花板的。真正值錢的技能，是新人一進… · @swordBluesy · TwKit

@swordBluesy

# 你寫的技能只在你自己的電腦上好用，那它就不叫團隊資產，叫個人習慣 一支技能如果只有你自己會用、用得好，那它的價值是有天花板的。真正值錢的技能，是新人一進團隊就能用、換一台電腦還能用、跨專案還能用。做不到這一點，技能就只是你個人的快捷鍵，不是團隊的資產。 ## 分享技能的三種做法 第一種是專案技能，做法最直接：把技能放進專案的 .claude/skills，連同專案一起提交到倉庫。別人把專案複製下來，技能就跟著來了，不需要另外傳檔案、另外教設定。這種做法適合團隊內部共用的做法，例如這個專案的程式碼審查標準、提交格式、文件範本。技能跟著專案走，專案到哪裡，做法就到哪裡。 第二種是插件，適合跨倉庫、跨團隊分發。專案技能是跟著一個專案走，插件是可以跨多個專案、跨多個團隊散佈的包裝。當同一套做法要在很多專案裡重複用，每次複製貼上就太笨了，包成插件分發一次，大家都能拿到同一份。這裡的重點是範圍：一個專案內部用專案技能就夠了，多個專案共用才需要考慮插件。 第三種是企業托管，適合整個組織統一部署。企業層級的技能會部署給全組織，優先順序也是最高的。搭配 strictKnownMarketplaces，還可以限制技能只能從受信任的來源取得，避免來路不明的插件混進來。企業托管不是為了炫技，是為了統一與可控：全組織用同一套做法，出了問題也知道該改哪一份。 分享還有一條容易踩的坑，和子代理有關。子代理不會自動繼承技能，這一點一定要先講清楚。內建的 Explorer、Plan、Verify 不能使用技能，不管主對話的技能寫得多好，它們都不會自動拿到。只有在 .claude/agents 裡自訂的子代理，才可以在檔案頭的 skills 欄位裡明確列出它能用的技能，啟動時才會載入。而且列的時候要克制，只列那些始終相關的技能，不要把所有技能一股腦列上去，列多了，子代理的判斷一樣會變糊。 ## 一個可以照做的例子 假設你的團隊有一套程式碼審查標準，希望每個人都照同一套做，照做的步驟是這樣： 第一步，把審查技能放進專案的 .claude/skills，連同專案一起提交到倉庫，新人把專案複製下來，審查技能就已經在他的環境裡了。第二步，團隊成員在審查程式碼時，不需要再問標準是什麼，任務一對上描述，技能就會載入，照著同一套流程審查。第三步，如果團隊裡還有一支專門做審查的子代理，不要指望它自動繼承主對話的技能，要在它的自訂檔案頭 skills 欄位裡明確列出審查技能，讓它啟動時就載入。第四步，如果這套審查標準後來要在好幾個專案、好幾個團隊之間共用，再考慮包成插件分發，而不是每個專案各自複製一份，改的時候改到漏掉某個專案。 這個例子的關鍵不在於用了哪一種分發方式，而在於每一步都有明確的歸屬。專案內部的東西跟著專案走，跨專案的東西用插件，組織層級的東西用企業托管，子代理要用的東西明確列出，沒有哪一步是靠「應該會自動拿到」在賭。 ## S1哥觀點 分享技能最怕的不是技術做不到，而是心態上覺得自己的技能不值得分享，或者覺得分享很麻煩。結果就是每個人的環境裡都有一份長得差不多、但細節都不一樣的技能，團隊表面上用同一套工具，實際上每個人都在照自己的習慣做事。 爭論點在這裡：技能到底是個人效率工具，還是團隊資產？如果只當個人工具，寫得再好也只幫到一個人；如果當團隊資產來經營，寫的時候就會多想一步，別人看不看得懂、換專案還能不能用、新人要不要另外學一套。我的立場很直接：凡是會重複用、會影響產出品質的做法，都該當團隊資產來放。個人習慣可以留在個人技能裡，但團隊做法一定要放進專案或插件，讓它有辦法被複製、被更新、被繼承。 原文連結：https://anthropic.skilljar.com/introduction-to-agent-skills/434529 原文：Anthropic Academy（由 S1哥 編譯）

曝光 106 · 评论 1 · 点赞 1 · 书签 0