很多團(tuán)隊(duì)把 Prompt 當(dāng)萬能鑰匙，結(jié)果系統(tǒng)臃腫、上下文爆炸、行為不可控。Agent 生態(tài)已經(jīng)給出了更成熟的解法——Skill。

它不是又一段 Prompt，而是一套結(jié)構(gòu)化行為設(shè)計(jì)，用規(guī)范文件定義“在什么場景下、用什么工具、走什么流程、產(chǎn)出什么結(jié)果”。

本文基于 Anthropic 開放規(guī)范、Skill-Creator 構(gòu)建方法論和 Google 的五種設(shè)計(jì)模式，提煉出真正能落地的干貨，并給出可直接套用的示例。

一、Skill 的基因：一個文件，一份契約

Skill 的最小單元就是一個文件夾，核心文件是 SKILL.md，由 YAML 元數(shù)據(jù)和 Markdown 指令正文組成。元數(shù)據(jù)中 name 和 description 是必填項(xiàng)，其他如 license、allowed-tools 等可選。

name 必須全小寫，僅允許字母、數(shù)字和連字符，不能以連字符開頭結(jié)尾，不能連續(xù)連字符，且必須與文件夾名一致。例如 name: sql-review 合法，name: SQL-Review 非法。

description 則是一句精準(zhǔn)的行為觸發(fā)描述，而不是功能介紹。例如：

推薦寫法：description: 審查 SQL 查詢的性能與安全問題。當(dāng)用戶要求檢查 SQL、優(yōu)化查詢或提到數(shù)據(jù)庫性能時使用。

糟糕寫法：description: 幫助處理 SQL。

正文部分沒有硬格式要求，但強(qiáng)烈建議控制在一個屏幕內(nèi)（約 500 行），把詳細(xì)參考資料拆到 references/ 目錄。這樣 Agent 只在使用時加載，避免一次喂入過多信息。

二、漸進(jìn)式加載：用三層結(jié)構(gòu)解決上下文爆炸

Skill 規(guī)范最巧妙的設(shè)計(jì)就是三層漸進(jìn)式加載：

L1 目錄層：會話啟動時，Agent 只獲取所有 Skill 的 name 和 description，每個僅消耗幾十 token。即使你裝了 20 個 Skill，初始成本也只有 1000-2000 token。

L2 指令層：當(dāng)模型判斷當(dāng)前任務(wù)與某個 Skill 的描述匹配時，才會完整讀取 SKILL.md 正文。

L3 資源層：正文中引用的腳本、參考文檔等，在真正需要時才按需加載，比如“當(dāng) API 返回非 200 狀態(tài)碼時，讀取 references/error-codes.md”。

這種設(shè)計(jì)借鑒了 UI 設(shè)計(jì)的漸進(jìn)式信息披露，相比把幾萬 token 的指令全塞進(jìn) System Prompt，上下文消耗減少約 90%。

三、觸發(fā)密碼：Description 寫得好，Skill 才不會被忽視

Skill 的觸發(fā)不靠關(guān)鍵詞硬匹配，完全由模型根據(jù) description 自主判斷。因此 description 必須強(qiáng)調(diào)用戶意圖，而不是 Skill 的內(nèi)部機(jī)制。多用祈使語氣：“Use this skill when…”，并且覆蓋用戶可能的各種表述。

舉個例子，假設(shè)你做了一個 data-cleaner Skill：

推薦 description：

description: 清洗 CSV、Excel 或 JSON 數(shù)據(jù)集——處理缺失值、異常檢測、格式標(biāo)準(zhǔn)化。當(dāng)用戶上傳數(shù)據(jù)文件并要求清洗、準(zhǔn)備分析或指出數(shù)據(jù)質(zhì)量問題時使用，即使未提及“清洗”一詞。

這樣模型在看到“幫我把這個表格里奇怪的值處理一下”時也能觸發(fā)。差勁的描述如“用于數(shù)據(jù)清洗”，會漏掉大量變體請求。

四、Skill-Creator的工程化哲學(xué)：像訓(xùn)模型一樣訓(xùn) Prompt

Anthropic 的 Skill-Creator 本質(zhì)是一個“用來創(chuàng)建 Skill 的 Skill”，它把機(jī)器學(xué)習(xí)中的訓(xùn)練/測試集、防過擬合、A/B 測試等理念完整移植到 Prompt Engineering 上。

核心思想有三點(diǎn)：

第一，泛化優(yōu)于定制。不要為了通過幾個測試用例就不斷加死規(guī)則，那只會讓 Skill 過擬合，面對新 prompt 反而失效。遇到頑固問題，嘗試換個比喻或推薦不同工作模式。

第二，解釋“為什么”而非堆砌“必須”?，F(xiàn)代大模型有較好的心智模型，告訴它“為什么這個檢查重要”，比寫滿 ALWAYS/NEVER 更有效。

第三，提取重復(fù)模式。如果測試中 Agent 總是自己寫相似的輔助腳本（比如都生成了 validate_schema.py），那就把它提升為 Skill 自帶的腳本資源。

不過在實(shí)際使用中，Skill-Creator 的 description 優(yōu)化循環(huán)（run_loop.py）極其消耗 Token，社區(qū)實(shí)測一次觸發(fā)評估就燒掉 69% 的 5 小時配額。因此我個人建議：除非 Skill 極其復(fù)雜且觸發(fā)模糊，否則不需要上自動化描述優(yōu)化，人工打磨 description 往往性價(jià)比更高。

五、Writing-Skills：用 TDD思維寫 Skill

