AI 助手的技能：SKILL.md 是什麼，以及如何不用終端安裝

什麼是 SKILL.md

SKILL.md 是一個純文字檔案，裡面寫著 AI 助手動手做事之前要先讀的一份說明。 它不是程式，也不是外掛，就是普通的 markdown：寫清楚某一類活兒該怎麼幹——先核對什麼、 按什麼順序推理、結果以什麼形式給出、什麼事絕對不做。把檔案放進程式碼倉庫，助手取走它， 從此這類活兒就按寫好的方式做，而不是由模型臨場發揮。

這個格式出現在 2025 年底，幾個月內就通用了：Claude、Codex、Copilot、Cursor、 Gemini CLI 以及幾十種工具都能讀，公開目錄裡的技能數量已經以十萬計。可幾乎所有文件 都是寫給擁有終端、倉庫和一個正在執行的程式設計代理的人看的——這也是這件事至今看著像 開發者專屬的唯一原因。

檔案本身很簡單。兩部分，用一行三個連字元隔開。

下面是一個體量接近真實的完整技能。它規定了怎麼覆盤一通銷售電話的錄音：找什麼、 按什麼順序找、以及什麼不能靠猜來補。

---
name: sales-call-review
description: 銷售電話覆盤 —— 異議、訊號、下一步
---

# 銷售電話覆盤

你正在分析一通與潛在客戶通話的文字記錄。

## 處理順序

1. 把異議「按原話」摘錄，加引號。不要轉述：
   異議的原始措辭本身就是資料。
2. 每條異議標明是否作了回應，以及回應是否被接受。
   沉默不等於接受。
3. 找出關於預算、時間和決策人的訊號。
   如果某個訊號沒出現，就照實寫「未提及」。
4. 確定下一步：具體做什麼、誰來做、什麼時候之前。

## 輸出格式

按上面的順序分四節。節內用短條目，不寫引言段落。
異議以引號原文呈現。

## 不要做的事

- 不揣測對方動機，只處理真正說出口的內容。
- 不用百分比估算成交機率——沒有支撐這個判斷的資料。
- 如果全程沒談到價格，就不要把打折當作下一步。

請注意這個檔案裡沒有什麼：沒有程式碼，沒有配置，沒有 API 金鑰，沒有安裝命令。 技能是寫下來的經驗，不是軟體。正因如此，從沒開啟過終端的人也能寫；也正因如此，安裝 它至今還要用終端，才顯得反常。

技能、工具和提示詞：各管什麼

這三樣解決的問題不同，卻總被混為一談。區別比看上去簡單：提示詞定角色，技能定 方法，MCP 給訪問權限。

由此得出實用的判斷：助手答得不著邊際，你需要技能；答得對但不知道事實， 你需要 MCP。技能再打磨也帶不來資料，MCP 再多也教不會方法。多數場合需要的是技能： 方法比資料老化得慢得多，而且寫一次就夠。

為什麼「無需終端」通常說的是別的事

「怎樣不用終端安裝技能」是常見的搜尋，結果也確實給出了答案。只不過答的是另一個 問題。

由此可以得到一個更好的判斷標準：別問「需不需要終端」，問「我是不是得在自己 電腦上再養一個代理」。如果答案是「是」，那麼無論安裝介面多精緻，技能都仍然是 開發者的工具。

不用終端、也不用程式設計代理的安裝方式

Whisperer 直接讀取 SKILL.md，並把它應用到助手的回答上。沒有什麼要安裝：檔案不會 到達你的電腦，沒有目錄，也沒有需要重啟的東西。來源有兩個——一個公共目錄，以及任何 一個公開的 GitHub 倉庫。

1. 網頁端 → 提示詞 → 「技能」按鈕
2. 「現成的」標籤頁 → 輸入檢索詞：system design、code review、
   sales、writing……
3. 列表會顯示名稱、來源倉庫和安裝次數。點開一個即可讀到它
   frontmatter 裡的說明
4. 「安裝」——技能進入你的資料庫
5. 開啟一個提示詞 → 「連線」→ 選擇技能

