我前陣子花了整整兩個(gè)晚上把 GitHub 上那些叫 skills 的東西挨個(gè)翻了一遍。不看不知道這里面水確實(shí)深有寫得像樣的有純粹湊數(shù)的還有不少是作者自己都沒用過就丟上去的。這篇文章不打算講什么高深理論就把我目前對 AI skills技能的理解、怎么挑、怎么寫以及最容易踩的坑一五一十分享出來。1. 到底什么是 AI skills它解決了什么問題先說個(gè)最直觀的感受。以前我用 AI 助手干活總覺得自己像個(gè)傳話筒先描述需求再把 AI 的輸出復(fù)制到別處改完再貼回來來回折騰。后來接觸了 skills才發(fā)現(xiàn)這個(gè)東西本質(zhì)上是把“你平時(shí)怎么干活”的那套流程、規(guī)則、話術(shù)打包成一坨結(jié)構(gòu)化的提示詞讓 AI 能一次性按你的套路執(zhí)行。我習(xí)慣這么理解如果說大模型是一張什么都會(huì)一點(diǎn)的白紙那 skills 就是你在紙上面提前畫好的格子。模型按格子走就不會(huì)跑偏。skills 能解決的問題其實(shí)是把“經(jīng)驗(yàn)”沉淀下來。舉個(gè)例子我在寫前端代碼的時(shí)候經(jīng)常要處理表單校驗(yàn)、請求封裝、狀態(tài)管理這類重復(fù)性很高的需求。如果每次都在對話里重新描述一遍“你幫我按項(xiàng)目的規(guī)范寫”既累又不穩(wěn)定。做成一個(gè) skill 之后丟給它一個(gè)需求描述它就知道該輸出什么風(fēng)格的代碼、該遵守什么約束甚至?xí)詣?dòng)參考項(xiàng)目里已有的文件結(jié)構(gòu)。GitHub 上比較火的幾個(gè) skills 庫比如 awesome-claude-skills 這類其實(shí)就是一群人在共享自己總結(jié)出來的“最佳實(shí)踐”。你下載到本地給 AI 工具配置一下路徑就能在對話里直接調(diào)用。這事兒聽起來有點(diǎn)像裝插件但實(shí)際用起來比插件更輕——它不改變模型本身只改變模型被調(diào)用時(shí)的上下文和指令。說到底skills 的核心價(jià)值在于讓 AI 從“會(huì)聊天”變成“會(huì)干活”。光這一點(diǎn)就值得花點(diǎn)時(shí)間弄清楚它是怎么運(yùn)作的。2. 怎么把 GitHub 上的 skills 裝到 Claude Code 里我最早接觸的就是 Claude Code身邊問“怎么手動(dòng)裝 GitHub 上的 skills”的人也最多所以先把這條路徑盤清楚。嚴(yán)格說起來手動(dòng)安裝一個(gè) skill 也就是三步把代碼庫拉到本地找到或者創(chuàng)建合適目錄然后在配置里告訴工具“技能在哪”。我用一個(gè)真實(shí)例子演示。假設(shè)你在 GitHub 上找到某個(gè)作者發(fā)布的 skills 倉庫倉庫里通常會(huì)有個(gè) skills 或者 .claude/skills 目錄。你要做的第一件事是把整個(gè)倉庫 clone 下來或者像下文件一樣下成 zip 再解壓。這個(gè)動(dòng)作沒有太多技術(shù)含量但要注意一點(diǎn)盡量把 skills 放在一個(gè)固定的、不帶空格、不帶中文的路徑下不然一些工具解析路徑的時(shí)候容易出幺蛾子。第二步就是搞清楚這個(gè)倉庫里哪些目錄是有效的 skill。一個(gè)標(biāo)準(zhǔn)的 skill目錄下應(yīng)該至少有一個(gè) SKILL.md 文件這個(gè)文件就是技能的核心定義。有的倉庫打包了一堆技能有的一個(gè)技能單獨(dú)占一個(gè)倉庫差別只在于管理習(xí)慣。你在本地建一個(gè)總目錄比如叫 ~/my-skills然后把各個(gè)倉庫里的技能目錄拷進(jìn)去保持每個(gè)技能是一個(gè)獨(dú)立文件夾。第三步是打開 Claude Code 的配置文件。這塊不同版本可能略有差異但大方向是一致的在配置里增加一個(gè)路徑指向讓工具啟動(dòng)時(shí)能掃描到這些技能。我的做法是在項(xiàng)目根目錄或者用戶目錄下的 .claude 設(shè)置里加上 skills 路徑然后把工具重啟一遍。重啟之后你在對話里只要提到跟某個(gè)技能相關(guān)的關(guān)鍵詞它會(huì)自動(dòng)去匹配或者你直接問它有沒有某個(gè)技能它也能列出來。裝好之后怎么驗(yàn)證我的土辦法是隨便起一個(gè)新對話在對話里直接說“加載 XX 技能然后按這個(gè)技能的要求幫我做一件事”看它是不是走你預(yù)設(shè)的那套流程。如果它還像沒裝之前一樣自由發(fā)揮八成就是路徑?jīng)]配對或者 SKILL.md 的頭部格式不標(biāo)準(zhǔn)工具沒識別出來。這份排查思路等后面章節(jié)我再細(xì)化。3. 哪些 skills 值得裝以及如何挑選如果說安裝是體力活那挑選就是智商活了。GitHub 上搜“skills”結(jié)果數(shù)量大得離譜而且星球大戰(zhàn)式地分化一部分是真的好用一部分是花架子還有一部分是拿別人代碼改個(gè)名就上傳的。我的選擇標(biāo)準(zhǔn)就三條看作者、看示例、看維護(hù)情況。先說看作者。如果這個(gè)倉庫是某個(gè)知名的 AI 工具配套出的比如 Anthropic 官方推薦的或者作者是某個(gè)語言項(xiàng)目的核心維護(hù)者那質(zhì)量基本有保障。反過來說一個(gè)剛注冊沒幾天、就上傳了一個(gè)萬能大錦集式 skills 的賬號大概率是拿集成的提示詞充數(shù)下載的意義不大。然后是看示例。只有一個(gè) SKILL.md 的倉庫信息量通常不夠。好的 skills 倉庫一般會(huì)帶上幾個(gè)示例輸入輸出甚至有一小段測試用的樣例數(shù)據(jù)。這個(gè)細(xì)節(jié)特別重要因?yàn)榧寄艿男Ч茈y通過閱讀描述判斷只有看它實(shí)際產(chǎn)出的東西你才能知道輸出風(fēng)格適不適合自己。我見過不少倉庫描述寫得很唬人點(diǎn)開示例一看完全是用英文回答的或者全部是空泛的套話這種就直接別折騰了。最后是看維護(hù)。一個(gè)技能能不能長期用取決于作者是否持續(xù)更新。Model 的能力在變工具的調(diào)用規(guī)則也在變今年能用的提示詞半年后可能就變味了。我的經(jīng)驗(yàn)是看一眼最近一次 commit 的時(shí)間超過六個(gè)月沒動(dòng)的除非功能極其封閉穩(wěn)定否則不如自己寫一個(gè)。具體到我個(gè)人常用的大概這么幾類。一是代碼評審類的 skills它會(huì)給 AI 設(shè)定一整套審查規(guī)則比如按可維護(hù)性、性能、安全性分層打分輸出時(shí)帶嚴(yán)重級別標(biāo)注。二是數(shù)據(jù)清洗類的 skills適合做表結(jié)構(gòu)檢查、缺失值統(tǒng)計(jì)配置好之后處理 CSV 效率特別高。三是文檔生成類的 skills它會(huì)要求 AI 按固定模板生成項(xiàng)目說明、接口文檔篇幅和措辭都能控制得住。熱詞里提到的“數(shù)學(xué)建模 skills”“AI 漫劇常用 skills”我也研究過。數(shù)學(xué)建模那類技能本質(zhì)是把建模比賽常用的分析流程比如問題重述、假設(shè)檢驗(yàn)、模型構(gòu)建、敏感性分析固化成一套輸出模板比賽時(shí)確實(shí)能省不少時(shí)間。AI 漫劇那類則更偏向創(chuàng)意生產(chǎn)它會(huì)規(guī)定分鏡描述格式、角色一致性規(guī)則、對白風(fēng)格本質(zhì)上也是把創(chuàng)作者的創(chuàng)作規(guī)范壓縮成提示詞?？梢姴煌I(lǐng)域的 skills 長得不一樣但內(nèi)核邏輯都是“把經(jīng)驗(yàn)?zāi)０寤薄?. 從零寫一個(gè) skill格式、思路和避坑如果你已經(jīng)用了一些現(xiàn)成的 skills下一步自然會(huì)手癢想寫一個(gè)自己的。我鼓勵(lì)你嘗試因?yàn)樽约簩懗鰜淼募寄懿抛钯N合你的習(xí)慣。一個(gè)完整的技能核心就一個(gè)文件SKILL.md。這個(gè)文件通常分兩段頭部是 YAML 格式的元信息正文是 Markdown 格式的指令內(nèi)容。頭部看起來大概是這樣的--- name: code-reviewer description: 用于對前端代碼進(jìn)行系統(tǒng)性審查覆蓋性能、安全性與可維護(hù)性 ---這個(gè) name 和 description 是工具識別技能用的description 尤其關(guān)鍵因?yàn)?AI 在判斷要不要調(diào)用這個(gè)技能時(shí)主要就是靠讀 description 來做語義匹配。你描述得越具體越容易在對話中被正確觸發(fā)。別寫“一個(gè)用于代碼審查的技能”這種大廢話要寫成“審查 React 項(xiàng)目中的組件性能與狀態(tài)管理代碼輸出分級問題列表與修改建議”。正文部分就是你要給 AI 的完整指令。這里我建議按順序?qū)懰膲K內(nèi)容。第一塊寫這個(gè)技能的適用場景和不適用場景。以代碼審查為例你可以說這個(gè)技能面向前端項(xiàng)目的 PR 審查不適用于后端架構(gòu)評審。這樣 AI 遇到不合場景的問題時(shí)不會(huì)硬套模板。第二塊寫執(zhí)行流程。給 AI 一個(gè)固定的動(dòng)作順序比如先通讀代碼并定位關(guān)鍵函數(shù)再按安全、性能、可讀性分層檢查最后生成帶嚴(yán)重級別的報(bào)告。AI 一旦有了明確的步驟就不會(huì)亂來。第三塊寫輸出格式。這是我特別看重的一步格式不固定是很多人寫技能失敗的通病。你應(yīng)該告訴它報(bào)告必須分幾個(gè)章節(jié)每個(gè)問題怎么描述是否給出修復(fù)代碼片段整體用中文輸出還是英文輸出甚至要求它把結(jié)果控制在多少字內(nèi)。格式不設(shè)死AI 就放飛自我這個(gè)技能跟沒寫一樣。第四塊寫負(fù)面約束。比如“不要修改原始代碼”“不要在報(bào)告中評價(jià)代碼作者”“不要輸出鼓勵(lì)性套話”。負(fù)面約束的作用是用顯式的規(guī)則擋住 AI 的自由發(fā)揮實(shí)測下來非常管用。寫完初版之后一定要多做幾輪測試。除非是很簡單的技能否則一次寫對幾乎不可能。你拿著示例數(shù)據(jù)跑一遍看輸出的東西哪里不像話再回 SKILL.md 里補(bǔ)規(guī)則。這個(gè)迭代過程才是真正把技能調(diào)順的必經(jīng)之路。另外有個(gè)細(xì)節(jié)一個(gè) skill 目錄里除了 SKILL.md你也可以放一些輔助文件比如腳本、模板、參考文檔。AI 在處理任務(wù)時(shí)可以查閱這些文件。用得好技能的能力邊界會(huì)大很多比如審查技能里放一份團(tuán)隊(duì)代碼規(guī)范文檔AI 就會(huì)拿它當(dāng)標(biāo)準(zhǔn)去比對。5. 數(shù)學(xué)建模比賽里的 skills真的能提分嗎近兩年“數(shù)學(xué)建模 skills”成了熱門搜索詞很多參賽者想走捷徑。我的看法是skills 在建模比賽里的價(jià)值主要體現(xiàn)在壓縮重復(fù)勞動(dòng)上而不是替代模型思維。先把比賽流程拆開看從讀題、找數(shù)據(jù)、建模、求解、寫論文到答辯 PPT哪一步最耗時(shí)多數(shù)隊(duì)伍會(huì)死在寫論文和做結(jié)果分析上。前者要按組委會(huì)模板輸出大量規(guī)范性文字后者要做不同參數(shù)條件下的敏感性對比。這兩塊恰恰是 skills 最擅長的事情。我見過一套做得不錯(cuò)的數(shù)學(xué)建模 skills它的做法是建立多個(gè)子技能分別負(fù)責(zé)“題目理解與問題重述”“數(shù)據(jù)探索與可視化”“模型結(jié)果表格生成”。每個(gè)子技能都規(guī)定了輸出格式和行文風(fēng)格。比如“題目理解”這個(gè)子技能會(huì)要求 AI 用三句話提煉問題核心、列出約束條件、識別可用數(shù)據(jù)源。這樣的輸出可以直接粘貼進(jìn)論文開頭省下大量調(diào)格式的時(shí)間。但有一點(diǎn)必須提醒技能寫得好不好并不等于模型算得對不對。比賽里最核心的算法設(shè)計(jì)、公式推導(dǎo)、結(jié)果合理性判斷仍然需要人來做。我見過有隊(duì)伍把技能生成的分析報(bào)告直接當(dāng)結(jié)論用結(jié)果把某個(gè)明顯偏離實(shí)際的參數(shù)也寫進(jìn)論文里最后被評委追問得很難看。技能是幫你節(jié)省整理和表達(dá)的時(shí)間不是負(fù)責(zé)產(chǎn)生真正的洞察。如果你要自己組一套建模用的 skills我建議優(yōu)先覆蓋這幾個(gè)方向數(shù)據(jù)清洗與統(tǒng)計(jì)摘要、圖表輸出規(guī)范、論文各章節(jié)寫作模板。這幾項(xiàng)占了比賽流程中可模板化的大部分工作。至于建模思路生成這類偏向創(chuàng)造性輸出的技能效果不穩(wěn)定不如老老實(shí)實(shí)自己讀題想模型。6. 常見的配置問題與排查方法使用 skills 的過程中遇到的絕大多數(shù)問題都集中在“工具沒識別到技能”和“技能加載了但不生效”這兩類。我把這些問題整理成一張排查表能幫你快速定位?，F(xiàn)象可能原因處理辦法對話里完全感知不到技能存在配置路徑?jīng)]寫對或工具沒重啟檢查配置文件中路徑是否存在重啟工具后再試技能能列出但執(zhí)行沒有按規(guī)則走SKILL.md 頭部 YAML 格式損壞檢查 name 和 description 是否規(guī)范確保沒有格式錯(cuò)位同一個(gè)技能有時(shí)生效有時(shí)失效description 寫得過于寬泛匹配不穩(wěn)定改進(jìn) description 的關(guān)鍵詞和適用場景描述技能輸出帶亂碼或路徑錯(cuò)誤輔助文件路徑包含中文字符或空格把技能整體挪到純英文路徑下再試更新技能后還是老行為工具緩存了舊的技能內(nèi)容清除工具緩存或刪除舊目錄重新加載這里想特別提一下“清理 skills”這個(gè)話題。熱詞里提到的 tibo 關(guān)于清理 skills 的方法我總結(jié)下來核心思路就一句話定期刪除不再用或者重復(fù)的技能。很多用戶喜歡瘋狂下載各種技能裝了一堆之后工具匹配時(shí)反而會(huì)被不相關(guān)的描述干擾該觸發(fā)的技能反而不觸發(fā)了。我現(xiàn)在每個(gè)月會(huì)清理一次技能目錄把使用頻率低的移到備份文件夾只保留真正依賴的那幾個(gè)。這樣的好處是匹配更準(zhǔn)啟動(dòng)加載更快排查問題也更容易。還有一個(gè)小經(jīng)驗(yàn)如果你同時(shí)用多個(gè) AI 工具比如既用 Claude Code 也用別的終端工具不同工具對技能目錄的約定不一樣。有的是按文件名識別有的要求寫成特殊的前綴。我踩過坑后學(xué)乖了分別在各自的配置里指向獨(dú)立目錄不要讓兩個(gè)工具共享同一個(gè)技能目錄不然其中一個(gè)工具更新了文件另一個(gè)用的還是舊配置互相干擾。7. 怎么上手最穩(wěn)零基礎(chǔ)也能跑通全流程如果你是第一次接觸 skills我建議不要急著看花里胡哨的熱門技能庫先走一條最穩(wěn)的路找一個(gè)官方示例技能裝好跑通一個(gè)最簡單的例子再自己改一個(gè)句子試試手。這樣能在最小代價(jià)下建立起對“技能到底是怎么起效”的感覺。第一步選定一個(gè)工具。你手頭日常用的 AI 編程工具或終端助手是哪個(gè)就用哪個(gè)。以 Claude Code 為例先確認(rèn)它能正常運(yùn)行然后去官方文檔里找到內(nèi)置 skills 或者示例技能的位置。第二步下載一個(gè)極簡技能。最好是個(gè)只包含一個(gè) SKILL.md 的倉庫別碰那些動(dòng)輒幾十個(gè)技能、還有一堆依賴的庫。第三步按前面第二章節(jié)的步驟安裝配好。第四步用一個(gè)具體的小任務(wù)測試比如“幫我用規(guī)范格式寫一個(gè) TODO 文件”。如果輸出明顯符合技能里預(yù)設(shè)的標(biāo)準(zhǔn)說明整套鏈路是通的。第五步改動(dòng)技能里的一個(gè)輸出格式要求再跑一次感受一下改動(dòng)帶來的變化。做完這五步你對 skills 的掌控力就超過絕大多數(shù)只看過介紹的人了。之后再進(jìn)入自己寫技能的階段一定從需求最痛的場景開始別一上來就想搞個(gè)全能技能。比如你每周都要生成項(xiàng)目周報(bào)那就寫一個(gè)周報(bào)技能規(guī)定好結(jié)構(gòu)、措辭、篇幅。這個(gè)技能幫到你之后你自然知道下一個(gè)該寫什么。就我個(gè)人的經(jīng)驗(yàn)skills 這個(gè)東西門檻不高但天花板很高。你花一晚上把流程跑通再用幾周慢慢迭代自己的技能庫之后每次用 AI 干活的效率都會(huì)有肉眼可見的提升?？刂坪米约旱募寄軘?shù)量保持整理習(xí)慣它就會(huì)變成一個(gè)越用越順手的個(gè)人工具箱而不是擺設(shè)。最后分享一個(gè)小技巧寫 SKILL.md 的時(shí)候多用“必須”“禁止”“如果……則……”這類明確指令少用“可以”“建議”這類模糊詞。AI 對肯定指令的遵循度明顯更高。這句話算是我踩了無數(shù)坑之后最想告訴你的。