1. 從“skills”這個詞說起為什么它突然成了高頻詞最近不管是刷技術(shù)社區(qū)還是跟同行吃飯聊天“skills”這個詞出現(xiàn)的頻率明顯高了起來。一開始我以為大家只是在聊招聘JD里的技能要求后來發(fā)現(xiàn)不是——有人在聊怎么把自己的能力拆成可復(fù)用的模塊有人在聊怎么給AI助手配置一套技能包還有人在聊團(tuán)隊內(nèi)部怎么建一個“技能庫”來減少重復(fù)造輪子。這個詞從一個抽象的英文單詞變成了一個具體的、可操作的項目概念。我自己第一次認(rèn)真對待“skills”這個概念是因為一個很實(shí)際的問題我發(fā)現(xiàn)自己和團(tuán)隊在重復(fù)解決同一類問題。比如每次新項目啟動都要重新寫一遍數(shù)據(jù)校驗的邏輯、重新配一遍日志采集、重新搭一遍接口重試機(jī)制。這些東西不難但很煩而且每次寫法還不太一樣導(dǎo)致維護(hù)成本很高。后來我就想能不能把這些東西抽象成一個個獨(dú)立的“技能單元”需要的時候直接調(diào)用而不是每次從頭寫。這個想法其實(shí)就是“skills”項目的核心把能力模塊化、可復(fù)用、可組合。它不是一個具體的框架或工具而是一種組織思路——把零散的能力沉淀成結(jié)構(gòu)化的技能包讓個人和團(tuán)隊都能按需取用。適合誰來參考我覺得三類人最需要一是經(jīng)常做重復(fù)性技術(shù)工作的開發(fā)者二是帶團(tuán)隊的技術(shù)負(fù)責(zé)人三是正在探索AI輔助工作流的產(chǎn)品或運(yùn)營同學(xué)。不管你基礎(chǔ)如何只要你有“這件事我好像做過好幾遍了”的感覺那“skills”這個思路就值得你花時間了解一下。2. 整體設(shè)計思路為什么是“技能包”而不是“工具箱”2.1 核心問題能力碎片化帶來的隱性成本在聊具體怎么做之前我想先把問題說透。很多人覺得“重復(fù)勞動”只是浪費(fèi)時間但其實(shí)它的成本遠(yuǎn)不止時間。我總結(jié)下來能力碎片化至少帶來三層隱性成本。第一層是認(rèn)知成本。每次重新做一件事你都要重新回憶“上次是怎么處理的”“當(dāng)時踩了什么坑”“哪個參數(shù)需要特別注意”。這些信息如果沒被記錄下來每次都要重新走一遍彎路。我見過一個團(tuán)隊同一個接口的超時重試邏輯三個人寫了三個版本每個版本的重試次數(shù)和退避策略都不一樣最后線上出問題的時候排查了半天才發(fā)現(xiàn)是策略不統(tǒng)一。第二層是質(zhì)量成本。重復(fù)勞動往往伴隨著質(zhì)量波動。第一次做的時候可能很認(rèn)真第十次做的時候就開始敷衍了。如果沒有一個標(biāo)準(zhǔn)化的“技能包”作為參照每次產(chǎn)出的質(zhì)量全靠個人狀態(tài)這在高頻迭代的場景下是很危險的。第三層是協(xié)作成本。當(dāng)一個人離職或轉(zhuǎn)崗他腦子里的那些“怎么做”很難完整交接。文檔往往滯后代碼注釋也不一定到位。但如果這些能力被沉淀成了結(jié)構(gòu)化的技能包交接就變成了“把這個包拿走按里面的說明操作”效率完全不一樣。2.2 方案選型為什么不用現(xiàn)成的工具或框架有人可能會問市面上不是有很多工具和框架來解決復(fù)用問題嗎比如各種腳手架、模板引擎、低代碼平臺。我試過一些但最后選擇自己搭一套“skills”體系原因有幾個。現(xiàn)成工具往往綁定特定技術(shù)棧。比如某個腳手架只支持某一種前端框架換個項目就用不了。而“skills”的思路是技術(shù)棧無關(guān)的它更像是一種組織方式底層可以用任何語言或工具實(shí)現(xiàn)?，F(xiàn)成工具通常太重。為了用一個功能要引入一整套依賴學(xué)習(xí)成本高定制成本更高。而“skills”體系是輕量的每個技能包可以很小只解決一個具體問題用不用、怎么用都由你決定。還有一個很實(shí)際的原因現(xiàn)成工具的抽象層次往往不合適。它們要么太底層你要寫很多配置才能用起來要么太高層你想改一點(diǎn)細(xì)節(jié)就發(fā)現(xiàn)改不動?！皊kills”體系允許你自己控制抽象層次每個技能包可以簡單到只是一個函數(shù)也可以復(fù)雜到包含完整的配置和文檔。2.3 設(shè)計原則三個“可”字我在設(shè)計這套體系的時候給自己定了三個原則后來發(fā)現(xiàn)這三個原則基本決定了整個體系的形態(tài)。第一個原則是可發(fā)現(xiàn)。技能包不能藏在某個深層目錄里得有統(tǒng)一的索引和命名規(guī)范讓人能快速找到“有沒有現(xiàn)成的技能可以用”。我見過太多團(tuán)隊把可復(fù)用的代碼扔在一個叫“utils”的文件夾里結(jié)果沒人知道里面有什么最后還是各寫各的。第二個原則是可組合。單個技能包解決一個問題多個技能包可以串起來解決一個復(fù)雜流程。這就要求技能包之間的接口要清晰輸入輸出要明確不能有隱藏的依賴。第三個原則是可驗證。每個技能包都應(yīng)該有對應(yīng)的測試或驗證方式確保它在不同環(huán)境下都能正常工作。沒有驗證的技能包用起來心里沒底最后大家還是不敢用。這三個原則聽起來簡單但實(shí)際落地的時候每一個都會遇到取舍。比如“可發(fā)現(xiàn)”和“可組合”有時候會沖突——為了讓技能包容易找到你可能想把它放在顯眼的位置但為了讓技能包容易組合你可能想把它放在統(tǒng)一的目錄結(jié)構(gòu)里。這些取舍后面我會具體講。3. 核心細(xì)節(jié)解析一個技能包到底包含什么3.1 技能包的最小結(jié)構(gòu)我先給一個我實(shí)際在用的技能包結(jié)構(gòu)你可以直接參考skills/ >