1. 從熱詞到剛需為什么“skills”突然成了AI圈的頂流這段時間AI圈里“skills”這個詞的熱度一路飆升GitHub上相關的倉庫、教程、官方文檔被反復討論吳恩達的Agent技能教程PDF也在社群里瘋狂流傳。說實話我第一次看到這個詞刷屏的時候心里是有些困惑的——這不就是“技能”的英文單詞嗎AI領域早就有的概念怎么突然又火起來了后來仔細扒了一圈才明白這次討論的“skills”不是泛泛而談的技能培養(yǎng)而是指大模型Agent和編程助手比如Claude Code、Codex、OpenCode、Cursor里的一個具體功能模塊。簡單來說它是一套預定義好的能力封裝讓AI在特定場景下按照固定流程、固定工具、固定參數(shù)去完成某類任務比如“讓Claude生成PPT”“讓Codex分析整個項目結構”“用AI做前端頁面設計稿還原”等。這套邏輯之所以能在最近集中爆發(fā)有一個很關鍵的原因大模型本身的“聰明”已經夠了但“靠譜”遠遠不夠。你讓AI自由發(fā)揮寫代碼它可能寫得不錯但風格不一致讓它分析項目它可能東看兩眼西看兩行抓不住重點。Skills本質上就是給這些聰明的模型裝上一套“標準化作業(yè)手冊”告訴它遇到什么場景該調什么工具、按什么順序、輸出什么結構。理解了這層邏輯你就明白為什么搜索詞里會有一堆“skills推薦”“skills如何開發(fā)”“claude code skills官方文檔”之類的訴求了。這篇文章我就不繞圈子了直接把我這段時間踩過的坑、驗證過的方法、以及從理論到實戰(zhàn)的完整路徑都整理出來給正準備上手skills的讀者一條能直接抄作業(yè)的路線。2. 先搞清楚“skills”到底是什么2.1 不同工具里的skills名字相同但實現(xiàn)有差異在深入操作之前我強烈建議你先建立一個認知框架skills這個概念在不同工具體系里的定位和實現(xiàn)方式并不完全一樣。這就好比“插件”在Chrome、VS Code、WordPress里都是擴展功能的但API、文件和運行機制完全不同。我自己日常用得比較多的是Claude Code、Codex和開源的OpenCode這三個工具對skills的理解就各有側重Claude Code的skills以.claude/skills/目錄下的Markdown文件通常叫SKILL.md為核心每個skill文件夾里可以附帶腳本、模板和參考文檔。觸發(fā)方式既有自動匹配也可以手動/skill-name調用。Codex的skills早期更依賴.codex/skills.toml這種配置文件來聲明能力和依賴后來也在往Markdown文件的模式上靠攏整體識別邏輯比較強調“項目內嵌配置”。OpenCode的skills走的是相對自由的開源路線很多社區(qū)貢獻者把skills做成獨立的倉庫里面有完整目錄結構和說明文檔用起來更像“可插拔的擴展包”。這個差異乍一看會增加學習成本但往好處想核心思路是一致的都是把某個高頻任務的最佳實踐沉淀成一個個文件讓AI在需要時能按圖索驥地執(zhí)行。2.2 skills和MCP工具是“上下級”關系很多人在搜“skills如何調用mcp工具”這個問題問到點子上了。我打個比方MCPModel Context Protocol是給AI提供“手”的工具比如讓它能查數(shù)據庫、操作瀏覽器、訪問外部API而skills是給AI提供“操作手冊”的流程告訴它遇到什么場景該用哪只手、先用哪根手指、按什么順序來。所以一個完整的skills往往是一個**“流程框架工具調用組合”**。比如我自己做了一個“網頁查資料并整理報告”的skill里面就聲明了主任務根據主題做深度資料調研并輸出結構化報告工具依賴WebSearch MCP工具、WebFetch MCP工具執(zhí)行流程先拆解主題關鍵詞 - 多輪搜索收集來源 - 抓取關鍵頁面 - 交叉驗證 - 按固定格式輸出這個skill本身不包含工具實現(xiàn)它只負責“調度”。MCP工具則是獨立的Server通過配置暴露出來。你在skill文件里寫明需要哪些工具、怎么用AI讀取后就能精準調用。2.3 為什么說skills是“superpower skills”搜索結果里頻繁出現(xiàn)“superpower skills”這個詞很多博主和分析師用它來形容這一波skills熱潮的價值。我個人非常認同這個定性但想補充一個更實際的角度skills的價值不在于讓AI變得更“聰明”而在于讓AI在特定任務上變得“可預期”。舉個很直觀的例子。用Cursor做前端開發(fā)的時候如果不加任何約束你讓它生成一個按鈕組件它每次生成的命名風格、代碼組織、樣式方案可能都不一樣運氣好時很驚艷運氣差時就是災難。但如果我給Cursor配置了一套“前端組件開發(fā)skill”里面規(guī)定了項目前綴、樣式方案、TypeScript類型規(guī)范、文件組織方式AI生成的結果就會穩(wěn)定在80分以上。這不是模型能力提升了而是我的經驗被沉淀到了skill文件里AI在執(zhí)行時“繼承”了我的經驗。這一點對個人開發(fā)者尤其重要因為它意味著你不需要每次重復解釋需求。你的最佳實踐、項目規(guī)范、代碼偏好都可以固化到skills里一勞永逸。3. 動手開發(fā)一個skills前需要準備什么3.1 先想清楚“這個skill解決什么問題”大多數(shù)人上手skills容易犯的一個錯就是一上來就找模板、看文檔、寫配置結果做出來一個“什么都能干但什么都沒干好”的廢物技能。我自己第一版skills就犯了類似的毛病目標描述寫了一大段最后AI執(zhí)行時無所適從。我現(xiàn)在做skills之前一定會先回答三個問題這個任務是不是高頻重復的如果三個月才用一次沒必要做成skills直接對話描述需求就行。這個任務的結果是不是有固定預期比如“生成PPT大綱”就比“幫我寫點東西”更容易沉淀成skill因為輸出格式可以明確定義。這個任務是否需要固定的工具組合如果需要搜索引擎、數(shù)據庫、瀏覽器等多種MCP工具協(xié)同做成skill能大幅減少溝通成本。以我最近做的“數(shù)學建模報告生成skills”為例這個想法的來源就是競賽期間反復要做同一套流程讀題、拆解問題、確定模型、寫代碼求解、輸出論文。每個環(huán)節(jié)單獨讓AI做都行但每次都重新描述需求、重新指定輸出格式太浪費時間了。做成skill之后整個流程被固化成一條流水線每次只需要丟題目進去就能得到完整的工作流。3.2 了解你要用的工具生態(tài)在動手之前你得先清楚你的目標平臺支持什么樣的配置方式。這里有三個層面的準備了解核心目錄結構比如Claude Code的.claude/skills/Codex的.codex/你得知道skill文件應該放在哪、命名規(guī)則是什么。了解skill描述文件的寫法絕大多數(shù)是Markdown格式但不同工具對FrontmatterYAML頭部、正文結構、關鍵詞匹配的解析有差異需要參考對應官方文檔。了解本機環(huán)境的MCP工具配置如果你計劃讓skill調用外部工具得先把MCP Server裝好、配置好。否則skill寫完了AI想調工具卻調不到那這個skill就是個空架子。我就踩過一個很典型的坑有一次寫了一個“滲透測試信息收集skill”里面聲明了需要調用一個漏洞庫查詢API但當時那臺測試機上根本沒配這個MCP Server。結果AI每次執(zhí)行到查詢環(huán)節(jié)就卡住要么假裝成功實際上沒調要么報錯。后來在skill的說明里特意加了一句“執(zhí)行前檢查工具可用性如果不可用則跳過該環(huán)節(jié)”才把這個坑填上。3.3 從模仿優(yōu)秀開源項目起步關于“開發(fā)自己的skills”我的建議是先別急著發(fā)明先學會借鑒。GitHub上已經有不少高質量的skill倉庫比如baoyu的技能包、mattpococks skills、還有各種社區(qū)整理的“awesome claude skills”合集。花一晚上時間把這些倉庫里star數(shù)高的skill挨個打開看看你很快就能摸清幾個共通的寫法規(guī)律Frontmatter必須精準name名稱、description描述、when_to_use何時使用這幾個字段是AI判斷“什么時候該調用我”的關鍵寫得越具體自動觸發(fā)越準確。正文步驟要結構化好的skill絕對不是寫一段話完事而是用有序列表、清晰的分步說明、具體的輸出模板來約束AI的行為。附帶的示例文件極重要很多優(yōu)秀skill會帶若干example比如輸入樣例、輸出樣例、參考代碼這些比任何文字說明都更能框定AI的輸出風格。我個人的第一個生產級skill——一個“圖片還原設計稿給前端開發(fā)”的實用skill就是參考了一個開源repo的寫法改造出來的。原版只支持基礎還原我加了一個“移動端適配檢查”子模塊在skill里補充了一套移動端布局審查清單結果生成質量明顯提升了一個檔次。4. 手把手做一個“測試用例生成skills”這部分我直接以“測試用例生成”為例完整走一遍開發(fā)流程。如果你有自己的目標場景把核心步驟對應替換即可。4.1 定義需求與使用場景這個skill面向的典型場景是你在開發(fā)一個Web項目經常需要針對接口或頁面寫測試用例。每次手寫用例需要翻需求文檔、核對字段邊界、覆蓋異常場景費時費力還容易漏。用這個skill你只需要提供一段需求描述或接口定義AI會按預設的框架生成一套規(guī)范的測試用例。我在skill描述里特意強調了“適合對已有功能模塊做補充測試也適合新接口的用例初稿”這樣可以避免AI在不該用的時候被誤觸發(fā)。4.2 編寫SKILL.md核心文件這個skill的核心文件結構大致如下我給的是簡化版本你實際使用時可按需擴充--- name: test-case-generator description: 根據需求描述或接口定義生成結構化測試用例覆蓋功能、邊界、異常、安全等場景。 when_to_use: 用戶需要為Web接口或功能模塊編寫、補充測試用例時使用 --- # 測試用例生成指南 ## 輸入要求 用戶需提供以下至少一種信息 - 接口定義路徑、方法、參數(shù)、返回結構 - 功能需求描述角色、行為、規(guī)則 ## 執(zhí)行步驟 1. 分析輸入內容提取核心業(yè)務規(guī)則 2. 按等價類劃分法設計正常場景用例 3. 按邊界值分析法補充邊界場景 4. 補充異常場景和安全性場景如未授權訪問、參數(shù)注入 5. 按模板輸出測試用例文檔 ## 輸出模板 每一條用例包含用例編號、用例標題、前置條件、測試步驟、測試數(shù)據、預期結果、優(yōu)先級。 ## 注意事項 - 如果輸入信息不足先輸出問題清單不要猜測需求 - 覆蓋HTTP狀態(tài)碼語義區(qū)分4xx和5xx的斷言邏輯 - 對敏感字段密碼、Token的斷言只能校驗格式不能寫入真實值4.3 加入示例提升穩(wěn)定性很多人寫skills會忽略示例的價值但我在實測中發(fā)現(xiàn)AI對示例的依賴程度遠超我們的想象。同一個skill有示例和沒示例輸出質量能差出一大截。原因是LLM非常擅長模仿模式你的示例越接近真實的輸入輸出它生成的用例就越符合你的預期。我當時的做法是在skill同目錄下放了一個examples/文件夾里面包含example_input.json一個模擬“用戶注冊接口”的接口定義example_output.md基于該接口生成的完整測試用例edge_cases.md一組容易被遺漏但值得關注的特殊場景有了這幾個文件AI在生成時就有了“參照物”不論措辭風格還是覆蓋維度都不會跑偏。4.4 用命令行驗證skill效果配置好之后你需要實際驗證一下。以Claude Code為例在項目目錄下啟動后輸入一句觸發(fā)描述比如請幫我為這個用戶登錄接口生成測試用例如果skill文件寫得好AI會給出類似“我將使用test-case-generator技能來生成測試用例”的提示然后按照你預設的格式輸出。如果AI沒觸發(fā)你需要檢查description和when_to_use字段的描述是否夠精確或者手動調用skill看看問題出在哪。5. 我在實際使用中遇到的坑和心得5.1 寫得太“全”反而不好用第一次做skills的人很容易陷入一個誤區(qū)恨不得把自己腦內所有經驗都寫進去。我試過把一個skill的描述文件寫到幾千字幾乎涵蓋所有可能的情況結果AI在執(zhí)行時反而猶豫不決頻繁跳流程輸出質量極不穩(wěn)定。后來我學到的經驗是skills不是為了窮盡所有場景而是為了固定核心動作。你只需要把最關鍵、最不能出錯的幾個步驟和規(guī)范寫進去剩下的交給AI臨場發(fā)揮。把skill想象成新員工入職手冊不是把所有知識都塞進去而是告訴他標準動作和紅線具體干活時他自己會想辦法。5.2 版本管理一定不能省skills是文本文件天然適合放進Git倉庫管理。我一開始偷懶直接在項目目錄里改來改去結果有一次調整輸出模板把整個方案改崩了回滾都回不去?，F(xiàn)在我的所有skills都會放獨立的repo或者至少在項目里單獨建目錄每次改動都提交還能寫清楚變更原因。這套做法的額外好處是你可以建一個自己的skills合集倉庫在不同項目里通過軟鏈或復制的方式復用同一套技能。我目前維護的skills倉庫已經有三四十個模塊從代碼審查、數(shù)據庫遷移到React組件開發(fā)都有換新項目的時候拉下來一套配置就能用。5.3 不同模型的skill兼容性測試過程中我還有一個特別真實的體感同一個skill在不同模型上的表現(xiàn)差異巨大。因為skill本質上是用自然語言寫的而不同模型對自然語言的指令遵循程度不同。Claude系模型對這類結構化指令的遵循度很高執(zhí)行起來像模像樣而有些開源小模型讀了skill經?！白杂砂l(fā)揮”該走流程時直接跳步。如果你的工作流必然要跨模型我的建議是在skill文件里加入一條“自我檢查”指令讓AI在輸出前主動對照skill中的要求和模板做一次排查。這種做法能明顯提升弱一點模型的下限。6. 從使用到制作如何進入“skills創(chuàng)作者”狀態(tài)關于“skills creator”這個話題現(xiàn)在社區(qū)討論的很多但真正能持續(xù)輸出高質量skill的人并不多。結合我的實踐我總結了幾個從“使用者”轉變成“創(chuàng)作者”的關鍵動作。首先保持“痛點驅動”的創(chuàng)作模式。不要為了做skill而做skill我?guī)缀跛械膕kill都來自真實項目里“被AI的重復勞動惹毛了”的瞬間。比如連著三天跟AI說“按公司的代碼規(guī)范生成組件”說到煩了就花半小時把它固化成一個skill從此一勞永逸。這種來源的skill一定實用因為它是從真實需求里長出來的。其次持續(xù)吸收社區(qū)養(yǎng)分。GitHub上的熱門skills倉庫隔三差五就會更新多去翻翻別人的設計思路。我記得有個老外寫的“web前端 mcp skills”合集把瀏覽器操作、截圖還原、樣式調試等多個mcp工具封裝成了一整套前端開發(fā)流程對我啟發(fā)很大?？戳怂鸾鈫栴}的方式我才意識到原來skill不單是“提示詞模板”更可以是一套工具鏈的編排邏輯。最后敢于在細節(jié)里打磨。我做數(shù)學建模skills的時候最開始只寫了流程框架AI生成的求解代碼質量一般后來我仔細想了想把算法選型建議、性能約束、輸出圖表格式都補了進去效果馬上不一樣了。這個迭代過程才是最提升功力的地方。7. 不同平臺和場景下的skills實戰(zhàn)推薦如果你已經上手了基礎技能不妨看幾個我實測下來比較實用、也是許多熱詞背后大家常問的場景7.1 前端開發(fā)方向“Cursor 前端使用的skills有哪些”是很多人關心的。以我目前的配置為例一個完整的前端開發(fā)skills家族可以包括頁面還原skill輸入設計稿圖片或地址輸出可用的React/Vue組件組件開發(fā)skill根據屬性需求生成風格統(tǒng)一的組件附帶Storybook文檔響應式適配skill在已有頁面基礎上做移動端適配處理和測試實測下來組件開發(fā)skill帶來的收益最明顯因為它的“標準動作”最多——命名、樣式變量、props類型、測試用例、文檔每一個規(guī)范都可以在文件里寫死AI生成一次就能通過代碼審查節(jié)省了大量來回改改的時間。7.2 代碼分析與項目維護方向Codex用戶經常搜“codex 分析項目的skills”。這類skill的核心價值在于讓AI從“幫你寫代碼”升級為“幫你讀懂代碼”。我的做法是設計了一個“項目架構解讀”skill內部要求AI按模塊拆解項目、繪制架構關系和依賴鏈路、標記潛在的壞味道并輸出一份項目級README。前端跟后端混合的項目尤其受益AI不會只看某個目錄就下結論而是按流程通盤分析。7.3 學術與數(shù)學建模方向“academic research skills”和“數(shù)學建模skills”也是這波熱門詞里的高頻搜索。學術類skills我通常會讓AI按“文獻檢索 - 文獻速讀 - 核心論點歸納 - 引用梳理”的流程執(zhí)行配合學術搜索MCP工具基本上一個下午能搞定一篇綜述的初稿材料。數(shù)學建模類的更復雜一些除了常規(guī)思路拆分最關鍵的是要在skill里內置“模型假設-建立-求解-驗證-靈敏度分析”的標準論文框架這會極大提高比賽寫作效率。7.4 辦公與內容生產方向“claude code ppt skills”的搜索量一直不低。我做過一個PPT大綱生成skill內部包含受眾分析、章節(jié)推薦結構、演講節(jié)奏建議、以及每一頁的內容密度控制原則。說實話這類skill的技術含量不算高但因為它把“好PPT的標準”沉淀成了可執(zhí)行的規(guī)范輸出結果比我直接問AI“幫我寫個PPT大綱”要靠譜得多。8. 如果你想把skill做成一個長期資產最后說一點關于“長期主義”的想法。現(xiàn)在這個階段skills的價值正在被越來越多人發(fā)現(xiàn)但大部分人的用法還是“從社區(qū)下載幾個、試用一下、新鮮感過了就閑置”。我并不覺得這是壞事因為工具本來就是“需要才用”。但如果你想把它當成長期資產來經營我建議你從現(xiàn)在開始做兩件事。第一件建一個自己的skills“能力清單”。把工作或學習中高頻出現(xiàn)的任務列出來評估哪些適合做成skill哪些不適合做一個優(yōu)先級排序。這個清單既是你的效率路線圖也是將來回顧總結的依據。第二件把你的項目規(guī)范持續(xù)注入到skill里。隨著項目演進代碼規(guī)范、目錄結構、輸出要求都會變skill也要跟著升級。我一直保持一個習慣當發(fā)現(xiàn)AI按現(xiàn)有skill產出的結果開始“不對味”時第一反應不是換模型或加提示詞而是回頭檢查skill文件是不是該更新了。這個思維轉變才是你真正掌握skills精髓的標志。我自己這段時間最深刻的感受是skills這個小東西看似只是給AI寫個說明書但你認真打磨它的時候其實是在把近幾年積累的工作經驗做一次系統(tǒng)化沉淀。這個過程本身比AI輸出的結果更有價值。