09 · 各家怎麼落地
這本書不綁定任何一家。但 Skill 這件事必須落到具體工具上，所以這一章給一張對照表：名字各不相同，形狀是一樣的。
這一章最容易過期
產品名、選單位置、檔案路徑，隨時會變。記形狀，別記路徑——具體位置以你所用工具的官方文件為準。
形狀是什麼
不管在哪家，一個 Skill 都由這三樣組成：
- 一個標識（名字）
- 一段說明：這是幹什麼的 + 什麼時候用它
- 一段正文：具體怎麼做
區別只在於：這三樣存在哪、由誰觸發、能不能帶附件。
對照表
| 形態 | 在哪兒 | 觸發方式 | 能帶附件嗎 |
|---|---|---|---|
| 檔案式 Skill | 一個資料夾，裡面放一個說明檔案（常見命名是 SKILL.md）；個人的放使用者目錄，專案的放專案目錄 | AI 自己按說明匹配 | 能，還能帶腳本 |
| 上傳式 Skill | 網頁版產品的設定裡上傳（通常打包成 zip） | AI 自己按說明匹配 | 通常能 |
| 自定義助手 / 智慧體 | 產品裡"建立智慧體 / 應用 / GPTs"，把正文貼進說明框 | 你手動選中那個助手 | 通常能傳知識檔案 |
| 專案規則檔案 | 專案根目錄的一個約定檔名（各家不同） | 開啟這個專案就自動生效 | 一般不能 |
| 企業內部平臺 | 建一個"應用"，貼進配置 | 看平臺設計 | 看平臺 |
四種形態各自的取捨
檔案式：最適合團隊
優點：跟程式碼放一起，能提交、能 diff、能 review、能回滾。改了誰都看得見。附件和腳本支援最好。
缺點：得有個能讀檔案系統的工具（命令列或 IDE 裡的那類）。純網頁使用者用不了。
適合：產研團隊、有程式碼倉庫的場景、需要多人共用同一版的場景。
上傳式：網頁使用者的對應物
優點：網頁版就能用，不需要本地環境。
缺點：版本管理靠你自己。多數產品是每個人各傳一份——同事那份和你這份很容易走散。
適合：個人高頻使用；團隊用的話，要額外約定一個"哪份是權威版本"的地方。
自定義助手 / 智慧體：最容易上手
優點：幾乎每家都有，介面化，五分鐘能建一個。
缺點：通常要你手動選中它，而不是 AI 自動判斷。這跟真正的 Skill 有本質區別——你得先想起來"這活該用那個助手"。
適合：第一次嘗試；或者你本來就習慣"先選工具再幹活"。
專案規則檔案：作用域最清楚
優點：開啟這個專案就生效，不用觸發，不會漏。
缺點：它更像專案級的 System Prompt 而不是 Skill——每次都全量生效，不是按需載入。所以只該放"在這個專案裡幹什麼都適用"的規矩，不能塞具體流程。
適合：專案約定、程式碼規範、術語表。
一個跨平臺的現實問題
Skill 通常不跨平臺同步
你在網頁版傳的 Skill，命令列工具裡讀不到；命令列裡的檔案式 Skill，網頁版也看不見。同一個 Skill 想在幾個地方用，多半要各放一份。
這不是誰的設計缺陷，是它們的儲存位置本來就不同。
應對辦法：把正文當成唯一的源。
在你的倉庫或共享盤裡存一份權威版本（就是那份 Markdown），需要用在哪個平臺，就從這份複製過去。
改的時候改源，再同步。別在各個平臺上分別改——那是走散的開始。
一份能到處用的正文
不管落到哪個平臺，這份正文是通用的——你只是把它放到不同的地方：
# [Skill 名]
## 什麼時候用
[什麼情況下適用；什麼情況下不適用]
## 流程
1. …
2. …
## 輸出模板
[模子]
## 規則
- …
## 示例
[至少一組，含邊界情況]
## 檢查清單
- [ ] …上面這段貼進"自定義助手"的說明框，也貼進 SKILL.md 的正文，只是前者要在開頭補一句"什麼時候用我"，後者寫進 description 欄位。內容一模一樣。
關於 Skill 的"標準"
目前最標準化的一種形式，是用一個資料夾 + 一個帶 YAML 頭的 SKILL.md：
---
name: meeting-notes
description: 做什么 + 什么时候用
---它的價值不在於哪家發明的，而在於它把"觸發說明"和"正文"分開了，這才有了按需載入。其他形態或多或少都在往這個方向走。
所以：你按這個形狀寫正文，將來搬到哪兒都不虧。