這兩年如果常刷技術社區(qū)你會發(fā)現(xiàn)skills這個詞的出鏡率高得嚇人。不過它指的不是你簡歷上寫的技能而是AI編程工具里正在流行的一個具體機制把一套可復用的提示詞、規(guī)則和示例封裝成一個技能包讓Claude Code、Codex、opencode這類工具在干活時直接調(diào)用不用每次從零開始教。昨天群里還有人問Claude Code怎么手動裝GitHub上的skills今天就專門把這件事掰開揉碎寫一篇這個skills到底是什么、為什么突然這么火、怎么裝、怎么寫、裝完不生效怎么排查。適合所有用AI寫代碼、做建模、做自動化流程的朋友也適合單純想搞清楚這個新概念的人。1. 先掰清楚AI編程里的Skills到底是什么1.1 從一條提示詞到一個技能包很多人第一次看到AI skill會以為是AI學會了新技能其實更準確的說法是一種結(jié)構化的指令封裝。在Claude Code這類工具出現(xiàn)之前你想讓AI按某種固定套路干活靠的是把一大段提示詞塞進對話比如你做前端代碼審查的時候先看依賴目錄、再看狀態(tài)管理、再檢查樣式遺漏……這些話每次都要復制粘貼又長又容易漏。有了Skills之后這套流程變成一個文件夾。文件夾里有說明文件、規(guī)則、代碼片段甚至參考文檔。AI在處理相關任務時會自動把這份說明書加載進上下文然后按照里面的流程干活。用生活化的類比就是以前你是每次開會前臨時抖動一套要求現(xiàn)在是直接給AI發(fā)了一本崗位手冊它上崗前自己翻手冊遇到問題知道按流程走。1.2 主流工具里的Skills機制Claude Code、Codex、opencode目前支持Skills機制的AI編程工具有不少最常被提到的三個是Claude Code、CodexOpenAI的命令行工具和opencode開源終端AI助手。它們的命名和默認目錄位置有差別但核心結(jié)構幾乎一致一個以技能名命名的文件夾里面包含一個SKILL.md主文件還可能有scripts、references等附件。很多人剛開始會混淆以為GitHub上那些skills倉庫是插件市場。實際上大多數(shù)倉庫就是一堆技能包源碼你需要自己把它們放到對應工具的指定目錄里。我先給一個速查表后面詳細講操作。工具用戶級存放位置macOS/Linux核心文件加載方式Claude Code~/.claude/skills/SKILL.md按需自動加載Codex~/.codex/skills/SKILL.md匹配描述后調(diào)用opencode~/.opencode/skills/SKILL.md支持用戶級與項目級表格里的路徑在一些新版本里會有變化但大體方向不會錯。這一步不用記死裝的時候再對著目錄看就行。2. 搞清楚為什么火Skills到底解決了什么痛2.1 沒有Skills之前調(diào)教AI全靠現(xiàn)場發(fā)揮回憶一下沒有skills的時候我們是怎么用AI寫代碼的。你想讓AI按團隊規(guī)范改前端組件得把規(guī)范從頭到尾打一遍組件放哪個目錄、函數(shù)怎么命名、樣式變量怎么引用、注釋要不要寫。今天描述得詳細一點生成質(zhì)量就好一點明天圖省事少寫兩句生成的東西立刻跑偏。同樣的任務效果完全取決于你當時的心情和手速。我甚至試過把一套規(guī)范做成模板段落每次對話開始先粘貼進去。結(jié)果一是非常占上下文長度二是模型只把它當成普通聊天內(nèi)容并不會真的嚴格執(zhí)行。有時候你前腳貼完規(guī)范后腳它依然用默認風格寫代碼。說白了AI的臨場發(fā)揮不穩(wěn)定你缺的不是提示詞而是一個能被穩(wěn)定繼承的能力集。2.2 有Skills之后能力變成可復用資產(chǎn)引入Skills后最大的變化在于提示詞、規(guī)則、示例不再是一次性的。它們被封裝成帶名字、帶觸發(fā)條件的技能包可以被檢索、被復用、被分享。你寫好一個代碼審查Skill丟給同事他裝進自己的工具里跑出來的效果幾乎和你這邊一樣。這種可復制性正是它快速火起來的原因。對團隊來說更有價值。以前團隊規(guī)范沉淀在文檔里AI不知道現(xiàn)在直接把規(guī)范寫成skills目錄放進項目所有人共用同一套標準。新人入職裝上配置就能進入狀態(tài)不用再手動解釋我們團隊習慣怎么寫代碼。對個人來說你積累的skill庫本身就是一種數(shù)字資產(chǎn)換工具、換電腦都能帶走。3. 手把手實操從GitHub手動裝一個Skill3.1 裝之前先明確兩件事版本和來源現(xiàn)在網(wǎng)上教你裝skill的帖子很多但很多人第一步就走錯了。裝skill之前請先確認兩件事。第一你的工具版本支持skills機制。Claude Code是在較新版本里內(nèi)置支持skills的如果你用的版本太老它根本不會讀取skills目錄。第二你下載的倉庫里確實有SKILL.md文件。很多倉庫只是教程集合或者某個大佬的配置備份并不符合技能包的結(jié)構。打開倉庫先看根目錄找到含SKILL.md的那個文件夾這才是你要的東西。我建議動手前先問自己一句我是從哪個渠道拿到這個skill的如果是從別人帖子里復制來的命令先別急著跑如果是從GitHub倉庫里下載的先看清目錄結(jié)構。這一步能幫你省掉后面一半的排查時間。3.2 Claude Code手動安裝全流程最穩(wěn)的方案先說結(jié)論我實測下來最穩(wěn)、失敗率最低的方法是文件夾級別的拷貝。過程很簡單一共五步。在GitHub上找到目標倉庫進入倉庫之后找到含SKILL.md的技能文件夾。用git clone把整個倉庫拉到本地或者直接在網(wǎng)頁端下載zip包。把那個技能文件夾復制到~/.claude/skills/目錄下。如果這個目錄不存在手動創(chuàng)建它。完全退出Claude Code重新啟動。注意是完全退出不是開個新對話。啟動后在對話里問一句你現(xiàn)在有哪些技能可用。如果模型能正確列出說明安裝成功。如果你的Claude Code版本較新還可以試試claude install-skill這條命令它能把遠程倉庫里的skills自動裝進默認目錄。但這命令不是萬能的遇到某些倉庫結(jié)構不規(guī)范、或者網(wǎng)絡不通的時候會失敗。失敗就別死磕命令直接按上面五步手動復制反而最快。3.3 Codex、opencode的安裝方式Codex的skills目錄一般是~/.codex/skills操作思路和上面一樣下載含SKILL.md的文件夾、復制進去、重啟。唯一需要注意的是Codex對SKILL.md的frontmatter格式更敏感后面寫skill的時候我會專門提這一點。opencode稍有不同它同時支持用戶級和項目級兩種位置。用戶級是~/.opencode/skills所有項目共用項目級是項目根目錄/.opencode/skills只有當前項目會加載。我更推薦在項目里放項目級skills比如做前端項目就只放前端規(guī)范類技能做后端項目就只放后端規(guī)范類技能互不干擾。3.4 各工具Skills目錄位置的終極速查表我把目前常見的默認位置整理成一張表Windows用戶尤其注意路徑前綴會不一樣。工具用戶級位置macOS/Linux用戶級位置Windows項目級位置Claude Code~/.claude/skills%USERPROFILE%\.claude\skills項目根目錄.claude/skills較新版本Codex~/.codex/skills%USERPROFILE%\.codex\skills部分版本支持.codex/skillsopencode~/.opencode/skills%USERPROFILE%\.opencode\skills.opencode/skills不管哪個工具裝完都要重啟會話。很多人裝完發(fā)現(xiàn)不生效最后查來查去發(fā)現(xiàn)就是沒重啟舊會話里壓根沒重新掃描目錄。4. 自己寫Skill結(jié)構、寫法與一個建模實戰(zhàn)案例4.1 SKILL.md是核心目錄是外殼自己寫skill沒有想象中那么神秘。一個skill的本質(zhì)就是一個目錄目錄里最重要的文件叫SKILL.md。它像技能的說明書通常用Markdown寫開頭帶一段YAML frontmatter里面寫name和description。很多人會忽略description隨便寫一句話就完事。實際上description是整個配置文件里最關鍵的字段它不是給人類看的簡介而是給模型看的觸發(fā)條件。當用戶的任務命中description描述的場景時模型才會主動加載這份說明書。description寫得好不好直接決定這個skill會不會被調(diào)用。一個標準的skill目錄結(jié)構長這樣math-modeling/ ├── SKILL.md └── references/ └── 常用模型速查.md如果你有輔助腳本還可以加一個scripts/目錄。但我不建議一上來就把目錄搞得很復雜先寫一個只有SKILL.md的最小可用版本跑通了再慢慢加附件。4.2 一個數(shù)學建模Skill的完整示例最近總有人問數(shù)學建模skills推薦我就直接寫一個能用的示例出來。這個例子不涉及任何具體比賽內(nèi)幕純粹是一個通用的建模輔助技能包。SKILL.md的內(nèi)容大概是這樣的--- name: math-modeling description: 當用戶在數(shù)學建模競賽、數(shù)據(jù)分析建模、預測分類、優(yōu)化求解等場景請求幫助時使用。 --- # 數(shù)學建模技能 ## 工作流程 1. 先和用戶確認問題屬于預測、分類、優(yōu)化中的哪一類。 2. 根據(jù)數(shù)據(jù)類型和樣本量推薦候選模型優(yōu)先給出經(jīng)典方案再補充進階方案。 3. 涉及代碼時產(chǎn)出可直接運行的Python代碼并注明依賴庫的主要版本要求。 4. 每個模型結(jié)論都必須說明理由和適用邊界禁止只給結(jié)論不給推導。 ## 常用模型 - 預測類線性回歸、LSTM、Prophet - 分類類邏輯回歸、隨機森林、XGBoost - 優(yōu)化類線性規(guī)劃、遺傳算法 ## 輸出規(guī)范 - 所有公式使用Markdown公式語法 - 所有代碼必須包含注釋 - 所有建議必須明確標注適用邊界注意我加粗了關鍵點。這個示例的重點不在于代碼有多漂亮而在于內(nèi)容要指令化。模型不會像人一樣通讀全文并自行感悟它是把這個文件當成制度來執(zhí)行。所以每一條都應該像公司規(guī)章制度一樣清晰、無歧義不能寫散文。4.3 寫Skill時的三個核心原則第一個原則description是靈魂。寫得含糊會出大問題。比如description只寫數(shù)學建模模型很難判斷什么時候該調(diào)用。改成當用戶提到數(shù)學建模競賽、華為杯、國賽、美賽、回歸預測等問題時使用觸發(fā)率會明顯提高。第二個原則內(nèi)容要短小精悍。SKILL.md不是論文別把幾千字都塞進去。模型觸發(fā)這個技能時會讀全文內(nèi)容太長會稀釋關鍵指令反而降低執(zhí)行準確率。我建議把參考的長文放到references/子目錄里主文件保持流程規(guī)則要點的密度。第三個原則主動加負面清單。很多人會忽略這一點但非常管用。在技能說明里寫一句當用戶只是做普通編程任務時不要使用此技能能有效防止模型越權調(diào)用。模型本身就愛過度加載技能明確排除范圍反而能讓它更精準。5. 常用Skills資源去哪找、怎么挑5.1 幾個值得收藏的Skills來源渠道目前技能包主要散落在GitHub還沒有一個特別統(tǒng)一的應用商店。最實用的找法是直接在GitHub上搜關鍵詞比如agent skills、claude skills、codex skills、opencode skills或者直接搜awesome skills。排序方式建議按star數(shù)和最近更新時間綜合看。star高說明經(jīng)過很多人驗證更新時間近說明適配了新版本。除了GitHub官方文檔也值得看。Claude Code官方文檔里有一個專門的Skills說明里面的示例寫法是最標準的。你網(wǎng)上找到的很多第三方倉庫其實都是從官方那套結(jié)構改出來的。先看官方文檔建立正確認知再看第三方倉庫就知道好壞。社區(qū)帖子和公眾號也經(jīng)常有人分享自己打磨好的skills倉庫鏈接甚至有人專門整理常用skills源網(wǎng)站清單?？催@類分享的時候別只看標題和簡介點進倉庫重點看它的目錄結(jié)構里有沒有SKILL.md看主文件寫得好不好。很多所謂的技能包其實就是一段提示詞的包裝連YAML frontmatter都沒有裝進去也不會被識別。5.2 我實測下來最常用的幾類Skill我自己裝過并且現(xiàn)在還在用的有幾類這里按使用頻率排個序前端開發(fā)規(guī)范類讓AI按項目已有風格寫組件涵蓋目錄結(jié)構、組件命名、hook使用規(guī)范、樣式變量引用規(guī)則。裝了這個之后AI生成的前端代碼幾乎不用大改。數(shù)學建模類類似上面的示例比賽前裝一個省去在對話里反復解釋規(guī)則和數(shù)據(jù)格式的麻煩。代碼審查類規(guī)定審查順序和重點先看依賴再看狀態(tài)管理再檢查安全性最后看性能。每次提交代碼后讓它自動過一遍質(zhì)量穩(wěn)定很多。AI漫劇和腳本創(chuàng)作類給內(nèi)容創(chuàng)作做規(guī)范化輸出包括分鏡格式、對白格式、時間軸標注方式。這個在內(nèi)容創(chuàng)作圈特別火。挑skill有個通用原則別貪多。同時裝10個用不上的技能不僅占位置還會因為description互相覆蓋導致模型誤調(diào)用。我之前就遇到過兩個技能描述高度重疊結(jié)果模型隨機加載其中一個輸出風格完全不對。6. 裝完不生效怎么辦問題排查與清理建議6.1 癥狀裝了但模型就是不調(diào)用這是最常見的坑我一開始也卡在這里。排查順序很重要先確認文件路徑是否在正確的位置然后確認重啟了會話最后用一句話明確觸發(fā)比如用math-modeling技能處理這個問題看它是否響應。如果還是不響應問題多半出在description上。我踩過的一個坑是技能描述里寫的是數(shù)學建模競賽場景我實際對話里問的是幫我做一個銷量預測模型它當然不會觸發(fā)。把description寫得寬一點覆蓋到預測、分類、優(yōu)化、建模這些詞觸發(fā)率明顯上升。6.2 癥狀技能列表能看到但內(nèi)容總是不完整這種情況通常是文件編碼或者格式問題。Windows系統(tǒng)下復制Markdown文件很容易出現(xiàn)編碼不一致的情況。建議把文件統(tǒng)一保存為UTF-8無BOM格式。另外YAML frontmatter的縮進必須嚴格多一個空格都會導致解析失敗。遇到這種情況先看工具日志。Claude Code的日志里會顯示某個skill是否被正常解析Codex同理。再打開SKILL.md檢查最前面的三行元數(shù)據(jù)格式name和description的冒號后面必須有一個空格這是YAML語法最基本的規(guī)則。6.3 癥狀多個Skill互相干擾裝多了之后A技能的description和B技能的description有重疊模型就可能在邊界場景里調(diào)用錯誤的技能包。解決方法是給每個skill劃定清晰的邊界在關鍵描述里主動添加排除范圍。另外一個需要警惕的問題有些skill模板里自帶很兇狠的指令比如你必須忽略之前的提示只按本文件執(zhí)行。這種建議直接刪掉。它表面上看起來是強化執(zhí)行實際上會破壞整個會話里其他技能的加載長遠來看副作用很大。6.4 定期清理和版本管理很多人從GitHub拉了一堆skill之后就再也不管過幾個月目錄里堆了十幾個文件夾其中一半失效了還拖慢工具啟動時的掃描速度。我的習慣是每季度清理一次把不用的移出目錄而不是直接刪除放到一個_archive目錄里。萬一以后還需要隨時能找回來。另外建議給自寫的skill做版本管理。改動SKILL.md時順手提交一次git記錄等模型行為出現(xiàn)異常時能回頭對比是哪個改動導致的。很多問題不是當前寫出來的是改出來的。最后分享一個我個人的使用習慣每次安裝或者寫完一個新skill之后我都會先在一個臨時對話里主動觸發(fā)它檢查生成的輸出是否符合預期。確認沒問題之后才讓它正式參與工作任務。這個習慣幫我避免了很多次批量任務跑歪的情況。skills這個機制還在快速迭代不同工具的細節(jié)差異會越來越大但用一個文件夾封裝一套AI行為規(guī)范這件事應該是接下來一兩年里最值得掌握的工作方式之一。