02 · 什麼時候該做成 Skill

判斷標準就一句：一件事你只幹一次，Prompt 就夠；一件事你每週都幹，就值得做成 Skill。 這一章把這句話拆成能對照的訊號。

五個"該做了"的訊號

訊號 1：同一段話你貼了第三次

最直接的訊號。第一次是探索，第二次是巧合，第三次就是模式。

訊號 2：你的提示詞比材料還長

提示詞篇 08 章提過這個訊號。當你為了讓它穩定，堆了一大段規矩、模板、例子，而每次真正變的只有最後那幾百字材料——那一大段就該搬走。

訊號 3：同事問你"你那個提示詞能給我一份嗎"

一旦有第二個人要用，你就需要一個有明確版本、不會被各自改歪的東西。發一段文字過去，三個月後就是四個版本。

訊號 4：你開始擔心自己漏了哪條規矩

規矩超過五條，人就記不全了。你每次貼的時候都要回頭對一遍"這次有沒有漏掉'人名不要補全'"——這個焦慮本身就是訊號。

訊號 5：這件事有明確的"我們公司的做法"

PRD 該包含哪幾塊、週報的口徑、對客郵件的措辭禁忌、程式碼提交資訊的格式——凡是"我們這兒是這麼幹的"，都是 Skill 的天然素材。這類知識模型不可能自己知道，而且一旦寫下來就長期有效。

三種不該做的情況

一、這件事你一年幹兩次

做 Skill 有成本：寫、測、維護。一年兩次的活，成本收不回來。存在文件裡，用的時候複製貼上。

二、每次的要求都不一樣

"幫我分析一下這個" —— 每次分析的對象、角度、深度都不同，抽不出穩定的規矩。硬做出來的 Skill 會是一堆廢話，還可能在不該觸發的時候觸發。

判斷方法：把你過去三次的提示詞並排放，圈出完全一樣的部分。圈出來不到一半，就先別做。

三、你還沒調穩這條提示詞

Skill 是給已經跑通的東西用的。 提示詞本身還在"時好時壞"，做成 Skill 只會把不穩定固化下來，而且以後更難改——因為已經有人在用了。

先按提示詞篇 08 章調到測試集全綠，再打包。

一張對照表

情況	用什麼
臨時問個問題	Prompt
一次性的活（改一封郵件、總結一篇文章）	Prompt
每次都要交代的語氣、格式偏好	System Prompt
只有你一個人用、每週幹幾次的固定流程	Skill（或 System Prompt，看你的工具支援哪個）
團隊都要用的固定流程	Skill
"我們公司的 XX 該怎麼寫"這類規範	Skill
要查的資料（產品文件、政策、價格表）	RAG，不是 Skill
需要連資料庫、發訊息	MCP，不是 Skill
需求每次都不一樣	Prompt，別硬做

System Prompt 還是 Skill

這兩個最容易混。分界線：

	System Prompt	Skill
什麼時候生效	這段對話每一輪都生效	只在相關的活上被觸發
適合裝	跨任務的通用偏好：語氣、不要開場白、拿不準要說不確定	某一類活的完整做法
數量	一份	可以很多份
太多了會怎樣	每輪都佔地方，而且不相關的規矩會干擾判斷	沒被觸發的不佔地方

一句話："不管幹什麼都該遵守的"進 System Prompt；"幹這類活時才需要的"進 Skill。

最常見的錯誤

把"我們公司 PRD 該怎麼寫"這種東西塞進 System Prompt。結果你讓它改一封郵件，它也開始按 PRD 的結構給你分六塊。

規矩越具體，越該待在 Skill 裡按需觸發。

一個務實的起步建議

別一上來做五個 Skill。做一個，用兩週。

挑你手上最高頻、最煩、規矩最清楚的那一件（多數人是紀要、週報、或者某種固定格式的文件），照 05 章 做出來，然後強迫自己用兩週。

兩週後你會知道三件事：它什麼時候沒被觸發、哪條規矩寫得太鬆、哪條其實多餘。這三件事你想是想不出來的，只能用出來。

有了這一個的經驗，第二個會快很多。

下一步

03 · 一個 Skill 的解剖 —— 三層結構，以及為什麼是三層。