最近社區(qū)里“skills”這個詞出現(xiàn)頻率高得離譜從“前端開發(fā)skills”到“安卓脫殼skills”再到各類“agent skills測試”“skills下載平臺”幾乎每隔幾天就能看到新的熱詞冒出來。我自己的第一反應(yīng)是這不就是給大模型塞一堆提示詞規(guī)則嗎有什么好稀奇的。但真正動手用了一段時間之后我得承認這個理解太淺了。skills 本質(zhì)上是在重新定義大模型的能力邊界讓一個通用聊天助手變成能按固定套路干活的“崗位專家”。這篇文章我想從個人實踐的角度把 skills 這件事拆開講透它到底是什么、為什么值得折騰、怎么從零寫一個能用的 skill、安裝調(diào)試有哪些坑以及我在實際項目里踩過的各種雷。不吹概念只說怎么落地適合那些已經(jīng)用過 ChatGPT、Claude、Codex 這類工具但還沒搞明白“技能文件”該怎么組織的人也適合想把手頭重復(fù)工作沉淀成可復(fù)用技能的開發(fā)者。哪怕你完全沒寫過代碼照著后面論文潤色那個例子走一遍也能體會到這套邏輯的爽點。1. skills到底是什么1.1 一個 skill 不只是“一段提示詞”很多人第一次接觸 skills看到 README 里那個SKILL.md文件會覺得這不就是 Markdown 寫的 prompt 嗎。表面看確實如此但實際區(qū)別很大。普通 prompt 是一次性的你打一段話模型按這段話執(zhí)行一次。而 skill 是結(jié)構(gòu)化的能力封裝它包含說明文件、參考示例、可執(zhí)行腳本、校驗規(guī)則甚至還有自己的工具調(diào)用邏輯。模型讀到SKILL.md之后不是“聽你指揮一次”而是“學(xué)會了你這套做事方法下次遇到同類任務(wù)能自己按流程走”。我打個比方普通 prompt 像你給實習(xí)生口頭交代“幫我把這份報告潤色一下”實習(xí)生這次干得怎么樣全看心情和悟性。而 skill 等于你給實習(xí)生一份崗位手冊里面寫著“潤色分三步第一步檢查邏輯第二步調(diào)整句式第三步統(tǒng)一術(shù)語每步做完都要輸出中間結(jié)果”手冊旁邊還配了工具、模板和反例。你說哪種方式更可靠。這也是為什么社區(qū)里很多人討論“skills 推薦”“find skills”的時候關(guān)注點都在技能庫的完整度上。一個成熟的 skill 文件通常包含幾個固定部件SKILL.md主說明文件告訴模型這個技能什么時候用、怎么用、輸出格式是什么。scripts/目錄可選存放輔助腳本比如格式化、抓取數(shù)據(jù)、批量處理文件。references/目錄可選放樣例、參考資料、術(shù)語表。配置文件比如skill.json聲明元數(shù)據(jù)、版本、依賴。這個結(jié)構(gòu)意味著 skills 已經(jīng)不只是提示詞技巧而是一套輕量級的“模型編程框架”。你定義流程模型負責(zé)執(zhí)行腳本負責(zé)處理模型做不了的計算和 IO 操作。1.2 為什么叫“技能”而不是“插件”和插件plugin相比skills 更強調(diào)“內(nèi)化”。插件是外部工具模型需要專門調(diào) API 才能用。技能則更像是模型的“動作記憶”它不需要外部系統(tǒng)介入模型讀取說明文件后就能直接表現(xiàn)出對應(yīng)的能力。Claude 官方文檔里有一篇非常出名的分析文章標題就叫《Claude Agent Skills: A First Principles Deep Dive》里面反復(fù)強調(diào)一個觀點skills 的目標是讓 agent 在復(fù)雜任務(wù)中“知道什么時候用什么方法”而不是把所有邏輯前置到系統(tǒng)提示里。從這個角度看安卓脫殼 skills、自動挖洞 skills 這類安全研究方向的熱詞其實一點也不奇怪。逆向工程和漏洞挖掘是高度依賴流程的領(lǐng)域一個經(jīng)驗豐富的安全研究員可以把“脫殼步驟”“動態(tài)調(diào)試路徑”“特征定位方法”固化成 skill讓 agent 按部就班地輔助分析。這也是 skills 被叫做 superpower skills 的原因它確實像是給模型裝上了某種超能力只是這個能力完全由你自己定義。我自己測試過一個小實驗讓同一個模型分別用“普通 prompt 提示詞描述”和“完整 skill 文件”去處理同一批客服工單分類任務(wù)。結(jié)果很直觀用 skill 的那次輸出格式穩(wěn)定、分類標準一致、每單耗時少三分之一。原因不復(fù)雜prompt 模式下模型每次都在重新理解規(guī)則而 skill 模式下規(guī)則是固定的模型只需要對照執(zhí)行。2. 主流實現(xiàn)和生態(tài)現(xiàn)狀2.1 Claude 系 skills 和 Codex skills 的各自風(fēng)格目前最常被提到的兩個實現(xiàn)一個是 Claude 官方市場里的 Agent Skills另一個是 OpenAI Codex 里支持的 skills 集合。兩者目標一致但設(shè)計思路差別挺大。Claude Agent Skills 走的是“文檔驅(qū)動”路線。一個技能本質(zhì)上就是一個文件夾主入口是SKILL.md模型通過讀取這份文檔來決定是否調(diào)用、如何調(diào)用。因為說明文件是自然語言寫的所以技能的創(chuàng)建門檻很低會寫 Markdown 的人就能貢獻技能。官方市場里的技能庫覆蓋了郵件處理、代碼審查、視頻腳本、論文潤色這些高頻場景直接下載就能用。Codex Skills 則更偏向“工程化”。它經(jīng)常和自動化流水線綁定一個 skill 可能包含多個腳本、配置模板、甚至 CI 校驗邏輯。Codex 社區(qū)里流行的“codex 好用的 skills”基本都是配合代碼倉庫用的比如自動生成 commit message、自動補單元測試、自動修 lint 錯誤。這類技能對執(zhí)行環(huán)境的要求更高通常需要把倉庫 clone 到本地再通過命令行調(diào)用。我整理過一張對比表可以幫你快速判斷自己更適合哪套體系維度Claude Agent SkillsCodex Skills技能形態(tài)文件夾 SKILL.md腳本集 配置 文檔門檻低會寫說明就行中高需要理解執(zhí)行流程典型場景內(nèi)容處理、分析、寫作輔助代碼生成、倉庫操作、自動化調(diào)用方式自然語言觸發(fā)模型自主判斷明確命令觸發(fā)流程感更強社區(qū)供給官方市場 GitHubGitHub 命令行工具集適合人群普通用戶、內(nèi)容創(chuàng)作者開發(fā)者、DevOps、技術(shù)團隊當(dāng)然這個對比不是絕對的現(xiàn)在兩邊都在互相學(xué)習(xí)。Claude 的技能也開始支持引用腳本Codex 也在加強文檔說明的作用。你如果剛?cè)腴T我建議先玩 Claude 系因為從安裝到見效的時間最短“skills 安裝包下載”之后一般放對文件夾就能跑起來。2.2 “skills 大全”和“下載平臺”到底在找什么熱詞里有一類特別有意思“skills大全”“skills下載平臺有哪些”“skills安裝包下載”。表面看是在找資源本質(zhì)上是大家發(fā)現(xiàn)了一個新生產(chǎn)力市場但不知道去哪里找高質(zhì)量貨。這和早期找“prompt 大全”的心理一模一樣只是 skills 的篩選門檻更高一個 prompt 寫得不好頂多沒效果一個 skill 寫得不好可能把流程帶偏。我常用的資源渠道有三類。第一類是官方市場比如 Claude 的 skills 市場質(zhì)量有基礎(chǔ)保障但數(shù)量有限。第二類是 GitHub 搜索關(guān)鍵詞用claude skills或agent skills按 stars 排序能挖到不少寶藏倉庫比如有人專門整理了幾十個文案寫作類技能還有合作團隊開源的內(nèi)部工種技能庫。第三類是社區(qū)博客和評測文章很多作者會把技能文件直接貼在文章里看到合適的復(fù)制下來就能用。但這里要提醒一句別見到 skill 就隨手裝。技能文件本質(zhì)是一段可執(zhí)行邏輯里面如果引用了腳本就相當(dāng)于在你機器上跑外部代碼。我的原則是先看 SKILL.md、再看 scripts 里的代碼、最后才安裝。尤其是命令行工具類的技能最好先在一個沒有重要數(shù)據(jù)的目錄里試跑一遍。2.3 為什么“agent skills 測試”突然成了剛需熱詞里有“agent skills測試”“skills開發(fā)”這兩個我特別有共鳴。最初我寫 skill 的時候覺得寫完就完事了結(jié)果經(jīng)常出現(xiàn)“文檔寫得很完美但模型根本不調(diào)用”的尷尬情況。后來才意識到技能和人一樣需要驗收。你至少要測四件事觸發(fā)準確性輸入什么內(nèi)容時模型會主動調(diào)用這個技能執(zhí)行穩(wěn)定性同一輸入跑五次輸出差異大不大腳本健壯性腳本遇到缺文件、空數(shù)據(jù)、異常符號時會不會崩潰上下文占用技能文檔太長會不會把對話窗口撐爆現(xiàn)在社區(qū)里已經(jīng)有人開始寫“skills 測試框架”了基本原理是準備一組典型輸入自動調(diào)用技能跑一遍檢查輸出結(jié)構(gòu)是否符合預(yù)期。我自己的土辦法更簡單在 Claude 里建一個測試會話把技能裝好后連發(fā)五條不同難度的請求看它是否按說明文檔執(zhí)行。比如測試論文潤色技能我會分別丟“摘要只有三行”“全文兩萬字”“帶圖表標注的論文片段”三種輸入觀察處理方式的差異。3. 手把手寫一個能用的 skill論文潤色3.1 為什么拿“論文潤色”當(dāng)例子因為熱詞里“codex寫論文的skills”“workbuddy skills 寫論文”“claude skills”出現(xiàn)的頻率非常高說明這是大多數(shù)人最需要的場景。而且論文潤色任務(wù)的流程相對固定讀原文、找邏輯斷點、改句式、統(tǒng)一術(shù)語、輸出修改說明每一步都可以文檔化。哪怕你完全沒寫過代碼只要理解這套流程就能跟著做出來一個能用的 skill。順便說一句官方市場里已經(jīng)有很多論文潤色技能了但自己寫一遍的價值在于你更清楚模型的處理邊界更知道哪里該給規(guī)則、哪里該留自由度。直接用現(xiàn)成的出了問題你很難判斷是文檔問題還是模型問題。3.2 技能文件的目錄結(jié)構(gòu)規(guī)劃論文潤色技能時我的目錄結(jié)構(gòu)是這樣paper-polish/ ├── SKILL.md # 主說明文件 ├── references/ │ ├── academic-terms.md # 學(xué)術(shù)術(shù)語對照表 │ └── before-after.md # 修改前后對比示例 └── scripts/ └── extract_refs.py # 從論文中提取參考文獻列表可選這個結(jié)構(gòu)的好處是說明、參考、代碼完全分層。模型先讀SKILL.md形成全局認知遇到術(shù)語問題去查references需要批量處理時就跑scripts。你在寫自己的技能時也可以參照這個模板不一定非要寫腳本但references目錄強烈建議保留它能顯著提升輸出質(zhì)量。3.3 SKILL.md 怎么寫才算清楚SKILL.md是整個技能的核心模型能不能正確執(zhí)行全看這份文檔寫得是否清晰。我見過很多人的技能文檔寫得像散文洋洋灑灑幾百字但模型讀了還是不知道第一步干什么。這里分享一個我摸索出的結(jié)構(gòu)模板--- name: paper-polish description: 用于學(xué)術(shù)論文的潤色與邏輯優(yōu)化特別適合英文摘要、引言和結(jié)論部分。 --- # 論文潤色 ## 使用場景 僅當(dāng)用戶提供論文段落、摘要或完整稿件并要求潤色時使用。 不要用于普通文案、朋友圈文案或非學(xué)術(shù)語境。 ## 處理流程 1. 通讀原文標記邏輯斷點。 2. 逐句優(yōu)化優(yōu)先修改被動語態(tài)、冗余表達和模糊指代。 3. 術(shù)語一致性檢查對照 references/academic-terms.md。 4. 輸出修改后文本并在末尾列出 3-5 條修改要點。 ## 輸出格式 必須按以下結(jié)構(gòu)返回 - 修改后版本 - 修改要點列表 - 術(shù)語對照表如有注意到幾個關(guān)鍵點沒有。首先是description字段模型會讀這個字段來決定是否觸發(fā)技能所以里面要寫清楚“什么時候用、什么時候不用”。其次是“處理流程”一定要拆到模型能直接執(zhí)行的粒度“逐句優(yōu)化”比“提升語言質(zhì)量”好用一百倍。然后是“輸出格式”固定了格式你后續(xù)做批量處理或者集成到工作流里都會容易很多。另外SKILL.md里可以加一小節(jié)“禁忌事項”。比如論文潤色技能里我會寫不改動作者的原意、不新增實驗數(shù)據(jù)、不修改參考文獻編號。這些約束能有效防止模型自由發(fā)揮過度。3.4 腳本在技能里的作用論文潤色這個場景里腳本不是必需品但有兩個地方腳本特別好用。一是參考文獻提取論文里參考文獻格式五花八門讓模型靠閱讀去解析容易出錯寫個正則腳本提取就穩(wěn)得多。二是批量處理比如你有二十篇摘要要潤色模型每次只能處理一段腳本可以先按段落拆分文本潤色完成后自動拼回去。我給extract_refs.py寫過一個簡化版本大概長這樣import re import sys def extract_references(text): # 簡單匹配 [1]、[1,2]、[1-3] 這類引用標記 pattern r\[(\d(?:[,\-]\d)*)\] return re.findall(pattern, text) if __name__ __main__: content sys.stdin.read() refs extract_references(content) for ref in refs: print(ref)注意這個腳本只是為了說明“技能里的腳本可以承擔(dān)什么角色”實際使用時要根據(jù)自己的論文格式調(diào)整正則。更重要的是你要在SKILL.md里寫清楚“什么時候調(diào)用腳本、什么時候不調(diào)用”。比如我規(guī)定當(dāng)用戶要求“提取參考文獻列表”時才運行腳本只是潤色正文時不要額外跑腳本打斷節(jié)奏。4. 安裝引入與管理從官方市場到本地目錄4.1 幾種安裝路徑先說最簡單的情況如果你用的是 Claude 這種帶有官方市場的產(chǎn)品直接搜索 skill 名稱點安裝即可。熱詞里“claude 國內(nèi)安裝 skills 官方市場”說明很多人第一步就卡在這里其實口碑比較好的辦法是先用官方客戶端或網(wǎng)頁版進入 settings 里的 skills 板塊找到市場并搜索。這個過程的本質(zhì)是把遠程倉庫克隆到本地指定目錄所以你也可以繞過市場直接把 GitHub 上的技能文件夾下載下來放到對應(yīng)目錄里。具體路徑因工具而異但邏輯一致。以 Claude 桌面版為例技能通常放在~/.claude/skills/每個技能一個文件夾里面要有SKILL.md否則不會被識別。Codex 的安裝方式更偏命令行一般通過codex skills install 倉庫地址這類命令完成安裝后會自動配置執(zhí)行環(huán)境。熱詞里“idea使用skills”“reasonix如何安裝新skills”也屬于這一類本質(zhì)都是“把技能文件放到工具能掃描到的目錄”。4.2 安裝之后的“冒煙測試”技能裝好不代表能用我強烈建議每次安裝完都做一次不超過五分鐘的冒煙測試。測試步驟很簡單新建一個空會話不寫任何額外提示詞。輸入一個該技能覆蓋范圍內(nèi)的典型請求。觀察模型是否主動提到找到了對應(yīng)技能?？摧敵龈袷绞欠窈蚐KILL.md里定義的一致。如果沒觸發(fā)檢查技能目錄名是否包含空格或非法字符檢查description是否包含用戶可能說的關(guān)鍵詞。我自己曾經(jīng)裝了一個“代碼審查 skills”結(jié)果發(fā)了五次請求模型都當(dāng)成普通問答處理。排查半天發(fā)現(xiàn)是SKILL.md的description寫的是“Review code”而我在提問時用的是“幫我看看這段代碼”關(guān)鍵詞完全沒接上。后來把 description 改成“審查代碼、檢查代碼質(zhì)量問題、Code Review”之后第二次就觸發(fā)了。這個細節(jié)很值得記下來。4.3 多個技能之間的優(yōu)先級管理技能裝多了就會出現(xiàn)另一個問題沖突。比如你同時裝了“論文潤色”和“學(xué)術(shù)寫作助手”模型面對一段論文摘要到底該調(diào)哪個很多新手對這個感到頭疼。解決辦法是在每個技能的description里明確“適用邊界”并且可以在SKILL.md的開頭加一行“只有在用戶明確要求潤色時使用不要進行學(xué)術(shù)寫作指導(dǎo)”。我實測下來這句話能明顯減少技能之間“搶活”的概率。如果沖突還是嚴重還有一個土辦法把不常用的技能暫時移出 skills 目錄放到一個_disabled文件夾里。需要用時再移回來。這比在配置里反復(fù)開關(guān)快得多而且不會誤刪文件。5. 使用中的高頻問題與排查思路5.1 常見問題速查表我用表格把這段時間遇到最多的問題整理了一下基本覆蓋了新手階段的全部痛點了現(xiàn)象可能原因排查與解決模型完全無視技能description 寫得太泛或沒包含觸發(fā)詞把觸發(fā)說法寫進 description至少包含三種同義表達技能被調(diào)用但輸出跑偏SKILL.md 流程不夠具體拆步驟每個動作細化到可執(zhí)行指令腳本執(zhí)行時報錯缺依賴或路徑不對確認腳本在 skill 目錄下可獨立運行不要依賴全局變量會話上下文快速耗盡SKILL.md 或 references 內(nèi)容過長把長樣例移到 references只在主文檔保留核心規(guī)則兩個技能互相沖突description 邊界不清加“僅當(dāng)…時使用”的限制語句排版輸出不穩(wěn)定輸出格式描述不夠硬用“必須”“不得”等強約束詞并用列表固定結(jié)構(gòu)這張表我建議保存下來遇到問題先對號入座大部分情況不需要去翻文檔。5.2 一次真實的排查經(jīng)歷有段時間我寫了一個“分鏡腳本 skills”靈感來自熱詞里的“分鏡skills下載”。這個技能的目標是根據(jù)小說章節(jié)生成分鏡腳本包含景別、運鏡、時長、臺詞。第一次測試就翻車了模型確實調(diào)用了技能但輸出只有三行字和文檔里要求的表格結(jié)構(gòu)完全不符。我翻看生成的日志發(fā)現(xiàn)模型只讀了SKILL.md里“使用場景”那一段后面的“輸出格式”部分完全沒執(zhí)行。原因是我的SKILL.md結(jié)構(gòu)太靠近純自然語言了細節(jié)全埋在段落里模型沒抓住重點。后來我重寫了文檔把所有關(guān)鍵規(guī)則全部列表化并在文件最開頭用加粗寫了一句“輸出必須是完整分鏡表格不得以段落形式返回”。再測輸出質(zhì)量立刻提升了。這件事給我的教訓(xùn)是技能文檔不是文章而是“操作手冊”模型閱讀效率最高的結(jié)構(gòu)永遠是短句、列表、固定格式。5.3 關(guān)于“上下文占用”的提醒很多人忽略了一個問題技能文檔本身會占用模型的上下文窗口。一個寫了兩千字的SKILL.md相當(dāng)于每一次對話都先塞兩千字進去。如果同時裝了十幾個技能光技能內(nèi)容就可能占掉上下文的一小半留給實際任務(wù)的容量就少了。這和你電腦開了太多后臺程序?qū)е聝?nèi)存不足是一個道理。解決辦法其實很樸素給技能做“瘦身”。主文檔只保留流程骨架參考資料全部放到references/目錄里讓模型按需讀取。另外在SKILL.md里明確寫出“首次響應(yīng)只輸出關(guān)鍵結(jié)論不接受額外解釋”也能節(jié)省大量 token。我試過把同一套技能從三千字壓縮到一千字輸出質(zhì)量沒有明顯下降但響應(yīng)速度快了不少。6. 安全邊界與我的幾點經(jīng)驗6.1 技能里的腳本要慎之又慎因為 skills 可以攜帶腳本所以安全問題必須正視。一個技能文件夾放到本地后腳本通常以當(dāng)前用戶權(quán)限運行。如果腳本來自陌生人倉庫里面寫了刪除文件、上傳數(shù)據(jù)、修改系統(tǒng)配置的操作后果可能很嚴重。這不是危言聳聽社區(qū)里已經(jīng)出現(xiàn)過惡意技能的預(yù)警案例。我的建議是三條只安裝可信來源的技能官方市場優(yōu)先。安裝后打開腳本看一眼重點關(guān)注os.system、shutil.rmtree、requests.post這類敏感調(diào)用。給技能運行設(shè)置一個獨立的臨時目錄不要讓它直接操作主項目文件。這和“自動挖洞 skills”這種安全研究場景其實并不沖突。研究者在隔離環(huán)境里把攻擊性技能用于實驗屬于正常測試但對普通用戶來說保持謹慎是底線。6.2 skill 不是越復(fù)雜越好我見過一些人開發(fā)技能時恨不得把所有邏輯都塞進去寫了幾十頁文檔、掛了七八個腳本。結(jié)果呢模型在第一步就看不懂了腳本互相依賴調(diào)試成本極高。我的經(jīng)驗是一個技能只解決一個核心問題。拿論文潤色舉例你完全可以把“潤色”“查重”“生成參考文獻”分別做成三個技能。它們可以放在同一個技能目錄下但各自獨立。這樣做的好處是模型觸發(fā)任何一個技能都不需要加載另外兩個的配置上下文更省出錯時也更容易定位。熱詞里“superpower skills”聽起來很玄但真正好用的 superpowers往往是那些專注、克制、流程清晰的技能?！皊uperpowers 具體使用”這個問題我自己的答案是別貪多把一個技能打磨到十倍好用比收藏一百個技能有價值得多。6.3 寫技能文檔的三個反直覺技巧最后分享三個我寫作時總結(jié)出來的小技巧可能和直覺不太一樣。第一個技巧是“先寫禁忌再寫流程”。因為模型對否定指令的敏感度往往高于肯定指令。你說“不要改變作者原意”比“保持作者意圖”更能約束行為。所以我在每個技能文檔的開頭部分都會先列三到五條“不得做”的事項。第二個技巧是“引用具體的實例”。空泛的規(guī)則很難被執(zhí)行但一個“before-after 示例”能讓模型立刻理解你要的風(fēng)格。我在論文潤色技能里放了一個改前改后的對照表模型看到之后輸出的風(fēng)格明顯更接近我的期望。第三個技巧是“給技能一個內(nèi)部代號”。比如把論文潤色技能命名為“學(xué)術(shù)文本清潔工”然后在 description 里同時寫“論文潤色”“學(xué)術(shù)文本清潔工”兩個說法。模型在處理相關(guān)請求時會更容易聯(lián)想到這個技能。這個方法沒有論文級別的原理支撐但在我實測里效果不錯。寫在最后從一個小技能開始如果你看完這篇文章還是覺得有點抽象我的建議特別簡單今天就寫一個文檔描述你手頭最重復(fù)的一件事比如周報怎么寫、會議紀要怎么整理、代碼注釋怎么補。然后用三十分鐘把它變成一個最簡版技能裝進你的 AI 工具里試一次。這個動作本身比任何教程都有用因為它會逼你去想“流程到底是什么”“邊界在哪里”“怎么讓另一個智能體理解我的標準”。等你跑通第一個技能再看那些“skills大全”“skills推薦”你的視角會完全不一樣你不再是一個下載者而是一個能判斷、能修改、能創(chuàng)造的人。這大概就是 skills 這件事最有魅力的地方。