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