Skill 与 MCP：给 AI 装上手和工具

背景

直接和 AI 对话，你会发现两个硬伤：

它不会做某些事——比如写一篇结构严谨的 DOCX、按某个固定流程做代码评审。它的训练数据里有“知识”，但缺“动作”。
它做不到某些事——比如读取你本地的文件、查询你的数据库、操作真实的外部系统。它活在沙箱里，和你的世界是断开的。

前者靠 Skill，后者靠 MCP。它们不是同一类东西，但常被一起提到，因为都回答同一个问题：怎么让 AI 不只是聊天。

一句话区分：Skill 是“教 AI 按规矩办事的方法”，MCP 是“把 AI 接到真实世界的水管”。

分析

Skill：把流程沉淀成可复用的“剧本”

裸的 AI 像 RTOS 裸奔——每次都从零开始。Skill 是给它的“固件”：一段打包好的、带触发条件与执行步骤的工作流。

它通常由三部分组成：

触发词（trigger）：用户输入 /docx 或一句意图，匹配上某个 Skill。
指令（SKILL.md）：告诉 AI 该怎么做这件事，分几步、每步产出什么、何时停下确认。
可选资源：附带的脚本、模板、参考文档。

解决的核心问题：把一次性的对话，变成可重复、可迭代的流程。 不用每次都重新解释“先建文档、再加修订、最后导出”，Skill 自己记得。

我这次会话里加载的一堆 Skill 就是典型例子——docx 负责文档处理，systematic-debugging 负责调试，test-driven-development 负责测试。每个都是一个有名字、有边界的能力包。

MCP：给 AI 接上外部世界的“标准接口”

Skill 让 AI 知道“怎么做”，但手还是被绑在沙箱里。MCP（Model Context Protocol） 解决的是“够不到”的问题。

它本质是一个协议——规定了 AI 客户端和外部工具服务器之间怎么对话。你启动一个 MCP server（比如文件系统、数据库、Android 模拟器），它把一批 tools 暴露出来，AI 就能在对话里调用这些工具。

和“写个插件给某个特定 AI”相比，MCP 的价值在于解耦：

工具方写一次 server，所有支持 MCP 的 AI 客户端都能用。
AI 方不用为每个外部系统学一套私有协议，统一按 MCP 调用。
工具的调用是结构化的：参数有 schema，返回有格式，AI 不会靠“猜 JSON”出错。

类比：Skill 是给 AI 的“操作手册”，MCP 是给 AI 的“标准驱动接口”。一个偏软件层，一个偏硬件层。

一个具象的对照

维度	Skill	MCP
解决	不会做（缺流程）	做不到（够不到）
形态	打包的工作流/指令	协议 + 工具服务器
触发	意图匹配 / 斜杠命令	AI 主动调用 tool
边界	AI 内部的“怎么做”	AI 外部的“能碰什么”
复用	跨任务、跨项目	跨 AI 客户端

实现

实际工作流里两者经常组合用。一个常见模式：

MCP 提供 raw 能力——比如文件系统 server 让 AI 能读写磁盘。
Skill 编排这些能力——比如 docx Skill 调用文件读写 + 模板，按步骤产出文档。

伪示意（一个 MCP server 暴露的 tool 定义长这样）：

{
  "name": "read_file",
  "description": "读取本地文件内容",
  "inputSchema": {
    "type": "object",
    "properties": {
      "file_path": { "type": "string" }
    },
    "required": ["file_path"]
  }
}

AI 拿到 tool 列表后，会在需要时按 schema 填参数、发起调用，再把返回结果接回对话。整个过程对用户透明，但每一步都可审计、可拒绝。

调用外部工具会触及真实系统——读写文件、发请求、动设备。权限边界要明确：哪个 tool 能自动跑、哪个必须先问用户，最好一开始就定死，别等出事再补。

结论

Skill 填的是“能力流程化”的坑，把零散对话沉淀成可复用方法。
MCP 填的是“能力外接化”的坑，用统一协议把真实世界接给 AI。
两者互补：没有 Skill，AI 重复劳动；没有 MCP，AI 闭门造车。

把 AI 当协处理器，Skill 是它的固件，MCP 是它的总线——三者齐了，它才真正从“能聊天”变成“能干活”。