0. 太长不读
说实话，MCP 和 Skills 这两个概念，在 Claude Code 生态里确实是出了名的容易搞混。一句话概括：MCP 管连接，Skills 管流程。但真正让人头疼的，不是这句话本身，而是——Skills 里可以带脚本，脚本又能调 API、操作数据库……这不就撞到 MCP 的地盘上了吗？
这篇文章会从协议层、运行时、工程实践三个维度，把两者的边界彻底拆清楚。核心结论先放这儿：
- Skills 脚本和 MCP 在能力上确实有重叠，可运行机制完全是两码事
- MCP 是持久化服务进程，而 Skills 脚本是按需执行的、一次性的命令
- 选择的判断标准不是“能不能做”，而是“该用什么姿势做”
- 真正到生产环境，大多数场景需要的是两者协同，而不是二选一
1. MCP 到底是什么
一句话定义
MCP（Model Context Protocol），是 Anthropic 在 2024 年 11 月推出的一个开源标准协议，专门用来把 AI 应用连接到外部系统。你可以把它想象成 AI 世界里的 USB-C 接口——通用、标准、即插即用。
架构三件套
整个架构由三个核心组件构成，各司其职：
┌─────────────────────────────────────────────┐
│ MCP Host（Claude Code / IDE / 任意 AI 应用） │
│ │
│ ┌───────────┐ JSON-RPC 2.0 ┌────────┐ │
│ │ MCP Client │ ◄──────────────► │ MCP │ │
│ │（内置） │ stdio / SSE │ Server │ │
│ └───────────┘ └────────┘ │
│ │
│ ┌──────┴─────┐ │
│ │ 外部系统 │ │
│ │ DB / API / │ │
│ │ Notion / GH │ │
│ └────────────┘ │
└─────────────────────────────────────────────┘
| 组件 | 职责 | 类比 |
|---|---|---|
| MCP Host | 承载 LLM 的应用环境 | 电脑 |
| MCP Client | 管理 Host 与 Server 之间的通信 | USB 控制器 |
| MCP Server | 连接外部系统，暴露工具和数据 | USB 设备 |
运行时特征
MCP Server 是一个独立的、持久运行的服务进程。它启动之后，会做以下几件事：
- 向 Host 注册自己提供的所有工具（这是自动发现的，不需要你手动配置）
- 维持长连接，保持状态（包括认证、会话、缓存等）
- 通过 JSON-RPC 2.0 接收调用请求，返回结构化结果
- 生命周期跟随 Host，不会用完就退出
关键词提炼一下：持久、有状态、结构化通信、自动注册、跨应用复用。
一个具体例子
比如你启动了一个 Notion MCP Server，Claude 会自动获得以下这些工具：
notion-search
notion-create-pages
notion-update-page
notion-query-database-view
notion-get-comments
...（共 15+ 个工具）
不需要你做任何额外的配置，Claude 直接就能知道：自己可以搜索 Notion、创建页面、查询数据库……每个工具的定义、参数约束、返回格式，全部由 Server 进行了结构化声明。干净利落。
2. SKILLS 到底是什么
一句话定义
Skills 是 Claude Code 的本地扩展机制，本质就是一组存放在 .claude/skills/ 目录下的指令文件，用来教 Claude 怎么“做事”。
文件结构
.claude/skills/
└── my-skill/
├── SKILL.md # 必须：指令定义（YAML frontmatter + Markdown）
├── scripts/ # 可选：可执行脚本
│ ├── lint.sh
│ └── deploy.py
└── templates/ # 可选：模板文件
└── pr-template.md
SKILL.md 的两段式结构
---
name: code-review
description: "Use when reviewing PRs or code changes. Don't use for writing new code."
---
## 审查流程
1. 先读取变更文件列表
2. 对每个文件检查以下维度：
- 安全性：是否引入 OWASP Top 10 漏洞
- 性能：是否有 N+1 查询、不必要的循环
- 可读性：命名是否清晰，逻辑是否直接
3. 如果发现问题，运行 `scripts/lint.sh` 验证
4. 输出结构化审查报告
Frontmatter 负责配置触发条件（告诉 Claude 在什么时候用），下面的 Markdown 则定义了具体的操作流程（告诉它怎么做）。
运行时特征
Skills 的加载机制很有意思，是延迟的、按需的：
- 启动时，Claude 只会加载每个 Skill 的 name + description，占用的资源极少（大约 30-50 tokens/skill）
- 用户输入到达后，Claude 会扫描所有可用的 Skills，匹配出最相关的那个
- 匹配成功，才会把完整的 SKILL.md 读取到上下文中
- 如果指令里引用了脚本，Claude 会通过 Bash 工具去执行
- 执行完毕，脚本进程就退出
关键词：延迟加载、无状态、纯文本指令、通过 Bash 执行脚本、仅限 Claude Code。
3. 能力重叠：SKILLS 脚本也能调 API
这才是大多数人困惑的根源。我们来看两个具体的例子：
用 MCP 查 GitHub Issues
// MCP Server（持久运行）
// Claude 自动获得 list-issues、create-issue、close-issue 等工具
// 调用时：
await mcp.callTool("list-issues", { repo: "owner/repo", state: "open" });
// 返回：结构化 JSON，包含 issue 列表
用 Skill 脚本查 GitHub Issues
#!/bin/bash
# scripts/list-issues.sh
gh issue list --repo "$1" --state open --json number,title,labels
# SKILL.md
---
name: github-issues
description: "Use when user asks about GitHub issues"
---
查看 issues 时，运行 `scripts/list-issues.sh `。
两种方式，都能顺利地拿到 GitHub Issues。那问题来了——它们到底有什么本质区别？
4. 核心区别：不是能不能，是怎么做
4.1 生命周期
MCP Server:
启动 ──────────── 运行中（持久） ──────────── 随 Host 关闭
注册工具 处理请求 维持连接
Skill 脚本:
触发 → 执行 → 返回 → 退出
触发 → 执行 → 返回 → 退出
（每次都是全新进程）
MCP Server 启动一次，服务整个会话。而 Skill 脚本每次调用，都会诞生一个新进程，事情干完就立刻退出。
这个差异带来的实际影响非常明显：MCP Server 可以维持数据库连接池、缓存查询结果、保持 OAuth 会话；而 Skill 脚本每次执行，都得重新建立连接、重新走一遍认证流程。
4.2 工具发现
| 维度 | MCP | Skill 脚本 |
|---|---|---|
| 发现方式 | 启动时自动注册所有工具 | Claude 读 SKILL.md 才知道有脚本 |
| 参数定义 | JSON Schema，结构化声明 | 命令行参数，靠自然语言描述 |
| 返回格式 | 结构化 JSON | stdout 文本 |
| 错误处理 | 结构化错误码 + 修正建议 | exit code + stderr |
MCP 的工具是“结构化注册”的，Claude 在调用之前，就能精确地知道每个工具的参数类型、约束条件和返回结构。而 Skill 脚本的“工具发现”，依赖的是 Claude 去阅读自然语言指令，然后自己构造出 Bash 命令来执行。
4.3 通信方式
MCP:
Claude ←── JSON-RPC 2.0 ──→ Server
双向、结构化、可流式、支持回调
Skill 脚本:
Claude → Bash("scripts/xxx.sh arg1 arg2") → stdout
单向、纯文本、一次性
4.4 跨应用复用
MCP 是一个协议级的标准。一个写好的 Notion MCP Server，可以同时被 Claude Code、VS Code Copilot、Cursor、ChatGPT 使用——只要是实现了 MCP Client 的应用，都能接上它。
而 Skills 是 Claude Code 的专属功能。换一个 AI 工具来看，那些 Skill 文件就只是一堆普通的 Markdown 文档了。
4.5 一张表总结
| 维度 | MCP Server | Skill 脚本 |
|---|---|---|
| 本质 | 独立服务进程 | Bash 执行的脚本文件 |
| 生命周期 | 持久运行 | 按需启停 |
| 状态 | 有状态（连接池、缓存、会话） | 无状态（每次重来） |
| 通信 | JSON-RPC 2.0 双向结构化 | stdin/stdout 纯文本 |
| 工具发现 | 自动注册 | 读指令后才知道 |
| 参数 | JSON Schema 强类型 | 命令行参数，自然语言描述 |
| 返回 | 结构化 JSON | 文本输出 |
| 错误 | 结构化错误 + 建议 | exit code + stderr |
| 复用 | 跨所有 MCP 兼容应用 | 仅 Claude Code |
| 开发成本 | 较高（需实现 Server） | 较低（写个脚本就行） |
5. 那 SKILLS 的真正价值是什么
看到这里，你可能会想：如果 MCP 在“外部连接”这件事上，严格优于 Skill 脚本，那 Skills 存在的意义到底是什么？
5.1 Skills 的核心是知识，不是能力
Skills 最重要的部分，其实不是 scripts/ 目录，而是 SKILL.md 里的那些指令。它真正定义的是：
- 什么时候做：触发条件和反例
- 怎么做：步骤、流程、判断标准
- 做到什么程度：验收标准
# 示例：数据库迁移 Skill
---
name: db-migrate
description: "Use when creating or modifying database migrations. Don't use for queries."
---
## 迁移流程
1. 检查当前迁移状态：`scripts/check-migration-status.sh`
2. 生成迁移文件前，确认：
- 是否有未应用的迁移
- 字段命名是否符合 snake_case 约定
- 是否需要数据回填
3. **禁止**在迁移中使用 `DROP COLUMN`，改用 `ALTER COLUMN ... SET NOT VISIBLE`
4. 生成后必须运行 `scripts/validate-migration.sh` 检查语法
5. 迁移文件名格式：`YYYYMMDD_HHMMSS_description.sql`
这里面，90% 的价值在于流程规范和团队约定。脚本本身，只是用来辅助验证的工具而已。
5.2 Skills 脚本擅长确定性计算
LLM 其实有一些很不擅长的事，比如：
- 精确的正则匹配和文本处理
- 数值计算和统计
- 文件格式转换（CSV → JSON、Markdown → HTML）
- 本地文件系统的批量操作
这些任务，最适合交给脚本去做。Claude 只需要负责调用和解读结果。
## 代码统计 Skill
当用户问项目规模时：
1. 运行 `scripts/count-lines.sh`
2. 解读输出，给出概要
#!/bin/bash
# scripts/count-lines.sh
cloc --json . | jq '{languages: [.header.n_lines], total_code: .SUM.code, total_comments: .SUM.comment, total_blank: .SUM.blank}'
这类任务，既不需要持久服务，也不需要结构化通信。一个脚本，干净利落，足够了。
5.3 Skills 是上下文管理的载体
回到上下文工程的视角来看，Skills 的延迟加载机制，本身就是一种极其聪明的优化：
系统提示（常驻，约 30-50 tokens/skill）
├── skill-1: name + description
├── skill-2: name + description
└── skill-n: name + description
匹配触发后才加载完整指令（几百到几千 tokens）
100 个 Skills 在系统提示里，只占 3000-5000 个 token。完整的指令，只有在需要的时候才会被加载到上下文，用完之后还可以释放。这种渐进式加载的能力，是 MCP 工具定义做不到的——要知道，MCP 那 55,000 个 token 的工具定义，是在启动时全量注入的。
6. 实战：什么场景用什么
6.1 决策树
需要连接外部系统？
├── 是 → 需要持久连接/状态/会话？
│ ├── 是 → MCP
│ └── 否 → 调用频率高？
│ ├── 是 → MCP（连接复用、缓存）
│ └── 否 → Skill 脚本就够
└── 否 → 需要定义工作流程？
├── 是 → Skill
└── 否 → 既不需要外部连接也不需要流程定义 → 可能 CLAUDE.md 就够了
6.2 场景对照表
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 读写 Notion 页面 | MCP | 需要 OAuth 会话、频繁交互 |
| 查询生产数据库 | MCP | 连接池、事务、持久会话 |
| 操作 Figma 设计稿 | MCP | 双向通信、状态同步 |
| 按团队规范审查代码 | Skill | 核心是流程知识，不是外部连接 |
| 提交前跑 lint 检查 | Skill 脚本 | 一次性执行，无需持久化 |
| 统计代码行数 | Skill 脚本 | 确定性计算，LLM 做不好 |
| 格式化 Markdown 表格 | Skill 脚本 | 文本处理，脚本更准确 |
| 部署到 Cloudflare | Skill + MCP | Skill 定义部署流程，MCP 连接 CF API |
| 每日早报推送到 Slack | Skill + MCP | Skill 定义内容格式，MCP 负责发送 |
6.3 协同使用的典型模式
最有价值的用法，其实是两者配合使用：
Skill（流程层） MCP（能力层）
┌──────────────┐ ┌──────────────┐
│ 1. 读取 PR 变更 │──────────► │ GitHub MCP │
│ 2. 按规范审查 │ │ │
│ 3. 查关联 Issue │──────────► │ Linear MCP │
│ 4. 写审查报告 │ │ │
│ 5. 发通知 │──────────► │ Slack MCP │
└──────────────┘ └──────────────┘
Skill 负责编排“做什么、按什么标准做”；MCP 则提供“连接到哪、怎么通信”。两层各管各的，互不侵入，清晰又优雅。
7. 常见误区
| 误区 | 事实 |
|---|---|
| “MCP 就是高级版 Skill” | 不是。两者解决的是不同层面的问题 |
| “有了 MCP 就不需要 Skills” | 不对。MCP 不管流程定义和团队约定 |
| “Skill 脚本能替代 MCP” | 能力上部分重叠，但缺少持久连接、状态管理、跨应用复用 |
| “MCP 很难，先用 Skill 脚本顶着” | 对于简单场景确实可以，但别把它当长期方案 |
| “工具越多越好” | 5 个 MCP Server 就 55,000 tokens。工具多了 Claude 反而选不对 |
| “Skill 只是花哨的 Prompt” | Skill 支持脚本、模板、子 Agent 调度，远不止 Prompt |
8. 工程落地建议
8.1 从 Skill 开始，按需引入 MCP
大多数团队的初始需求是“让 Claude 按我们的方式做事”，而这正是 Skills 最擅长的地方。不要一上来就搭 MCP Server，步子太大了。
推荐的启动顺序：
- 先写
CLAUDE.md，定义项目级约定 - 重复出现的流程，抽成 Skill
- 需要外部系统交互时，评估是 Skill 脚本够用，还是需要 MCP
- 高频、有状态、跨应用的场景，再上 MCP
8.2 Skill 脚本转 MCP 的信号
当你发现 Skill 脚本出现以下情况，就该考虑迁移到 MCP 了：
- 每次执行都要重新认证（OAuth token 过期、需要重建连接）
- 脚本里有大量错误处理和重试逻辑
- 多个 Skill 都依赖同一个外部服务
- 需要维持长连接（WebSocket、数据库连接池）
- 其他 AI 工具也需要同样的能力
8.3 控制 MCP 工具数量
前面提到过，5 个 MCP Server 就占了 55,000 个 token，这大概是 200K 上下文的三成。工具定义过多，会直接导致：
- Claude 选错工具的概率上升
- Prompt Caching 的命中率下降
- 上下文留给实际任务的空间变少
记住一个原则：只接真正需要的 MCP Server，不要贪多。
9. 划重点
- MCP 是协议级标准，提供持久化的外部系统连接；Skills 是 Claude Code 本地扩展，提供流程知识和确定性脚本。两者解决的是不同层面的问题。
- Skills 脚本确实能干 MCP 能干的部分事情，但机制完全不同：一个是持久服务进程，一个是按需执行的一次性命令。
- 选择的标准不是“能不能做”，而是“该怎么做”：需要持久连接、状态管理、跨应用复用，用 MCP；需要定义流程、团队约定、确定性计算，用 Skills。
- 最有价值的用法是两者协同：Skill 编排“做什么、怎么做”，MCP 提供“连到哪、怎么通信”。
- 从 Skill 开始，按需引入 MCP。不要一上来就搭 Server，也不要用 Skill 脚本硬撑需要持久连接的场景。
- 控制 MCP 工具数量。5 个 Server 就 55,000 tokens，工具越多，Claude 越容易选错。
参考资料
- Anthropic, Introducing the Model Context Protocol
- Anthropic, Extend Claude with skills
- Anthropic, Introducing Agent Skills
- Model Context Protocol, What is MCP?
- Tw93, 你不知道的 Agent：原理、架构与工程实践
- IntuitionLabs, Claude Skills vs. MCP: A Technical Comparison
- morphllm, Claude Code Skills vs MCP vs Plugins: Complete Guide
