別再把所有規則塞進 System Prompt：團隊打造 AI Skills 庫的實戰指南

很多團隊剛開始做 AI workflow 時，第一個反應都很一致：把規範、範例、口頭習慣、注意事項，通通塞進 system prompt。

短期看起來很省事。長期幾乎一定失控。

提示詞會越來越長，新人會開始複製上一個同事的整段模板，模型則會在一堆彼此無關的規則裡分神。最後你得到的不是一個更聰明的 agent，而是一個每天都在重新入職的實習生。

這也是為什麼這兩年越來越多團隊開始把重複任務做成 skills。它不只是「保存過的提示詞」，而是一種把專業知識、執行順序、參考資源和驗證標準打包成可重用模組的方法。

如果你已經寫過一兩個 skill，接下來真正要思考的問題其實不是「能不能寫」，而是：怎麼讓它在三個月後還能用，讓其他人也敢用。

這篇文章就專門談這件事。

什麼時候該把任務做成一個 skill？

不是每個需求都值得建 skill。很多事情一句 prompt 就夠了，硬拆成 skill 反而增加維護負擔。

我自己的判斷標準很簡單，只要下面四條裡中了三條，就值得考慮：

這個任務會反覆出現，而且不是只有你一個人會做。
這個任務有穩定流程，不靠靈感，靠步驟。
做錯的代價不低，例如會改壞程式、寫錯格式、漏掉檢查。
任務有辦法驗證，不是只能靠「感覺差不多」。

拿幾個常見例子來看：

「幫我想三個標題」通常不需要 skill，直接提問就好。
「依照團隊規範做 PR review，先抓高風險問題，再補測試缺口，最後按固定格式輸出」很適合做成 skill。
「把訪談錄音整理成文章，先提要、再抽引述、再生成雙語版本」也很適合。

換句話說，skill 最擅長處理的是高頻、重複、可檢查的工作。它不適合包辦所有創意工作，但很適合承接那些本來就容易流程化的專業任務。

一個能活得久的 skill，至少要有四層

很多 skill 寫不好，不是因為模型不夠強，而是因為作者只寫了「要做什麼」，沒有寫清楚「怎麼判斷、怎麼收尾」。

一個實用的 skill，我建議至少拆成四層：

1. 觸發層：讓 agent 知道什麼時候該打開它

這一層通常就是 name 和 description。別小看這兩行，它們直接決定 skill 會不會被正確喚起。

壞描述長這樣：

description: 幫助處理前端問題

這種寫法太空。前端問題到底是排版、效能、hook、測試，還是 build 失敗？對 agent 來說，這句話幾乎沒有可操作性。

更好的寫法是：

description: 當用戶要求排查 React 元件重渲染、useEffect 重跑、或互動卡頓時使用此 skill。優先檢查依賴陣列、非必要 state 與列表渲染。

這才像一個觸發器。它有任務類型，也有檢查方向。

2. 指令層：把流程寫成順序，而不是情緒

不少人寫 skill，會下意識把它寫成品牌文案：

你是一位世界級專家，擅長高品質、專業、全面地處理各種問題。

這種句子看起來很有氣勢，實際上幫助很小。agent 真正需要的是順序、限制和輸出格式。

例如：

## Instructions
1. 先閱讀變更檔案與測試結果。
2. 只優先報告會導致行為錯誤、效能退化或安全風險的問題。
3. 每個問題都必須指出檔案、行號與原因。
4. 如果沒有明確問題，直接說明「未發現阻塞性問題」，不要硬湊建議。

這種寫法遠比「請像資深工程師一樣思考」有用，因為它把執行標準說清楚了。

3. 資源層：把重內容放到外面，不要全塞正文

真正成熟的 skill，很少只靠一個 SKILL.md。

你通常還會需要：

references/ 放範文、規範、最佳實踐
examples/ 放正反案例
scripts/ 放可執行檢查腳本
templates/ 放輸出模板

一個很常見的誤區，是把所有內容都直接寫進主文件。這會讓 skill 很快膨脹，改一次規範就要翻整份長文。

更好的做法是保持骨架簡短，細節外掛。像這樣：

my-skill/
├── SKILL.md
├── references/
│   ├── editorial-style.md
│   └── release-checklist.md
├── templates/
│   └── weekly-report.md
└── scripts/
    └── validate_links.sh

主文件負責決策，資源文件負責細節。這樣後續維護才不會痛苦。

4. 驗證層：告訴 agent 何時停，怎麼確認沒做錯

這一層最容易被漏掉，但我覺得它反而是區分「玩具 skill」和「可交付 skill」的關鍵。

