Claude Skills 深度拆解:它和 MCP、Subagent 到底是什么关系
Simon Willison 说过一句话,挺刺耳:
Claude Skills are awesome, maybe a bigger deal than MCP.
第一次看到这话,我是不信的。MCP 解决的是「模型能接什么」,Skills 看起来只是几个 markdown 文件,怎么可能更重要?
直到我自己写了三个 Skill,把团队里重复了半年的活儿塞进去,才明白他说的是什么意思。

一、Skills 到底是什么
一句话:一个文件夹 + 一份 SKILL.md。
pdf-report/
├── SKILL.md # 必需:说明这个 Skill 干什么、怎么干
├── scripts/
│ └── build.py # 可选:可执行脚本
└── templates/
└── weekly.md # 可选:模板、参考文档、示例
SKILL.md 的开头是 YAML frontmatter:
---
name: pdf-report
description: 把 CSV 数据生成 PDF 周报。当用户要求生成周报、月报或经营分析 PDF 时使用。
---
# 生成周报 PDF
## 步骤
1. 读取 `data/` 目录下最近的 CSV,确认时间范围
2. 运行 `scripts/build.py --input data/ --output out/report.pdf`
3. 检查生成页数,超过 5 页时提醒用户精简指标
## 注意
- 金额单位统一为万元,保留一位小数
- 图表配色固定用 templates/palette.json,别自己调
就这样。没有 SDK,没有注册中心,没有构建流程。
它的本质是「写给模型看的操作手册」。
二、为什么它不占上下文
这是 Skills 最聪明的地方,叫渐进式披露(progressive disclosure)。
一个 Skill 的内容分三层,加载时机完全不同:
| 层级 | 内容 | 什么时候进上下文 |
|---|---|---|
| 第一层 | frontmatter 里的 name + description | 常驻,但只有几十个 token |
| 第二层 | SKILL.md 的正文 | 命中时才读,几百到几千 token |
| 第三层 | scripts / templates / 参考资料 | 按需执行或读取,根本不进上下文 |
对比一下传统做法:把所有规范文档塞进系统提示词,一个 PDF 规范就吃掉 8000 token,而且每次对话都吃。
Skills 的做法是:启动时只告诉模型「有这么一本手册,讲的是生成 PDF 周报」,等真的要做这件事了,才翻开目录看正文,需要执行脚本了才去跑。
这也解释了一个常见疑问:为什么装十几个 Skill 不会把上下文撑爆?因为装的时候只装了「书名」,没装内容。
三、Skills ≠ MCP,它们管的不是一回事
这是最容易混的地方,我用一句话区分:
MCP 管「工具怎么接进来」,Skills 管「这类活儿怎么干」。
具体对比:
| MCP | Skills | |
|---|---|---|
| 解决什么 | 让模型能调用外部工具和数据 | 让模型按你的规范完成一类任务 |
| 形态 | 协议 + Server 进程 | 文件夹 + markdown + 脚本 |
| 谁来写 | 工具提供方 | 业务方自己 |
| 运行时 | 跨进程调用 | 读文件、执行脚本 |
| 换个模型还能用吗 | 能,是标准协议 | 能,本质是提示词工程 |
举个具体例子:
你要做「每周经营分析报告」这件事。
- MCP 负责让模型能拿到数据库里的销售数据、能读文件系统、能发邮件。
- Skills 负责告诉模型:先取哪几张表、怎么算同比、图表用什么配色、报告分几段、什么情况下要标注异常。
没有 MCP,模型拿不到数据;没有 Skills,模型拿到数据也不知道你的规矩。
两个都缺一不可,但 Skills 更「业务」,MCP 更「基础设施」。
Simon Willison 说 Skills 可能更重要,我理解他的意思是:MCP 让能力变多,Skills 让能力变准。 而实际工作中,让人抓狂的往往是后者。
四、Skills 和 Subagent 也不是一回事
第三个容易混的东西。
- Subagent:另开一个独立的上下文窗口去干活,干完只把结论带回来。解决的是「上下文太满」和「任务要隔离」。
- Skills:在当前上下文里,给模型加一本可查阅的手册。解决的是「模型不知道你的规范」。
判断很简单:
- 任务很长、很脏、只需要结果 → 用 Subagent
- 任务不复杂,但步骤有讲究、格式有要求 → 用 Skills
- 两者可以叠:Subagent 里也可以加载 Skill
五、什么样的活儿值得写成 Skill
我写了三个之后,总结出一条判断标准:
这件事,你是不是已经跟同事解释过三遍以上?
如果是,就值得写。
我写的三个:
- 周报生成:数据源固定、计算口径固定、排版固定。以前每次都要说一遍「金额用万元、同比算环比」。
- 代码审查清单:团队有 12 条硬性规范(比如禁止裸
except、必须打日志)。以前靠人记,现在 Skill 里列清楚,模型审代码会自动对照。 - 客户方案模板:不同行业的方案结构不同,把结构写进 Skill,输出格式就稳了。
反例: 只做一次的临时任务、需要大量人工判断的决策、纯靠模型自由发挥的创意工作。这些写 Skill 是浪费。
六、写 Skill 的三个经验
第一,description 写得像「触发条件」,不要像「功能简介」。
差:description: 生成 PDF 报告
好:description: 把 CSV 数据生成 PDF 周报。当用户要求生成周报、月报或经营分析 PDF 时使用。
因为 description 是模型判断「要不要翻开这本手册」的唯一依据。写清「什么时候用」,命中率差好几倍。
第二,正文写成「步骤 + 判断」,不要写成「知识科普」。
模型不需要你解释什么是同比,它需要知道「同比算不出来的时候,是留空还是标 N/A」。写规则,不写背景。
第三,能写成脚本的,别写成文字。
「金额保留一位小数」这种要求,与其在正文里反复强调,不如在 build.py 里 round(x, 1)。脚本比提示词可靠一个数量级。
上面这些,是我看完一份《Claude Skills 完全指南》之后自己动手验证的。那份资料把 Skills 从概念、渐进式披露、和 MCP 的对比、到三类适用人群讲得挺完整:

加上我自己写的三个 Skill 的完整代码和踩坑记录,一起整理成了一份笔记。
想要的,扫码加我,备注「大模型」👇

不用转发、不用关注,加上直接发你。
348



被折叠的 条评论
为什么被折叠?



