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 的解剖 —— 三层结构，以及为什么是三层。