如果一個 skill 只能教 agent 怎麼做，卻沒有告訴它怎麼驗證，那最後常常會停在一個看起來很像完成、其實還沒落地的狀態。

舉個例子：

寫文案 skill 的驗證可能是「標題長度不超過 60 字元，描述不超過 160 字元」。
重構 skill 的驗證可能是「跑測試、看 lint、確認型別檢查通過」。
內容發布 skill 的驗證可能是「圖片存在、frontmatter 完整、內部連結帶尾斜線」。

Skill 不應只寫「完成任務」，而要寫：

## Verification
- 確認輸出檔案已建立
- 執行測試或檢查腳本
- 若驗證失敗，先回報失敗原因，不要假裝完成

這幾行字，常常比多加一整段背景介紹更值錢。

可直接複用的 team skill 模板

如果你準備在團隊內共用 skills，我建議先從下面這種骨架開始，再按場景加料：

---
name: release-note-writer
description: 當用戶需要整理版本更新、發佈說明或 changelog 時使用此 skill。優先提取對用戶可感知的變更，避免照抄 commit 訊息。
---

# Release Note Writer

## Goal
輸出一份可直接貼到公告、產品更新頁或電子郵件的版本說明。

## Inputs
- Git 變更記錄
- 已合併 PR 摘要
- 產品或運營補充說明

## Instructions
1. 先區分使用者可感知變更與內部維護變更。
2. 只保留真正值得對外說明的內容。
3. 用短句說人話，避免 commit 口吻。
4. 如果資訊不足，先列出缺口再動筆。

## Output
- 一段 40-70 字摘要
- 3-5 條更新要點
- 一條需要注意的限制或已知問題

## Verification
- 不要出現內部工單編號
- 不要照抄 git commit 原文
- 確認每條更新都能被非工程角色看懂

你會發現，這個模板其實沒有追求花哨。它只是把「輸入、流程、輸出、驗證」四件事說清楚。可偏偏就是這種樸素結構，最耐用。

團隊化之後，真正困難的是治理，不是編寫

一個人寫三個 skill 不難。十個人共用三十個 skill，問題才真正開始。

我看過不少團隊最後不是敗在模型效果，而是敗在治理：

skill 名字越取越抽象，沒人知道該用哪個
規範改了，沒人更新對應 skill
三個 skill 做同一件事，只是口吻不同
舊 skill 其實該退休了，卻還在被 agent 誤觸發

所以到了團隊規模，請把 skill 當成一種「輕量產品」，不是一段一次性 prompt。最少要補上這幾件事：

指定 owner：每個 skill 都要有人負責，不然過期只是時間問題。
加最後更新日期：不是為了好看，是為了讓團隊知道它多久沒被碰。
寫清楚適用範圍：不要讓一個 skill 又做 review、又做修 bug、又做文件生成。
建立淘汰機制：一旦流程改版，就要能明確標記 deprecated，而不是留著碰運氣。

你甚至可以把 skill 維護納入 code review。只要有人發現 agent 反覆犯同一種錯，就不是只修這一次，而是回頭修 skill。

這一步非常關鍵。真正高效的團隊，修的不是單次輸出，而是背後那套可重用的行為資產。

三個很常見的失敗模式

失敗一：description 寫得像標語

「處理內容相關任務」「協助工程工作」「提升效率」這種描述幾乎等於沒寫。skill 不是海報標題，它首先得可搜尋、可觸發、可判斷。

失敗二：把所有經驗都塞進主文件

如果 SKILL.md 長到像小說，多半表示它已經失去模組邊界了。把例子、規範和腳本拆出去，主文件只保留骨架。

失敗三：沒有驗證出口

很多 agent 最大的問題不是不會開始，而是不知道什麼叫完成。沒有驗證標準，輸出就很容易停在「看起來不錯」的半成品。

最後的判斷標準其實很務實

一個 skill 寫得好不好，我現在只看三件事：

新同事第一次用，能不能大致用對。
三個月後回來看，還看得懂、改得動。
agent 用完之後，能不能留下可驗證的結果，而不是只留下自信。

如果三條都做到了，這個 skill 大概率就不是臨時 prompt，而是真正能進工作流的資產。

skills 的價值，從來不只是「省幾個 token」。它真正厲害的地方，是把原本散落在聊天紀錄、資深同事腦內和各種口頭默契裡的做事方式，慢慢沉澱成團隊可以共享的操作系統。

這件事一旦做起來，AI 才不會每次都從零開始，而你的工作流也才有可能真正累積。