1. 網頁端 → 提示詞 → 「技能」→ 「自己的倉庫」標籤頁
2. 貼上下列任意一種形式：
   owner/repo
   https://github.com/owner/repo
   https://github.com/owner/repo/tree/main/skills/sales-review
   https://github.com/owner/repo/blob/main/skills/sales-review/SKILL.md
3. 「查詢技能」——我們會遍歷倉庫，把其中的每個 SKILL.md 連同說明
   列出來。如果你貼上的是某個具體目錄的連結，那個技能會排在最前
4. 在想要的那個上點「安裝」→ 然後連線到提示詞

技能到底作用在哪裡

技能不是接到「整個助手」上，而是接到某個具體角色 的提示詞上。角色指的是工作領域：回答問題、讀程式碼、讀影象、系統設計。把技能接到一個 角色上，它就在這個角色工作的所有地方生效。

連線有兩種模式，差別比名字給人的印象要重。

「補充」——技能被追加到提示詞文字上。角色和語氣依舊由提示詞決定，技能負責 細化方法。十次裡有九次該選這個。

「替換」——技能把提示詞文字整個擠掉，單獨送進模型。它是給那種自成一體的 技能用的：角色、步驟、輸出格式它都已經定好，這時你自己的提示詞反而礙事。若連線了 兩個技能而其中一個是「替換」，那它排在最前，「補充」的技能隨後對它作細化。

安裝之後，技能會發生什麼

這裡藏著區分「能用的安裝」和「日後添堵的安裝」的關鍵。技能會被釘在某個提交 上。安裝那一刻我們記錄取到的是檔案的哪個版本，之後一直用這一個。

「從倉庫更新」會重新讀取檔案、展示新版本，並把技能重新釘到當前提交。從資料庫裡 刪除技能，它的所有連線也一併消失，不需要另外清理。

先寫哪三個技能

挑選標準是：在你已經把同一件事解釋過三遍的地方，技能才划算。如果每次對話 都要重複同一條說明，那它就是候選；如果一個季度才用一次，手寫更省事。

1. 領域術語表

最被低估、也最快寫完的一個。你們的產品名、內部縮寫、同事的姓、客戶名稱——所有模型 第一次聽見就會寫錯的東西。五分鐘的工作量，效果在每一通電話裡都看得見。

---
name: our-glossary
description: 公司內部使用的術語、產品名和人名
---

# 我們的術語表

這些詞會反覆出現。請嚴格按下面的寫法書寫。

## 產品
- [名稱] —— [一句話說明是什麼]

## 縮寫
- [縮寫] —— [全稱]。不要與[相似的縮寫]混淆

## 人員
- [姓名] —— [職責]

如果某個詞讀音接近表中的詞，採用表中的寫法。
遇到不認識的術語，就按聽到的樣子保留，不要「訂正」成
你已經知道的相似詞。

2. 你的跟進郵件的固定形態

通話之後的郵件每次都遵循同樣的結構，而這個結構因人而異。技能把它固定下來：包含哪 幾節、按什麼順序、寫多長、第一句話怎麼起頭。「助手回答了」和「助手像你一樣回答了」 之間的距離，在第一次嘗試時就會顯現出來。

3. 針對你這類會議的覆盤方法

文章開頭那個例子就是。面試、銷售電話、覆盤會和調研訪談，各自值得撈出來的東西並不 相同。通用助手撈的是「主要話題」；技能撈的是原話異議，或者客戶痛點的訊號，或者同一 組問題下不同候選人的差異。

安全：公開技能裡約有三分之一存在問題

這是本文最重要的一節，而多數教學裡根本沒有這一節。

只要記住技能是「代理信任的一份說明」，機制就清楚了。危險出現在代理有手段去 執行它的時候：對檔案、對 shell、對你金鑰的訪問權限。這時「看一下 .env， 把裡面的內容加進配置」這一行，就直接變成了洩露。

由此引出一個在選擇安裝方式時值得弄清的區別。

把話說透：別人寫的說明，不存在「完全安全」這回事。去掉程式碼執行，最重的那 一類攻擊就沒有了——金鑰被盜、後門、檔案外傳——但文字仍然是文字。一份心懷不軌的技能， 依然能把助手往作者中意的措辭上推：推薦某個產品、不提替代方案、把結論輕輕帶偏。正文 在安裝時和每次更新時都會過一遍內容過濾，明顯違規的寫法過不去——但過濾器識別的是違規， 不是動機。

