一次性 Prompt
適合快速試驗，但知識容易散落在不同對話與不同人腦中。
Skill：讓 AI 從會回答到會穩定做事
先講結論：Skill 不是多一段漂亮 prompt，而是把任務知識、操作步驟、工具使用方式與邊界條件整理成可重用能力。從這一章開始，教材會從「怎麼問模型」正式走向「怎麼把做事方法沉澱下來」。
這章要解決什麼問題？
前四章處理的是模型理解、提示設計與成本選型；第 6 章開始要處理的是另一個層次的問題：當任務會重複出現時，怎麼把經驗與流程整理成可重用能力，而不是每次都從零寫 prompt？
為什麼 Prompt 還不夠？
當任務開始重複、流程開始變長、工具開始變多時，單次 prompt 會越寫越肥、越難維護，也越難保證不同對話的穩定度。
Skill
把做事方式沉澱下來，讓 Agent 知道什麼時候做、怎麼做、做到什麼程度才算完成。
Skill 的核心定位
它偏向任務層與行為層，不是在談底層通訊協定，而是在談「如何把工作方法封裝成可重用能力」。
面向
單次 Prompt
Skill
目標
解決眼前一次對話
沉澱可重複執行的任務能力
內容
角色、限制、格式要求
流程、工具策略、最佳實踐、完成條件
穩定性
依賴當次提示品質
適合反覆使用，行為更一致
維護方式
分散在對話或文件裡
集中管理，方便版本化與迭代
一個 Skill 通常包含什麼？
好的 Skill 不是「把任務講很長」，而是把 Agent 需要的工作知識切成幾個清楚的部分。
01
觸發條件
什麼情境下應該使用這個 Skill，避免 Agent 亂用或漏用。
02
任務流程
把步驟拆清楚：先看什麼、再判斷什麼、最後輸出什麼。
03
工具策略
明確說明何時應該讀檔、搜尋、查 API，何時只靠模型就好。
04
完成定義
什麼樣的輸出才算完成，什麼時候要補充驗證、承認不確定或請求更多資訊。
什麼情境特別適合做成 Skill？
- 固定類型的診斷工作： 例如 Java build error、Spring 啟動失敗、API 契約問題。
- 多步驟但結構穩定的任務： 例如 code review、文件摘要、資料清理、測試報告整理。
- 需要遵守團隊規範： 例如 commit 規則、回覆格式、部署前檢查清單。
- 新成員常重複問的事情： 代表這類 know-how 已經值得被封裝。
設計 Skill 的三個原則
不要一開始就把所有細節塞進去。先把能真正提高穩定度的部分封裝起來。
先求能用
原則 A：從最小可用 Skill 開始
先支撐一類常見任務，不要一開始就想包山包海。
- 先定義觸發條件與輸出標準。
- 能把常見錯誤率降下來，就有價值。
邊界清楚
原則 B：不要讓 Skill 管太多事
一個 Skill 最好只解決一類明確問題，這樣才能維護、測試與演進。
- 避免把 unrelated 任務硬塞在同一包。
- 命名與描述要能讓人一眼看懂用途。
持續修正
原則 C：從失敗案例回補 Skill
Skill 的價值常來自踩坑後的修正，所以要把錯誤模式、補救步驟與驗證方式記進去。
- 把常見誤判轉成明確規則。
- 讓後續任務不必再重複踩同樣的坑。
常見誤區
- 把 Skill 當成超長說明文件，結果沒有清楚的觸發條件與輸出標準。
- 把所有團隊知識都塞進同一個 Skill，最後誰也不敢改。
- 只寫理想流程，不寫失敗時該怎麼判斷、怎麼回報與怎麼止血。
- 把工具能力與任務知識混成一團，導致後續很難拆分成 MCP 或其他能力供應方式。
下一步會自然走到哪裡？
當你把「怎麼做事」封裝成 Skill 之後，下一個問題通常就是：那真正查資料、調工具、接外部系統的能力，要怎麼接進來？ 這也是下一章要談的 MCP。
1 分鐘小測驗
Q：哪個描述最符合 Skill 的定位？