ELI5 · 说人话

MCP 和 Skill

MCP GitHub 数据库 SKILL.md 读一遍

一个把 AI 接到外面的东西上，
一个告诉 AI 这活该怎么干。

一个给手，一个给规矩

先分清

一个是线，一个是书

能力
一根数据线

MCP 是一套插口标准。插上，AI 才够得着你的 GitHub、数据库、公司内网。没插上，它连门都摸不到。

知识
一本工作手册

Skill 是一个文件夹加一份 Markdown。AI 本来就会写代码，手册告诉它：在你这儿，这类活得按这个规矩来。

拆开看 · 其一

MCP 是怎么接的

中间多了一个跑着的程序。AI 不直接碰 GitHub，它跟这个程序说话，程序替它去碰。

AI 脑子 要 给 MCP Server 一个跑着的程序 GitHub · Slack 数据库 · 内网

实线 = 请求　虚线 = 返回

代价也在这儿：要装、要配、要登录。而且它一上来就把自己那一整份工具清单塞进 AI 的脑子，用不用得上都占地方。

但「程序」不等于「你得部署一个服务」。本地这种（stdio）是客户端自己 spawn 的子进程，没有端口、没有守护进程，你退出客户端它就跟着死。只有远端那种（HTTP）才是真有 URL、要一直在线的服务。

拆开看 · 其二

Skill 就是一个文件夹

没有进程，没有端口，没有登录。
就是几个文件，丢进去就生效。

写周报/ ├── SKILL.md ← 必须有：名字、一句话简介、正文 ├── references/ ← 太长的资料，需要时才翻 └── scripts/ ← 能直接跑的脚本

聪明的地方是它分三次才全读完：

1 平时：只有名字和一句话简介躺在那儿 ≈ 30 字 2 看着像要用：整篇 SKILL.md 才读进来 几百行 3 真卡住了：才去翻 references/ 里的细节 按需

用不上就一直停在第一层

所以你可以塞一百个 Skill 进去，平时也就占几百字。MCP 做不到这个——它的工具清单是全量常驻的。

最少要什么

各自的最小个头

同样是「能用起来」，一个要凑齐六件事，
一个只要两个字段。

最小的 MCP 一个能被拉起来的进程
  1. 一条管道stdio 最省事：标准输入收消息，标准输出发消息。要走网络就换成 HTTP。
  2. 说 JSON-RPC 2.0来往的每一条都得是这个格式，不是随便什么 JSON 都行。
  3. 接一次握手客户端喊 initialize，你回自己的名字、版本，以及「我有 tools」。
  4. 报一份清单tools/list：每个工具的名字、干什么用、参数长什么样（JSON Schema）。
  5. 接活交货tools/call：收到名字和参数，干完把结果塞进 content 数组还回去。
  6. 在客户端登记一行配置里写清楚拿什么命令把你拉起来，不然没人知道你存在。
// server.js —— 用官方 SDK，就这么长 const server = new McpServer({ name: "hello", version: "1.0.0" }) // 一个工具 = 名字 + 干什么用 + 参数 schema + 真正干活的函数 server.tool( "add", "把两个数加起来", { a: z.number(), b: z.number() }, async ({ a, b }) => ({ content: [{ type: "text", text: String(a + b) }] }) ) await server.connect(new StdioServerTransport())
// 客户端配置里还得登记这一行，否则它不会被拉起来 { "mcpServers": { "hello": { "command": "node", "args": ["server.js"] } } }
最小的 Skill 一个文件
  1. 一个文件夹名字小写加连字符，跟里面写的 name 对上。
  2. 一份 SKILL.md只有它是必须的。references/、scripts/ 全是可选。
  3. 两个必填字段开头 frontmatter 里的 name 和 description，就这两个。
  4. 正文写怎么干普通 Markdown，该几步写几步。写长了再拆去 references/。
写周报/ └── SKILL.md ← 只有这一个是必须的
--- name: weekly-report description: 把本周的 git 提交整理成周报。用户说「写周报」 「这周干了啥」的时候用。 --- # 下面是正文，普通 Markdown 就行 1. `git log --since="7 days ago" --author=<我>` 2. 按项目分组，每组挑 3 条 3. 每条写成「做了什么 → 带来什么」

description 是唯一一直占着上下文的东西。它得同时说清「这是干嘛的」和「什么时候该想起我」——写虚了，这个 Skill 一辈子不会被触发。

落差就在这儿：MCP 的「最小」是一个要握手、要报 schema 的进程；Skill 的「最小」是两行 YAML 加一段大白话文件。

走一遍

真接一次是什么样

