Skill 是什麼：一篇給開發者的入門文章

Skill（或 Skills）可以理解為給 AI Agent 準備的「可複用技能包」。它通常是一個資料夾，裡面放著任務說明、腳本、範本和參考資料，AI 在處理相關任務時會按需載入這些內容，從而更穩定、可重複地完成特定工作。

對開發者來說，Skill 的價值不在「寫一個更長的 Prompt」，而在於把反覆出現的經驗、流程和規範沉澱下來。這樣一來，AI 不只是「知道要做什麼」，還更清楚「應該按什麼步驟做、產出什麼結果、遵守哪些約束」。

先說最基礎的規範

剛開始入門，Skill 不用寫得太複雜，先抓住幾個最關鍵、最常用的部分就夠了。Skill 的核心是一個目錄，裡面至少要有說明文件，複雜一點的 Skill 再附加腳本和資源。

一個適合新手採用的最小結構可以是：

my-skill/
├─ SKILL.md
├─ scripts/
├─ assets/
└─ references/

這裡最關鍵的是 SKILL.md。它作為Skill 的入口檔案，通常包含兩部分：一是頭部元資訊，例如 name 和 description；二是正文說明，用來寫觸發場景、執行步驟、輸出要求和範例。

先遵守這幾條基礎規範：

• 一個 Skill 只解決一類問題，不要把太多目標混進同一個 Skill。

• 目錄名和 name 盡量清晰具體，例如 nextjs-docker-dev、api-testcase-generator，不要使用過於寬泛的名字。

• description 直接寫清「適合什麼場景、解決什麼問題」，方便 AI 判斷什麼時候該用它。

• SKILL.md 裡至少寫清四件事：何時觸發、需要哪些輸入、分幾步執行、最後輸出什麼。

• 有固定範本或腳本時，再放進 assets/ 和 scripts/，不要把所有細節都堆在 Markdown 裡。

如果想看更完整的規範和進階實踐，可以直接參考官方文件與官方資料：Anthropic 幫助中心的「什麼是技能」頁面、官方工程部落格關於 Agent Skills 的文章，以及官方 PDF《The Complete Guide to Building Skills for Claude》。

• 官方幫助中心：<https://support.claude.com/zh-CN/articles/12512176-什麼是技能>

• 官方工程文章：<https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills>

• 官方 PDF 指南：<https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf>

Skill 和 Prompt 的區別

很多人第一次接觸 Skill，會覺得它只是「Prompt 的升級版」。這種理解不能算錯，但還不夠準確。Prompt 更像一次性的口頭指令，而 Skill 更像一份可長期複用的 SOP，裡面不僅有任務要求，還可能帶腳本、範本和參考資料。

Prompt 的優點是輕量、直接，適合臨時任務；Skill 的優點是穩定、可重複，適合經常出現、品質標準明確的工作。

Anthropic 的幫助中心明確把 Skill 描述為包含指令、腳本和資源的資料夾，並強調 Claude 會動態載入這些內容來提升專業任務表現。

什麼場景適合用 Skill

不是所有事情都值得做成 Skill。最適合 Skill 的，通常是那些「重複頻繁、步驟明確、輸出可驗證」的任務，因為這類工作最容易從標準化裡獲得收益。

常見適用場景包括：

• 本地開發環境搭建，例如為某個專案生成 Docker 開發配置。

• 程式碼生成或腳手架初始化，例如建立模組範本、頁面範本、測試範本。

• 測試設計與測試程式碼骨架生成，例如自動整理 API 測試點。

• 文件整理、發布說明、PR 描述生成等格式比較固定的工作。

反過來說，一次性任務、流程還沒穩定下來的任務，或者高度依賴靈感發散的任務，通常不必急著做成 Skill。先用普通對話把流程跑順，再決定是否沉澱成 Skill，往往更高效。

一個好的 Skill 應該具備什麼

一個好 Skill 不一定複雜，但通常都具備幾個共同點：邊界清晰、說明具體、輸出明確、能複用。官方資料和實踐文章都強調，Skill 的目標不是寫得「宏大」，而是讓 AI 在特定問題上穩定發揮。

最基礎的判斷標準可以很簡單：

• 名稱具體，能看出用途。

• 描述明確，能看出觸發場景。

• 步驟清楚，AI 知道先做什麼、後做什麼。

• 輸出固定，便於檢查結果是否達標。

• 有範本、腳本或範例時能一起打包，減少 AI 每次重新猜測。

對於團隊協作來說，這一點尤其有意義。因為 Skill 本質上是在把原本散落在 README、Wiki、口頭傳承裡的做事方法，變成 AI 可以執行的標準流程。

案例一：Next.js 本地 Docker 開發環境

這是最適合做成 Skill 的開發類任務之一。因為本地環境搭建幾乎每個專案都會遇到，而且對新人最容易造成阻塞：依賴服務怎麼起、環境變數怎麼配、Node 版本怎麼統一、資料庫怎麼初始化，這些問題通常都重複出現。

如果把它做成 Skill，目標並不是只生成一個 docker-compose.yml，而是讓 AI 能圍繞整個「本地開發環境」給出完整結果。比如它應該能識別專案的套件管理器、Next.js 啟動方式、是否依賴 Postgres/Redis，並在缺少資訊時繼續追問，再輸出一套可執行的 Docker 配置和說明文件。

一個典型的輸出可以包括：

• Dockerfile，定義 Node 環境和應用啟動方式。

• docker-compose.yml，把 app、資料庫、快取等服務串起來。

• .env.example，列出本地開發所需環境變數。

• scripts/dev-init.sh，執行初始化、遷移或 seed。

