最近身邊討論 agent 開(kāi)發(fā)的人突然多了起來(lái)各種框架、開(kāi)源項(xiàng)目層出不窮。前半年的熱點(diǎn)還是 RAG、Function Calling現(xiàn)在風(fēng)向已經(jīng)明顯轉(zhuǎn)向了“給 Agent 配技能”。團(tuán)隊(duì)里做 Code Review 的同事跑過(guò)來(lái)問(wèn)我skills 到底是什么和 prompt 有什么區(qū)別為什么大家都在裝 skills說(shuō)實(shí)話這是個(gè)好現(xiàn)象——說(shuō)明大家開(kāi)始意識(shí)到Agent 的能力上限很大程度上不取決于模型本身而取決于你給它準(zhǔn)備了多少可復(fù)用的技能。這段時(shí)間我自己在幾個(gè)項(xiàng)目里陸續(xù)試了 Claude Code skills、Codex 的 skills 機(jī)制也手動(dòng)開(kāi)發(fā)過(guò)兩套內(nèi)部 skill踩了不少坑也總結(jié)出一些規(guī)律。這篇文章就把我對(duì) agent-skills 的完整理解寫出來(lái)從底層原理到具體開(kāi)發(fā)步驟再到生態(tài)里值得裝的 skill 清單和測(cè)評(píng)方法一次性講透。不管你是剛開(kāi)始接觸 agent 開(kāi)發(fā)還是已經(jīng)在寫自己的 skill 庫(kù)應(yīng)該都能從中找到有用的東西。1. 從 prompt 到 skillsAgent 圈正在經(jīng)歷的范式轉(zhuǎn)變1.1 為什么是現(xiàn)在skills 爆發(fā)的三個(gè)直接推手先聊一個(gè)反直覺(jué)的現(xiàn)象llm 的能力在快速變強(qiáng)但對(duì)普通開(kāi)發(fā)者來(lái)說(shuō)“把大模型用好”這件事反而變難了。原因很簡(jiǎn)單模型越強(qiáng)用戶期待它完成的任務(wù)就越復(fù)雜。半年前你寫一個(gè)“請(qǐng)總結(jié)這份文檔”的 prompt 就夠用現(xiàn)在大家想讓 agent 自己看懂代碼庫(kù)、自動(dòng)修 bug、獨(dú)立完成前端頁(yè)面。任務(wù)的復(fù)雜度上了好幾個(gè)臺(tái)階靠一段 prompt 已經(jīng)兜不住了。skills 機(jī)制就是在這個(gè)背景下被推上前臺(tái)的。它爆發(fā)的直接推手有三個(gè)第一Claude 的 Agent Skills 規(guī)范發(fā)布給了行業(yè)一套統(tǒng)一的 skill 組織格式。SKILL.md 加技能目錄的標(biāo)準(zhǔn)結(jié)構(gòu)讓 skill 可以像文件一樣被復(fù)制、共享、版本管理。第二以 superpower skills 為代表的開(kāi)源 skill 庫(kù)在社區(qū)里瘋傳大家突然發(fā)現(xiàn)原來(lái)“給 Claude 裝上技能包”這件事如此簡(jiǎn)單效果還立竿見(jiàn)影。第三Codex 和 Claude Code 這類編碼 agent 工具的普及讓開(kāi)發(fā)者第一次在日常工作流里高頻接觸“模型 技能 工具調(diào)用”的組合模式。這三個(gè)推手疊加在一起直接把 skills 從一個(gè)小眾概念推成了 agent 開(kāi)發(fā)的事實(shí)標(biāo)準(zhǔn)。1.2 skills 到底解決的是什么問(wèn)題如果用一句話概括skills 解決的是“大模型不知道怎么做但你其實(shí)知道怎么做”的問(wèn)題。舉個(gè)例子。你讓一個(gè)剛畢業(yè)的實(shí)習(xí)生去 review 前端代碼他會(huì)看但不知道該按什么標(biāo)準(zhǔn)看、先看什么后看什么、哪些問(wèn)題必須阻斷、哪些問(wèn)題可以提建議。你得給他一份團(tuán)隊(duì)規(guī)范文檔再帶他過(guò)兩個(gè)真實(shí) case他才能獨(dú)立干活。Agent 也是一樣。底層模型有強(qiáng)大的理解和生成能力但它沒(méi)有“你們項(xiàng)目的代碼規(guī)范、你常用的技術(shù)棧、你們團(tuán)隊(duì)約定俗成的檢查清單”這些私有知識(shí)。你當(dāng)然可以把這些全部寫進(jìn) system prompt但那樣 prompt 會(huì)變得無(wú)比臃腫既浪費(fèi) token又容易讓模型抓不住重點(diǎn)。更合理的做法是把這些知識(shí)封裝成一個(gè)個(gè)獨(dú)立的 skill——像給實(shí)習(xí)生發(fā)了一本《前端 review 手冊(cè)》一樣用到的時(shí)候才翻開(kāi)來(lái)看。這也解釋了為什么 skill 和 prompt 不是一回事。Prompt 是你對(duì)模型的一次性指令而 skill 是一整套可復(fù)用的“操作手冊(cè) 工具包”通常包含說(shuō)明文檔、腳本、參考資料、示例代碼。模型在對(duì)話過(guò)程中根據(jù)用戶需求決定是否加載某個(gè) skill加載后才按照 skill 里寫的規(guī)范去執(zhí)行任務(wù)。1.3 Skill 在 Agent 工作流里的位置要理解 skill 的價(jià)值得先看它在整個(gè) Agent 工作流里處在什么位置。一個(gè)完整的 Agent 系統(tǒng)通常包含模型、工具、記憶、工作流編排和技能這幾個(gè)層次。模型負(fù)責(zé)理解和推理工具負(fù)責(zé)執(zhí)行具體操作記憶負(fù)責(zé)跨會(huì)話保留信息工作流編排負(fù)責(zé)把多個(gè)步驟串聯(lián)起來(lái)而技能層負(fù)責(zé)提供“特定領(lǐng)域內(nèi)的高效方法論”。技能和其他幾層都有交互它內(nèi)部可以調(diào)用工具它本身可以被記憶系統(tǒng)檢索它也會(huì)指導(dǎo)工作流的編排方式。我比較喜歡的一個(gè)類比是如果把 Agent 比作一個(gè)外科醫(yī)生模型是醫(yī)生的腦子工具是手術(shù)刀和縫合線那么 skill 就是手術(shù)操作規(guī)范手冊(cè)。腦子再聰明刀再鋒利沒(méi)有一個(gè)標(biāo)準(zhǔn)化的操作流程醫(yī)生也很難穩(wěn)定地完成高難度手術(shù)。skills 的作用就是把“知道該怎么做”沉淀成“每次都按最優(yōu)的方式做”。2. 深入拆解一個(gè) skill目錄結(jié)構(gòu)、SKILL.md 與加載機(jī)制2.1 一個(gè)標(biāo)準(zhǔn) skill 從外到內(nèi)長(zhǎng)什么樣現(xiàn)在社區(qū)里主流的 skill 格式基本都遵循 Anthropic 提出的 Agent Skills 規(guī)范。一個(gè) skill 本質(zhì)上就是一個(gè)目錄目錄名就是技能名目錄里至少包含一個(gè)SKILL.md文件通常還會(huì)帶上腳本、參考資料和示例。拿我本地寫的一個(gè)“前端結(jié)構(gòu)圖生成”skill 舉例目錄結(jié)構(gòu)是這樣的frontend-structure-map/ ├── SKILL.md ├── scripts/ │ ├── analyze_tree.py │ └── generate_mermaid.py ├── references/ │ ├── react_project_patterns.md │ └── vue_project_patterns.md └── examples/ ├── ecommerce_platform.md └── admin_dashboard.mdSKILL.md是這個(gè) skill 的入口文件里面寫清楚這個(gè)技能是干什么的、什么時(shí)候用、怎么一步步執(zhí)行。scripts/放實(shí)際可執(zhí)行的代碼references/放模型執(zhí)行任務(wù)時(shí)需要參考的領(lǐng)域知識(shí)examples/放完整的輸入輸出示例用來(lái)給模型提供 few-shot 參考。把 skill 安裝到 Claude Code 時(shí)只需要把整個(gè)目錄放到~/.claude/skills/下面。運(yùn)行時(shí)模型會(huì)先掃描技能目錄清單當(dāng)用戶請(qǐng)求匹配到某個(gè)技能的 description 時(shí)再把對(duì)應(yīng)的 SKILL.md 載入上下文。2.2 SKILL.md 的 frontmatter 與正文寫作規(guī)范SKILL.md 的結(jié)構(gòu)很講究它由 YAML frontmatter 和 Markdown 正文兩部分組成。frontmatter 是給“模型調(diào)度器”看的正文才是給模型執(zhí)行時(shí)讀的。一個(gè)合格的 frontmatter 長(zhǎng)這樣--- name: frontend-structure-map description: 分析前端項(xiàng)目目錄結(jié)構(gòu)與路由設(shè)計(jì)生成結(jié)構(gòu)圖。僅當(dāng)用戶需要理解前端項(xiàng)目架構(gòu)、代碼組織方式或準(zhǔn)備重構(gòu)時(shí)使用。 ---這里最關(guān)鍵的是description字段。它決定了模型什么時(shí)候會(huì)想到加載這個(gè) skill。寫得太泛比如“生成結(jié)構(gòu)圖”模型會(huì)在不需要的時(shí)候誤調(diào)用浪費(fèi)上下文寫得太窄模型該用的時(shí)候又想不到。我在實(shí)踐中總結(jié)出一個(gè)技巧description 里要寫清楚“輸入條件”和“觸發(fā)場(chǎng)景”而不是功能描述。比如上面這個(gè) description我不僅寫了“分析目錄結(jié)構(gòu)和路由”還補(bǔ)了一句“僅當(dāng)用戶需要理解架構(gòu)、準(zhǔn)備重構(gòu)時(shí)使用”這就是在幫模型做觸發(fā)判斷。正文部分是核心我把它理解成“替不熟悉這個(gè)領(lǐng)域的人寫一份可執(zhí)行的 SOP”。不要寫抽象的原則要寫具體的步驟。判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果一個(gè)人從來(lái)沒(méi)畫過(guò)前端結(jié)構(gòu)圖看完你的 SKILL.md 能不能一步步做出來(lái)2.3 模型是怎么“讀”skill 并執(zhí)行的理解了文件結(jié)構(gòu)我們?cè)賮?lái)看運(yùn)行時(shí)到底發(fā)生了什么。當(dāng)用戶發(fā)出一條消息模型的調(diào)度機(jī)制會(huì)先把當(dāng)前可用的 skill 清單過(guò)一遍。它會(huì)對(duì)比用戶消息的語(yǔ)義和每個(gè) skill 的 description判斷是否命中。命中后SKILL.md 的正文內(nèi)容才會(huì)被加載進(jìn)對(duì)話上下文。整個(gè)機(jī)制最精妙的地方在于“延遲加載”。如果系統(tǒng)里裝了 50 個(gè) skill模型不會(huì)把 50 份文檔全讀一遍而是在需要的時(shí)候只加載相關(guān)的幾個(gè)。這就像你廚房里放了 50 本菜譜但做紅燒肉的時(shí)候只會(huì)翻開(kāi)川菜那一本。加載之后SKILL.md 里的步驟會(huì)進(jìn)入模型的“執(zhí)行計(jì)劃”模型按照步驟一項(xiàng)項(xiàng)執(zhí)行過(guò)程中可以調(diào)用腳本、讀取參考文檔也可以根據(jù)中間結(jié)果調(diào)整策略。skill 內(nèi)部還可以設(shè)計(jì)條件分支比如“如果檢測(cè)到項(xiàng)目是 Vue就讀 vue 的參考文檔是 React就讀 react 的參考文檔”這樣同一個(gè) skill 可以適配多種情況靈活性很高。2.4 一個(gè)容易忽略的細(xì)節(jié)skill 的邊界感很多人寫 skill 的時(shí)候容易犯一個(gè)毛病恨不得把整個(gè)領(lǐng)域的知識(shí)全塞進(jìn)去。實(shí)際上 skill 一定要有邊界感專注解決一個(gè)問(wèn)題。skill 內(nèi)部的 SKILL.md 正文我一般控制在 300 到 600 行以內(nèi)。太長(zhǎng)了模型加載后會(huì)沖淡核心指令的權(quán)重而且消耗的上下文 token 太多多輪對(duì)話里容易擠占用戶內(nèi)容的空間。如果某個(gè)領(lǐng)域的知識(shí)量實(shí)在太大就拆成多個(gè) skill互相之間通過(guò) description 里的關(guān)鍵詞做區(qū)分。另外SKILL.md 里涉及的命令、腳本路徑必須寫成相對(duì)路徑并且要在正文里說(shuō)明“當(dāng)前工作目錄是 xxx”否則模型執(zhí)行時(shí)容易找不到文件。這是我踩過(guò)最多次的坑后面會(huì)專門展開(kāi)講。3. 別再混淆skill、prompt、MCP、agent 和 workflow 的邊界3.1 一張表理清五個(gè)概念的定位社區(qū)里討論 skills 的時(shí)候最常見(jiàn)的問(wèn)題就是概念混淆。很多人把 skill 和 prompt、skill 和 MCP、skill 和 agent 混為一談。這里我用一張表把這五個(gè)概念的定位徹底說(shuō)清楚。概念本質(zhì)解決什么問(wèn)題一個(gè)類比Prompt一次性的指令文本告訴模型“這次任務(wù)是什么”給實(shí)習(xí)生的一次口頭交代Skill可復(fù)用的方法論 工具包告訴模型“這類任務(wù)用什么標(biāo)準(zhǔn)、什么步驟做”給實(shí)習(xí)生的一本崗位手冊(cè)MCP標(biāo)準(zhǔn)化的工具接入?yún)f(xié)議讓模型能調(diào)用外部系統(tǒng)數(shù)據(jù)庫(kù)、瀏覽器、API給實(shí)習(xí)生開(kāi)通的系統(tǒng)賬號(hào)和權(quán)限Agent自主規(guī)劃與執(zhí)行的整體系統(tǒng)把目標(biāo)拆解成動(dòng)作循環(huán)執(zhí)行直到完成實(shí)習(xí)生本人Workflow寫死的步驟編排固定順序執(zhí)行不允許模型自由發(fā)揮一套標(biāo)準(zhǔn)操作流程表從這個(gè)表能看出來(lái)skill 的定位介于 prompt 和 agent 之間。它比 prompt 更結(jié)構(gòu)化、可復(fù)用又不像 agent 那樣具備完整的規(guī)劃循環(huán)能力。Skill 本身不決策它只提供“被調(diào)用時(shí)的專業(yè)能力”。3.2 Skill 和 prompt 的區(qū)別何時(shí)用哪個(gè)Prompt 適合“一次性、低頻、高度定制”的任務(wù)Skill 適合“重復(fù)發(fā)生、有方法論、需要沉淀”的任務(wù)。我給你一個(gè)判斷標(biāo)準(zhǔn)同一個(gè)任務(wù)你一個(gè)月之內(nèi)需要讓模型做超過(guò)三次就應(yīng)該考慮把它抽成一個(gè) skill。第一次直接寫 prompt 可以第二次微調(diào)一下也還行第三次你會(huì)發(fā)現(xiàn)你又在重復(fù)相似的步驟這時(shí)候就該把公共的部分固化下來(lái)了。另一個(gè)重要的區(qū)別是觸發(fā)方式。Prompt 是用戶主動(dòng)提供的指令而 skill 可以被模型自動(dòng)發(fā)現(xiàn)和加載。用一個(gè)寫代碼審查規(guī)則的例子說(shuō)明你不給模型裝 skill每次都要說(shuō)“按我們團(tuán)隊(duì)的規(guī)范檢查代碼注意性能、安全、可維護(hù)性每個(gè)問(wèn)題給出嚴(yán)重級(jí)別……”這段話本身就占了大量 token。裝了 skill 之后你只需要說(shuō)“檢查這段代碼”模型自己會(huì)去匹配 skill然后按照 skill 里寫的規(guī)范執(zhí)行。這就是效率的碾壓。特別是對(duì)于編碼 agent 這種高頻場(chǎng)景每天幾十次交互省下來(lái)的 token 非常可觀。3.3 Skill 和 MCP 的真正關(guān)系分工而非競(jìng)爭(zhēng)skill 和 MCP 是我見(jiàn)過(guò)被混淆得最厲害的一對(duì)。很多人覺(jué)得既然有了 MCP模型什么工具都能接還要 skill 干嘛這個(gè)想法完全搞錯(cuò)了方向。MCP 解決的是“模型怎么觸達(dá)外部世界”的問(wèn)題它負(fù)責(zé)建立連接。Skill 解決的是“觸達(dá)之后怎么做才算專業(yè)”的問(wèn)題它負(fù)責(zé)提供方法。兩者是上下游關(guān)系。舉個(gè)實(shí)際的例子。一個(gè)用于數(shù)據(jù)庫(kù)分析的 skill內(nèi)部會(huì)調(diào)用數(shù)據(jù)庫(kù) MCP 服務(wù)器來(lái)執(zhí)行查詢但具體查哪些表、用什么指標(biāo)口徑、結(jié)果怎么解讀這些是 skill 里規(guī)定的內(nèi)容。MCP 是那條“管道”skill 是管道里面流的水。在 Agent 開(kāi)發(fā)中比較合理的架構(gòu)是底層架設(shè)若干個(gè) MCP 服務(wù)器代碼庫(kù)、數(shù)據(jù)庫(kù)、瀏覽器、設(shè)計(jì)稿上層配置若干 skill代碼審查、數(shù)據(jù)庫(kù)分析、頁(yè)面生成、結(jié)構(gòu)圖繪制。模型在某個(gè)任務(wù)里先加載 skillskill 里的步驟指引模型去調(diào)用對(duì)應(yīng)的 MCP 工具兩邊配合才能把活干漂亮。3.4 Skill 和 agent 的區(qū)別能力包和調(diào)度器的關(guān)系還有朋友問(wèn)我寫的 skill 是不是就是一個(gè) agent不是。最核心的區(qū)別在于自主性。Agent 有目標(biāo)拆解、計(jì)劃執(zhí)行、自我糾錯(cuò)的能力它是一個(gè)完整的執(zhí)行主體。Skill 沒(méi)有這些它只是一個(gè)被動(dòng)加載的知識(shí)包和方法論。你給我一個(gè) skill 文件我不會(huì)自己動(dòng)但你把我這個(gè) agent 配上那個(gè) skill我就能干得更專業(yè)。換個(gè)說(shuō)法Agent 是“調(diào)度器 執(zhí)行器”的整體skill 是執(zhí)行器手里的一本“專項(xiàng)能力手冊(cè)”。同一個(gè) agent 可以加載不同的 skill 來(lái)應(yīng)對(duì)不同領(lǐng)域的任務(wù)就像同一個(gè)程序員在不同項(xiàng)目里看不同的技術(shù)文檔。不過(guò)也要承認(rèn)現(xiàn)在的邊界正在模糊。有些 agent 框架已經(jīng)開(kāi)始支持在 skill 內(nèi)部定義簡(jiǎn)單的決策邏輯讓 skill 具有一定的“半自主”能力。但從設(shè)計(jì)理念上講保持 skill 的“被動(dòng)加載”屬性是更健康的選擇這樣系統(tǒng)的可預(yù)測(cè)性更強(qiáng)調(diào)試起來(lái)也容易得多。4. 從零開(kāi)發(fā)一個(gè)可用 skill以“前端結(jié)構(gòu)圖生成”為例4.1 選定目標(biāo)什么樣的任務(wù)適合做成 skill前面聊了這么多理論和概念現(xiàn)在進(jìn)入實(shí)操環(huán)節(jié)。我拿自己最近開(kāi)發(fā)的一個(gè)“前端結(jié)構(gòu)圖生成”skill 來(lái)完整走一遍流程。先說(shuō)要選對(duì)任務(wù)。適合做成 skill 的任務(wù)有三個(gè)特征第一步驟明確可以固化為流程第二需要領(lǐng)域知識(shí)光靠模型常識(shí)做不好第三結(jié)果輸出格式相對(duì)統(tǒng)一便于后續(xù)使用?！扒岸私Y(jié)構(gòu)圖生成”完全符合這三個(gè)特征。前端項(xiàng)目結(jié)構(gòu)分析雖然不復(fù)雜但沒(méi)有統(tǒng)一方法時(shí)模型會(huì)自由發(fā)揮有時(shí)候輸出一棵目錄樹(shù)就結(jié)束了有時(shí)候只是泛泛而談。我需要的是穩(wěn)定輸出一份“目錄信息 路由關(guān)系 關(guān)鍵模塊分析 Mermaid 圖”四件套。這正是一個(gè) skill 的用武之地。4.2 設(shè)計(jì) skill 的目錄與 SKILL.md 正文明確了目標(biāo)接下來(lái)就是搭建目錄結(jié)構(gòu)。我在前面已經(jīng)展示了這個(gè) skill 的目錄現(xiàn)在具體說(shuō)每個(gè)文件的定位。SKILL.md是整個(gè) skill 的核心frontmatter 里 description 要寫清楚觸發(fā)條件。正文部分我按照“前置條件、執(zhí)行步驟、輸出格式、注意事項(xiàng)”四段來(lái)組織。執(zhí)行步驟這一節(jié)里面我會(huì)明確要求模型先運(yùn)行scripts/analyze_tree.py獲取項(xiàng)目結(jié)構(gòu)再根據(jù)應(yīng)用的入口文件識(shí)別路由配置結(jié)合references/里的框架模式文檔判斷技術(shù)棧最后調(diào)用scripts/generate_mermaid.py生成結(jié)構(gòu)圖。這里有一個(gè)非常重要的寫作技巧SKILL.md 里寫給模型看的指令語(yǔ)氣要使用“祈使句 明確預(yù)期”。不要寫“你可以嘗試分析項(xiàng)目的路由”要寫“分析項(xiàng)目的路由配置列出所有頁(yè)面級(jí)組件及其路徑映射”。模型對(duì)指令的遵循度很高但前提是你能把指令寫得足夠具體。以下是我實(shí)際使用的 SKILL.md 骨架--- name: frontend-structure-map description: 分析前端項(xiàng)目目錄結(jié)構(gòu)與路由配置生成結(jié)構(gòu)圖。當(dāng)用戶要求理解前端項(xiàng)目架構(gòu)、梳理模塊關(guān)系、重構(gòu)前做結(jié)構(gòu)分析時(shí)使用。 --- # 前端結(jié)構(gòu)圖生成 ## 輸入要求 - 前端項(xiàng)目根目錄路徑如果用戶未指定使用當(dāng)前工作目錄 - 項(xiàng)目使用的框架類型React / Vue / 其他可通過(guò)配置文件識(shí)別 ## 執(zhí)行步驟 1. 運(yùn)行 python3 scripts/analyze_tree.py project_root 獲取三層目錄樹(shù)。 2. 識(shí)別入口文件React 查 src/App.jsx 或路由配置文件Vue 查 src/router/。 3. 解析路由配置列出頁(yè)面組件與 URL 的映射關(guān)系。 4. 讀取 references/react_project_patterns.md 或 references/vue_project_patterns.md 判斷項(xiàng)目模式。 5. 用腳本生成 Mermaid 結(jié)構(gòu)圖輸出 structure.md。 ## 輸出格式 - 目錄樹(shù)摘要 - 路由映射表 - 關(guān)鍵模塊說(shuō)明 - Mermaid 結(jié)構(gòu)圖4.3 配套腳本與參考文檔的寫法細(xì)節(jié)SKILL.md 只解決了“怎么做”的問(wèn)題真正讓 skill 好用的是配套腳本和參考文檔。scripts/analyze_tree.py的設(shè)計(jì)邏輯很簡(jiǎn)單遍歷項(xiàng)目目錄過(guò)濾掉node_modules、.git、dist等目錄輸出三層深度的目錄樹(shù)。這個(gè)腳本看起來(lái)不難但恰恰是過(guò)濾規(guī)則的設(shè)計(jì)決定了模型拿到的信息質(zhì)量。如果不過(guò)濾node_modules模型會(huì)被幾萬(wàn)個(gè)文件淹沒(méi)根本分不清重點(diǎn)。scripts/generate_mermaid.py則接收一個(gè) JSON 格式的中間結(jié)果輸出 Mermaid 的graph TD結(jié)構(gòu)圖。我讓兩個(gè)腳本分開(kāi)而不是一個(gè)腳本干完所有事是因?yàn)橹虚g結(jié)果可以讓模型“看一眼再判斷”如果結(jié)構(gòu)圖生成得不對(duì)模型可以只調(diào)整路由數(shù)據(jù)而不需要重新掃描整個(gè)項(xiàng)目。這種解耦設(shè)計(jì)大大提高了容錯(cuò)率。references/里的兩個(gè)文件實(shí)際上是把“資深前端對(duì)項(xiàng)目結(jié)構(gòu)的理解”這個(gè)隱性知識(shí)顯性化。比如 React 項(xiàng)目里我寫了頁(yè)面組件通常在src/pages下路由配置在src/router或App.jsx全局狀態(tài)在src/store公共組件在src/components。模型看到這些模式說(shuō)明后再配合目錄樹(shù)就能做出比較靠譜的分析判斷。4.4 測(cè)試與迭代讓 skill 從“能用”到“好用”skill 開(kāi)發(fā)完不算完測(cè)試和迭代才是重頭戲。我一般會(huì)準(zhǔn)備三組測(cè)試用例一個(gè) React 電商項(xiàng)目、一個(gè) Vue 后臺(tái)管理系統(tǒng)、一個(gè)純靜態(tài)多頁(yè)應(yīng)用。每組測(cè)試我都用完全相同的用戶指令“幫我分析一下這個(gè)項(xiàng)目的結(jié)構(gòu)”觀察模型會(huì)不會(huì)主動(dòng)加載 skill、加載后依不依循 SKILL.md 的步驟執(zhí)行、最終輸出的結(jié)構(gòu)圖畫得對(duì)不對(duì)。第一輪測(cè)試通常能暴露大量問(wèn)題。最常見(jiàn)的有三種description 寫得不精確導(dǎo)致模型沒(méi)有加載 skillSKILL.md 里的步驟順序不夠清晰導(dǎo)致模型跳步腳本對(duì)某些邊界情況報(bào)錯(cuò)比如空目錄、嵌套過(guò)深。每一輪發(fā)現(xiàn)的問(wèn)題都回到對(duì)應(yīng)文件里去改改完再重新跑測(cè)試。我開(kāi)發(fā)這個(gè) skill 花了三個(gè)晚上大概迭代了五六輪最后才達(dá)到比較穩(wěn)定的效果。一點(diǎn)心得測(cè)試 skill 的時(shí)候不要用你已經(jīng)反復(fù)跑過(guò)的同一個(gè)項(xiàng)目反復(fù)測(cè)那樣很容易自我感覺(jué)良好。我在第一輪測(cè)試時(shí)用了自己熟悉的項(xiàng)目輸出的結(jié)構(gòu)圖看起來(lái)挺對(duì)但換了個(gè)完全陌生的項(xiàng)目后模型就開(kāi)始胡編亂造路由配置了。后來(lái)我在 SKILL.md 里專門加了一條“路由信息必須來(lái)自項(xiàng)目?jī)?nèi)實(shí)際文件禁止推測(cè)”這個(gè)問(wèn)題才被解決。5. 生態(tài)盤點(diǎn)那些值得裝的 skills 與正確的安裝方式5.1 開(kāi)源神器 superpower skills零成本入門首選說(shuō)到社區(qū)里最火的 skills 合集superpower skills 必須排第一個(gè)。這個(gè)項(xiàng)目把大量高頻能力打包成了一個(gè)個(gè)獨(dú)立的 skill從寫代碼到做研究、從寫作潤(rùn)色到數(shù)據(jù)分析都有覆蓋。它的安裝方式很簡(jiǎn)單直接把倉(cāng)庫(kù)克隆下來(lái)把skills/目錄下的技能復(fù)制到你的 skill 目錄就行。以 Claude Code 為例安裝到~/.claude/skills/打開(kāi)一個(gè)新的對(duì)話模型就能自動(dòng)發(fā)現(xiàn)這些技能了。我個(gè)人比較推薦 superpower skills 里的“代碼審查”和“漸進(jìn)式重構(gòu)”這兩個(gè)技能。代碼審查 skill 的覆蓋面很全從安全性、性能、可維護(hù)性、正確性幾個(gè)維度去檢查輸出的審查報(bào)告結(jié)構(gòu)清晰而且每個(gè)問(wèn)題都帶嚴(yán)重級(jí)別標(biāo)注。漸進(jìn)式重構(gòu) skill 則特別適合老項(xiàng)目維護(hù)場(chǎng)景它提倡小步快跑每次只改一個(gè)模塊改完跑測(cè)試再繼續(xù)比一次性大重構(gòu)穩(wěn)妥太多。5.2 Claude Code 的 skills 目錄機(jī)制與常用技能Claude Code 是 Anthropic 推出的終端編碼 agent它對(duì) skills 的支持非常原生。安裝 skill 只要把它放到~/.claude/skills/skill-name/目錄下目錄里包含SKILL.md即可不需要任何額外的注冊(cè)配置。這個(gè)簡(jiǎn)單到極致的安裝機(jī)制推動(dòng)了大量開(kāi)發(fā)者貢獻(xiàn)自己的 skill。社區(qū)里比較受歡迎的有“commit message 生成”“單元測(cè)試編寫”“API 文檔生成”“數(shù)據(jù)庫(kù)索引分析”這些偏向開(kāi)發(fā)流程的技能。其中“commit message 生成”是我安裝后使用頻率最高的。它會(huì)把 git diff 的變更內(nèi)容解析出來(lái)按照 Conventional Commits 規(guī)范生成提交信息。以前我提交代碼總是隨手寫“fix stuff”現(xiàn)在讓模型按 skill 來(lái)提交信息都帶上了feat:、fix:、refactor:這些前綴項(xiàng)目日志清晰了一個(gè)量級(jí)。5.3 Codex 生態(tài)里的 skills用法與優(yōu)勢(shì)OpenAI 的 Codex 也有自己的 skill 加載機(jī)制。和 Claude Code 略有不同的是Codex 更傾向于在對(duì)話中通過(guò)關(guān)鍵詞觸發(fā)技能同時(shí)支持在配置文件里預(yù)先聲明待加載的 skill 列表。我在 Codex 環(huán)境下的一個(gè)體驗(yàn)是它對(duì)代碼庫(kù)全局上下文的處理比較激進(jìn)所以 skill 的設(shè)計(jì)要更強(qiáng)調(diào)“精準(zhǔn)裁剪”。如果 skill 里要求模型先讀一堆文件很容易把上下文撐爆。Codex 生態(tài)里比較好用的 skill 傾向于短小精悍型比如“問(wèn)題定位專家”它教模型用二分法快速縮小 bug 范圍步驟不超過(guò)五步但每一步都直擊要害。5.4 Hermes Agent 與其他框架的 skills 適配除了兩大編碼 agent還有一類 agent 框架也擁抱了 skills 概念典型代表是 Hermes Agent。這類框架通常會(huì)把 skill 作為 agent 的“能力組件”之一與 memory、tool 并列。安裝方式一般是在配置里聲明啟用的 skill 列表。選擇框架的時(shí)候我建議先看你主要用 agent 做什么。如果是在終端里寫代碼Claude Code 或 Codex 的 skills 生態(tài)最豐富。如果是在做通用業(yè)務(wù)流程自動(dòng)化那通用 agent 框架的 skill 機(jī)制會(huì)更靈活因?yàn)樗ǔＴ试S你在一個(gè)工作流里加載多個(gè) skill 協(xié)同完成復(fù)雜任務(wù)。我自己目前的配置是Claude Code 里裝了 8 個(gè)偏代碼類的 skill通用 agent 框架里裝了 5 個(gè)偏業(yè)務(wù)類的 skill。代碼類的覆蓋 commit、review、重構(gòu)、單測(cè)業(yè)務(wù)類的覆蓋數(shù)據(jù)分析、報(bào)告生成、郵件撰寫、會(huì)議紀(jì)要。日常工作里七八成的重復(fù)性任務(wù)基本都能靠模型加 skill 直接完成。5.5 判斷一個(gè) skill 是否靠譜的三個(gè)標(biāo)準(zhǔn)社區(qū)里 skills 的數(shù)量增長(zhǎng)很快但質(zhì)量參差不齊。裝了一個(gè)不靠譜的 skill不僅沒(méi)有幫助還會(huì)干擾模型正常對(duì)話。我判斷一個(gè) skill 值不值得裝主要看三個(gè)維度。第一description 是否寫清楚了觸發(fā)場(chǎng)景如果 description 寫得模棱兩可比如“一個(gè)有用的技能”說(shuō)明作者沒(méi)想清楚這個(gè) skill 的邊界果斷放棄。第二SKILL.md 的步驟是否足夠具體如果正文全是“根據(jù)項(xiàng)目情況靈活判斷”這類廢話模型拿到手也不知道該怎么執(zhí)行。第三是否有 examples 或測(cè)試用例沒(méi)有示例的 skill 就像沒(méi)有文檔的開(kāi)源庫(kù)調(diào)試起來(lái)全憑運(yùn)氣。6. 開(kāi)發(fā)與使用 skill 中的四個(gè)大坑我的實(shí)測(cè)經(jīng)驗(yàn)6.1 坑一description 寫得太泛模型亂觸發(fā)這是我在開(kāi)發(fā)第一個(gè) skill 時(shí)遇到的問(wèn)題。當(dāng)時(shí)我寫了一個(gè)“代碼重構(gòu)”skilldescription 寫的是“幫助用戶重構(gòu)代碼”。聽(tīng)起來(lái)沒(méi)毛病對(duì)吧結(jié)果裝上之后用戶隨口問(wèn)一句“幫我看看這段代碼怎么樣”模型都會(huì)觸發(fā)重構(gòu) skill把正常的代碼風(fēng)格問(wèn)詢變成了一場(chǎng)大動(dòng)干戈的重構(gòu)建議。后來(lái)我改成“在用戶明確要求重構(gòu)或代碼存在明顯重復(fù)、過(guò)長(zhǎng)函數(shù)、復(fù)雜條件等重構(gòu)信號(hào)時(shí)使用”觸發(fā)準(zhǔn)確率一下就上來(lái)了。description 的寫作原則就是寧可寫長(zhǎng)一點(diǎn)把“什么時(shí)候不該用”也寫進(jìn)去也不要為了簡(jiǎn)潔而留下歧義空間。6.2 坑二路徑與腳本問(wèn)題導(dǎo)致 skill 執(zhí)行失敗剛才說(shuō)過(guò)這是我在所有 skill 開(kāi)發(fā)里遇到最多的問(wèn)題。SKILL.md 里如果直接寫python scripts/xxx.py模型會(huì)默認(rèn)從當(dāng)前工作目錄去找但當(dāng)前工作目錄不一定是 skill 所在的目錄。解決方案是在 SKILL.md 開(kāi)頭寫清楚“這個(gè) skill 的根目錄是相對(duì)于 SKILL.md 文件的位置”或者提供一個(gè)一鍵安裝腳本把 skill 安裝到固定位置后在 SKILL.md 里用絕對(duì)路徑模板來(lái)引用腳本。更穩(wěn)妥的做法是在 skill 內(nèi)部寫一個(gè)setup.sh自動(dòng)檢測(cè)環(huán)境并配置好路徑變量。6.3 坑三上下文管理失控skill 變成 token 黑洞有些 skill 的 SKILL.md 本身寫得非常長(zhǎng)再加上 references 目錄里的文檔動(dòng)不動(dòng)幾十頁(yè)模型一旦加載上下文直接少了一大截。如果用戶的問(wèn)題本身還帶著大量項(xiàng)目文件內(nèi)容很容易出現(xiàn)上下文超限。我的優(yōu)化思路是“分層加載”。SKILL.md 只保留最高層的執(zhí)行框架和關(guān)鍵決策點(diǎn)詳細(xì)的參考資料單獨(dú)放文件。并在 SKILL.md 里寫明“僅當(dāng)需要判斷技術(shù)棧時(shí)讀取 references/react_project_patterns.md”而不是讓模型把整個(gè)目錄全部讀一遍。這樣 model 大部分情況下只需要加載 SKILL.md特殊情況下才按需拉取參考文件。6.4 坑四為了跑分而優(yōu)化skill 在真實(shí)場(chǎng)景里失效最后這個(gè)坑更像一個(gè)提醒。之前有個(gè)朋友跟我討論如何評(píng)測(cè) skill 時(shí)說(shuō)到他在某個(gè)公開(kāi) benchmark 上把一個(gè) skill 調(diào)到了很高的分?jǐn)?shù)但在實(shí)際項(xiàng)目里一用就露餡。原因是他在開(kāi)發(fā)過(guò)程中把 benchmark 里的測(cè)試用例的各種邊界情況都“背”下來(lái)了SKILL.md 里寫滿了針對(duì)這些用例的硬編碼規(guī)則。這就是典型的 Goodhart 定律一旦某個(gè)指標(biāo)變成了目標(biāo)它就不再是一個(gè)好的指標(biāo)。Skill 的評(píng)測(cè)一定要用“沒(méi)見(jiàn)過(guò)的真實(shí)項(xiàng)目”來(lái)測(cè)而且關(guān)鍵是看模型在沒(méi)有你人工指導(dǎo)的情況下能不能獨(dú)立完成從加載 skill 到產(chǎn)出結(jié)果的完整鏈路。我的做法是每?jī)芍茏鲆淮握鎸?shí)場(chǎng)景回歸測(cè)試把最近遇到的新需求作為測(cè)試用例看 skill 能不能應(yīng)對(duì)沒(méi)見(jiàn)過(guò)的場(chǎng)景。這樣才不會(huì)讓 skill 變成一個(gè)只會(huì)做“練習(xí)題”的應(yīng)試選手。另外再分享一個(gè)我自己總結(jié)的小經(jīng)驗(yàn)skill 的維護(hù)和代碼維護(hù)一樣需要持續(xù)投入。技術(shù)棧在變最佳實(shí)踐在變skill 里的知識(shí)如果幾個(gè)月不更新慢慢就會(huì)過(guò)時(shí)。我通常會(huì)把“skill 維護(hù)”列進(jìn)每周的例行工作清單里花半小時(shí)檢查一下哪些 skill 的使用頻率在下降哪些 description 需要補(bǔ)充新場(chǎng)景這半小時(shí)的投入性價(jià)比非常高。