不是所有工作流都该做成 Skill：先过这 7 关
MCP 规范 2026-07-28 版（2026-07-28 释出）把 Skills over MCP 列为可选扩展，同时把 Tools 定义为可供模型执行的函数——这两件事放一起，刚好能给“什么该做成 Skill”划一条边界。过去一年里，很多 AI 团队的工作流从“给模型写一条更长的提示词”慢慢变成了“把稳定任务封装成 Skill”。但做得多了以后会发现，真正失败的封装往往不是代码写错，而是对象一开始就选错了——比如把一周用一次、步骤经常变的任务也封装起来，结果维护成本反而高于复用价值。
本文按 MCP 规范与一般工程实践给出 7 个决策点（其中阈值数字是我自己的工程经验，不是 MCP 规范要求）。具体到实现层面，本文假设你已经装好 MCP 客户端 SDK 或等价工具；如果还没装，建议先看官方 Quickstart 跑通一次，再回到这 7 关。
先分清：Skill 不是提示词收藏夹
MCP 规范把服务器能力分成 Resources、Prompts、Tools 三类：Resources 提供上下文数据，Prompts 提供模板化消息，Tools 是模型可以执行的函数，这是官方分类（据 MCP Specification）。Skills over MCP 出现在扩展列表里，定位是 “rich, structured instructions for agent workflows”。这句话的关键不是 “rich”，而是 “structured”——如果一个工作流每次都要靠你临时在聊天里补充大量上下文，它还没有到值得做成 Skill 的阶段。
这里有一个容易混的点：提示词擅长的是“告诉模型怎么想”，Skill 擅长的是“让模型可以怎么做”。前者是认知引导，后者是可调用的流程。下面 7 个决策点可以当作过滤网，每过一关，它就更像函数而不是一段提醒。所有判断阈值都是我的工程经验值，不是 MCP 规范要求，我会在每一条里标清楚。
7 个决策点
1. 这件事一个月会做几次？
如果每月少于 10 次，且单次不超过 15 分钟，封装和维护的投入通常不划算。这里的 10 次 / 15 分钟是我的门槛，不是官方数据。低于这个频率，复制粘贴提示词加手动调整往往更省时间。一个三个月才跑一次的数据清洗，写成 Skill 以后最大的可能是你忘了它存在，等再跑时环境已经变了。
2. 步骤是否稳定，还是每次都要重新排一遍？
稳定的定义是过去三次执行时，步骤顺序变化不大。步骤一变，Skill 里的工具调用顺序或解析逻辑就会开始出错。一个每周都要改的 Skill 会变成新的负担，而且这种负担通常比原来的工作流更隐蔽，因为它把“变化”藏进了固定结构里。
3. 输入输出能不能结构化？
如果能写清楚“输入是什么、输出是什么”，例如 YAML、JSON，甚至一个明确的文件路径，那适合封装；如果结果要用一页自然语言才能描述完整，先别做。结构化不是指数据一定规整，而是指边界清晰。边界清晰的任务，测试和回滚都容易。
4. 是否必须访问工具或外部数据？
如果需要读文件、查数据库、调 API、跑命令，Skill 的价值就大，因为模型不应该靠想象返回数据。如果只是让模型总结一段文字或改写一句话，提示词更直接。在 MCP 的语境里，这类能力对应的是 Tools 而不是 Prompts。
5. 失败成本是否可逆？
MCP 规范的安全原则之一是把 Tool 当作任意代码执行，必须让用户明确授权后才能调用。这是官方提醒，不是实践装饰。如果一个 Skill 会删除数据、发送消息、合并分支，而这些动作不可撤回，那就只保留半自动或强制确认。失败可逆的任务更适合自动化。
6. 是不是只有你一个人用？
个人工作流，提示词通常最轻；跨团队或跨项目复用时，Skill 的标准化收益开始超过维护成本。如果这件事只出现在你的聊天记录里，没有第二个人需要复现，那它可能更属于“个人知识管理”而不是“工作流产品”。
7. 能不能自动化测试？
能写脚本或断言判断“对/错”的任务适合 Skill；只能靠人主观评价“好不好”的任务，比如创意写作、情感安抚、风格判断，封装后很难验收。验收困难不代表不能封装，而是意味着你的 Skill 会长期缺少“坏了”的信号。
最小骨架
官方没有规定 Skill 的文件结构；下面是实践中常见的最小骨架，如果你是 MCP 环境，可以把执行部分映射到 Tools，把结构说明放到相当于 Skill 扩展的文档里。具体字段名可根据平台调整，不必照抄。
my-first-workflow-skill/
├── README.md # 说明这个 skill 做什么、输入输出、失败边界
├── prompt.md # 稳定指令：只写跨次不变的规则
├── skill.yaml # 元信息：触发条件、工具依赖、版本
└── scripts/
└── run.py # 幂等、可测试的执行逻辑这个骨架的核心只有一句话：prompt.md 每次都不改，变的东西进输入；scripts/run.py 每次都能被 assert。很多封装失败，就是因为在 prompt.md 里写了一次性的任务细节。
如果想把 7 个决策点变成一个可复算的自测函数，可以这样写：
def worth_skill(times, stable, structured_io, tool_needed, reversible, shared, testable):
score = 0
if times >= 10: score += 2
if stable: score += 2
if structured_io: score += 1
if tool_needed: score += 1
if reversible: score += 1
if shared: score += 1
if testable: score += 1
return score >= 6 # 我的阈值，团队可以调整阈值可以改。重点不是这个数字，而是让“封装”变成一个有明确判据的动作，而不是一时兴起。
什么时候不要做 Skill？如果前三项里有两项不满足，先继续用提示词；如果只有你一个人用，先写成聊天命令或模板；如果失败不可逆，先保留 confirm，不要一步到位全自动。
下面把上面 7 个决策点压缩成一张速查表，方便粘贴到团队 wiki：
| 项 | 通过条件 | 不通过怎么办 |
|---|---|---|
| 频次 | 每月≥10 次、单次 ≤15 分钟 | 复制粘贴 + 手动调整 |
| 步骤稳定性 | 过去 3 次步骤变化不大 | 重写为提示词或脚本 |
| 输入输出结构化 | 边界清晰、能写 schema | 先用提示词跑通再决定 |
| 工具/数据依赖 | 需要文件/DB/API/命令 | 提示词 + 手动查 |
| 失败可逆 | 撤销成本低 | 保留 confirm 步骤 |
| 多人复用 | 至少 2 人会用到 | 写成聊天命令 |
| 可独立测试 | 能写冒烟用例 | 拆成更小的子任务 |
反方：把不该封装的封装了
把这 7 个决策点当成硬门槛的反面是：门槛本身可能让人过度工程化。最常见的反方是”既然过 6 关就能做，那就做一个 Skill 吧”——结果是把一周用一次、步骤逻辑经常变的任务也封装起来，最后维护成本反而高于复用价值。
这条反方对工程上的含义是：上面 7 关都过了之后，还要问一句”如果三个月后没人用，删掉它需要多少工作”。如果删起来比维护起来还费劲，那它就不该被封装。
FAQ
Q：MCP 规范到底是不是必须把 Skill 写成 Tools？
不是。规范把 Skills over MCP 放在可选扩展里（2026-07-28 版规范），Tools、Resources、Prompts 是三类核心能力，Skill 是上层组合。如果你的 Skill 不需要让模型主动调用工具，只是一段结构化指令，用 Prompts 类就够了。
Q：怎么判断一个 Skill 是该升级成”工具”还是该降级回”提示词”？
看用户/agent 调用它时，是否希望它有副作用（写文件、调 API、改数据库）。如果有，封装成 Tool；如果是把上下文整理成结构化输入给模型用，Prompts 类更合适。
Q：Skill 和 prompts 收藏夹的最大区别是什么？
收藏夹是单条 prompt 的累积，每次用还要挑；Skill 是一段结构化指令加一份调用约定，调用方知道输入输出、副作用、错误模式。这是 Skills over MCP 在规范里强调”structured”的原因。
一个最小骨架（实践常见结构，不是 MCP 规范的硬性规定）
过完上面 7 关之后，做一个最小可跑的 Skill 通常包含三段：清单、入口、错误处理。下面是按一般工程习惯整理的最小骨架——MCP 规范 2026-07-28 版规定了 Tools、Resources、Prompts 三类能力，但对”一个 Skill 仓库的目录长什么样”并没有给出官方模板，所以这部分的目录与文件名都是实践经验，不是规范要求：
my-skill/
├── SKILL.md # 模型读到的入口说明（≤200 字，单一目的）
├── tools/
│ └── main.py # 模型可调用的 Tools 实现
├── resources/
│ └── input.schema.json # Tools 的输入 schema
└── tests/
└── smoke.py # 至少一个端到端冒烟用例SKILL.md 的写法是 Skill 与提示词最不一样的地方。它不是给模型的”提示词”，而是模型调用 Skill 时先读到的一段说明；语言上要短、要描述目的和副作用，不要塞示例对话。下面是一个示例骨架（按上面的目录约定写的示意，不是官方范例）：
# Skill: git-diff-summary
Purpose: Summarize the diff of the current branch against main.
Inputs:
- base_ref: string (default: "main")
- max_commits: integer (default: 50)
Side effects:
- Read-only. Does not modify the repo.
Returns:
- JSON: { commits: [...], files_touched: [...], risk_score: 0..1 }骨架就这么多。Skills over MCP 在规范里被定位成”rich, structured instructions for agent workflows”，所以重点在”结构化”——输入输出是什么、副作用是什么、有没有超时——而不是把提示词原样搬过来。做了之后用 tests/smoke.py 跑一遍，确认能按预期返回 JSON；如果返回的是大段自然语言，先别上线，按”输入输出能不能结构化”那一关重新判一下。
相关来源
评论区
登录后可评论。