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