最近大半年AI編程圈里最熱門的詞除了MCP就是Skills。你要是用Claude Code或者Codex寫代碼多多少少都刷到過“裝了某個skill之后AI寫前端速度快了一倍”之類的帖子。我自己從2025年Q3開始重度折騰skills前后裝了幾十個有的一裝就香有的裝完就吃灰中間踩的坑攢了一籮筐。今天就把這些經(jīng)驗一次性倒干凈skills到底是什么、怎么手動裝GitHub上的skills、怎么寫自己的skill、數(shù)學(xué)建模和AI漫劇這些場景里怎么玩、最后怎么清理維護。新手照著操作能跑通老手也能撿幾個我花時間換來的細(xì)節(jié)。1. Skills到底是什么一次說清定位、結(jié)構(gòu)與運行邏輯1.1 一個skill包拆開來看是什么先直接點破一個skill在文件系統(tǒng)里就是一個目錄。目錄里必須有入口文件SKILL.md可選assets、scripts、references等子目錄。SKILL.md內(nèi)部用YAML frontmatter聲明name和description后面是自由Markdown正文正文里可以寫工作流程、輸出模板、注意事項。我隨便扒一個GitHub上熱門倉庫的典型結(jié)構(gòu)my-skill/ ├── SKILL.md ├── scripts/ │ └── check_env.py └── references/ └── best-practices.mdClaude Code的agent skills機制會在對話時掃描這些目錄Codex類似OpenCode也支持。關(guān)鍵點在于description是常駐在模型上下文里的而SKILL.md正文只有在任務(wù)觸發(fā)時才被完整加載。這意味著什么同樣一個能力用skill比把一整段提示詞塞進system prompt要省token而且觸發(fā)更精準(zhǔn)。這也是為什么現(xiàn)在的AI編程工具都在推skills而不是讓你繼續(xù)寫幾百行的system prompt。1.2 為什么偏偏是SKILL.md這種設(shè)計要理解這個設(shè)計先得明白模型上下文是稀缺資源。你如果每次把一份幾千字的專業(yè)流程全量塞進對話模型很容易被無關(guān)信息干擾中間部分還會被遺忘就是所謂的lost in the middle問題。Skills走的是漸進式披露progressive disclosure思路先用一小段description描述“什么時候用、能干什么”讓模型判斷要不要打開這個skill。一旦打開正文再逐步引導(dǎo)它讀取references、調(diào)用scripts。這個思路本質(zhì)上就是lazy loading——標(biāo)簽常駐內(nèi)容按需加載。我實際做過對比同一個代碼評審流程寫在system prompt里大概多消耗30%的上下文觸發(fā)穩(wěn)定性還不如用一個skill。大模型的注意力是有限的你給它越少噪音它執(zhí)行主任務(wù)就越不走樣。注意description不是給你看的是給模型看的。你寫“這是數(shù)學(xué)建模全面助手”這種廢話模型根本不知道什么時候該調(diào)用它。好的description要包含觸發(fā)條件、適用任務(wù)、能力邊界后面我會給示例。1.3 Skills和MCP不是競爭關(guān)系很多人一上來就問“有MCP了還要skills干嘛”我理解這種疑問但它倆定位完全不同。MCP更像外接的“手”——通過工具調(diào)用幫模型拿數(shù)據(jù)、操作外部系統(tǒng)比如讀數(shù)據(jù)庫、調(diào)API、操作瀏覽器。而skill更像是“大腦里的操作手冊”——告訴模型按什么流程、什么標(biāo)準(zhǔn)去完成一類任務(wù)。你可以用MCP讓模型讀取某個項目的代碼再用一個code-review skill指導(dǎo)它按你的規(guī)范去評審兩者配合非常順。正確姿勢不是二選一而是先把skill層做厚再按需接MCP。我在實際工作流里MCP工具不超過五個但skill會維持十個左右覆蓋高頻重復(fù)任務(wù)。2. 手動安裝GitHub上的Skills三種主流工具的完整實操2.1 Claude Code里最省事的方式plugin marketplace如果GitHub倉庫按Claude Code插件規(guī)范組織也就是根目錄有.claude-plugin/marketplace.json那安裝是命令行級的。在Claude Code里執(zhí)行/plugin marketplace add owner/repo /plugin install skill名marketplace.json會聲明這個倉庫里有哪些plugin、哪些skill、各自的路徑。裝完執(zhí)行/plugin status能看到清單。這種方式好處是后續(xù)拉更新方便缺點是需要倉庫本身按規(guī)范組織。很多隨手分享的skill倉庫并不符合這時候就得手動裝。2.2 真正的“手動裝”直接把skills目錄拷進去很多倉庫其實就是純skills集合沒有marketplace.json。這時候不需要插件市場手動拷貝就行。核心邏輯就是把每個skill目錄放進Claude Code的skills搜索路徑。用戶級路徑一般是在~/.claude/skills/項目級路徑是.claude/skills/項目級優(yōu)先級更高。操作步驟把倉庫clone到本地找到里面所有包含SKILL.md的目錄一般是一級或二級目錄把需要的skill目錄完整復(fù)制到~/.claude/skills/下或者復(fù)制到當(dāng)前項目的.claude/skills重啟Claude Code會話用skill描述里的任務(wù)動詞發(fā)起請求看是否觸發(fā)這里我踩過一個很典型的坑只復(fù)制了SKILL.md沒把scripts、references一起復(fù)制結(jié)果skill能識別但運行時找不到腳本。所以復(fù)制的時候要整個目錄一起拷千萬別精簡。Codex和OpenCode的機制類似無非是路徑不同一般都在各自配置目錄下比如~/.codex/skills/、~/.opencode/skills/不同版本可能有差異但核心思路完全一致目錄加SKILL.md。2.3 安裝后怎么驗證真的生效了很多人裝完說“沒看到效果”其實不是skill的問題是驗證方法不對。我建議三步走確認(rèn)路徑對在對應(yīng)工具里查看skills列表或者plugin status開一個干凈會話用description里的觸發(fā)詞發(fā)起任務(wù)比如裝的是代碼評審skill就直接說“幫我review一下這段代碼”別用模糊的“幫我看看”觀察模型輸出結(jié)構(gòu)是否變化生效時它通常會按skill規(guī)定的章節(jié)、維度輸出如果完全沒變化多半是沒識別到如果部分生效多半是description寫得不夠準(zhǔn)導(dǎo)致模型觸發(fā)不穩(wěn)定。先分清是哪一種再對癥下藥。3. 自己動手寫Skill一份能用的SKILL.md是怎么誕生的3.1 先寫description決定這個skill由誰觸發(fā)整個SKILL.md里最影響成敗的就是frontmatter。給你一個我自己在用的模板--- name: math-modeling-guide description: 數(shù)學(xué)建模競賽解題流程助手。當(dāng)用戶需要完成數(shù)學(xué)建模題目、選擇模型、撰寫建模論文時使用。覆蓋問題分析、模型選擇、求解、結(jié)果檢驗、論文結(jié)構(gòu)五個階段。不適合純數(shù)值計算。 ---name保持簡短英文小寫加連字符description才是靈魂。我見過太多人的skill不生效都是因為description把“是什么”寫得很華麗卻沒有寫“什么時候用”。模型靠description判斷是否調(diào)用skill所以觸發(fā)指令要明確邊界也要明確否則它會在不該用的時候硬套該用的時候反而漏掉。3.2 正文按流程寫讓模型一層層往下讀正文不要一口氣把全部細(xì)節(jié)倒出來。最好的寫法是先給overview再分階段給指令復(fù)雜的部分丟到references里。拿數(shù)學(xué)建模skill舉例正文可以這樣組織階段一問題重述與假設(shè)要求先列出建模目標(biāo)、約束條件、數(shù)據(jù)情況階段二模型選擇按數(shù)據(jù)類型和問題類型給出決策樹階段三求解步驟指明用什么工具、腳本怎么調(diào)階段四結(jié)果檢驗包括敏感性分析和誤差指標(biāo)階段五論文結(jié)構(gòu)給出章節(jié)模板每個階段用二級標(biāo)題分隔模型讀到哪一步就執(zhí)行哪一步不會因為一次塞太多導(dǎo)致執(zhí)行混亂。3.3 加腳本和參考資料讓skill真正能落地純文本的SKILL.md只能約束思考方式但很多任務(wù)需要實際執(zhí)行。比如建模里要算熵權(quán)法、灰色關(guān)聯(lián)度你可以寫一個Python腳本放在scripts/下SKILL.md里用bootstrap聲明依賴--- name: entropy-weight description: 計算熵權(quán)法指標(biāo)權(quán)重。當(dāng)用戶需要做客觀賦權(quán)、計算指標(biāo)權(quán)重時使用。 bootstrap: python scripts/check_env.py ---或者直接在正文里指示模型當(dāng)進入模型求解階段時運行scripts/entropy_weight.py。這樣skill就從“提示詞”變成了真正的“工具包”。依賴要寫清楚腳本開頭做環(huán)境檢查缺庫就報清晰錯誤方便排查。注意skill不是越復(fù)雜越好。一個skill只干一件事復(fù)雜任務(wù)拆成多個skill互相配合維護起來比自己騙自己好用得多。我一開始寫過一個巨大的“全能開發(fā)助手”skill后來發(fā)現(xiàn)模型經(jīng)常只觸發(fā)一半改成幾個小skill之后穩(wěn)定多了。4. 實戰(zhàn)場景數(shù)學(xué)建模、前端開發(fā)與AI漫劇里怎么用Skills4.1 數(shù)學(xué)建模從“會聊天”到“按套路出活”數(shù)學(xué)建模比賽包括華為杯這種研究生競賽最大的痛點不是AI不會做而是AI輸出太散。每個隊伍都要經(jīng)歷問題分析、模型選擇、求解、檢驗、論文撰寫如果讓AI自由發(fā)揮它的回答每次都不一樣風(fēng)格和深度完全不可控。用skill把這些環(huán)節(jié)固化成流程后AI的輸出就穩(wěn)定得多。社區(qū)里流傳的數(shù)學(xué)建模skills推薦做得好的基本都是把常見模型比如層次分析、回歸、優(yōu)化、微分方程、神經(jīng)網(wǎng)絡(luò)以及對應(yīng)適用條件做成了決策表再配一套論文寫作模板。我自己在實戰(zhàn)里的做法是先裝一個模型選擇skill用它快速鎖定問題類型再讓一個論文結(jié)構(gòu)skill接管后續(xù)寫作。這樣上下文切換干凈不容易串味。之前也試過一個skill搞定全流程結(jié)果就是前后風(fēng)格割裂效果反而不如拆分。4.2 前端開發(fā)把視覺需求變成代碼的流水線前端大概是skills最早火起來的場景。從設(shè)計稿轉(zhuǎn)代碼、響應(yīng)式布局檢查、組件測試生成都有現(xiàn)成的包。superpower skills里的視覺拆分是很典型的一個。我自己常用的有兩個一個負(fù)責(zé)從截圖描述UI細(xì)節(jié)輸出風(fēng)格指南一個負(fù)責(zé)代碼審查按性能、可訪問性、可維護性輸出修改建議。這兩個配合起來等于給Claude配了個前端質(zhì)檢員。如果你是寫React或Vue的強烈建議至少裝一個能產(chǎn)出設(shè)計規(guī)范的skill。實測下來設(shè)計還原度和代碼質(zhì)量都明顯上一個臺階模型不會再一腳踩進“憑感覺配色”的坑里。4.3 AI漫劇創(chuàng)意生成也需要流程化AI漫劇這種內(nèi)容生產(chǎn)場景表面看是創(chuàng)意活實際極其流程化定角色、寫分鏡、生成畫面描述、配文案。圈子里的常用skills本質(zhì)上是把漫畫分鏡提示詞做成了可復(fù)用模板。比如角色一致性skill會要求第一步定義角色卡第二步輸出多視角參考圖描述第三步給分鏡腳本模板。這樣做的好處是團隊協(xié)作時每個人用同一套skill產(chǎn)出的風(fēng)格和格式高度統(tǒng)一省掉大量后期對齊成本。我看了幾個AI漫劇常用skills發(fā)現(xiàn)它們的共同點都是“把創(chuàng)作拆成固定步驟固定模板”你只要記住任何重復(fù)性的創(chuàng)作流程都可以沉淀成skill。5. 推薦技能庫與維護清理別把家底裝成垃圾堆5.1 值得關(guān)注的幾個開源技能庫聊幾個我在GitHub上真裝過、社區(qū)熱度比較高的obra的superpowers我給它的定位是“流程啟動器”里面每個skill都教模型按特定步驟推進任務(wù)比如深度研究、代碼調(diào)試、任務(wù)規(guī)劃。它不直接給你答案而是教AI怎么一步步想。適合當(dāng)?shù)讓蛹寄軒?。typesafe的ai skills偏工程化很多skill和主流開發(fā)框架強相關(guān)適合做后端和全棧的開發(fā)者。GitHub上有專門倉庫分類清晰裝前先看目錄結(jié)構(gòu)。社區(qū)合集類像codex nature skills、cola skills這類通常是網(wǎng)友按自己工作流整理的集合優(yōu)點是場景具體缺點是質(zhì)量參差。安裝的時候別整個倉庫全裝只挑跟自己的工作流匹配的。我一開始見啥裝啥最后光skill目錄就幾百兆AI反而變笨了——可選方案太多模型頻繁誤觸發(fā)輸出變得很“飄”。5.2 定期清理tibo的清理思路我也照著做過清理skills這件事我之前看到tibo分享過一套方法照著做了一遍非常實用先備份整個skills目錄防止刪錯打開最近一個月的工作記錄統(tǒng)計哪些skill被觸發(fā)過把從沒觸發(fā)過的skill先移出主目錄放到retired目錄過兩周確認(rèn)不影響工作后再徹底刪除還在用但有重疊的skill合并同類項這套思路看起來簡單但比憑空看文件名猜用途靠譜得多。我的習(xí)慣是每季度做一次每次都能刪掉至少三分之一從來沒觸發(fā)過的僵尸skill。別心疼那些吃灰的收藏留著它們只是給模型制造噪聲。5.3 多工具共用時的注意事項如果你同時用Claude Code、Codex、OpenCode同一個倉庫的skills可能要放在不同目錄格式也可能有差別不要想當(dāng)然認(rèn)為完全通用。我的做法是在本地建一個skills-dev目錄集中管理源碼用腳本按目標(biāo)工具復(fù)制到對應(yīng)目錄改完一處同步三處。別看這個動作小能避免“在Claude Code里更新了Codex那邊還在用舊版”這種低級但極常見的問題。6. 常見問題與排查技巧實錄6.1 裝了沒反應(yīng)90%出在三個地方先說結(jié)論。第一路徑不對或者SKILL.md文件名大小寫不一致系統(tǒng)壓根沒掃描到。第二frontmatter格式錯了YAML解析失敗整個文件被忽略。第三description寫得像產(chǎn)品宣傳語模型判斷不了什么時候用。排查時先看路徑再看語法最后換一個帶明確觸發(fā)詞的指令測試。不要一上來就懷疑工具本身不行我見過太多人把鍋甩給AI其實問題就出在skill文件本身。6.2 多個skill沖突時怎么處理當(dāng)兩個skill的觸發(fā)條件高度重合時模型會猶豫甚至同時觸發(fā)輸出就會很擰巴。解決辦法是給description加邊界詞比如一個寫“適用于前端項目評審”另一個寫“適用于Python項目評審”讓它們隔離。如果仍然沖突就直接合并成一個skill內(nèi)部用條件分支區(qū)分場景。記住一個原則skill不是越多越好而是邊界越清晰越好。6.3 腳本依賴和權(quán)限問題帶scripts的skill最容易翻車。典型情況Python腳本用了某個庫但環(huán)境沒裝腳本沒有可執(zhí)行權(quán)限Windows環(huán)境下shell腳本無法運行。我在寫skill時會在腳本開頭做環(huán)境檢查并給出人類可讀的錯誤提示同時所有腳本都顯式設(shè)置執(zhí)行權(quán)限。如果一個skill要給別人用務(wù)必在SKILL.md里寫清楚依賴清單否則別人裝完跑不起來體驗會非常差。6.4 常見問題速查表現(xiàn)象可能原因快速處理完全不生效SKILL.md不在掃描路徑內(nèi)檢查skills目錄位置和文件名大小寫偶爾生效description觸發(fā)詞不明確重寫description加入任務(wù)動詞和邊界輸出結(jié)構(gòu)混亂多個skill觸發(fā)條件沖突給description加場景邊界或合并skill腳本報錯依賴缺失或無執(zhí)行權(quán)限安裝依賴檢查shebang設(shè)置執(zhí)行權(quán)限上下文變大skill正文過長或常駐精簡正文把細(xì)節(jié)移到references更新后沒變化舊進程未重啟重啟會話確認(rèn)加載了新路徑踩過這么多坑之后我對skills的判斷是這樣的它不會取代MCP也不會取代工程經(jīng)驗但它把“如何讓AI穩(wěn)定輸出”這件事從玄學(xué)變成了工程。你完全不用追求裝幾十個skill真正好用的通常是那幾個跟你工作強相關(guān)的。先從手動裝一個GitHub上的skill開始跑通之后試著自己寫一個你會發(fā)現(xiàn)AI協(xié)作的質(zhì)量會有一個明顯的跳躍。哦對了最后再分享一個小技巧本地維護skills時把SKILL.md和腳本全部放進Git倉庫管理每次改動用commit記錄出問題隨時回滾。我第一次因為改壞一個腳本又找不到原版硬是重寫了半個下午從那以后就老老實實上Git了。