1. 從“skills”這個熱詞說起它到底是什么為什么突然火了最近幾個月不管是在技術社區(qū)還是各種開發(fā)者群聊里“skills”這個詞出現(xiàn)的頻率高得離譜。如果你只是偶爾刷到可能會以為它說的是“技能”這個泛泛的概念但只要你稍微往深里看一眼就會發(fā)現(xiàn)大家討論的其實是Agent Skills——一種讓 AI 編程助手比如 Claude Code、Codex 這類工具具備可復用、可組合、可版本管理的“能力模塊”的機制。說白了以前我們用 AI 寫代碼每次都得把上下文、規(guī)范、項目結構重新喂一遍效率低不說結果還不穩(wěn)定。而 Skills 的出現(xiàn)本質(zhì)上是把“怎么做一個特定任務”這件事從一次性的對話里抽出來變成一個獨立的、有結構的文件包。這個文件包里最核心的就是SKILL.md它用自然語言加少量元數(shù)據(jù)的方式告訴 AI 在什么場景下該調(diào)用什么能力、按什么步驟執(zhí)行、注意哪些邊界條件。我最早接觸這個概念是在一個前端項目里當時團隊想讓 AI 幫忙統(tǒng)一處理組件的命名規(guī)范和目錄結構。一開始大家都是把規(guī)則寫在 prompt 里但每次新開一個會話就得重新貼一遍而且不同人寫的 prompt 風格不一樣AI 的輸出也飄忽不定。后來有人提議把這套規(guī)則做成一個 skill放在項目根目錄的.skills文件夾下結果整個流程一下子就穩(wěn)了——不管誰用、什么時候用只要觸發(fā)條件匹配AI 就會自動加載這個 skill按同樣的邏輯干活。所以如果你問我 skills 解決了什么問題我的回答很直接它解決的是 AI 輔助開發(fā)中“重復勞動”和“一致性缺失”這兩個老大難問題。適合誰來學我覺得只要你在日常工作中會用到 AI 編程工具不管是前端、后端、數(shù)據(jù)科學還是數(shù)學建模都值得花點時間了解一下。哪怕你暫時不打算自己寫 skill至少要知道怎么安裝、怎么用別人分享的 skill這已經(jīng)能幫你省下大量重復溝通的成本。2. Skills 的核心機制拆解為什么是 SKILL.md而不是別的2.1 SKILL.md 的設計哲學讓 AI 自己決定什么時候用很多人第一次看到SKILL.md的時候會有點懵——這不就是一個 Markdown 文件嗎憑什么它能讓 AI 變聰明這里面的關鍵不在于文件格式本身而在于它的內(nèi)容結構和加載時機。一個典型的SKILL.md通常包含幾個部分頂部的元信息比如 name、description、trigger 條件中間的步驟說明以及底部的示例和邊界情況。AI 在運行時會先掃描所有可用的 skill然后根據(jù)當前對話的上下文判斷哪個 skill 的 trigger 條件被滿足了再把對應的內(nèi)容加載進上下文。這個過程是按需加載的不需要你手動切換也不需要你把所有規(guī)則都塞進系統(tǒng)提示里。我打個比方以前的 prompt 就像你每次做飯都得把菜譜從頭念一遍給廚師聽而 skill 就像你把菜譜寫好了放在架子上廚師看到你今天點了紅燒肉自己就去把對應的菜譜抽出來照著做。這個“自己抽”的動作就是 skill 機制最值錢的地方。2.2 和傳統(tǒng) prompt 工程的區(qū)別從“一次性”到“可積累”傳統(tǒng) prompt 工程最大的問題是不可積累。你今天調(diào)好了一個很滿意的 prompt明天換個會話、換個模型版本可能就失效了。而且 prompt 通常是寫在對話里的沒法版本管理沒法 code review更沒法分享給團隊其他人復用。Skills 把這件事變成了工程化的。SKILL.md可以放在 Git 倉庫里可以寫 changelog可以打 tag可以像代碼一樣做 review。你改了一版 skill團隊里所有人拉下來就能用效果是一致的。更重要的是skill 可以被組合——一個 skill 可以依賴另一個 skill就像函數(shù)調(diào)用一樣。這種可組合性讓復雜任務的拆解變得非常自然。2.3 觸發(fā)機制與上下文管理AI 是怎么“想起”某個 skill 的這里涉及一個很多人忽略的細節(jié)skill 不是越多越好。如果你在項目里塞了幾十個 skillAI 在判斷該用哪個的時候反而容易出錯因為 trigger 條件之間可能會打架。我實測下來一個項目里同時激活的 skill 最好控制在 5 到 8 個以內(nèi)超過這個數(shù)量AI 的調(diào)用準確率會明顯下降。觸發(fā)機制一般有兩種一種是關鍵詞觸發(fā)比如 skill 的 description 里寫了“當用戶提到組件命名規(guī)范時使用”那 AI 看到相關關鍵詞就會加載另一種是顯式調(diào)用比如你在對話里直接說“用 xxx skill 來處理這個任務”。前者更自然后者更可控。我的建議是兩者結合——日常用關鍵詞觸發(fā)關鍵任務用顯式調(diào)用兜底。3. 從零開始寫一個自己的 Skill完整實操流程3.1 環(huán)境準備你需要什么工具和目錄結構先說清楚寫 skill 本身不需要什么特殊環(huán)境一個文本編輯器加一個 Git 倉庫就夠了。但如果你想讓 skill 真正跑起來得確保你用的 AI 編程工具支持這個機制。目前 Claude Code 對 skills 的支持比較成熟Codex 這邊也在跟進具體版本要求建議看官方文檔的最新說明。目錄結構方面我習慣在項目根目錄下建一個.skills文件夾里面每個 skill 一個子目錄子目錄名就是 skill 的標識符。比如.skills/ component-naming/ SKILL.md examples/ good-example.tsx bad-example.tsx api-error-handling/ SKILL.md每個 skill 目錄里至少有一個SKILL.md如果有示例文件或者輔助腳本可以放在同級目錄下在SKILL.md里用相對路徑引用。3.2 寫好 SKILL.md 的五個關鍵部分我寫過的 skill 不算多但踩過的坑不少?？偨Y下來一個能穩(wěn)定工作的SKILL.md應該包含以下五個部分第一部分是元信息頭。通常用 YAML front matter 的格式寫在文件最上面包括 name、description、version、trigger 這幾個字段。description 要寫得具體但不啰嗦trigger 要覆蓋你希望 AI 自動加載這個 skill 的典型場景。第二部分是目標說明。用一兩句話講清楚這個 skill 是干什么的解決什么問題。這部分是給 AI 看的也是給以后維護這個 skill 的人看的。第三部分是執(zhí)行步驟。這是核心內(nèi)容要按順序列出 AI 應該怎么做。每一步都要具體到可執(zhí)行的程度不要寫“優(yōu)化代碼結構”這種模糊的話而要寫“檢查每個組件的文件名是否以 PascalCase 命名如果不是重命名為 PascalCase”。第四部分是示例。給一兩個正例和反例讓 AI 知道什么算做對了什么算做錯了。示例不用多但要有代表性。第五部分是邊界和禁忌。明確告訴 AI 在什么情況下不要用這個 skill或者執(zhí)行過程中有哪些絕對不能做的事。這部分很多人會忽略但實際用起來能避免大量誤操作。3.3 一個真實案例前端組件命名規(guī)范 skill下面是我實際在用的一個 skill 的簡化版你可以直接參考這個結構來寫自己的--- name: component-naming description: 統(tǒng)一 React 組件的文件命名和導出規(guī)范 version: 1.2.0 trigger: - 用戶提到組件命名 - 用戶要求整理組件目錄 - 新建組件文件時 --- ## 目標 確保項目中所有 React 組件的文件名、導出名和目錄結構保持一致。 ## 執(zhí)行步驟 1. 掃描 src/components 下所有 .tsx 文件 2. 檢查文件名是否為 PascalCase如果不是重命名 3. 檢查默認導出名是否與文件名一致如果不一致修正 4. 檢查每個組件是否放在以組件名命名的子目錄中 5. 如果組件有配套的樣式文件或測試文件確保它們在同一目錄下 ## 示例 正例src/components/UserProfile/UserProfile.tsx 反例src/components/user-profile/index.tsx ## 邊界 - 不要修改 node_modules 下的任何文件 - 不要重命名已經(jīng)被其他文件引用的組件除非同時更新所有引用 - 如果組件名和文件名沖突無法自動解決停下來詢問用戶這個 skill 寫完之后我們團隊里不管誰用 AI 整理組件輸出都是一致的。以前每次都要在對話里重復一遍規(guī)則現(xiàn)在完全不用了。3.4 調(diào)試和迭代怎么知道 skill 寫得好不好寫完一個 skill 只是開始真正花時間的是調(diào)試。我的做法是先在小范圍試比如拿一個具體的任務讓 AI 跑一遍看它有沒有正確加載 skill、有沒有按步驟執(zhí)行、有沒有在邊界情況下停下來。如果發(fā)現(xiàn) AI 沒加載 skill通常是 trigger 寫得不夠具體或者 description 和實際對話的匹配度不高。如果加載了但執(zhí)行不對多半是步驟寫得太模糊或者示例不夠有代表性。如果 AI 在邊界情況下亂來那就是禁忌部分沒寫清楚。我一般會迭代三到五版才覺得一個 skill 比較穩(wěn)。每次改完都記一下改了什么、為什么改這樣后面維護的時候不至于忘了當時的思路。4. 安裝和使用別人分享的 Skills少走彎路的實操建議4.1 從哪里找現(xiàn)成的 skill現(xiàn)在網(wǎng)上分享 skill 的地方越來越多GitHub 上搜SKILL.md或者agent-skills能出來一大堆。比較活躍的倉庫通常會有分類目錄比如前端開發(fā)、數(shù)據(jù)處理、數(shù)學建模、文檔寫作等等。我建議優(yōu)先找star 數(shù)高、最近有更新、有實際使用案例的倉庫不要隨便下一個來路不明的 skill 就往項目里塞。另外有些 skill 是跟特定工具綁定的比如專門給 Claude Code 用的或者專門給 Codex 用的。下載之前看清楚兼容性說明不然裝上去可能根本不生效。4.2 手動安裝 skill 的完整步驟假設你在 GitHub 上找到了一個想要的 skill手動安裝的流程大概是這樣的把倉庫 clone 到本地或者直接下載 zip 包解壓找到里面包含SKILL.md的目錄通常一個 skill 一個目錄把整個 skill 目錄復制到你項目的.skills文件夾下檢查SKILL.md里的 trigger 條件是否和你的項目場景匹配不匹配就改一下重啟你的 AI 編程工具讓它重新掃描 skill 目錄在對話里測試一下看 AI 能不能正確加載注意有些 skill 會依賴外部腳本或者特定的環(huán)境變量裝之前一定要看 README 里的依賴說明不然跑起來會報錯。4.3 常見安裝問題排查我遇到過幾次裝完不生效的情況排查下來基本是這幾個原因問題現(xiàn)象可能原因解決方法AI 完全不加載 skill目錄結構不對SKILL.md 不在正確位置確認 skill 目錄直接放在 .skills 下不要多套一層加載了但執(zhí)行報錯缺少依賴或環(huán)境變量看 SKILL.md 里的依賴說明補齊缺失項多個 skill 沖突trigger 條件重疊精簡 trigger或者改成顯式調(diào)用改了 skill 不生效工具緩存了舊版本重啟工具或者手動清除緩存目錄4.4 使用別人 skill 的注意事項別人的 skill 再好也是為別人的項目場景寫的。直接拿來用之前我建議至少做三件事讀一遍 SKILL.md 的每一步確認沒有你不希望 AI 執(zhí)行的操作檢查示例是否符合你的項目規(guī)范不符合就改掉在測試分支上先跑一遍確認沒問題再合到主分支。還有一點很重要不要同時裝太多功能重疊的 skill。比如你裝了兩個都是處理代碼格式化的 skillAI 在觸發(fā)的時候就會猶豫甚至可能兩個都加載導致指令沖突。我的做法是同類功能只保留一個其他的要么刪掉要么改成手動調(diào)用。5. 進階玩法把 Skills 組合起來解決復雜任務5.1 Skill 之間的依賴和調(diào)用單個 skill 能解決的問題是有限的真正有意思的是把多個 skill 組合起來。比如你可以有一個 skill 負責代碼規(guī)范檢查另一個 skill 負責生成測試用例第三個 skill 負責更新文檔。當你說“幫我重構這個模塊”的時候AI 可以依次加載這三個 skill按順序執(zhí)行。實現(xiàn)這種方式的關鍵是在 skill 的步驟里顯式引用其他 skill。比如在重構 skill 的最后一步寫“調(diào)用 test-generation skill 為修改后的代碼生成測試”。這樣 AI 就知道該去加載哪個 skill 了。5.2 用 skill 做數(shù)學建模和數(shù)據(jù)分析我看到不少人在討論數(shù)學建模比賽里怎么用 skills。說實話這個場景特別適合。數(shù)學建模的流程通常是固定的理解問題、選擇模型、寫代碼求解、分析結果、寫論文。你可以把每個階段做成一個 skill比如“模型選擇 skill”里寫清楚什么類型的問題該用什么模型“論文寫作 skill”里規(guī)定好摘要、假設、符號說明的格式。這樣不管題目怎么變AI 都能按同樣的流程幫你推進不會因為換了個題目就完全不知道從哪下手。我試過用這種方式輔助寫代碼效率提升很明顯尤其是那些重復性的數(shù)據(jù)預處理和可視化部分。5.3 團隊協(xié)作中的 skill 管理如果是團隊一起用 skill我強烈建議把.skills目錄納入 Git 管理并且制定一個簡單的 review 流程。誰想加新 skill提個 PR其他人看一下 trigger 條件有沒有沖突、步驟有沒有歧義、禁忌有沒有遺漏。合并之后所有人拉下來就能用同一套能力。另外skill 也要寫 changelog。每次改了什么都記一下這樣當 AI 的行為發(fā)生變化時你能快速定位是哪個 skill 的哪次改動導致的。6. 我踩過的坑和總結出來的經(jīng)驗6.1 不要試圖用一個 skill 解決所有問題我一開始寫 skill 的時候總想寫一個“萬能 skill”把所有規(guī)范都塞進去。結果就是 trigger 條件寫得特別寬泛AI 動不動就加載它加載之后又因為步驟太多太雜執(zhí)行到一半就亂了。后來我學乖了一個 skill 只做一件事做精做透。需要多個能力的時候用組合的方式解決而不是堆在一個文件里。6.2 trigger 要具體但不要過于狹窄trigger 寫得太寬skill 會被頻繁誤加載寫得太窄又可能該加載的時候不加載。我的經(jīng)驗是用具體的動作詞加對象詞比如“當用戶要求重命名組件文件時”就比“當用戶提到組件時”好得多。同時可以留一兩個稍微寬泛的 trigger 作為兜底但不要超過三個。6.3 示例比描述更有用AI 對示例的敏感度遠高于對抽象描述的理解。與其寫“代碼要整潔”不如直接給一段整潔的代碼和一段不整潔的代碼讓 AI 自己去對比。我后來寫 skill 的時候示例部分花的時間比步驟部分還多但效果確實好很多。6.4 定期清理不再使用的 skill項目在變skill 也要跟著變。有些 skill 可能半年前很有用但現(xiàn)在項目結構改了它已經(jīng)過時了。如果不清理這些過時的 skill 會干擾 AI 的判斷。我一般每個月花十分鐘過一遍.skills目錄把不再用的刪掉把需要更新的更新一下。6.5 不要忽略安全邊界最后說一個容易被忽略的點skill 里一定要寫清楚AI 不能做什么。比如不能自動提交代碼、不能修改生產(chǎn)環(huán)境配置、不能刪除文件而不詢問。這些邊界看起來是常識但 AI 在執(zhí)行復雜任務的時候如果沒有明確限制真的可能會做出你意想不到的操作。我在禁忌部分通常會寫三到五條硬性規(guī)則實測下來能避免絕大多數(shù)誤操作。關于 skills 這個話題能聊的還有很多比如怎么給 skill 做版本管理、怎么在 CI 里自動校驗 skill 的格式、怎么把 skill 和現(xiàn)有的 lint 工具結合起來。但上面這些是我覺得最核心、最實用的部分。如果你剛開始接觸建議先從寫一個最簡單的 skill 開始跑通了再慢慢加復雜度。別一上來就搞大而全的東西那樣很容易受挫。