1. Skills 到底是什么一次搞懂這輪新玩法的底層邏輯最近半年AI 編程助手圈子里最讓我覺得值得花時間研究的概念就是 skills。我最早是在 Claude Code 里接觸到的當(dāng)時團隊里一個同事把代碼評審的規(guī)范做成了一個技能包丟到共享倉庫里讓大家批量安裝效果出奇地好。后來發(fā)現(xiàn) Codex、OpenCode 也都在往這個方向走GitHub 上各種skills 推薦常用 skills 源網(wǎng)站的熱度一直沒下去。但我也看到大量用戶把 skills 等同于提示詞模板覺得換了個名字而已。說實話這種理解會耽誤很多事。一個 skill 和一個 prompt 最大的區(qū)別在于它是一套有邊界、可命名、可復(fù)用、可被 AI 主動檢索的能力模塊。它不是塞進上下文里的一段話而是一個結(jié)構(gòu)化的包。你可以把它理解成給 AI 裝一個可隨時調(diào)用的小插件平時不占對話空間一旦任務(wù)相關(guān)AI 會自動識別到這個該用技能 X 來處理然后才把技能內(nèi)容加載進來。這個機制帶來的直接好處是你不用再每回手動復(fù)制粘貼大段提示詞也不用擔(dān)心項目一復(fù)雜、上下文一長技能就淹沒在無關(guān)信息里。在這一章里我不打算講太玄的理論只想把 skills 的結(jié)構(gòu)、加載機制以及它到底解決了什么痛點說清楚。這是后面所有實操的基礎(chǔ)也是你判斷該不該自己寫一個技能時的核心依據(jù)。1.1 一個 Skill 的典型構(gòu)成一個標(biāo)準(zhǔn)技能包的目錄結(jié)構(gòu)通常長這樣my-skill/ ├── SKILL.md ├── scripts/ ├── references/ └── assets/最關(guān)鍵、唯一必需的文件是SKILL.md。它的開頭是 YAML 格式的元信息包含name技能名稱、description技能描述之后是正文指令。scripts/放可執(zhí)行腳本或輔助程序references/放參考文檔、代碼片段、樣例輸出assets/放靜態(tài)資源或模板?？雌饋聿粡?fù)雜但要注意幾點。第一元信息的質(zhì)量決定 AI 會不會用這個技能。description不能寫成一個幫你做代碼審查的工具這種毫無觸發(fā)點的廢話。好的描述是這樣的對項目代碼變更進行系統(tǒng)性審查重點關(guān)注安全性、性能、可維護性問題適用于提交前檢查、Pull Request 評審前后階段。 這段話包含了適用的任務(wù)場景AI 一看到代碼審查相關(guān)指令就會想到這個技能。第二正文指令決定 AI 的實際表現(xiàn)。它不需要很長但必須把思考順序、執(zhí)行步驟、輸出格式寫清楚。我給自己的要求是一個技能正文盡量控制在 300 到 800 字之間說清楚先看什么后看什么什么情況下輸出什么結(jié)構(gòu)就行。第三支持資源不是越多越好。很多人喜歡往技能包里塞一堆文檔結(jié)果 AI 加載時上下文容量被撐爆反而拖慢響應(yīng)。我一般只在技能涉及外部工具、公式、數(shù)據(jù)模板時才放資源且只放必要的那一兩份。1.2 為什么 Skills 能提升 AI 的表現(xiàn)上限我從自己的使用體驗說一個觀點Skills 最大的價值不是讓模型變聰明而是讓模型的每分力氣都花在刀刃上。模型的能力上限其實是固定的但有效輸出質(zhì)量會隨上下文質(zhì)量大幅波動。你把項目規(guī)范、編碼風(fēng)格、安全紅線、行業(yè)常識全部混在一段對話里模型很容易被無關(guān)信息帶偏反過來如果你能在恰當(dāng)?shù)臅r機只把相關(guān)內(nèi)容交給它它的表現(xiàn)會穩(wěn)定非常多。Skills 就是這個恰當(dāng)篩選的機制。舉個例子。我有一次讓 AI 幫我審查一個前端項目的改動如果不掛技能它會關(guān)注一些雞毛蒜皮的地方比如某個變量命名不夠優(yōu)雅、某段代碼可以拆成函數(shù)——不是說這些不對而是它不是代碼評審最該抓的東西。掛上寫好的 code-review 技能后它的行為馬上變了先去讀 diff再看有沒有重復(fù)請求、內(nèi)存泄漏、可訪問性受損最后按嚴(yán)重程度分級輸出。這就是技能在起作用它把人的工程經(jīng)驗編碼進了模型的決策路徑。另一個容易忽略的好處是團隊協(xié)作。以前團隊里定義完代碼規(guī)范想執(zhí)行約束得靠每個人自己遵守。現(xiàn)在我可以把規(guī)范直接做成技能包放進倉庫讓同事一次性安裝大家用同一套審查規(guī)則輸出質(zhì)量自然對齊。這是純提示詞做不到的也是 skills 能在社區(qū)里快速火起來的核心原因。2. 手動安裝 GitHub 上的 Skills以 Claude Code 為例的完整實操熱詞里那句claude code 怎么手動裝 github 上的 skills被搜索量很高說明很多人都在這一步卡住了。我理解你的感受GitHub 上的技能包那么多下載下來卻不知道該往哪放。其實安裝的本質(zhì)非常簡單就是把倉庫里的技能文件夾放到工具指定的技能目錄下讓工具能掃描到。我用 Claude Code 把整個過程拆開講。2.1 安裝前后目錄結(jié)構(gòu)與最短路徑Claude Code 的默認(rèn)技能目錄是~/.claude/skills。安裝前先確認(rèn)這個目錄存在mkdir -p ~/.claude/skills ls ~/.claude/skills如果目錄還空著說明你還沒裝過任何技能安裝就從零開始。如果你用的是 Windows路徑類似是C:\Users\你的用戶名\.claude\skills原理一致。到 GitHub 上找一個技能倉庫比如某個人寫的frontend-review-skill倉庫內(nèi)部結(jié)構(gòu)通常是frontend-review-skill/ ├── SKILL.md ├── scripts/ └── README.md你要做的就是把包含SKILL.md的那個文件夾整體復(fù)制到~/.claude/skills/下。這樣做完技能目錄的最終結(jié)構(gòu)應(yīng)該是~/.claude/skills/frontend-review-skill/SKILL.md這里有個非常常見的坑很多人用git clone直接把整個倉庫克隆進技能目錄導(dǎo)致結(jié)構(gòu)變成~/.claude/skills/frontend-review-skill/frontend-review-skill/SKILL.md多了一層嵌套工具就識別不了。判斷標(biāo)準(zhǔn)很簡單SKILL.md必須在技能文件夾的第一層不能藏在更深的路徑里。2.2 命令實操與常見報錯我喜歡的安裝方式是用一條命令完成克隆并安放cd ~/.claude/skills git clone https://github.com/你的用戶名/你的技能倉庫.git克隆完后進入倉庫檢查結(jié)構(gòu)如果發(fā)現(xiàn)倉庫根目錄下就是SKILL.md那這個技能可以直接用如果倉庫里同時包含多個技能比如每個技能一個子目錄那你得把每個技能子目錄單獨復(fù)制出來cp -r ~/.claude/skills/大倉庫/技能A ~/.claude/skills/技能A_component/ cp -r ~/.claude/skills/大倉庫/技能B ~/.claude/skills/技能B_component/裝完技能不等于完事。我建議你立刻驗證一下直接打開 Claude Code給出一個和技能描述吻合的任務(wù)觀察它是否自動加載了對應(yīng)技能。如果沒有任何反應(yīng)按下面三個方向排查。報錯一目錄層級不對。檢查SKILL.md是否在技能文件夾第一層不要在技能文件夾里面再包一層同名文件夾。報錯二YAML 元信息格式錯誤。name和description頂格寫冒號后面要有空格縮進別亂用 Tab用空格。格式錯了工具無法解析技能頭部會直接跳過這個技能。報錯三描述寫得太模糊。如果description是代碼審查這種泛泛的詞AI 可能在遇到任務(wù)時判斷不出來該用這個技能。改成帶觸發(fā)場景的描述比如適用于提交前檢查或代碼重構(gòu)評審場景。2.3 遠程倉庫安裝的正確姿勢與安全提示有些技能倉庫提供了自動安裝腳本命令往往是curl -fsSL https://example.com/install.sh | bash我的原則是執(zhí)行任何腳本前先下載下來看一眼內(nèi)容再決定是否運行。雖然大多數(shù)倉庫是可信的但先確認(rèn)再執(zhí)行應(yīng)該成為使用開源資源的基本習(xí)慣。你可以先curl -fsSL 地址 -o install.sh打開文件檢查沒有異常行為后再bash install.sh。如果是自己手動從網(wǎng)頁下載 ZIP 包解壓后注意一個問題macOS 默認(rèn)會給 ZIP 解壓出來的目錄加一層__MACOSX隱藏目錄Windows 也可能多出一些輔助文件。這些都不影響使用直接忽略即可但要小心別把壓縮包里的外層文件夾也一并復(fù)制進去。還有一個值得說的點純提示詞型技能只有SKILL.md一個文件不帶腳本幾乎適用于所有工具而帶scripts/的技能對執(zhí)行環(huán)境有依賴。安裝前先看 README搞清楚它依賴的是 Python 還是 Node.js避免裝完才發(fā)現(xiàn)跑不起來。3. 不同業(yè)務(wù)場景的 Skills 推薦清單與選型思路技能裝多了你會發(fā)現(xiàn)真正好用的從來不是那種包羅萬象的全能技能而是針對單一場景做到極致的專用技能。下面我按最近社區(qū)討論熱度最高的三個方向來說前端開發(fā)、數(shù)學(xué)建模競賽、AI 創(chuàng)意內(nèi)容生產(chǎn)。這三個方向最能體現(xiàn) skills 的實用價值。3.1 前端開發(fā)的 Skills 組合前端方向最值得優(yōu)先配置的技能是代碼評審類。一個成熟的 frontend code review 技能應(yīng)該把審查維度固定下來而不是泛泛地看哪里有 bug。我給團隊配置的技能里審查優(yōu)先級大致是是否有重復(fù)或冗余的網(wǎng)絡(luò)請求、是否存在內(nèi)存泄漏風(fēng)險尤其事件監(jiān)聽和定時器、可訪問性是否受損、改動是否破壞了既有狀態(tài)管理邏輯。這種技能輸出的審查意見會非常結(jié)構(gòu)化分為嚴(yán)重問題、建議修復(fù)、可選優(yōu)化三個級別并且會給出具體修復(fù)示例。第二推薦的是組件生成類技能。這種技能內(nèi)置了團隊的目錄約定、命名規(guī)范、常用 UI 組件庫的使用方式AI 生成 React 或 Vue 組件時就會自動遵守這些約束。比如團隊規(guī)定所有頁面級組件文件放在pages/組件級別文件放在components/技能加載后 AI 會自動按這個路徑去生成不會再把文件位置寫得亂七八糟。第三是 TypeScript 類型安全類。這類技能對類型設(shè)計的要求是能用字面量聯(lián)合類型就不用string能用接口正常定義就不用any函數(shù)參數(shù)要顯式標(biāo)注返回類型。實際體驗下來這類型技能能把代碼里的any數(shù)量壓得非常低代碼可維護性提升明顯。我的建議是別一次性裝十幾個前端技能只需要把代碼評審 組件生成 類型安全這三板斧配齊基本能覆蓋日常 80% 的場景。3.2 數(shù)學(xué)建模與競賽場景的 Codex Skills華為杯建模比賽好用的 codex skills這個詞條能進熱搜說明大量參賽者已經(jīng)在嘗試用 AI 工具提升效率。數(shù)學(xué)建模的流程極度結(jié)構(gòu)化非常適合用技能把規(guī)范操作固化下來。我推薦按階段拆成三件套。第一件是數(shù)據(jù)處理技能。它的職責(zé)很窄讀取原始數(shù)據(jù)文件識別字段類型、缺失值和異常值輸出清洗后的標(biāo)準(zhǔn)化數(shù)據(jù)并自動生成描述性統(tǒng)計報告。別小看這一步比賽前期大量時間都耗在數(shù)據(jù)清洗上。第二件是模型選型技能。它內(nèi)部維護了一張問題類型到算法模型的映射表?？吹筋A(yù)測未來值就往時間序列、回歸模型方向走看到分類就自動比較決策樹、SVM、隨機森林甚至淺層神經(jīng)網(wǎng)絡(luò)的適用條件看到優(yōu)化問題就往線性規(guī)劃、動態(tài)規(guī)劃方向帶。它會為每個候選模型給出復(fù)雜度、適用數(shù)據(jù)量和預(yù)期精度的對比幫你更快做決策。第三件是論文排版技能。比賽最痛苦的不是算不出來而是算出來了不知道怎么在論文里講清楚。一個排版的技能會固定摘要結(jié)構(gòu)背景、方法、結(jié)果、結(jié)論四段式、固定圖表編號規(guī)則、固定公式排版方式。LaTeX 用戶尤其推薦配置一個這類技能它能直接輸出標(biāo)準(zhǔn)格式的論文片段節(jié)省大量時間。我個人的體會是別指望一個技能從數(shù)據(jù)處理幫你寫到論文排版那是功能堆疊會互相打架。拆成三個獨立技能反而每個都能保持小而精。3.3 AI 漫劇與創(chuàng)意內(nèi)容生產(chǎn)方向AI 漫劇是內(nèi)容和 AI 技術(shù)結(jié)合的新玩法核心痛點是角色一致性。同一個角色在中景、特寫、不同光線條件下臉不能崩服裝不能變。而普通提示詞換個語氣、換個上下文結(jié)果就飄了。Skills 在這里能做三件事。第一件是角色設(shè)定提煉。把一段描述性的角色介紹壓縮成結(jié)構(gòu)化的穩(wěn)定標(biāo)簽發(fā)型、發(fā)色、瞳色、臉型、服飾特征、標(biāo)志性道具每一個都用短詞固定。這樣后續(xù)所有鏡頭生成都在同一個角色約束集合下工作。第二件是分鏡腳本拆分。把一個 300 字的故事段落切分成 6 到 8 個鏡頭序列每個鏡頭標(biāo)明景別、運鏡、角色狀態(tài)、環(huán)境光線。這個技能的輸出格式一旦固定后續(xù)生成效率會明顯上升。第三件是文生圖參數(shù)固定。同一個技能內(nèi)置風(fēng)格詞、光線詞、負面提示詞的黑名單每次調(diào)用時自動補充上防止畫面風(fēng)格突然變化。如果你正在做 AI 漫劇這類一致性維護技能比任何靈感生成技能都值錢。因為靈感你隨時都有但畫面穩(wěn)定只能靠規(guī)范約束來實現(xiàn)。4. 從零寫一個自己的 Skill結(jié)構(gòu)、命名與調(diào)試要點聊完現(xiàn)成的技能包我想花一整章說說怎么寫自己的技能。只下載別人的你永遠只是使用者真正自己寫一個你會重新理解 AI 工具的設(shè)計邏輯。而且寫一個技能的門檻沒有你想得那么高關(guān)鍵在于思路清晰。4.1 Skill 文件格式與元信息設(shè)計我直接給一個最小可用的SKILL.md示例你就照著這個結(jié)構(gòu)去寫--- name: api-error-debug description: 分析后端接口報錯日志定位錯誤根因適用于 API 聯(lián)調(diào)、線上問題排查、日志分析場景。輸入為錯誤日志或接口返回信息輸出為根因分析報告。 --- # API 接口錯誤排查 你在協(xié)助開發(fā)者排查 API 接口報錯問題。請按以下步驟執(zhí)行 1. 先讀完整的錯誤日志或錯誤響應(yīng)不要跳過任何前綴信息 2. 分類錯誤類型網(wǎng)絡(luò)層、鑒權(quán)層、參數(shù)校驗層、業(yè)務(wù)邏輯層、數(shù)據(jù)庫層 3. 對每類錯誤給出根因判斷標(biāo)準(zhǔn) 4. 按以下結(jié)構(gòu)輸出 - 錯誤類型 - 根因概率排序從高到低 - 每條根因?qū)?yīng)的驗證建議 - 修復(fù)示例如果能在現(xiàn)有代碼上下文中給出注意頭部 YAML 的description這是 AI 將來決定是否加載技能的關(guān)鍵。你應(yīng)該多花十分鐘反復(fù)打磨它。一個技巧是在描述里嵌入任務(wù)動詞和目標(biāo)場景比如分析定位適用于輸入為輸出為這樣 AI 檢索時匹配的維度會更多。正文的編號列表也很關(guān)鍵。我發(fā)現(xiàn)以數(shù)字步驟開頭的指令比自由段落文本更容易讓模型按順序執(zhí)行。指令里可以加約束比如不要貼折行后的代碼這種負面約束效果也很好。你還可以引導(dǎo) AI 的探索行為讓它主動查詢代碼庫或讀取相關(guān)文件。4.2 指令內(nèi)容撰寫的黃金法則寫指令正文這件事我總結(jié)了三條比較實用的法則你自己寫的時候可以直接套用。法則一一個技能只解決一個問題。如果你把寫代碼、寫測試、寫文檔塞進同一個技能AI 會經(jīng)常跑偏。技能不是流程手冊它是單項能力模塊。法則二給出正反例而非抽象規(guī)則。直接對比反例注意代碼規(guī)范。正例函數(shù)命名使用動賓結(jié)構(gòu)例如fetchUserData不要用getData或uData這類模糊命名。正反例比抽象規(guī)則可靠得多因為模型的模仿能力整體強于演繹能力。法則三把輸出結(jié)構(gòu)定死。模型默認(rèn)的輸出習(xí)慣是啰嗦的你要提前告訴它最終報告長什么樣、順序是什么、哪些信息必須包含。比如結(jié)論放最前面緊接著證據(jù)鏈最后才是建議這種有一個明確順序的指令能顯著改善調(diào)試體驗。4.3 本地調(diào)試與效果驗證技能寫完一定要測我的標(biāo)準(zhǔn)流程分三步。第一步檢查元信息是否能被正確解析。進入技能目錄運行l(wèi)s ~/.claude/skills/my-skill/ cat ~/.claude/skills/my-skill/SKILL.md確認(rèn)目錄層級正確、YAML 頭部沒有語法錯誤、正文沒有畸形 Markdown。第二步主動觸發(fā)測試。在對話里明確說請用 my-skill 的方式處理這個問題看模型是否加載技能、是否按照指令順序執(zhí)行。如果模型沒有按步驟來大概率是正文指令寫得太寬泛或被其他指令覆蓋了。第三步誘捕式測試。不給模型任何明確技能名直接給一個含糊但相關(guān)的任務(wù)看它能否根據(jù)description自動選中并加載技能。如果它能做到說明技能的觸發(fā)能力是合格的。很多情況下誘捕式測試失敗了問題都出在description上——描述內(nèi)容沒有覆蓋到實際任務(wù)場景。還有一個通常被忽略的點技能引用腳本時要確認(rèn)執(zhí)行權(quán)限。比如你在scripts/下放了analyze.py那它得是chmod x可執(zhí)行的或者用python顯式調(diào)用。否則 AI 嘗試調(diào)用腳本失敗常常會靜默降級直接繞開技能輸出一個不完整的結(jié)果你還不容易察覺。5. 技能庫、下載源與生態(tài)工具的分布情況現(xiàn)在 GitHub 上的 skill 資源已經(jīng)多到找不過來。很多人到處搜集技能庫網(wǎng)址但真正決定體驗的不是數(shù)量而是你知道去哪找、找什么類型、裝完能不能用。這一章把資源分布的現(xiàn)狀講清楚。5.1 值得關(guān)注的開源技能庫社區(qū)資源目前大致分三類。第一類是綜合型技能集合倉庫。這種倉庫通常一口氣收錄幾十個甚至上百個技能適合新手一次性批量安裝然后逐個體驗。在 GitHub 上搜 awesome claude skills 或 skills collection 能發(fā)現(xiàn)不少這類項目。它們的優(yōu)點是全面缺點是質(zhì)量參差不齊有些技能明顯是湊數(shù)的。我的建議是別全裝挑和你工作流匹配的裝。第二類是框架型項目。它們不只是給技能還給技能定義了一套標(biāo)準(zhǔn)的寫法、參數(shù)接口甚至讓技能之間可以互相調(diào)用。社區(qū)里討論度很高的 superpowers 就是這一類。它解決了一個很現(xiàn)實的問題單一技能只能做單一功能但如果技能之間能協(xié)作就能完成復(fù)雜的多步驟任務(wù)。這類框架學(xué)習(xí)成本高一些但它帶來的能力升級是值得的。第三類是特定領(lǐng)域小倉庫。只解決一個問題比如日志分析、論文潤色、Excel 數(shù)據(jù)清洗。這種倉庫通常質(zhì)量很高但需要你自己有目的地檢索。找的時候可以圍繞業(yè)務(wù)關(guān)鍵字 skills組合比如 excel skills github 或 dataclean skill。5.2 不同工具對 Skills 的兼容性差異必須給大家提個醒skills 目前并沒有統(tǒng)一的行業(yè)標(biāo)準(zhǔn)。Claude Code、Codex、OpenCode 對技能的支持程度和規(guī)范細節(jié)不一樣。我自己用下來Claude Code 的 SKILL.md 形態(tài)比較成熟對 YAML 元信息、腳本資源、文件目錄的解析都比較完善。Codex 也在加這塊能力但在技能加載機制或目錄約定上略有差異尤其對scripts/資源的處理方式不一定直接兼容。OpenCode 目前更多是吸收社區(qū)規(guī)范玩家眾多功能迭代更快。所以我建議你在安裝技能包時先看一下它是否是純提示詞型。如果是純SKILL.md那幾乎在所有工具里都能通用。如果帶了scripts/和特定依賴就要考察一下目標(biāo)工具的腳本執(zhí)行方式是不是匹配。一句話總結(jié)能復(fù)用通用格式的技能就不要鋌而走險硬塞帶依賴的技能。技術(shù)選型上我給一個更務(wù)實的建議如果你剛開始接觸選一個主力工具研究透徹即可不要同時在幾款工具里各裝一份同類技能。把主力的技能機制、目錄結(jié)構(gòu)、腳本加載方式搞清楚再去橫向遷移效率會高很多。6. Skills 的清理、邊界與長期維護經(jīng)驗熱詞里有一條很具體的問題問tibo 關(guān)于清理 skills 的方法推薦一看就是被技能堆積問題折磨過的人。我自己大概裝過五六十個技能最后穩(wěn)定使用的不到二十個。大部分技能不是沒用而是在特定場景下才偶發(fā)揮價值。但如果不管不顧技能庫就會變成數(shù)字雜物間AI 每次掃描負載增大還可能選錯技能。這一章把我清理和維護的經(jīng)驗完整分享一下。6.1 什么時候該清理 Skills我的判斷標(biāo)準(zhǔn)很直接一個技能如果連續(xù)兩周都沒被自動加載過一次它就進入了退化區(qū)間。這里的沒被加載指的不是你沒用過而是你在對話里發(fā)出相關(guān)任務(wù)時AI 并沒有主動選中它。另一個需要清理的信號是技能之間發(fā)生沖突。比如你有兩個代碼審查類技能它們的描述高度接近AI 有時加載 A 有時加載 B輸出風(fēng)格完全不一樣。這種結(jié)果對用戶是災(zāi)難因為每次輸出都不可預(yù)測。正確做法是果斷合并。還有一個容易忽略的是腳本依賴過期的技能。技能引用的 Python 包升級了、API 字段變了或者工具鏈版本提升了舊技能就會過保質(zhì)期。這類問題往往在你某天突然用到它時才發(fā)現(xiàn)那時候再排查非常痛苦。定期盤點能減少這類突發(fā)問題。6.2 清理方法論與推薦做法我的清理流程一般分三步。第一步是盤點。進入技能目錄把每個技能包列出來ls ~/.claude/skills/逐個打開SKILL.md看name和description問自己三個問題這個技能在過去兩周有沒有被加載過它解決的問題我現(xiàn)在還用不用它和別的技能有沒有重復(fù)第二步是分類。我習(xí)慣在~/.claude/下建一個skills_archive/文件夾把冷門、暫時不用但以后可能用到的技能移過去。這不等于刪掉只是讓主目錄更干凈。命令很簡單mkdir -p ~/.claude/skills_archive mv ~/.claude/skills/冷門技能 ~/.claude/skills_archive/第三步是合并。職責(zé)重疊的技能合并成一個。合并不是簡單地把兩段文字拼在一起而是把兩個技能的描述和指令重新梳理成結(jié)構(gòu)化模式。比如把frontend review和accessibility check合并成web-quality review描述涵蓋兩類任務(wù)指令里用條件分支區(qū)分場景。做完這步技能庫通常會縮水一半但效果會明顯提升。6.3 我的維護習(xí)慣與個人經(jīng)驗最后分享幾個我長期堅持的小習(xí)慣。第一我習(xí)慣在技能描述的最后加上日期標(biāo)記。比如在description末尾寫最后驗證2025-07。這樣做的好處是每個月盤點時只要一看描述就能知道哪些技能需要重新測試哪些可以直接退役。日期標(biāo)記雖然看起來不起眼但它能有效防止過期技能繼續(xù)帶病運行。第二我每個季度做一次實測回歸。挑出自己最常用的六到八個技能逐個用誘捕式測試觸發(fā)一遍檢驗它們是否還能被 AI 正確加載、指令是否還適應(yīng)當(dāng)前模型版本。模型升級很頻繁技能描述里的某些措辭可能突然就失效了定期回歸能及時發(fā)現(xiàn)問題。第三我不建議在不同工具里各裝一份同款技能。Claude Code、Codex、OpenCode 各自的加載機制不一樣維護成本會翻倍。挑一個主力工具深入研究它的技能解析邏輯、腳本運行方式、上下文注入機制把它玩透比到處收集技能包要高效得多。我自己的主力工具是 Claude Code平時新發(fā)現(xiàn)一個技能包先手工安裝到它的目錄下測試確認(rèn)效果后再決定是否供其他場景復(fù)用。清理和維護這件事短期內(nèi)看不出多大差別但長期下來它會決定你的 AI 工具到底處于越用越順的狀態(tài)還是裝了很多卻什么也不穩(wěn)定的狀態(tài)。技能庫不是收藏夾少而精永遠比多而雜靠譜。最后再分享一個小技巧給你的技能統(tǒng)一命名規(guī)范比如都用領(lǐng)域-功能的結(jié)構(gòu)像web-perf-audit、>