Claude Skills 与 MCP：AI 能力扩展的两种哲学
Claude Skills 与 MCP：AI 能力扩展的两种哲学
引言
如果你正在使用 Claude，你可能听说过两个重要的技术名词：Skills（技能） 和 MCP（Model Context Protocol，模型上下文协议）。
它们都是扩展 Claude 能力的方式，但定位完全不同。
用一个简单的类比：
- MCP 就像给 Claude 装上"USB 接口"——让它能连接外部世界
- Skills 就像给 Claude 一本"操作手册"——教它如何完成特定任务
还有一个更生动的类比——五金店场景：
你走进五金店修理坏掉的橱柜。店里有你需要的一切：木胶、夹子、替换铰链。 但知道买什么、怎么用，是另一个问题。
MCP = 货架上的工具（让你能拿到） Skills = 店员的专业知识（告诉你该买什么、怎么用）
工具再多，不会用也白搭。专业知识再丰富，没有工具也干不了活。两者缺一不可。
什么是 MCP？
核心概念
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的开放协议标准。
它解决了一个核心问题：如何让 AI 与外部系统对话？
在 MCP 出现之前，每接入一个新的工具或数据源，开发者都需要编写专门的适配代码。这被称为 "N×M 问题"——N 个 AI 模型要对接 M 个工具，需要 N×M 种集成方式。
MCP 提供了一个统一的"翻译层"，让所有 AI 模型可以用同一种方式与所有工具交互。
技术架构
MCP 采用客户端-服务器架构：
┌─────────────┐ JSON-RPC ┌─────────────┐
│ Claude │ ◄──────────────► │ MCP Server │
│ (Client) │ (stdio/HTTP) │ (工具服务) │
└─────────────┘ └─────────────┘
│
▼
┌───────────────┐
│ 外部系统 │
│ - 数据库 │
│ - API │
│ - 文件系统 │
└───────────────┘
MCP 的核心能力
MCP 服务器可以提供三种能力：
| 能力类型 | 说明 | 示例 |
|---|---|---|
| Resources（资源） | 提供数据访问 | 读取数据库、获取文件内容 |
| Tools（工具） | 执行操作 | 发送邮件、创建 PR、执行查询 |
| Prompts（提示词模板） | 预定义的交互模式 | 代码审查模板、分析报告格式 |
代码示例：一个简单的 MCP 服务器
from mcp.server.fastmcp import FastMCP
# 创建 MCP 服务器
mcp = FastMCP("我的工具服务")
# 定义一个工具：两数相加
@mcp.tool()
def add(a: int, b: int) -> int:
"""将两个数字相加"""
return a + b
# 定义一个资源：个性化问候
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
"""获取个性化问候语"""
return f"你好, {name}!"
# 启动服务器
mcp.run(transport="streamable-http")
行业采纳情况
MCP 在发布一年内已成为事实上的行业标准：
- 2025年3月：OpenAI 宣布采纳 MCP
- 2025年4月：Google DeepMind 确认 Gemini 将支持 MCP
- 2025年5月：Microsoft 在 Build 大会宣布 Windows 11 支持 MCP
- 2025年12月：Anthropic 将 MCP 捐赠给 Linux 基金会下的 Agentic AI Foundation
什么是 Skills？
核心概念
Skills（技能）是 Anthropic 在 2025 年 10 月推出的能力扩展机制。
它解决的问题是：如何教会 Claude 特定的工作方式？
与 MCP 的"连接外部系统"不同，Skills 专注于"传授知识和流程"。
设计哲学
Skills 的设计非常简洁——核心就是一个 Markdown 文件（SKILL.md），加上可选的辅助脚本。
my-skill/
├── SKILL.md # 核心指令文件
├── references/ # 参考资料（可选）
│ └── patterns.md
├── examples/ # 示例（可选）
│ └── demo.sh
└── scripts/ # 辅助脚本（可选）
└── validate.sh
工作原理：渐进式加载
Skills 采用"渐进式披露"策略：
- Claude 首先扫描所有 Skill 的元数据（约 100 tokens）
- 根据用户请求判断哪些 Skill 相关
- 仅加载相关 Skill 的完整内容（通常 < 5000 tokens）
这种设计避免了上下文窗口被大量无关内容占满。
代码示例：一个 SKILL.md 文件
---
name: 代码审查技能
description: 当用户要求"审查代码"、"检查这段代码"或提到"code review"时使用此技能
version: 0.1.0
---
## 代码审查流程
当审查代码时，请遵循以下步骤：
### 1. 安全性检查
- 检查是否存在 SQL 注入风险
- 检查是否有硬编码的敏感信息
- 验证输入是否经过适当处理
### 2. 代码质量
- 函数是否单一职责
- 变量命名是否清晰
- 是否有重复代码
### 3. 输出格式
使用以下模板输出审查结果：
**安全性**: ✅/⚠️/❌
**可维护性**: ✅/⚠️/❌
**建议**: [具体改进建议]
Skills 的存储位置
- 个人 Skills：
~/.claude/skills/（跨项目可用） - 项目 Skills：
.claude/skills/（团队共享）
Skills vs MCP：核心对比
一句话区分
如果你在解释"怎么做"，那是 Skill。如果你需要 Claude"访问"某物，那是 MCP。
更通俗地说：MCP 让 Claude 能连接到工具，Skills 教 Claude 如何使用工具。
结合后的三大优势
当 Skills 和 MCP 结合使用时，你会获得：
| 优势 | 说明 | 示例 |
|---|---|---|
| 清晰的发现 | Skill 指定先查哪些数据源、按什么顺序 | 会议准备 Skill 指定：先查项目页面，再查历史会议记录，最后查利益相关者资料 |
| 可靠的编排 | 多步骤工作流变得可预测，每次执行相同 | 不再是"拉数据→格式化→才发现漏了信息"，而是按 Skill 定义的顺序稳定执行 |
| 一致的输出 | 输出符合团队标准，无需反复修改 | 报告结构、详细程度、语气都符合预期，不再需要"再改改格式" |
职责边界：避免冲突
MCP 服务器可能包含工具使用提示和常见任务的 prompt。这些应该保持通用。
经验法则：
- MCP 指令：如何正确使用服务器和工具（查询语法、API 格式）
- Skill 指令：如何在特定流程中使用它们（先查哪些记录、如何交叉引用、如何格式化输出）
注意冲突：如果 MCP 说"返回 JSON"，Skill 说"格式化为 markdown 表格"，Claude 就得猜该听谁的。
最佳实践：让 MCP 处理连接和数据格式，让 Skills 处理呈现、排序和工作流逻辑。
分层架构：Skill 只引用，不安装
一个常见的问题：Skill 是否负责安装和配置 MCP 工具？
答案是：不负责。Skill 只是引用工具名，假设 MCP 已经配置好。
以 Notion 的 spec-to-implementation Skill 为例：
┌─────────────────────────────────────────────┐
│ Skill: spec-to-implementation │ ◄── 只定义"怎么做"
│ 引用工具： │
│ • Notion:notion-search │
│ • Notion:notion-fetch │
│ • Notion:notion-create-pages │
└─────────────────────────────────────────────┘
│
│ 调用（假设已存在）
▼
┌─────────────────────────────────────────────┐
│ MCP Server: Notion │ ◄── 需独立安装配置
│ • API Key 配置 │
│ • 权限设置 │
│ • 服务器运行 │
└─────────────────────────────────────────────┘
职责划分：
| Skill 负责 | MCP 负责（独立于 Skill） |
|---|---|
| 定义调用顺序和流程 | 服务器安装 |
| 规定输入参数格式 | API 密钥/认证配置 |
| 规范输出格式 | 网络连接/权限设置 |
| 提供模板和最佳实践 | 服务器运行和维护 |
类比理解：
Skill 就像一份菜谱——告诉你先放什么、后放什么、火候多大，但不负责帮你买锅、装煤气灶。
MCP 就像厨房设备——需要你自己购买、安装、调试。菜谱只是假设你已经有了这些设备。
这种分离设计的好处：
- Skills 保持轻量：只是 Markdown 文件，易于分享和版本控制
- MCP 可复用：一个 Notion MCP 可以被多个 Skills 共同使用
- 独立演进：MCP 升级不影响 Skill，反之亦然
详细对比表
| 维度 | MCP | Skills |
|---|---|---|
| 定位 | 连接外部系统 | 传授工作方法 |
| 类比 | USB 接口 | 操作手册 |
| 技术复杂度 | 需要理解协议、传输层 | Markdown + YAML |
| 开发门槛 | 较高（需编程能力） | 较低（会写文档即可） |
| Token 消耗 | 较高（数千到数万） | 较低（元数据约100） |
| 调用方式 | 被动响应请求 | 主动判断使用时机 |
| 发布时间 | 2024年11月 | 2025年10月 |
| 开放性 | 开放协议，跨模型通用 | 已发布为开放标准 Agent Skills |
使用场景对比
使用 MCP 的场景：
- 需要访问数据库
- 需要调用外部 API
- 需要操作文件系统
- 需要与第三方服务集成
使用 Skills 的场景：
- 涉及工具的多步骤工作流：会议准备需要从多个源拉取信息，然后生成结构化文档
- 需要一致性的流程：每季度的财务分析必须遵循相同方法论，合规审查有必须检查的项
- 想要捕获和分享的领域专业知识：研究方法论、代码审查标准、写作指南
- 即使团队成员离职也应保留的工作流：这就是制度知识——把"只有老员工才知道的事"变成可复用的指令
协同工作示例
MCP 和 Skills 不是互斥的，而是互补的：
场景：自动化数据报告生成
┌──────────────┐
│ MCP │ ──► 连接数据库，获取原始数据
└──────────────┘
│
▼
┌──────────────┐
│ Skills │ ──► 按公司格式处理数据、生成报告
└──────────────┘
│
▼
┌──────────────┐
│ 输出 │ ──► 符合公司规范的分析报告
└──────────────┘
官方实战案例
以下是 Anthropic 官方博客中展示的两个真实案例。
案例1：金融分析 - 可比公司估值
分析师做可比公司分析时，需要从多个数据源拉取财务指标，应用相同的估值方法，并按合规标准格式化输出。这是重复、易出错的工作。
| 组件 | 内容 |
|---|---|
| Skill | Comparable Company Analysis（可比公司分析） |
| MCP 服务器 | S&P Capital IQ、Daloopa、Morningstar |
工作流程：
- 发现：Skill 确定要查询哪些数据源
- 连接：MCP 连接拉取实时财务数据
- 编排：Skill 应用估值方法论，格式化输出
- 验证：Skill 根据合规要求进行校验
案例2：会议准备 - Notion Meeting Intelligence
会议准备很繁琐：需要从项目文档、历史会议记录、利益相关者信息等多处拉取上下文，然后整合成预读材料和议程。
| 组件 | 内容 |
|---|---|
| Skill | Meeting Intelligence（定义搜索哪些页面、输出结构、包含哪些章节） |
| MCP 服务器 | Notion 连接（搜索、读取、创建页面） |
工作流程：
- 发现：Skill 指定相关页面——项目、历史会议、利益相关者信息
- 连接：MCP 连接搜索并检索 Notion 内容
- 编排：Skill 构建两个文档：内部预读材料 + 外部议程
- 保存：MCP 连接将文档保存到 Notion，组织好并添加链接
- 验证：Skill 确保输出符合格式标准
开发者案例：Context7 MCP + Skill
让我们用一个开发者场景的例子来展示 MCP 和 Skills 如何协同工作。
Context7 是什么？
Context7 是由 Upstash 开发的 MCP 服务器，解决了一个实际痛点：
LLM 的训练数据会过时，但编程库的文档在持续更新。 Context7 让 AI 能实时获取任意库的最新官方文档。
Context7 MCP 提供的工具
| 工具名 | 功能 |
|---|---|
resolve-library-id | 将库名解析为 Context7 ID |
get-library-docs | 获取指定库的最新文档 |
单独使用 MCP 的问题
如果只有 MCP，每次查文档你都需要：
- 手动调用
resolve-library-id - 记住返回的 library ID
- 再调用
get-library-docs - 自己整理输出格式
创建一个配套的 Skill
我们可以创建一个 Skill 来规范这个流程：
---
name: 智能文档查询
description: 当用户询问任何编程库的用法、API、最佳实践时使用此技能
version: 0.1.0
allowed-tools: [
"mcp__context7__resolve-library-id",
"mcp__context7__get-library-docs"
]
---
## 文档查询流程
当用户询问某个库的使用方法时：
### 步骤 1：解析库名
调用 `mcp__context7__resolve-library-id`
- 输入用户提到的库名
- 获取 Context7 兼容的 library ID
### 步骤 2：获取文档
调用 `mcp__context7__get-library-docs`
- 使用上一步获得的 library ID
- 如果用户有具体问题，设置 topic 参数聚焦相关内容
### 步骤 3：整理输出
按以下格式呈现结果：
**库名**: [名称] ([版本])
**官方来源**: [文档链接]
### 核心用法
[整理后的关键代码示例]
### 注意事项
[从文档中提取的重要提示]
效果对比
| 场景 | 只有 MCP | MCP + Skill |
|---|---|---|
| 用户说"Next.js 路由怎么用" | 需要多步手动操作 | 自动完成全流程 |
| 输出格式 | 原始文档片段 | 结构化、易读 |
| 使用门槛 | 需了解工具调用 | 自然语言即可 |
工作流程图
用户："React hooks 怎么用？"
│
▼
┌─────────────────────────────┐
│ Skill 被激活 │
│ "智能文档查询" │
└─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ MCP 工具调用 #1 │
│ resolve-library-id("React")│
│ 返回: /facebook/react │
└─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ MCP 工具调用 #2 │
│ get-library-docs( │
│ id: "/facebook/react", │
│ topic: "hooks" │
│ ) │
└─────────────────────────────┘
│
▼
┌─────────────────────────────┐
│ Skill 规范输出格式 │
│ 结构化展示文档内容 │
└─────────────────────────────┘
这个例子清晰地展示了：
- MCP 负责"能力"：提供获取文档的工具
- Skill 负责"智慧"：定义何时用、怎么用、如何呈现
如何选择？
决策流程图
你的需求是什么？
│
├─► 需要访问外部数据/系统？ ──► 使用 MCP
│
├─► 需要教 Claude 特定流程？ ──► 使用 Skills
│
└─► 两者都需要？ ──► 组合使用！
│
└─► MCP 提供连接能力
Skills 提供处理规范
实际建议
- 入门用户：先从 Skills 开始，门槛低，见效快
- 有开发经验：尝试编写 MCP 服务器，扩展 Claude 的能力边界
- 团队协作：两者结合，MCP 统一工具接入，Skills 统一工作规范
总结
一句话记住
解释"怎么做" → Skill 需要"访问"某物 → MCP
快速对比
| MCP | Skills | |
|---|---|---|
| 核心职责 | 连接外部系统 | 传授工作方法 |
| 类比 | 五金店货架 | 店员专业知识 |
| 门槛 | 需要编程 | 会写文档即可 |
| 最佳搭档 | 提供工具访问 | 定义如何使用工具 |
核心洞察
MCP 和 Skills 代表了 AI 能力扩展的两种不同哲学：
- MCP 强调标准化和互操作性——是连接 AI 与外部世界的桥梁
- Skills 强调简洁性和效率——是将人类知识（尤其是制度知识）注入 AI 的管道
它们不是竞争关系，而是互补关系：
- MCP 负责**"能做什么"**（能力）
- Skills 负责**"怎么做"**（智慧）
随着时间推移，团队会积累起一系列相互关联的 Skills 和 MCP 连接，让 Claude 成为你们领域的专家。
参考资料
官方文档
- Extending Claude's capabilities with skills and MCP - 本文主要参考来源
- Skills explained: How Skills compares to prompts, Projects, MCP, and subagents
- Anthropic MCP 官方介绍
- MCP 规范文档
- Agent Skills 开放标准
技术资源
案例参考
延伸阅读