James Moss - Using skills to pay the bills: graduating from solo hacks to a team workflow - DevCon26

技能管理危機的根源在於其超低門檻。與傳統軟體只能由工程師創建不同，技能本質上是文本檔案加少量腳本，任何人都能編寫，這導致企業內部出現「技能寒武紀大爆發」。GitHub 公開倉庫已有 240 萬+技能分布在 44,000 個專案中，更不用說私有環境。問題是沒人看得清這些技能在哪裡、怎麼被用、有沒有作用。

James 從客戶訪談引用了三句話：某大型 AI 服務公司的架構主管說「無數倉庫分散的技能讓統一與集中分配成了不可能任務」；工程師稱「現在就是大亂鬥」。他的現場調查證實了這一點——幾乎所有人都舉手承認看不清團隊用了哪些技能。

失敗模式有五種。重疊最常見：多個團隊不知道彼此存在，各自寫了達到相同功能的技能。漂移則是新版本發布但舊版本仍被使用，如教育者 Matt Pocock 發布了增強版 grill with docs 來取代舊的 grill me 技能，但許多人還在用舊版。激活問題是根本無法知道技能有沒有被使用。腐爛指技能文檔與實際代碼不同步，過期技能通常和沒有技能一樣糟。過度加載最隱蔽：模型知道的技能名稱和描述會被注入每個上下文窗口開頭，當技能數量超過上下文百分比限制時，描述會被截斷，模型因此無法識別和激活技能。

Tesla 建設的 Skills Inventory 工具透過連接客戶 GitHub 組織來解決這個問題。它會掃描所有倉庫找出技能，讓你按倉庫或技能分類檢視，看到 token 使用量，重點是自動檢測上述五種失敗模式並生成報告供修復。如果檢測到第三方技能，還會顯示公開註冊表的安全掃描和評分結果。此工具目前在私密測試階段。

解決方案借鑑軟體開發成熟實踐。分解是首要原則：不要寫龐大技能，拆成小模組透過 plugins 組合，讓代理按需選擇激活哪些部分，同時人類可直接調用某個微粒度技能（如只用按鈕層級技能建小工具）。Tesla 的 UI 技能就是這樣：一個技能從 Figma 設計拆解成元件，然後用低階（按鈕）、中階（表單）、高階（頁面）三個技能交由子代理實現。擴展而非編輯：如果第三方技能好用但不符合你的技術棧或公司最佳實踐，寫一個新技能來呼叫它，讓代理自己判斷意圖和覆蓋細節，千萬別直接改源碼，隊友會恨你。

避免全局技能是致命錯誤。在開發機個人配置中的技能會造成「在我機器上能跑」問題——兩個人跑同樣任務、同個代碼庫卻得到不同結果，因為只有一人有該技能或版本不同。這無法追蹤、難以除錯，因為技能不在 diff、不在 PR review、不在 CI。正確做法是版本控制技能跟著代碼進倉庫，像鎖定套件版本一樣。Boris Churny（Claude Code 創意雲負責人）已率先示範：「禁止本地設置，所有工作流改進、hook、技能都必須檢入倉庫讓所有人使用」。

自動化審查應貫穿流程。你不會不跑 linter 就提交代碼，也要求代理寫測試，技能審查類似：跑在本地得快速反饋，也該納入 CI 防止質量衰退。James 展示的例子中，一個演示技能通過了格式檢查（行數、前置元數據都合法），但 LLM 審查給了 20% 分數，警告它包含危險金融操作，根本不能發佈。

發佈到註冊表解決可見性和供應鏈問題。現在大多人直接從 GitHub 或 marketplace 裝技能，但中央註冊表提供單一真相源、版本鎖定、安全掃描前置門檻。GitHub 滿是技能 fork，同名技能其實來自不同地方改過內容，註冊表防止這種混亂。更重要的是可以設定最小發布年齡政策：比如要求技能發佈至少三天才能安裝。三週前 miniature claude 供應鏈攻擊事件中植入了全局 hook 試圖持久化自己，Tesla 正因為設了三天最小年齡，在 10-stack 團隊發現並修復前就擋住了所有開發者。Open Claw 註冊表已有 20% 惡意技能，其他地方也會跟進，註冊表中間層至關重要。

技能不該鎖定單一代理。銷售技能倉庫光是到字母 K 就有無數專案路徑，代理格局六個月內可能面目全非（token 成本上升、開源模型崛起），不想每次工具換就重寫投資。技能是持久資產，代理只是運行時。套件管理讓你寫一次、自動裝進任何代理。

團隊資產化需要共同所有權、安全貢獻環境、CI 門檻防止破壞，不讓單人或單隊獨占。測量推動改進最被忽視。Reddit 和 LinkedIn 充斥未驗證聲稱如「技能減少過度思考、削減 60-80% tokens」「四條規則把準確度從 65% 升到 94%」「這個提示消滅 90% 生產 bug」。Mythbusters 主持人 Adam Savage 名言：「科學和瞎搞的差別在於把它寫下來」。Eval 就是寫下來，讓你改動模型、代理、上下文任何一項都能衡量實際效果，對單技能或多技能跑測、在真實代碼庫驗證。

最後的啟示來自歷史。2005 年 PHP 無包管理器，所以人們從 SourceForge 下載 zip、解壓進代碼庫、完全沒安全審查、版本全看作者心情、用 FTP 直接傳到生產機。十年間業界發明了 Composer、語義版本控制、lock 檔、註冊表、CI、依賴掃描、簽名發佈，才把這套瘋狂搬到了文明時代。諷刺的是技能管理現在正在重蹈覆轍：跳過套件管理、直接從源安裝、沒有 CI 流程。好消息是不需要重新摸索十年，直接把 SDLC 成熟經驗應用到 CDLC（Context Development Life Cycle）就行。