• README-docker.md，告訴團隊怎麼啟動、怎麼排錯。

這個 Skill 的核心步驟通常是：先檢查倉庫現狀，再識別技術棧和依賴服務，然後在缺失資訊時追問，最後生成檔案並附上使用說明。這樣的結構比一句「幫我寫個 Docker 配置」可靠得多，因為它把上下文收集、檔案生成和交付說明統一放進了一個固定流程。

一個非常簡化的 SKILL.md 開頭可以寫成這樣：

---
name: nextjs-docker-dev
description: 為 Next.js 專案生成本地 Docker 開發環境，包括 app、資料庫、快取、環境變數範本和啟動說明。
---

當使用者希望為 Next.js 專案補充本地 Docker 開發配置時使用本 Skill。

步驟：
1. 檢查專案是否已有 Dockerfile 或 compose 檔案。
2. 識別套件管理器、Node 版本、啟動腳本。
3. 詢問是否需要 Postgres、Redis、熱更新。
4. 生成 Dockerfile、docker-compose.yml、.env.example。
5. 輸出啟動命令、常見故障和排查說明。

這個例子說明了 Skill 的本質：不是把所有知識都堆在一段 Prompt 裡，而是把一個任務的常見決策路徑明確下來，方便 AI 反覆使用。

案例二：自動生成 API 測試用例

第二個非常適合 Skill 的案例，是自動生成 API 測試用例。因為介面測試天然有固定套路：正常路徑、參數校驗、權限校驗、邊界條件、錯誤處理、冪等性和回應結構檢查，這些內容非常適合標準化。

如果只靠一次性 Prompt，AI 雖然也能列出一些測試點，但輸出品質常常依賴你提問是否完整。把它做成 Skill 之後，就可以提前規定：先讀取 API 定義，再按統一維度列出測試點，然後按指定框架輸出測試程式碼骨架，最後標出不確定項等待人工確認。

這個 Skill 的輸入通常包括：

• OpenAPI / Swagger 文件或介面定義。

• 鑑權方式，例如 Bearer Token 或 Session。

• 使用的測試框架，例如 Jest、Pytest、Playwright API。

• 環境資訊，例如 dev 或 staging 的 base URL。

輸出則可以分為兩層：第一層是結構化測試點，第二層是自動化測試程式碼範本。對於「建立訂單」這類介面，一個較完整的 Skill 至少會引導 AI 覆蓋正常建立、缺失參數、權限失效、庫存不足、重複提交是否冪等等關鍵情況。

一個簡化版 SKILL.md 可以這樣寫：

---
name: api-testcase-generator
description: 根據 API 定義生成結構化測試點和自動化測試程式碼骨架，適用於 REST API 介面測試。
---

當使用者希望為 API 自動生成測試用例、補齊邊界測試或生成測試程式碼範本時使用本 Skill。

步驟：
1. 讀取 API 定義，包括路徑、方法、參數、回應和鑑權方式。
2. 生成正常路徑、參數異常、權限異常、邊界值、冪等性等測試點。
3. 按使用者指定框架輸出測試程式碼骨架。
4. 對不確定的業務規則標記「需要確認」。

這種 Skill 的價值不只是提速，更重要的是幫助團隊把「測試經驗」顯式化。原本依賴資深同學腦中的隱性知識，現在可以變成 AI 可重複呼叫的工作流。

怎麼用 AI 幫自己做 Skill

做 Skill 最常見的誤區，是一開始就試圖設計一套特別完整的規範。更高效的做法通常是先拿一個真實任務，讓 AI 和你一起跑通，再把其中穩定、重複的部分提煉出來。

一個實用做法是按四步走：

1. 先完成一次真實任務，觀察 AI 缺什麼資訊、哪裡容易出錯。

2. 把這個任務拆成固定步驟，整理出輸入、追問點、輸出物。

3. 把高頻範本、腳本、說明文件放進 Skill 目錄。

4. 用真實 bad case 持續修正 Skill，而不是一次寫完就不管了。

這種方法特別適合開發團隊，因為很多流程本來就已經存在，只是散落在不同地方。Skill 做的事情，其實是把這些分散知識重新組織成 AI 可執行的型態。

在工作中怎麼把 Skill 用好

Skill 真正產生價值，不是因為「概念先進」，而是因為它能進入日常工作流。官方資料提到，Skill 的重要用途之一是承載組織知識和專業工作流，這對開發團隊尤其有現實意義。

在工作中更容易落地的做法通常有三條：

• 從小任務開始，先做一個高頻、邊界清晰、容易驗證效果的 Skill。

• 把 Skill 當作團隊知識的可執行版本，而不只是靜態文件。

• 像維護程式碼一樣維護 Skill，持續根據失敗案例修正它。

對很多團隊來說，一個「本地 Docker 開發環境」 Skill，或者一個「API 測試用例生成」 Skill，就已經足夠作為起點。因為這兩類任務同時滿足了重複頻繁、流程穩定、價值直觀三個條件，很適合快速看見收益。

結語

如果要用一句話解釋 Skill，可以說：它是把經驗、規範、流程和資源打包成 AI 可反覆呼叫的工作手冊。Anthropic 的官方定義也明確指出，Skill 是由指令、腳本和資源組成的資料夾，Claude 會在相關任務中動態載入它們，以改進專業任務表現。

對開發者來說，Skill 最值得投入的地方，不是「能不能做得很複雜」，而是「能不能把一個重複任務做得穩定、好用、可交接」。從 Next.js 本地 Docker 開發環境，到自動生成 API 測試用例，這些都是非常適合入門的起點。