Superpowers 框架中的 Writing-Skills 提出了 RED-GREEN-REFACTOR 循環(huán)，尤其適合紀(jì)律執(zhí)行型 Skill，比如強(qiáng)制 TDD 流程。

RED 階段：不帶 Skill 運(yùn)行壓力場景。例如給 Agent 一個已實(shí)現(xiàn)但沒寫測試的功能，問它“該不該先寫測試再提交？”，觀察它是否找出各種借口跳過 TDD。

GREEN 階段：針對基線漏洞寫最小 Skill，直接在正文中預(yù)先反駁常見借口。比如明確寫出：“‘我已經(jīng)手動測試過了’不是跳過自動化測試的理由，必須刪除實(shí)現(xiàn)代碼，用測試先行方式重寫?！?/p>

REFACTOR 階段：持續(xù)測試并堵住新出現(xiàn)的合理化借口。最終讓 Agent 在時間緊迫、疲勞狀態(tài)下依然嚴(yán)格遵守規(guī)則。

另一個重要發(fā)現(xiàn)：description 只應(yīng)描述觸發(fā)條件，絕不能總結(jié) Skill 的工作流程。否則 Agent 可能偷懶按描述執(zhí)行，根本不讀指令正文。例如：

錯誤：

description: 執(zhí)行實(shí)施計(jì)劃時使用——按任務(wù)派發(fā)子代理并在任務(wù)間進(jìn)行代碼審查。

正確：

description: 當(dāng)需要在當(dāng)前會話中執(zhí)行包含獨(dú)立任務(wù)的實(shí)施計(jì)劃時使用。

六、五種設(shè)計(jì)模式：Google 總結(jié)的 Skill 內(nèi)部結(jié)構(gòu)

規(guī)范告訴我們 Skill 長什么樣，但內(nèi)部邏輯如何組織？Google ADK 團(tuán)隊(duì)總結(jié)出五種高頻模式，這里給出易懂的變體示例。

1. Tool Wrapper 模式：按需注入領(lǐng)域知識

Skill 正文不羅列全部規(guī)范，而是指示 Agent 去加載參考文件。

示例（React 最佳實(shí)踐）：

name: react-expertdescription: React 組件設(shè)計(jì)、性能優(yōu)化與常見反模式。當(dāng)用戶編寫或?qū)彶?React 代碼時使用。

正文：加載 references/conventions.md 獲取完整約定。

審查代碼時：

1. 閱讀規(guī)范文件

2. 逐條對照檢查用戶代碼

3. 針對每處違規(guī)，給出原因和修改建議

2. Generator 模式：模板填空保證輸出一致性

讓 Agent 主動詢問缺失信息，再套用模板。

示例（發(fā)布說明生成器）：

name: release-notes-generatordescription: 根據(jù) Git 提交記錄生成結(jié)構(gòu)化發(fā)布說明。

正文：

第一步：加載 assets/release-template.md。

第二步：詢問用戶版本號、發(fā)布日期和重點(diǎn)變更類別。

第三步：按模板填充內(nèi)容，保持風(fēng)格一致。

第四步：輸出 Markdown 文件。

3. Reviewer 模式：檢查清單與打分分離

將檢查項(xiàng)獨(dú)立在外部清單中，Skill 只負(fù)責(zé)執(zhí)行。

示例（Python 代碼審查）：

name: py-reviewerdescription: 審查 Python 代碼的風(fēng)格、錯誤處理和常見安全漏洞。

正文：

加載 references/checklist.md，逐項(xiàng)檢查。每處違規(guī)記錄行號、嚴(yán)重級別，并解釋“為什么這是問題”，而非僅描述現(xiàn)象。

4. Inversion 模式：Agent 先采訪你再動手

在不確定需求時，Agent 通過結(jié)構(gòu)化提問收集完整信息再執(zhí)行。

示例（微服務(wù)拆分規(guī)劃）：

name: service-plannerdescription: 通過分階段提問為單體拆分制定方案。

正文：

第一輪：詢問業(yè)務(wù)領(lǐng)域、流量模式、數(shù)據(jù)依賴。

第二輪：詢問團(tuán)隊(duì)規(guī)模、技術(shù)棧約束、性能目標(biāo)。

全部回答完畢后，生成拆分方案草稿并迭代確認(rèn)。

5. Pipeline 模式：嚴(yán)格順序 + 檢查點(diǎn)

每個步驟有明確的輸入輸出與確認(rèn)門，禁止跳步。

示例（數(shù)據(jù)庫遷移腳本生成）：

name: migration-pipelinedescription: 從現(xiàn)有 schema 生成安全遷移腳本。

正文：

步驟1：連接數(shù)據(jù)庫，提取所有表和索引，列出清單讓用戶確認(rèn)。

步驟2：生成變更 SQL，經(jīng)用戶批準(zhǔn)后才能繼續(xù)。

步驟3：生成回滾腳本。

步驟4：運(yùn)行一次試遷移并校驗(yàn)，通過后輸出最終腳本。

選擇建議：不確定用哪種時，從 Tool Wrapper 開始；需要嚴(yán)格質(zhì)檢則加 Reviewer；需求模糊就先用 Inversion 收集信息。

Skill 正在成為 Agent 工程的標(biāo)準(zhǔn)化組件，三層加載解決了上下文膨脹，description 設(shè)計(jì)決定了觸發(fā)率，而內(nèi)部結(jié)構(gòu)模式直接決定執(zhí)行質(zhì)量。

我個人的體會是：不要把它當(dāng) Prompt 寫，而要像設(shè)計(jì)一個微服務(wù)一樣定義它的職責(zé)邊界、輸入輸出和容錯方式。輕量、清晰、可測試，才是 Skill 工程化的正確方向。