订单躺在公司的 MySQL 里。
没有现成的命令行，密码也不能给模型。

你 客户端 模型 server

  1. 1
    你

    写一个 server

    只开一个口子：query_orders。SQL 是你写死的，模型只能往问号里填参数——它没法自己造一句 SQL。

    // orders.js server.tool( "query_orders", "按状态和起始日期查订单笔数", { status: z.string(), since: z.string() }, async ({ status, since }) => { const [rows] = await db.query( "SELECT COUNT(*) n FROM orders WHERE status=? AND created_at>=?", [status, since] ) return { content: [{ type: "text", text: `${rows[0].n} 笔` }] } } ) await server.connect(new StdioServerTransport())
  2. 2
    你

    在配置里登记一行

    密码走 env，只进这个子进程，不进模型的上下文。写完就完事了——你不用去启动它。

    { "mcpServers": { "orders": { "command": "node", "args": ["/srv/mcp/orders.js"], "env": { "DB_DSN": "mysql://reader:***@10.0.0.7/shop" } } } }
  3. 3
    客户端

    把它拉起来，握个手

    你打开 Claude Code 的那一刻，它 spawn 出这个子进程，发 initialize，再要一份 tools/list，拿到：query_orders，两个参数。这一步你什么都没做。

  4. 4
    你

    说一句人话

    上周有多少笔订单卡在待发货？

  5. 5
    模型

    挑工具，把话翻成参数

    「待发货」对上 pending_shipment，「上周」算成日期。这一步是模型在猜——猜错了你得看得见，所以参数要回显给你。

    { "name": "query_orders", "arguments": { "status": "pending_shipment", "since": "2026-08-17" } }
  6. 6
    server

    查库，交货

    子进程拿参数去查，结果塞进 content 数组还回去。

    { "content": [ { "type": "text", "text": "1274 笔" } ] }
  7. 7
    模型

    用大白话回你

    上周有 1274 笔订单卡在待发货。

全程模型没见过数据库密码，也没法自己写 SQL——它只能在你划好的两个格子里填空。这就是这类活非 MCP 不可的原因：要连接、要凭证，而这两样都不能交给一份手册。

你关掉 Claude Code，这个子进程跟着结束。没有残留的服务要你管。

摆一起

一条一条对着看

比什么 MCP Skill
是个啥 一套协议，外加一个真在跑的程序 一个文件夹，里面一份 Markdown
给的是 能力 —— 让它够得着 知识 —— 让它做得对
谁动手 那个程序替 AI 去动 AI 自己动，用它手上已有的工具
怎么装 写配置、走认证，让客户端能把它拉起来 把文件夹丢进去，完事
占多少脑子 整份工具清单一直占着 平时一句话，用到才展开
能登录吗 能。OAuth、换令牌、长连接都扛得住 不能。它只是一段文字，没法自己去握手
改一改 改代码、重启进程 改 Markdown，存盘就生效
谁能用 任何支持 MCP 的客户端 任何能读文件、能跑命令的 agent

正面回答

那 Skill 能替代 MCP 吗

能吃掉一半，
另一半吃不掉。

这些确实在被吃掉
  • 只是包了个命令行的一个 GitHub MCP，底下无非在调 gh。AI 本来就会跑 gh，那层壳纯属多余。
  • 只是一堆固定说明的「先查 issue 再开 PR」这种规矩，写进 SKILL.md 比包成工具清楚得多。
  • 工具太多、白占脑子的拆成几个 Skill，用哪个展开哪个，省下的全是真上下文。
  • 只是在递一份文档的把 API 手册包成 MCP，不如塞进 Skill 的 references/，要看的时候才翻。
这些非 MCP 不可
  • 登录和授权OAuth 跳转、令牌过期自动换、公司 SSO。手册不会自己去握手。
  • 压根没有命令行的系统只有专有 SDK 或者内网协议，总得有人写个程序去桥。
  • AI 没有终端的地方不少客户端根本不给它跑命令。那手册再厚也是空谈——它没有手。
  • 要实时推送、要结构化数据服务端主动推、资源目录，这些靠读文档做不出来。

一句话：Skill 正在替掉那些本来就不该做成 MCP 的 MCP。真正干连接的那部分，一个都没少。

真实用法

它俩本来就是一起用的

MCP ── 把 GitHub 接上。登录、拉数据、提 PR，都归它。

Skill ── 定规矩。先查有没有重复 issue，标题怎么写，绝不直接推 main。

拔了线，规矩没处使；只有线没规矩，它就自由发挥了。不是二选一——是看它缺的是手，还是缺的是规矩。

MCP 让它够得着，
Skill 让它做得对。