[MCP·Skill #2] AI 代理程式 Skill 完整解析：從斜線指令到自動觸發

使用 AI 程式碼工具時，常常會重複相同指示，例如「提交訊息請使用這個格式」或「部署前請依照這份檢查清單」。

SeokWoo Lee資深 iOS 軟體工程師發佈 2026年7月23日更新 2026年8月27日閱讀 5 分鐘

[MCP·Skill #2] AI 代理程式 Skill 完整解析：從斜線指令到自動觸發封面圖

使用 AI 程式碼工具時，常常會重複相同指示，例如「提交訊息請使用這個格式」或「部署前請依照這份檢查清單」。

每次都用提示詞說明會很冗長，全部放進 CLAUDE.md 或 AGENTS.md 這類常駐規則檔案，又會讓每個工作階段的上下文變得沉重。

Skill 就是用來解決這種重複。簡單說，它會把特定工作的流程與知識封裝成檔案，只在需要時載入。

它原本是 Claude Code 的功能，但現在已不再專屬於某個工具。2025 年 12 月，Anthropic 以 Agent Skills 之名公開規格，成為開放標準；之後 OpenAI Codex、Gemini CLI、Cursor、VS Code（GitHub Copilot）等超過 30 個工具都採用了相同格式。也就是說，建立一次的 SKILL.md 即使換用工具也能照常使用。

本文將整理 Skill 的結構、斜線指令與自動觸發這兩種呼叫方式、各工具的支援狀況，以及它與常駐規則檔案的職責區分。範例以最早導入這項功能的 Claude Code 為主，但概念適用於所有工具。

先看重點摘要。

Skill 是從單一 SKILL.md 檔案開始的指示資料夾，如今已是不受工具限制的開放標準
呼叫方式有兩種：使用者直接呼叫的斜線指令，以及模型自行呼叫的自動觸發
核心設計是漸進式載入。平時只載入名稱與說明，執行時才讀取正文
始終適用的規則放在 CLAUDE.md、AGENTS.md 等常駐規則檔案，特定工作的流程則放進 Skill

Skill 的本質是 Markdown 資料夾

Skill 的結構很簡單。一個資料夾內有一個 SKILL.md，就符合最低要求。

---
name: release-note
description: 撰寫版本說明草稿。使用於「版本說明」「部署說明」等請求
---

# 版本說明撰寫流程
1. 收集上一個標籤之後的提交
2. feat/fix/chore進行分類
3. 依對使用者的影響排序並撰寫草稿

上方 frontmatter 的 name 與 description 是註冊資訊，下方正文則是實際流程文件。也可以在資料夾中加入參考文件或指令碼，擴充成「指示書＋工具箱」。

標準只定義到這個格式。檔案要從哪個資料夾讀取由各工具決定，因此只要知道主要使用工具的路徑即可。

工具	Skill 目錄
Claude Code	`~/.claude/skills/`（全域）、`프로젝트/.claude/skills/`（專案）
OpenAI Codex	`.agents/skills/`
Gemini CLI (Antigravity)	`~/.gemini/antigravity/skills/`

放進專案資料夾後，就能透過 Git 與團隊成員分享，這在實務中特別實用。工作方法不再是個人筆記，而會成為儲存庫資產。即使團隊成員使用不同的程式碼代理程式，也能讀取相同的 SKILL.md，不必統一工具就能共享流程。

兩種呼叫方式：手動與自動

Skill 的執行路徑分成兩種。

第一種是斜線指令。使用者像 /release-note 一樣直接輸入，明確呼叫它。由人決定何時執行。

第二種是自動觸發。模型查看對話內容後，判斷「這個請求屬於那個 Skill」，再自行載入。判斷依據就是 frontmatter 的 description。

description 不是給人看的說明，而是給模型使用的路由條件。越具體描述「何時使用這個 Skill」，並納入觸發語句，自動呼叫就越準確。

這裡漸進式揭露（progressive disclosure）的設計很重要。工作階段開始時，進入上下文的只有各 Skill 的名稱與一行 description。完整正文只會在該 Skill 實際被呼叫時讀取。

因此，即使註冊數十個 Skill，平時的上下文負擔也幾乎不變。這正是把所有流程塞進常駐規則檔案的決定性差異。許多供應商採用這種格式的主要原因，也是漸進式載入；對任何模型而言，上下文視窗都是昂貴的資源。

與常駐規則檔案分工

每個工具都有自己的「永遠讀取的規則檔案」，例如 Claude Code 的 CLAUDE.md、Codex 的 AGENTS.md、Cursor 的 rules。兩者都是「提供給模型的指示」，很容易混淆。判斷標準是套用時機。

常駐規則檔案（CLAUDE.md、AGENTS.md 等）：每個工作階段、所有工作都必須套用的規則，例如程式碼規範、禁止事項、專案背景
Skill：只有執行特定工作時才需要的流程，例如部署、審查、文件產生等單位工作

問自己「它是否必須永遠成立？」如果是，就是常駐規則檔案；只有特定情況成立，就是 Skill。把始終適用的規則移到 Skill，觸發不到時規則就會消失。反過來，把所有流程放進常駐規則檔案又會浪費上下文。

建立時容易卡住的地方

先記住實務上最常遇到的兩個問題。

自動觸發不成功時，幾乎總是 description 的問題。若只寫「文件撰寫助手」這類抽象描述，模型無法判斷何時該使用。列出實際使用者可能輸入的語句會更有效。

反過來，若觸發得太頻繁，可在 description 中明確寫出「僅在……時使用，單純問題不要使用」等排除條件。

這個技巧適用於所有工具。因為自動觸發的判斷主體終究是模型，而模型看到的只有一行 description；這個結構在標準層面是相同的。

總結

Skill 終究是提示詞的函式化。與其複製貼上重複指示，不如命名儲存，並只在需要時載入。如今這個函式也成為不依賴特定工具的標準格式。

只要曾經把同一個指示輸入兩次，它就是第一個 Skill 候選。今天建立的 SKILL.md，明年無論使用哪個代理程式都能跟著你走。

Skill 的本質是 Markdown 資料夾

兩種呼叫方式：手動與自動

與常駐規則檔案分工

建立時容易卡住的地方

總結

延伸閱讀