先说结论：Skills 是「操作手册」，MCP 是「插座」——一个管知识，一个管连接
Claude Skills 和 MCP 经常被放在一起比，其实它们解决的是两个不同维度的问题：Skills 解决「模型该按什么流程做事」（按需加载的指令与脚本包），MCP 解决「模型怎么连上外部系统」（标准化的工具连接协议）。理解这个分工，配置时就不会纠结「这个能力该做成 Skill 还是接个 MCP 」。
一张表看清区别
| 维度 | Claude Skills | MCP |
|---|---|---|
| 本质 | 带 frontmatter 的指令文件夹（SKILL.md + 支持文件） | 客户端-服务器协议（JSON-RPC，stdio/HTTP 传输） |
| 提供什么 | 知识、流程、脚本、参考文档 | 工具（tools）、资源（resources）、提示模板（prompts） |
| 加载方式 | 渐进披露：平时只有 description 常驻，触发才读正文 | 连接即枚举：工具列表常驻，调用时实时执行 |
| 运行位置 | 模型侧（指令注入上下文，脚本借模型的手执行） | 模型外（独立进程/远程服务，结果回传） |
| 典型例子 | 公司品牌规范、发版流程、代码审查清单 | GitHub 、数据库、文件系统、地图 API 连接 |
用一个例子看懂分工
假设要让 Claude 按公司规范发布一篇 WordPress 文章：
- 用 Skill：写一个 SKILL.md，内容是「发布前检查清单、标题怎么起、内链规则、封面规范」——这些是知识，模型读了自己会照做；
- 用 MCP：接一个 WordPress MCP 服务器，提供
wp_create_post、wp_upload_media工具——这些是能力，没有它模型再懂流程也碰不到你的站点。
两者组合才是完整方案：Skill 教「怎么发才对」，MCP 给「发出去的手」。单独只用其中一个，要么流程对但够不着（缺 MCP），要么够得着但乱发（缺 Skill）。
什么情况选 Skills
- 同样的指令、检查清单反复粘进对话；
- CLAUDE.md 里某段已经从「事实」长成「流程」；
- 知识量大但用得少（详细 API 文档、领域手册）——渐进披露让它在不用时不占上下文；
- 想跨工具复用：Agent Skills 是开放标准，Claude Code 之外的 AI 工具也能用。
什么情况选 MCP
- 模型需要访问它本来碰不到的数据或系统（数据库、 API 、私有服务）；
- 需要执行而不是「知道」：查真实数据、发真实请求、写真实文件；
- 一个连接器要服务多个客户端（写一个 MCP 服务器，Claude 、 Cursor 、 VS Code 都能接）。
快速判据：这件事「换个会话还需要重新告诉模型」→ Skill；这件事「模型不连外部系统就做不了」→ MCP 。
常见误区
- 把 MCP 当知识库用：通过 MCP 资源暴露一堆文档让模型读，不如直接做成 Skill——Skills 的按需加载对上下文更友好；
- 把流程硬写成 MCP 工具：把「检查清单」封装成一个工具函数，不如写成 SKILL.md 让模型灵活组合执行；
- 以为二者竞争：成熟项目通常 Skills 定义流程 + Hooks 管事件 + MCP 管连接，三层各司其职。
与 Function Calling 的三方对比也是高频问题，本站有专文拆解：
延伸阅读（站内）
Skill 能调用 MCP 工具吗？
能。 Skill 正文是指令，模型执行指令时可以自由使用手头的任何工具——包括 MCP 提供的。二者不冲突，组合使用正是推荐的架构。
MCP 服务器安全吗？要不要审查？
要。第三方 MCP 服务器是独立进程，拥有其声明的系统能力，历史上出现过工具描述投毒等攻击。只装可信来源的 server，生产环境审查工具列表与权限。
Skills 只有 Claude 能用吗？
Skills 是开放标准（Agent Skills），其他 AI 编程工具也可实现相同格式；MCP 同样是开放协议。但 Skill 的部分扩展字段（如调用控制）是 Claude Code 专属，跨工具使用时只依赖标准字段最稳。
参考来源：Claude Code 官方文档（code.claude.com）；modelcontextprotocol.io 协议规范。本文为原创整理。
评论 (0)