在Zui近的 AI Agent 讨论里MCP 与 Skill 两个词经常被一起抛出来甚至有人把它们当成同义词来使用。结果导致团队在设计流程时既找不到合适的入口，又找不到可靠的执行方式。今天我想把这两个概念像拆拼图一样，一块块拆开来让大家在实际项目中不再踩雷。

Zui直白的解释是——MCP是连接层。它负责把模型和外部工具、数据库、内部 API 等“桥梁”搭建好。换句话说Ru果你的 Agent 想要读取 Figma 的节点信息、调用 GitHub 的 PR 接口，或者查询内部的数据仓库，这些Neng力dou必须先经过 MCP 的包装。

下面是一段典型的 MCP 配置，它告诉模型Ke以使用哪些工具：

{
  "server": "figma",
  "capabilities": {
    "tools": ,
    "resources": 
  }
}

从上面Ke以kan出，MCP 并不关心「怎么写代码」或「怎么组织团队规范」，它只专注于「Neng否拿到数据」以及「以何种统一方式交给模型」。正因为如此，它往往是安全审计、权限管理以及版本控制的重点对象——一旦权限过宽，就会出现“模型Ke以随意读写磁盘”的尴尬局面。

把业务规则塞进 MCP。业务流程、代码风格、审查标准这些dou不属于接入层的范畴。

只关注工具列表，而忽视统一调用约定。不同系统的返回结构差异大，Ru果没有统一的 schema，后续处理会异常繁琐。

把安全策略写死在配置里。真正可维护的Zuo法是通过白名单 + 动态授权，而不是一次性放行所有接口。

Ru果说 MCP 把一双手递给了 Agent，那么 Skill 就是在教这双手该怎么使用——它是一套可复用的工作流包装体。Skill 包含了：

Instructions

References

Scripts

Constraints

举个Zui常见的例子：设计稿转前端页面。整个过程大致如下：

Figma 设计稿
   ↓    读取节点、样式、组件信息
   ↓    按团队约定映射到组件库 & 目录结构
   ↓   自动生成 React / Vue 页面代码
   ↓    自检 + 截图 + 输出交付说明

这里面第一步属于 MCP——提供原始结构化数据；后面的每一步dou属于 Skill——把原始数据转化为符合团队标准的产出。Ru果只搭建了 MCP，却没有对应的 Skill，那么 Agent 虽然Neng「kan懂」设计稿，却只Neng随意猜测如何生成代码；反之，只写了 Skill 而缺少 MCP，则整个流程根本无从启动。

hen多团队在第一次实现某个功Neng时会把所有细节硬编码进 Prompt，随后发现第二次改动时整套 Prompt Yi经飘得不靠谱。这正是缺少 Skill 的表现：没有将步骤、约束和脚本抽象成独立模块，使得每次复用dou需要重新撰写长篇大论。

A good skill looks like this:

skills/
└── figma-to-frontend/
    ├── SKILL.md               # 工作流描述 & 输入输出规范
    ├── references/
    │   ├── component-mapping.md
    │   └── design-token-rules.md
    └── scripts/
        └── post_check.sh     # 自动化自检脚本

当业务需求变geng，只需要修改对应的 reference 文档或脚本，而不必动到底层的 MCP 配置。

下面这张简化示意图帮助你快速定位问题所在：

用户需求 → Skill → MCP → GitHub / Notion / Figma / DB / 内部 API / CI

MCP 层：关注「Neng否拿到」以及「以何种统一协议交付」；主要牵涉安全、权限、协议兼容性。

Skill 层：关注「拿到了之后怎么Zuo」；涉及业务规则、质量检查、输出格式等。

当你遇到以下两类问题时Ke以快速判断该去哪个层面下手：

Poc 阶段，你Ke以先完成以下两步：

MCP 搭建完成后让模型Neng够成功获取结构化数据。。

Sprint 中加入一个Zui小可运行的 Skill，例如把节点信息直接渲染成 JSON 并保存至仓库。

The moment you have both layers functional, you’ll notice a dramatic drop in “结果飘忽不定”的抱怨，因为每一次运行dou遵循了明确且可追踪的步骤。

MCP 部分：\

{
  "server": "figma",
  "capabilities": {
      "tools": ,
      "resources": 
  },
  "auth": {
      "type":"oauth2",
      "scopes":
  }
}

S­kill 部分：\ 目录结构如下：

.
├─ skills/
│   └─ figma-to-frontend/
│       ├─ SKILL.md            # 描述输入、输出
│       ├─ references/
│       │   ├─ component-mapping.md
│       │   └─ design-token-rules.md
│       └─ scripts/
│           └─ post_check.sh   # 检查代码格式并生成截图报告
└─ src/
    ├─ components/
    ├─ pages/
    └─ tokens/
P​ipeline 示例：\
# Step 1: 用 MCP 拉取设计稿结构
nodes = mcp.call
# Step 2: 按 skill 中 mapping 表将节点映射为 UI 组件
components = skill.apply_mapping
# Step 3: 使用内部模板渲染 React 文件并写入 src/pages/
generator.render
# Step 4: 执行 post_check.sh Zuo lint & 截图
scripts.run
E​ffect：\
上线两周后该链路日均成功生成前端页面超过120次错误率从Zui初的15%降至不到1%。团队反馈：“我们现在只需要告诉 agent 哪个 Figma 文件 ID，就Neng得到符合公司 UI 标准的代码”，这正是 Skill 带来的价值——让Neng力变得**可复制**且**可监管**。

T​ips & 小技巧，让你的 MCP+Skill geng“稳”geng“快” 🎯

#1 保持配置与代码分离。 将所有 .mcp/*.json 放在专门目录，并使用 CI 自动校验 JSON Schema，可避免因手误导致接口失效。
#2 给每个 Skill 加上版本号。 当业务规范升级时只需新增 v2 目录，不必改动Yi有流水线，从而实现零风险切换。
#3 用日志桥接两层关系。 MCP 层记录「调用成功/失败」；Skill 层记录「业务步骤执行情况」。统一聚合后你Ke以快速定位到底是「连不上」还是「流程跑偏」。
#4 定期演练安全审计。 尤其是对外部 SaaS 接口，要确保 token 生命周期受控，否则即使功Neng完备也可Neng因安全事故被迫下线。
💡#5 别忘了人机交互体验。 即便技术栈Yi经成熟，也要让业务方Neng够通过简单 UI 配置要使用哪些 Skills，这样才Neng真正落地到产品中去。
}
C​onclusion – 两者不是对立，而是协同进化 🚦 
MCP 和 Skill 各自扮演着不可替代的角色：前者负责让模型拥有通向外部世界的大门，后者负责把打开的大门装配成可靠且易于重复使用的工作台。当你在项目初期就清晰划分这两块责任，并遵循“先接入，再编排”的顺序，你会发现原本混乱不堪的问题瞬间变得条理清晰，开发效率提升数倍也不是梦。

©2026 AI 技术社区 | 本文基于公开资料和作者实践撰写，仅作学习交流之用。如有侵权，请及时联系删除。
`