别再把 MCP 和 Skill 混着用了：一个负责接系统，一个负责把事做稳

别再把 MCP 和 Skill 混着用了：一个负责接系统，一个负责把事做稳

团队里一聊 agent 落地，十有八九会冒出两个词：MCP，Skill。

问题是，这两个词经常被混着用。有人说“先把 MCP 搭起来”，说着说着聊的是代码规范。有人说“做个 Skill 就行”，最后又在问怎么接 Figma、GitHub、Notion。

聊到最后，大家以为自己在讨论方案，其实连问题都没对齐。

先把我的判断摆这儿：

MCP 解决的是连接问题。Skill 解决的是复用问题。

再说白一点：

• MCP 更像接口层，负责把 agent 连到外部世界
• Skill 更像能力层，负责把一套做事方法封装起来

这俩不是一回事，但在实际项目里经常绑在一起。

先把语境说清楚

有一句得先说，不然后面很容易越聊越偏。

MCP 这个词比较稳。无论看 Anthropic 还是 OpenAI，它基本都指同一类东西：让 AI 应用接入外部工具、数据和工作流的协议层。

但 Skill 这个词没这么稳。

不同产品里，Skill 的实现方式和边界并不完全一样。本文说的 Skill，主要指 agent 产品里的那类“技能包”能力，也就是把 instructions、references、scripts、资源文件和工作步骤打包在一起，让 agent 在特定场景里稳定完成任务。

所以这篇文章不是在对比两个标准协议。 我想拆开的，是 AI 工具链里两个经常被混着说的层次。

MCP 到底解决什么问题

先说 MCP。

MCP 不是拿来“增强智能”的。 它干的是更基础的活：把模型接到外部系统上。

你把它当成 AI 世界里的统一插口就行。

如果你的 agent 需要：

• 读 GitHub issue
• 查 Notion 文档
• 连数据库
• 调内部 API
• 访问设计稿、日志系统、监控平台

那你第一个要解决的问题一定是：怎么连进去，怎么把这些能力用统一方式交给模型。

这就是 MCP 的活。

从官方定义看，MCP server 往外暴露的通常是 tools、resources、prompts 这几类能力。也就是说，MCP 更关心的是：

• 外部系统里有什么可用能力
• 这些能力如何被标准化描述
• agent 怎么发现并调用它们

所以 MCP 更像协议层和连接器。

它不定义你的团队怎么做代码评审，也不定义文章怎么排版，更不负责告诉 agent“遇到这种问题先查哪个文档，再跑哪个脚本，再用什么格式输出”。

它只负责一件事：

把外部世界安全、稳定、标准化地接进来。

Skill 到底解决什么问题

再说 Skill。

Skill 的重点不在“接入”，在“沉淀”。

当某类任务反复出现，而且你每次都得重讲一遍，你缺的往往不是新工具，而是一套能复用的方法。

比如这些场景：

• 每次做代码审查都要重复讲团队规范
• 每次把设计稿转前端都要重复讲目录结构、组件约束、验收标准
• 每次写技术文章都要重复讲目标读者、语言风格、结构模板
• 每次排查线上问题都要重复讲先看日志、再看监控、最后写复盘

这些问题有个共同点：

agent 不是做不了，是每次做法都不太一样。

这时候你真正要的就是 Skill。

Skill 本质上是在封装一套稳定工作流。里面可以有：

• 任务说明
• 执行步骤
• 参考资料
• 脚本
• 模板
• 输出格式

如果说 MCP 给了 agent 一双手，那 Skill 更像是在教它“这双手平时该怎么干活”。

所以 Skill 更偏能力编排，而不是工具接入。

它解决的是：

• 同样的任务，怎么每次都做得差不多
• 团队经验，怎么沉淀成 agent 能反复调用的能力
• 复杂任务，怎么从“临场发挥”变成“流程复用”

为什么很多人会把它们混在一起

因为真实场景里，它们本来就经常一起出现。

举个很典型的例子。

比如你要做一个“从设计稿生成前端页面”的 agent 流程。

这个流程里可能会有几步：

