大多數每天使用 AI 的人都不知道，現在已經有一套標準檔案格式，讓你把一項工作教一次，之後每次都以同樣方式完成。它叫做 Skill，本體只是一個 Markdown 檔案，而目前大約有 40 款 AI 產品已經能夠讀取它。
如果你覺得 AI 輸出品質時好時壞，如果你每開一個新對話就要再貼一次那段四百字的指令，或者你把「那個很好用的提示」存在記事本裡卻總是忘記拿出來用，那麼你缺的就是這一塊。寫出第一個 Skill，大約需要 20 分鐘。
什麼是 Agent Skill？它跟儲存起來的提示有何不同？
Agent Skill 是一個資料夾，裡面放著一個 SKILL.md 檔案：一份 Markdown 文件，開頭有一小段 YAML 標頭，說明這個 Skill 做什麼、以及什麼時候該用它。它跟儲存起來的提示最大的分別是，你不需要貼上它。AI 代理會自行讀取標頭，判斷這個 Skill 是否相關，然後自己載入指令。
這個分別比表面看起來重要。儲存起來的提示需要你記得它存在、找出來、按正確順序貼上。Skill 只是靜靜放在資料夾裡，任務一對上就會啟動。
Anthropic 於 2025 年 12 月 18 日將 Agent Skills 公開為開放標準，規格文件放在 agentskills.io。正因為它沒有被保留成專有格式，這套寫法才擴散得如此迅速。
截至 2026 年 6 月，大約有 40 款產品支援同一格式，包括 Claude、OpenAI Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Goose、OpenCode、Databricks Genie Code 與 Snowflake Cortex Code。一個檔案，多個工具。標準寫法可參考 官方的 Skill 撰寫指引。
為什麼你的 AI 輸出會飄移？Skill 檔案如何解決？
輸出會飄移，是因為指令每次重打都會變樣。你壓縮了一個步驟，你漏掉一項自以為理所當然的限制，你忘記了上星期讓輸出變好的那個範例。模型本身是穩定的，不穩定的是你的輸入。
Skill 檔案把這個變數移除。指令從「憑記憶重寫」變成「刻意修改的固定資產」。
它同時解決第二個問題：指令不再只存在你的腦袋裡。同事可以直接用你的 Skill，得到你的輸出品質。這正是「個人小技巧」與「團隊流程」之間的分野。
把它寫好而不是隨手寫，是有跡象值得的。SkillsBench 分析了 47,150 個公開分享的 Skill，平均品質分數為 12 分中的 6.2 分；而經過篩選整理的 Skill，平均令代理的任務通過率提升 16.2 個百分點。這些數字應視為方向性參考，而非對照實驗結果，因為樣本是從公開檔案抓取而來，並非配對實驗。但方向是清楚的：一個寫得好的 Skill 有可量度的幫助，一個含糊的 Skill 幾乎沒有作用。
SKILL.md 檔案裡面應該寫什麼？
SKILL.md 由兩部分組成：夾在兩行三個連字號之間的 YAML 標頭，以及一段 Markdown 指令內容。標頭必須從檔案的第一個位元組開始。必填欄位只有兩個，name 與 description，其餘全部可選。
標頭允許的欄位為 name、description、license、allowed-tools、metadata 與 compatibility。符合規格的執行環境會忽略無法辨識的欄位，因此多寫一個不明欄位不會導致失敗。
真正讓人踩坑的規則有三條：
--- name 只接受小寫英文字母、數字與連字號，上限 64 個字元，不能以連字號開頭或結尾，並且必須與上層資料夾名稱完全一致。一旦不一致，Skill 會靜靜地永不載入。
--- description 上限 1,024 個字元，必須同時說明「這個 Skill 做什麼」與「什麼時候應該用」。代理就是靠這一欄決定是否打開你的 Skill。
--- allowed-tools 限制 Skill 生效期間代理可以呼叫哪些工具。Claude Code 與 OpenClaw 會實際執行這項限制，但另外幾款代理會接受欄位卻默默忽略，因此不要把它當成安全邊界。
內容部分才是真正的方法論：步驟、限制、格式、範例。要寫得精簡。Skill 是透過漸進式披露載入的：name 與 description 會在每次執行時注入系統提示，成本極低；完整內容只在代理判斷你的 Skill 適用時才載入。常見建議是把內容控制在約 500 個 token 以內，長篇材料另外放進參考檔案，讓代理需要時再打開。
如何在 20 分鐘內寫出你的第一個 Agent Skill？
選一項你已經向 AI 解釋過三次以上的工作。不是最難的那項，而是最常重複的那項。例如每週報告格式、客戶電郵語氣、把會議記錄整理成行動項目的方式，又或者你每次都對草稿跑一遍的改寫流程。
接著建立一個名稱與 Skill 完全相同的資料夾，裡面放一個檔案。以下是一份可直接複製填寫的完整範本：
把以下內容複製到一個名為 SKILL.md 的檔案
---
name: weekly-client-update
description: 把一週的零散筆記整理成符合公司格式、可直接發給客戶的更新電郵。當使用者要求撰寫每週更新、客戶進度電郵、週五總結，或貼上粗略筆記並要求發給客戶時使用。
---
# 每週客戶更新
## 什麼時候使用
使用者手上有零散筆記、要點或會議謄本，需要一封面向客戶的更新電郵。
## 步驟
1. 把每一項分類為：已完成、進行中、受阻、需要客戶決定。
2. 刪去所有內部資訊：人力安排、工具抱怨、未確認的計劃。
3. 撰寫電郵：一句背景，接著四個分類的簡短要點，最後一個明確請求。
4. 全文控制在 200 字以內。不要用形容詞誇讚自己的表現。
## 格式
主旨：[客戶名稱] 每週更新，[日期範圍]
結尾只署寄件人的名字。
## 不要做的事
--- 不要編造日期或數字。若數據缺失，寫上「待確認」並在結尾標示。
--- 除非筆記明確指出延誤是我方責任，否則不要為延誤道歉。
## 良好請求範例
「可否在星期三前確認到達頁文案，讓我們維持 3 月 12 日的上線日期？」
然後用三份不同的凌亂筆記測試三次。每一次輸出不理想，都不要在對話裡糾正它。去改那個檔案。這個習慣就是 Skill 的全部價值：你的指令是永久變好，而不是暫時變好。
如果從零寫起讓你覺得費力，就把這件事交給模型。貼上這段：
試試這段提示
「我想把一項我經常重複的工作，寫成 SKILL.md 格式的 Agent Skill。以下是這項工作，描述得很粗糙：[貼上你的粗略描述，加上一個好輸出的例子與一個壞輸出的例子]。
請寫出完整的 SKILL.md。要求：YAML frontmatter 只包含 name 與 description；name 用小寫加連字號、少於 64 字元；description 少於 1,024 字元，同時說明用途與觸發情境，並使用我實際會輸入的字詞。內容少於 500 字，分為「什麼時候使用」、「步驟」、「格式」、「不要做的事」四節。請把我的好壞範例中隱含的規則明確寫出來。最後列出你所作的三個假設，讓我核對。」
Skill 檔案該放在哪裡？哪些工具會讀取它？
一個 Skill 就是一個內含 SKILL.md 的資料夾，放進你的工具會監看的 skills 目錄。在 Claude Code 與 Cowork 中，那是專案或使用者設定裡的 skills 資料夾；在 Cursor、Copilot、Codex 與 Gemini CLI 中，位置略有不同，但檔案格式一致。
正因為格式是共通標準，同一個資料夾可以在不同工具之間重用，而不需要為每個工具重寫一次。社群整理的合集，例如 VoltAgent 的 awesome-agent-skills，已收錄超過 1,000 個可跨 Claude Code、Codex、Gemini CLI、Cursor 等工具使用的 Skill。
現成 Skill 的數量已經相當龐大。目錄網站索引的規模驚人，單是 SkillsMP 就列出約 190 萬個從 GitHub 抓取的公開 Skill。這是需要謹慎挑選的理由，而不是值得興奮的理由。安裝任何 Skill 之前先讀一遍內容，因為你交出去的是你的指令，在某些設定下還包括工具權限。
Skill 之間可以組合。當你手上有三四個之後，代理可以把它們串起來：用一個做研究、另一個寫草稿、第三個負責核對。到了這一步，它就不再是整理得比較好的提示庫，而是一條工作流程，正如我們在AI 工作流程自動化一文中所述。
哪五個錯誤會令 Skill 完全不啟動？
Skill 的失敗是無聲的。Skill 沒有啟動時不會出現任何錯誤訊息，因此一個壞掉的 Skill，看起來跟一個你忘記使用的 Skill 完全一樣。以下五項最值得先檢查。
--- description 是寫給人看，而不是寫給路由用。「客戶溝通最佳實務」完全沒有告訴代理何時該啟動。要用你實際會輸入的字詞，寫出觸發條件。
--- name 與資料夾名稱不一致。name 欄位與上層資料夾名稱必須完全相同。這是最常見的無聲失敗。
--- frontmatter 沒有從第一個位元組開始。三個連字號之前多了一行空白、一段註解或一個 BOM，標頭就不會被解析。
--- 內容寫成了一本手冊。兩千字的背景資料載入慢，而且會把真正的指令埋掉。方法留在 SKILL.md，背景搬去參考檔案。
--- 把 allowed-tools 當成防護欄。它在部分執行環境會被執行，在其他環境會被忽略，因此絕不能靠它去阻止一個你真的不能允許的動作。
還有一項必須誠實面對的限制：Skill 讓你的指令穩定，但不會讓模型穩定。同一個 Skill 換另一個模型執行，或在同一模型更新之後執行，輸出仍可能不同。如果穩定性重要，就固定你測試過的模型，並在升級後重新測試，這與我們在推理模型提示技巧一文中提出的紀律一致。
立即動手：把你最常重複的工作變成 Skill
打開你的 AI 對話紀錄，找出這個月重打次數最多的那段指令。那就是你的第一個 Skill。你已經知道它有效，這正是它最適合被正式化的原因。
花 20 分鐘：寫好 SKILL.md，用真實輸入跑三次，每次輸出不到位就改檔案而不是改對話。到第三次，你手上的東西會比你最好的提示更好，因為它包含了你平時會忘記的那些修正。
然後放著不動，用一個星期。Skill 的價值不在你寫下它的那一天，而在它第四十次替你省下重新解釋的那一刻。
這就是把 AI 用好最不起眼的部分：少一點四處尋找提示，多一點建立可持續的小零件。懂AI的冷，更懂你的難 UD 同行28年，讓科技成為有溫度的陪伴。
本文由 UD AI 團隊審閱。
把一個 Skill 變成一套運作中的系統
一個 Skill 解決一項工作。一組互相連接、接上你真實工具與資料的 Skill，改變的是工作被完成的方式。掌握了這個技術，下一步是把它整合進每次都穩定運行的工作流程。UD 團隊手把手帶你完成每一步，從工具選擇、流程設計，到真正落地日常使用。
