技能 不是進階快捷提示詞，而是 代理 的工作協議
這裡的問題定義很準：代理 常常不是沒有能力，而是沒有穩定的做事方式。它會寫 code，卻不知道你們團隊的 code 審核 方式；它會調工具，卻不知道先調哪一個；它會產出結果，卻不知道什麼時候該停下來檢查。
提示詞 解決的是「這一次怎麼說」；技能 解決的是「之後遇到這一類任務，應該怎麼做」。
常見誤解與真正問題
技能 只是資料夾
看起來只是 SKILL.md 加幾個腳本，但真正價值不在形式，而在工作方法是否被固定下來。
代理 沒有順序感
任務一旦跨多步驟、多判斷、多品質標準，代理 如果沒有流程骨架，就容易亂跳、漏步驟或提早交付。
重複解釋
每次都得重新講偏好、規範、停止條件與檢查標準，代理 永遠像剛入職的新人。
封裝可重用工作流
把一次性的口頭說明，變成可觸發、可執行、可檢查、可分發的長期能力。
觸發率低，通常不是模型問題，而是 描述 沒寫成路由規則
name 和 description 看起來像最簡單的 YAML 前置中繼資料，但實際上它們是自然語言路由器。代理 是否會自動選中某個 技能，很大程度就靠這一段。
| 情況 | 常見寫法 | 結果 | 比較好的寫法 |
|---|---|---|---|
| 過於抽象 | 「幫助處理專案」 | 代理 不知道是 衝刺週期、PM、設計交付，還是文件整理。 | 寫清楚任務類型、使用者常用說法、關鍵能力與適用場景。 |
| 觸發不足 | 觸發詞太窄 | 該用時沒用，使用者得手動提醒。 | 把真實使用者表達方式寫進 描述，例如「排 衝刺週期」「拆任務」「估容量」。 |
| 過度觸發 | 描述範圍過大 | 不該用時也亂跳出來。 | 補上負面條件，例如只做高複雜度資料建模，不處理簡單圖表。 |
設計時的判斷點
- 技能 的第一門功課不是寫流程，而是先寫清楚邊界。
- 你要先知道它服務什麼任務、不服務什麼任務。
- 你要先知道使用者會怎麼描述這個任務。
官方補充
Anthropic 的 技能 authoring best practices 明講：description 是主要觸發機制，必須同時包含「它做什麼」和「什麼情境該用」。官方 skill-creator 範本甚至提醒，目前 Claude 有 under-triggering 傾向，所以描述要比一般文件更主動一點。
漸進式揭露 的重點不是省 代元，而是知識分層
這裡可以拆成三層：第一層是 前置中繼資料，常駐、短、可觸發；第二層是 SKILL.md 主流程；第三層是 references、scripts、assets 這些按需讀取的外部資源。這樣做的目的，是讓 代理 不要一開始就被整包知識淹沒。
不要先想做一個「專案管理 技能」，先定義 2 到 3 個具體用例
這裡推薦用一個很實用的結構：Use case / Trigger / Steps / Result。這會逼你把 技能 寫實，而不是停留在抽象標籤。
抽象寫法
name: project-management description: 幫助處理專案管理工作
這種寫法最大問題是沒有工作範圍、沒有觸發語境、沒有產出標準。
比較可用的寫法
use_case: Sprint 規劃 trigger: 使用者提到拆任務、排 sprint、估容量 steps: - 取得專案狀態 - 分析團隊容量 - 建議優先級 - 建立任務與標籤 result: 已規劃好的 sprint，不是只給建議
能用腳本驗證的，不要只靠自然語言提醒
這是整份方法論裡最工程的一段。模型擅長理解意圖與生成內容，但不擅長穩定執行精確檢查。資料缺欄、日期格式、JSON 結構規格、章節是否缺漏，這類事情應該交給腳本，而不是靠模型「記得」檢查。
自然語言版風險
- 這次記得，下次忘了。
- 知道該檢查，但不一定真的執行。
- 檢查結果不穩，沒辦法工程化比較。
技能工程 版做法
- 技能 負責解釋何時要驗證。
- 腳本負責做確定性檢查。
- 代理 負責看錯誤、修正、重新跑，直到通過。
官方文件裡最值得帶回工作的 5 種 技能 模式
順序工作流編排
適合有固定先後關係的任務，例如客戶接入、付款設定、資料審批。重點是依賴順序、驗證點與回滾方式。
多工具協調
適合跨系統任務，例如設計交接、文件導出、建立任務、通知團隊。重點是資料如何在工具之間傳遞。
迭代優化
適合報告、提案、設計稿、程式碼。重點不是一次生成，而是生成、檢查、修正、再驗證的循環。
上下文感知的工具選擇
同一句需求，因檔案類型、大小、協作需求不同，應選不同工具。技能 要寫的是決策樹，而不是只列工具。
領域專業判斷
最有價值的類型。像支付審核、安全審計、合規流程，封裝的是專業判斷，不只是工具調用順序。
先認清類型，再做拆分
如果一個 技能 想一次解決所有類型的問題，通常會變得很大、很亂，也不容易觸發。
對實務團隊 最直接的落地方式
| 場景 | 可以做成的 技能 | 要特別寫清楚的邊界 |
|---|---|---|
| 教學 HTML 產線 | 教學頁生成、圖片引用、章節結構、個人教學風格檢查 | 哪些來源可信、何時需要人工審稿、哪些段落不能自行腦補 |
| PM／議題分流 | 拆需求、排優先級、估工、建立標籤與下一步 | 什麼資訊不足時必須停下來問、哪些任務不能自動指派 |
| 工程 審核 | code 審核、測試檢查、回歸風險摘要、PR 評語 | 哪些判斷用腳本驗證、哪些只給建議、什麼情況要升級人工 審核 |
| 研究報告 | 來源搜尋、可信度排序、引用格式、結論保守化 | 哪些資料不能直接引用、哪些結論不能寫太滿、交付前如何驗證引用完整性 |
做 技能 前先過這張清單
- 先定義 2 到 3 個具體用例。
不要先寫「我要做個資料分析 技能」，先寫使用者會怎麼說、技能 應該做什麼、最後要產出什麼。 - 先寫 描述，再寫主流程。
如果描述沒有辦法把任務邊界講清楚，後面流程寫得再漂亮也沒用。 - 把知識拆層，不要整包塞進去。
前置中繼資料 常駐、SKILL.md放主流程、references / scripts / assets 按需載入。 - 能用腳本驗證的，就不要只靠模型記憶。
格式、結構規格、缺欄、章節完整性，這些都應該自動檢查。 - 替 技能 設定評估標準。
至少量測觸發率、工具調用失敗率、來回澄清次數、交付一致性。 - 把 技能 當產品維護，不要當一次性 提示詞。
要有版本、有測試、有回報、有修正，這樣團隊才真的能重複使用。