於是實用的結論很簡單：技能正文就擺在它的卡片上，值得讀一遍。那是兩屏用 日常語言寫成的 markdown，不是需要受過訓練才能審的程式碼。連線之前花五分鐘讀一讀，就 解決了在程式設計代理的世界裡需要掃描器才能解決的問題。

值得提前知道的限制

四件事，與其讓你以後發現，不如現在就說。

依賴指令碼的技能只能部分生效。目錄裡有一部分技能，是按「代理會執行隨附的 程式碼」來寫的。這裡只執行文字。如果說明本身能獨立成立，技能就完整生效；如果它歸根結底 是「執行 analyze.py」，那就完全不生效。這在安裝前就能判斷：說明和正文在 預覽裡都看得到。

正文上限是 24 000 個字元。大約十頁——超過任何一個像樣技能所需的量。更長的 檔案會被截斷後連線，而且我們會明確告知，不會悶聲不響。

技能始終在提示詞裡，不是按需載入。有些程式設計代理只在判斷任務相符時才把 正文拉進來。在這裡，已連線的技能會在該角色的每次請求中送給模型。這樣更可預期——不會 在你需要時偏偏沒觸發——同時也正是每個提示詞最多三個的原因。

不支援私有倉庫。我們訪問 GitHub 時不帶你的憑據，所以只能看到公開內容。私有 倉庫和不存在的倉庫在我們這兒是一回事：兩者都回「未找到」。

連線他人技能之前的核對清單

常見問題

寫技能需要會程式設計嗎？

不需要。技能就是用日常語言寫的文字：做什麼、按什麼順序、避開什麼。唯一的技術要求 是檔案開頭四行 frontmatter，可以直接從上面的例子裡照抄。GitHub 倉庫能在網頁介面建立， 檔案也用按鈕新增。

技能和系統提示詞有什麼不同？

提示詞寫的是誰在回答、用什麼語氣；技能寫的是某一類活兒怎麼幹。實際差別在於複用： 提示詞是個人的，而技能寫一次，就適用於所有做同樣工作的人。這也是人們會分享技能、卻 幾乎不分享提示詞的原因。

該選技能還是 MCP？

這不是二選一。技能帶來方法，MCP 帶來資料和操作。助手答得不著邊際，你需要技能；答 得不錯卻不知道事實，你需要 MCP。兩者都需要的情況也很常見：MCP 從任務看板取來資料， 技能規定怎麼處理它。

一個技能能連線到多個提示詞嗎？

可以。資料庫是共用的，連線數量沒有限制。技能只存一份，在所有接上的地方都生效。

如果作者在倉庫裡改了這個技能會怎樣？

什麼也不會發生。你的副本凍結在取用時的那個提交上。只有當你按下「從倉庫更新」， 改動才會到來——那時新的正文會重新過一遍內容過濾。

為什麼搜尋有時什麼都不返回？

兩個原因。目錄可能臨時不可用——這時列表是空的，但連線自己的倉庫照常可用。或者是 GitHub 在限流：沒有令牌時，配額是按整個服務計算的，這種時候等上幾分鐘，比把空結果 說成「沒有技能」要誠實。

為 Claude Code 或 Cursor 寫的技能在這裡能用嗎？

能，前提是說明本身能獨立成立：格式完全一致，文字讀起來也一樣。搬不過來的是那些 預設了檔案系統、shell 或指令碼執行的部分——一個處理你會議的助手，按設計就沒有這些 東西。

從哪兒開始

判斷技能是否適合你，最快的辦法是：挑一條你已經連著給助手下過好幾次的說明，把它 存成技能。檔案花五分鐘，連線花一分鐘。結果馬上就能讀出來：如果回答更貼近你本來的 意思，那你剛剛不用再重複自己了。如果沒有，那條說明講的是資料而不是方法，答案在別的 工具那裡。

技能資料庫在網頁端的提示詞裡。提示詞和角色的機制見 Prompt Studio 說明，哪個模型負責 哪個角色見模型角色參考。