1. 读取 Figma 设计稿
2. 提取颜色、间距、组件信息
3. 按团队规范生成 React 代码
4. 跑截图或测试
5. 输出交付说明

这里面：

• “读取 Figma 设计稿”更像 MCP 的事情，因为它涉及外部系统接入
• “按团队规范生成 React 代码并完成自检”更像 Skill 的事情，因为它是流程和规范的复用

所以很多团队会自然地把两者揉到一起。

其实不是。

更准确的理解应该是：

MCP 负责把能力接进来，Skill 负责把能力组织起来。

一个偏“连”，一个偏“用”。

拿一个真实场景拆开看：Figma 到前端代码

光讲概念还是有点飘。

直接拿一个很多团队都想做的场景来拆。

这个需求很常见：

设计师在 Figma 里出稿，agent 自动生成一个可继续开发的前端页面。

第一次做这件事的人，很容易把所有东西都塞进一个“大 Prompt”。 第一版也许能跑，第二版开始飘，第三版基本就没人敢碰了。

更稳的办法，还是先按层拆。

第 1 层：MCP 负责把 Figma 能力接进来

这一层不关心“页面怎么写”，只关心“agent 到底能拿到什么”。

比如一个 Figma 相关的 MCP server，可以给 agent 暴露这些能力：

• 根据文件或节点 ID 读取设计稿信息
• 获取节点树、文本内容、颜色、尺寸、间距
• 导出图片素材或图标
• 读取组件、变体、样式 token

这一层解决的全是接入问题：

• 能不能连 Figma
• 能连到什么粒度
• 返回的数据长什么样
• 权限和调用方式怎么控制

这些都很关键，但还不是“前端页面生成流程”本身。

所以 MCP 做完以后，agent 最多只是获得了：

“我现在能看懂这份设计稿了。”

它还没有获得：

“我该按你们团队的方式把它写成代码。”

第 2 层：Skill 负责把“设计转代码”的方法固化下来

到了这一层，问题就从“怎么连”变成了“怎么干”。

比如你可以把下面这套流程沉淀成一个 Skill：

1. 先读取 Figma 节点树，确认页面结构
2. 提取设计 token，映射到团队已有的颜色和间距变量
3. 优先复用现有组件库，不要直接生成一堆散装 div
4. 页面结构按项目目录规范落盘
5. 跑 lint、测试或截图检查
6. 输出“哪些地方是 1:1 还原，哪些地方做了工程化调整”

这时 Skill 封装的就不是“Figma API”。 而是团队自己的做法。

比如它可以额外规定：

• 组件优先使用 Button、Card、Modal 这些现有组件
• 样式优先走 design tokens，不直接写魔法数字
• 复杂布局先拆 section，再拆 block
• 图片资源要落到哪个目录
• 最终输出必须带一个自检清单

这些东西才真正决定结果稳不稳。

如果只做 MCP，会发生什么

很多团队就是卡在这里。

他们把 Figma 接进来了，agent 也确实能读节点信息，但生成代码还是一会儿一个样。

第一次可能是原生 CSS。 第二次改成 Tailwind。 第三次又开始手搓一套不符合项目规范的组件。

这不是 MCP 失效。 而是你只解决了“看得到设计稿”，没解决“怎么稳定产出项目代码”。

如果只做 Skill，会发生什么

反过来也一样。

如果你只写了一套“设计转代码流程”，但 agent 根本拿不到 Figma 的结构化信息，那它只能靠截图猜。

截图猜布局，做 demo 没问题，真拿去跑生产流程就很悬。

因为它很容易：

• 看不出精确间距
• 识别错组件层级
• 漏掉交互态和变体
• 把可复用组件识别成静态块

所以只做 Skill，也不够。

更合理的落地方式：MCP 提供观察能力，Skill 提供生产规则

这个场景最顺手的拆法，其实就一句话：

MCP 让 agent 能“读懂设计稿”，Skill 让 agent 能“按团队要求写代码”。

把它看成一条流水线就行：

Figma 设计稿
  ↓
MCP：读取节点、样式、素材、组件信息
  ↓
Skill：套团队规则，决定如何映射到组件库和目录结构
  ↓
生成前端代码
  ↓
Skill：自检、截图、补充交付说明

