最近 AI 編程圈子里好幾個(gè)群里都在刷一個(gè)詞skills。Claude Code 的 skills、Codex 的 skills、OpenCode 也來(lái)湊熱鬧連華為杯、數(shù)學(xué)建模的比賽群里都有人問(wèn)“有沒有好用的 skills 推薦”。粗看像是某個(gè)新插件其實(shí)它是 Agent 時(shí)代的一種“能力封裝機(jī)制”——把一套完整的指令、規(guī)則、工作流打包成一個(gè)文件夾讓 AI 在特定任務(wù)里直接調(diào)用。我最早接觸 skills 是今年年初調(diào) Claude Code 的時(shí)候當(dāng)時(shí)一直被它“每次都要重復(fù)交代背景”折磨。后來(lái)試著把一套代碼審查規(guī)范寫成了 skills效果出奇好AI 不用再臨時(shí)被灌輸規(guī)則行為穩(wěn)定了很多。之后我又陸續(xù)在 GitHub 上下載過(guò)別人寫好的 skills也自己動(dòng)手寫過(guò)幾個(gè)一步步踩了不少坑。這篇就把我這些實(shí)操經(jīng)驗(yàn)整理出來(lái)聊聊 skills 到底是什么、怎么手動(dòng)裝、怎么寫、哪些值得收藏以及最常見的幾個(gè)問(wèn)題怎么排查。如果你也是那種不想每次開新會(huì)話就從頭教 AI 一遍的人這篇文章應(yīng)該對(duì)你有用。1. Skills 到底是什么把“臨時(shí)抱佛腳”變成“能力封裝”1.1 一個(gè)很常見的痛點(diǎn)用過(guò) Claude Code、Codex 這類編程 Agent 的朋友應(yīng)該都有體會(huì)AI 很強(qiáng)但很“健忘”。你上次跟它說(shuō)好的代碼風(fēng)格、不要做的事、必須遵守的流程換一個(gè)新的對(duì)話窗口就全不認(rèn)了。于是每次開工前都要苦口婆心地寫一大段背景說(shuō)明要是遇到復(fù)雜任務(wù)光“輸入上下文”就得花十幾分鐘。這就是 skills 出現(xiàn)的直接原因——把這些反復(fù)交代的經(jīng)驗(yàn)、規(guī)則、規(guī)范打包成一個(gè)可復(fù)用的“技能包”。裝進(jìn)工具之后AI 遇到對(duì)應(yīng)場(chǎng)景會(huì)自動(dòng)加載相關(guān)技能不用你每次重新教。簡(jiǎn)單理解它就是給 AI 編程助手的“上崗培訓(xùn)工作手冊(cè)”。1.2 技能的三個(gè)形態(tài)規(guī)則、工具、模板Anthropic 官方博客里提到過(guò)一個(gè)很精辟的說(shuō)法skills 可以用三個(gè)詞解釋——rules規(guī)則、tools工具、templates模板。我自己用下來(lái)的理解是這樣的rules 形態(tài)把行為規(guī)則寫清楚比如“變量命名必須用 camelCase”“提交信息必須遵循 Conventional Commits”。這種技能不調(diào)用外部命令純粹約束 AI 的行為讓它別亂來(lái)。tools 形態(tài)技能里包含腳本讓 AI 在執(zhí)行任務(wù)時(shí)可以調(diào)用命令行工具。比如寫一個(gè)“批量壓縮圖片”的 skillsAI 會(huì)先看技能說(shuō)明再調(diào)用里面的 Python 腳本去干活。templates 形態(tài)適合高頻重復(fù)任務(wù)比如“生成一篇技術(shù)博客”技能里帶好了 Markdown 模板、章節(jié)結(jié)構(gòu)、SEO 要求AI 直接按模板填充內(nèi)容。這三種形態(tài)通?；旌显谝黄?。一個(gè)完整的 skills 往往既有規(guī)則約束也有腳本輔助還帶輸出模板這也正是它的靈活之處。1.3 為什么突然這么火Skills 能火起來(lái)有幾個(gè)現(xiàn)實(shí)原因。一是 Agent 類工具普及之后大家發(fā)現(xiàn)“上下文窗口再大也是有限”的與其每次塞一堆背景資料不如把常用能力固化成 skill既省 token 又穩(wěn)定。二是 Claude Code 和 Codex 都把 skills 作為官方功能推等于給這個(gè)格式定了標(biāo)準(zhǔn)三是社區(qū)里已經(jīng)有大量現(xiàn)成 skills 可以直接下載生態(tài)很快就起來(lái)了。你可以把 skills 想象成給 AI 配了一本“專項(xiàng)工作手冊(cè)”不同的任務(wù)翻不同的手冊(cè)比每次都從頭看書高效得多。理解了這層邏輯后面安裝、寫技能、調(diào)優(yōu)就都順理成章了。2. 認(rèn)識(shí) Skills 的標(biāo)準(zhǔn)結(jié)構(gòu)一份 SKILL.md 的解剖2.1 核心只在一份 SKILL.md一個(gè) skills 本質(zhì)上是一個(gè)目錄里面最關(guān)鍵的文件叫SKILL.md。這個(gè)命名基本是社區(qū)公認(rèn)的約定Claude Code、Codex、OpenCode 都默認(rèn)它。雖然不同工具的加載細(xì)節(jié)略有差別但核心思路一致——先看 SKILL.md再按里面的說(shuō)明去執(zhí)行。我拆解過(guò)一份社區(qū)里口碑不錯(cuò)的 skills它的SKILL.md開頭長(zhǎng)這樣--- name: code-reviewer description: 用于執(zhí)行代碼審查重點(diǎn)檢查安全性、性能與可維護(hù)性適用于 PR 提交前或代碼合并前的檢查場(chǎng)景。 allowed-tools: - rg - sed ---name是技能名description是給 AI 看的“何時(shí)該用這個(gè)技能”的標(biāo)簽allowed-tools是允許調(diào)用的命令白名單。別小看這個(gè)description它直接決定 AI 能不能在正確時(shí)機(jī)想起調(diào)用這個(gè)技能。寫得太籠統(tǒng)AI 該用的時(shí)候不用寫得太窄又容易跟別的技能混淆。2.2 正文的“漸進(jìn)式披露”原則Anthropic 在官方文檔里提過(guò)一個(gè)很重要的設(shè)計(jì)原則叫 “progressive disclosure”翻譯過(guò)來(lái)就是“漸進(jìn)式披露”。意思是 SKILL.md 正文不應(yīng)該一開始就把所有細(xì)節(jié)砸出來(lái)而是分層次展開先寫這個(gè)技能是干什么的再寫關(guān)鍵規(guī)則最后才是詳細(xì)操作步驟。這樣 AI 先看概覽只有當(dāng)任務(wù)確實(shí)需要深入時(shí)才會(huì)加載更多內(nèi)容。我模仿這個(gè)結(jié)構(gòu)寫過(guò)一份“博客文章生成”技能正文大致是# 博客文章生成技能 ## 適用場(chǎng)景 - 撰寫技術(shù)分享文章、產(chǎn)品介紹文案 - 需要保持統(tǒng)一文風(fēng)、結(jié)構(gòu)化輸出的寫作任務(wù) ## 核心規(guī)則 1. 標(biāo)題必須包含具體關(guān)鍵詞禁止空泛表達(dá)。 2. 段落之間必須自然過(guò)渡禁止 AI 式套路化總結(jié)。 3. 字?jǐn)?shù)控制在 800-1500 字特殊情況另行說(shuō)明。 ## 執(zhí)行步驟 1. 先根據(jù)主題列出大綱交用戶確認(rèn)。 2. 按大綱逐段撰寫每段不少于 150 字。 3. 完成后自查一遍刪除重復(fù)表達(dá)檢查是否有“總之”“綜上所述”等冗余收尾。這種寫法很實(shí)用前面一小段就夠 AI 判斷該不該用后面才是詳細(xì)參數(shù)和步驟。不要把說(shuō)明書寫得像長(zhǎng)篇小說(shuō)AI 每次載入技能都要讀一遍太長(zhǎng)了反而拖慢速度、稀釋重點(diǎn)。2.3 附加文件腳本、模板、參考素材都往目錄里塞除了 SKILL.md技能目錄里通常還放著其他輔助文件。比如我寫過(guò)的一個(gè)“批量壓縮圖片”技能目錄結(jié)構(gòu)是這樣的image-compressor/ ├── SKILL.md ├── scripts/ │ └── compress.py └── templates/ └── output-report.mdSKILL.md里只寫了“調(diào)用 scripts/compress.py 處理圖片輸出報(bào)告按 templates/output-report.md 的格式來(lái)”具體代碼邏輯都放在腳本里。這種做法的好處是正文保持精簡(jiǎn)復(fù)雜的邏輯交給腳本AI 只需要知道“該做什么、怎么調(diào)用”不用理解每一行代碼。2.4 命名空間和目錄命名的門道目錄名最好用 kebab-case小寫加連字符比如code-reviewer、image-compressor。有些工具對(duì)目錄名敏感比如 Codex 就要求技能目錄名匹配SKILL.md的name字段不一致可能導(dǎo)致加載失敗。目錄名同時(shí)也會(huì)出現(xiàn)在 AI 的上下文里太長(zhǎng)太啰嗦會(huì)在無(wú)形中占掉 token所以盡量短且表意清晰。3. 手動(dòng)安裝 GitHub 上的 Skills從克隆到生效3.1 先搞清楚你的運(yùn)行環(huán)境網(wǎng)上很多人問(wèn)“怎么手動(dòng)裝 GitHub 上的 skills”其實(shí)第一步不是去 clone 倉(cāng)庫(kù)而是先搞清楚你用的是哪個(gè)工具。不同工具的 skills 目錄位置不一樣Claude Code 認(rèn).claude/skills/Codex 用~/.codex/skills/OpenCode 有自己的一套約定。裝錯(cuò)位置等于白裝AI 根本找不到。裝之前可以用--version先看一眼工具版本。skills 功能迭代很快老版本可能根本不支持最好升級(jí)到最新版再動(dòng)手。我自己就吃過(guò)虧早先裝的 Claude Code 版本過(guò)低把技能放好幾天都不生效查了半天才發(fā)現(xiàn)是要升級(jí)。3.2 Claude Code 的手動(dòng)安裝方式以 Claude Code 為例手動(dòng)安裝一個(gè) skills 的完整步驟大概是找到項(xiàng)目或全局的 skills 目錄。項(xiàng)目級(jí)是當(dāng)前項(xiàng)目下的.claude/skills/全局的話通常在用戶主目錄下macOS/Linux 是~/.claude/skills/。把 GitHub 倉(cāng)庫(kù)里的技能文件夾復(fù)制進(jìn)去?？梢灾苯觛it clone整個(gè)倉(cāng)庫(kù)再拷也可以只下載那個(gè)技能目錄。確認(rèn)目錄里有SKILL.md文件夾命名符合 kebab-case。重啟 Claude Code讓技能被掃描加載。# 示例把名為 review-buddy 的技能裝到項(xiàng)目級(jí)目錄 mkdir -p .claude/skills cp -r ~/Downloads/review-buddy .claude/skills/ ls -la .claude/skills/review-buddy/裝完之后可以跟 AI 確認(rèn)一句“你有哪些可用技能”看它能不能列出你剛裝的那個(gè)。如果列不出來(lái)先檢查目錄位置和命名這是成功率最高的兩個(gè)原因。3.3 Codex 和 OpenCode 的做法OpenAI 的 Codex CLI 對(duì) skills 的支持也很積極社區(qū)里有人稱之為 “codex skills”。安裝上Codex 默認(rèn)找~/.codex/skills/同樣也是把技能目錄丟進(jìn)去就行。有些版本支持codex skills install這類子命令但熟練之后你會(huì)發(fā)現(xiàn)手動(dòng)復(fù)制其實(shí)更直觀——因?yàn)槟隳芡耆瓶匮b了什么。OpenCode 這邊稍微麻煩一點(diǎn)不同版本差異挺大。我自己用得不多建議以它的官方文檔為準(zhǔn)。但無(wú)論如何記住一個(gè)底層邏輯——skills 就是一組約定好的目錄文件手動(dòng)裝的本質(zhì)就是把這些文件放到工具會(huì)掃描的位置。這個(gè)思路通了工具再怎么換你都不會(huì)慌。3.4 用符號(hào)鏈接代替復(fù)制我后來(lái)用得更多的其實(shí)是符號(hào)鏈接而不是復(fù)制。把下載好的 skills 倉(cāng)庫(kù)放在一個(gè)統(tǒng)一目錄比如~/skills-library/然后在項(xiàng)目的.claude/skills/里建符號(hào)鏈接ln -s ~/skills-library/review-buddy .claude/skills/review-buddy這樣做的最大好處是方便更新GitHub 上的原倉(cāng)庫(kù)一git pull所有用到它的項(xiàng)目都跟著更新了。缺點(diǎn)是如果你把帶符號(hào)鏈接的項(xiàng)目發(fā)給別人對(duì)方會(huì)看到一堆斷鏈另外 Windows 上建符號(hào)鏈接還得開開發(fā)者模式或者用管理員終端。個(gè)人開發(fā)機(jī)用符號(hào)鏈接很爽團(tuán)隊(duì)協(xié)作還是老實(shí)復(fù)制吧。3.5 驗(yàn)證技能是否真的生效裝完不等于生效。最直接的驗(yàn)證方法是讓 AI 處理一個(gè)跟該技能匹配的小任務(wù)觀察它的行為是否明顯被技能約束了。比如我裝了個(gè) Python 代碼風(fēng)格檢查的技能就故意寫一段snake_case風(fēng)格代碼看 AI 會(huì)不會(huì)提醒我改成PEP8風(fēng)格、并主動(dòng)調(diào)用技能里的檢查腳本。也可以看日志。Claude Code 這類工具有 debug 模式會(huì)打印出加載了哪些 skill、調(diào)用了哪些文件。如果日志里壓根沒出現(xiàn)你那個(gè)技能的名字那就說(shuō)明加載路徑有問(wèn)題或description寫得太偏AI 根本沒意識(shí)到該用。4. 自己動(dòng)手開發(fā)一個(gè) Skills以“數(shù)模論文潤(rùn)色”為例4.1 為什么推薦從自己的場(chǎng)景出發(fā)寫有人喜歡到處收集 skills裝上幾十個(gè)結(jié)果常用的沒幾個(gè)。我的建議是先別急著囤試著從自己的高頻任務(wù)里挑一個(gè)來(lái)寫。寫技能的過(guò)程特別能加深對(duì) Agent 工作方式的理解——你需要把自己的經(jīng)驗(yàn)翻譯成 AI 能讀懂的規(guī)則這不是簡(jiǎn)單的“提需求”而是梳理方法論的過(guò)程。拿數(shù)學(xué)建模比賽來(lái)說(shuō)每年都有學(xué)生在群里問(wèn)“有沒有好用的數(shù)模 skills”。其實(shí)數(shù)模論文潤(rùn)色這種高頻任務(wù)就很適合自己寫個(gè)技能。4.2 需求拆解把經(jīng)驗(yàn)翻譯成指令寫技能第一步不是動(dòng)筆寫 Markdown而是想清楚這個(gè)任務(wù)里AI 需要哪些知識(shí)要遵守什么規(guī)則按什么順序做以“數(shù)模論文潤(rùn)色”為例我當(dāng)時(shí)的拆解結(jié)果是需要理解數(shù)模論文的基本結(jié)構(gòu)摘要、問(wèn)題分析、模型假設(shè)、模型建立、求解、靈敏度分析、優(yōu)缺點(diǎn)。需要知道摘要的重要性數(shù)模論文的摘要相當(dāng)于門面要能單看摘要就了解整篇文章的工作。需要遵守學(xué)術(shù)表達(dá)規(guī)范避免口語(yǔ)化、避免“大概”“差不多”、規(guī)范使用數(shù)學(xué)符號(hào)。需要輸出修改說(shuō)明不能只改完還要告訴用戶為什么這么改。把這些想清楚之后寫 SKILL.md 就快了。4.3 編寫 SKILL.md 的幾個(gè)實(shí)操細(xì)節(jié)動(dòng)手寫的時(shí)候有幾個(gè)細(xì)節(jié)值得留意。一是description里一定要帶上觸發(fā)場(chǎng)景比如“適用于數(shù)模論文的摘要潤(rùn)色、邏輯梳理、用語(yǔ)規(guī)范”這樣 AI 在遇到“幫我改改摘要”時(shí)才能自動(dòng)調(diào)起來(lái)。二是在正文里寫清楚輸入和輸出格式。我一般會(huì)規(guī)定AI 必須先重述用戶的核心需求再逐段給出修改意見最后輸出完整潤(rùn)色稿。這個(gè)“先重述需求再動(dòng)手”的規(guī)則能大幅減少 AI 自作主張的情況。三是給 AI 幾個(gè)反面例子。比如“禁止在潤(rùn)色時(shí)加入原文沒有的公式推導(dǎo)”很多 AI 一潤(rùn)色就喜歡“發(fā)揮”加一堆看似高深的推導(dǎo)其實(shí)完全偏離了論文原意。把這類禁忌寫進(jìn)去能省很多返工時(shí)間。4.4 迭代調(diào)優(yōu)把每次不滿意都沉淀成規(guī)則初版技能極少一次寫到位。我寫好的第一個(gè)版本用起來(lái)還是會(huì)出現(xiàn)段落過(guò)度發(fā)揮、術(shù)語(yǔ)不一致的情況。后來(lái)養(yǎng)成一個(gè)習(xí)慣每次用技能后把不滿意的地方記下來(lái)回 SKILL.md 里補(bǔ)一條規(guī)則。比如“某個(gè)概念在全文中必須使用同一譯名”“不允許在模型假設(shè)部分泛泛而談”。這么迭代了幾輪之后技能的穩(wěn)定度明顯提升。這個(gè)過(guò)程很像訓(xùn)練一個(gè)新同事第一次交代完總會(huì)有遺漏但每次都補(bǔ)一點(diǎn)后面就越用越順。5. 值得收藏的 Skills 源與場(chǎng)景化推薦5.1 官方源與社區(qū)聚合站點(diǎn)GitHub 上有個(gè)awesome-claude-skills之類的項(xiàng)目匯聚了大量社區(qū)技能裝的時(shí)候可以先去這種聚合倉(cāng)庫(kù)里翻。Anthropic 的官方倉(cāng)庫(kù)里也放了一批示例技能質(zhì)量較高適合當(dāng)模板參考。用英文搜 “awesome skills” 或 “skills marketplace” 能找到不少新的聚合目錄中文社區(qū)里也有不少博主在整理但質(zhì)量參差不齊裝之前最好看一下倉(cāng)庫(kù)的 star 數(shù)和最近更新日期。5.2 按場(chǎng)景優(yōu)先推薦的實(shí)用組合這里列幾個(gè)我用下來(lái)覺得真能提效、也符合社區(qū)熱度的場(chǎng)景組合寫作與內(nèi)容方向blog-writer帶文章大綱模板與 SEO 規(guī)則適合高頻輸出技術(shù)博客。meeting-notes把會(huì)議記錄整理成結(jié)構(gòu)化摘要帶行動(dòng)項(xiàng)提取規(guī)則。代碼與工程方向code-reviewer代碼審查技能嚴(yán)格檢查安全、性能、可維護(hù)性。git-commit-helper自動(dòng)生成 Conventional Commits 規(guī)范的提交信息這個(gè)我每天都在用。數(shù)學(xué)建模與數(shù)據(jù)分析方向math-model-reviewer檢查數(shù)模論文結(jié)構(gòu)完整性和邏輯漏洞。>