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