一个更接近实战的拆分方式

如果真要在团队里落地，我建议就这么拆：

MCP 层负责：

• 读取 Figma 文件和节点
• 导出图标或图片素材
• 提供设计 token 和组件元数据

Skill 层负责：

• 决定是生成 React、Vue 还是原生页面
• 决定优先复用哪些业务组件
• 决定目录结构、命名规则、样式方案
• 决定生成后怎么验证和怎么汇报结果

这样拆有个直接好处，Figma 接入能力可以复用到很多任务里。

今天你拿它做“设计转代码”。 明天也可以拿它做“设计走查”。 后天还可以拿它做“设计稿和线上页面差异检查”。

而 Skill 则可以按团队习惯继续细分。

比如：

• 一个 Skill 专门做营销页生成
• 一个 Skill 专门做后台表单页生成
• 一个 Skill 专门做移动端页面还原

这种扩展方式会更健康。

MCP 负责共享底层接入。 Skill 负责沉淀上层流程。

再看一眼工程里长什么样

如果把这个方案放进一个真实项目里，它的目录大概会长这样：

agent-workspace/
├── .mcp/
│   └── servers/
│       └── figma-server.json
├── skills/
│   └── figma-to-frontend/
│       ├── SKILL.md
│       ├── references/
│       │   ├── component-mapping.md
│       │   └── design-token-rules.md
│       └── scripts/
│           └── post_check.sh
├── src/
│   ├── components/
│   ├── pages/
│   └── tokens/
└── CLAUDE.md

这几层的职责其实很清楚。

.mcp/servers/figma-server.json 这一类配置，重点是告诉 agent：

• Figma 能怎么接
• 能调哪些接口
• 能读哪些资源

而 skills/figma-to-frontend/ 这层，重点是告诉 agent：

• 拿到设计稿信息以后，代码该怎么组织
• token 该怎么映射
• 现有组件该怎么复用
• 生成完以后要做哪些检查

一个足够表达思路的伪配置

先看 MCP 这一层。

下面这段不是某家产品的官方配置原样，只是方便理解的伪配置：

{
  "server": "figma",
  "capabilities": {
    "tools": [
      "get_file_nodes",
      "get_component_meta",
      "export_asset"
    ],
    "resources": [
      "design_tokens",
      "component_variants"
    ]
  }
}

这段配置只说明一件事：

agent 现在能从 Figma 拿到哪些结构化能力。

再看 Skill 这一层。

# figma-to-frontend

## Workflow
- 先读取目标节点的结构和样式信息
- 优先映射到现有组件库，不直接生成散装结构
- 间距和颜色优先使用 `src/tokens/` 中已有变量
- 页面文件落到 `src/pages/`
- 公共块抽到 `src/components/`
- 生成后运行 `scripts/post_check.sh`

## Output
- 给出生成文件列表
- 标明哪些地方无法 1:1 还原
- 标明哪些地方使用了工程化替代方案

这段就明显不是接入层配置了。

它不关心 Figma 怎么连接。 它关心的是另外几件事：

• 页面怎么生成
• 组件怎么复用
• 结果怎么验证
• 最后怎么交付

为什么这两段最好分开放

原因很简单，它们的变化频率本来就不一样。

MCP 层的变化，往往来自外部系统能力变化。 比如 Figma API 变了，或者你想新增素材导出能力。

Skill 层的变化，往往来自团队工程规范变化。 比如你们从 CSS Modules 切到 Tailwind，或者开始强制复用某套业务组件。

如果把这两层揉成一个大文件，后面维护只会越来越乱。

拆开以后，收益很直接：

• 换接入方式，不一定要改流程
• 换流程规范，不一定要改接入层
• 同一套 Figma MCP，可以复用给多个 Skill
• 同一个 Skill，也可以迁移到别的设计数据来源

所以我更愿意把它们理解成“接口层”和“能力层”。

三个场景，帮你快速判断该用谁

直接看判断题。

场景一：你要接 GitHub、Notion、数据库

优先考虑 MCP。

因为这里的核心问题不是流程，而是接入。

你首先要解决的是：

• agent 能不能访问这个系统
• 访问时暴露哪些能力
• 调用方式是否统一
• 权限边界怎么控制

如果连都没连上，后面的流程设计没有意义。

场景二：你要把一套团队流程固定下来

优先考虑 Skill。

比如你想让 agent 稳定执行下面这套流程：

• 先读 CLAUDE.md
• 再读项目目录
• 修改代码前先跑定位命令
• 输出必须包含验证步骤
• 代码评审优先报风险，不先讲总结

这时候你真正要沉淀的是“做事方法”。

它可能完全不依赖外部系统。

就算需要外部系统，也不是问题的核心。

场景三：你既要接系统，又要固化流程

两者一起上。

比如你要做一个“需求文档 -> 拆任务 -> 写代码 -> 自测 -> 提交 PR”的 agent。

这类场景里：

• 用 MCP 接文档系统、代码仓库、CI、设计平台
• 用 Skill 固化拆解方式、实现步骤、提交流程、验收清单

很多团队最后真会落地的，其实就是这个形态。

不是二选一。 而是分层协作。

一个实用判断框架

以后再遇到“这事该做 MCP 还是 Skill”，先问自己 3 个问题就行。

1. 这个问题的核心，是接外部能力，还是复用内部方法？

如果重点是“连系统”，偏 MCP。 如果重点是“沉淀流程”，偏 Skill。

2. 没有外部系统，这件事还成立吗？

如果没有 GitHub、Figma、Notion、数据库，这个能力就不存在，那大概率是 MCP 场景。

如果就算没有外部系统，流程本身依然成立，比如代码 review、文章写作、发布清单，那更像 Skill 场景。

3. 你想复用的，到底是工具，还是做法？

复用工具，偏 MCP。 复用做法，偏 Skill。

这三个问题一拆，基本就不会再混。

最容易踩的三个误区

误区一：Skill 是 MCP 的上位替代

不是。

Skill 不会自动帮你接入外部系统。 它可以消费工具，但它不等于工具接入层。

误区二：MCP 做完以后，不需要 Skill

也不是。

你把一堆工具接进 agent，只是让它“能做更多事”。 但“能做”不等于“稳定做对”。

很多团队接了一堆工具以后，结果发现 agent 输出还是飘。 原因通常不是工具不够，而是流程没固化。

误区三：Skill 只是换皮 Prompt

这么理解，真把 Skill 看扁了。

Prompt 当然也是 Skill 的一部分。 但真正有用的 Skill，不只是几段提示词。

它更像一个可复用的能力包，里面会带上步骤、参考、脚本、模板和约束。 重点不是“怎么提问”，而是“怎么稳定交付”。

我更建议你把它理解成这张分层图

用户需求
  ↓
Skill（流程、规范、模板、脚本、输出要求）
  ↓
MCP（连接外部工具、数据、服务）
  ↓
GitHub / Notion / Figma / 数据库 / 内部 API / CI

这张图最大的用处，是帮你快速判断问题该在哪一层处理。

如果你现在遇到的是“agent 拿不到数据”，去查 MCP。 如果你遇到的是“agent 每次做法都不一样”，去补 Skill。

别一上来就继续堆 Prompt。

最后说一个更现实的判断

团队真把 agent 用起来以后，最稀缺的通常不是模型能力。

而是两样东西：

• 能稳定接入外部世界的接口层
• 能持续复用团队经验的能力层

MCP 补的是前者。 Skill 补的是后者。

所以这两个概念最好的关系，不是谁替代谁。

更实际的说法是：

MCP 让 agent 有地方可去，Skill 让 agent 知道到了以后该怎么做。

如果你只做 MCP，你得到的是一堆可调用能力。 如果你只做 Skill，你得到的是一套可能落不了地的流程。

先拆开，再组合着用，很多 agent 架构问题反而会清楚得多。

参考资料

• MCP 官方文档：modelcontextprotocol.io/docs/gettin…
• Claude Code MCP 文档：code.claude.com/docs/en/mcp
• OpenAI Codex 产品页：openai.com/codex/
• OpenAI Codex 发布文：openai.com/index/intro…
• OpenAI Docs MCP 文档：platform.openai.com/docs/docs-m…