一个「在 Skill 里写段脚本不就行了吗？」的追问，逼出了这个问题的终极答案。

---

起因：为什么 MCP 和 Skill 看着像一回事？

我用 Claude Code 一段时间了，发现它有两种扩展方式：

• MCP（Model Context Protocol）：配一个外部服务，Claude 就能调用里面的函数，比如上传抖音视频

• Skill（技能）：写一段 Markdown 提示词放进 .claude/skills/，Claude 就学会了某种工作流程，用起来感觉也差不多

那我就想不通了：Skill 里也能写「遇到这种情况，你就写个 Python 脚本去执行」啊？那 MCP 还有什么用？为什么不全部用 Skill + 脚本替代？

我把这个问题丢给了 Claude Code 自己。

---

Claude 的回答分三层

第一层：物理形态完全不同

	MCP	Skill
本质	一个独立运行的外部进程	一段加载到上下文里的 Markdown 指令
运行在哪	独立子进程或远程服务器	Claude 的上下文窗口里
能做什么	里面的代码能做什么就能做什么（开浏览器、连数据库、常驻内存）	受限于 Claude 本身的能力（只能调它已有的工具）
配置	.mcp.json	.claude/skills/*.md

这解释了「它们是什么」，但没解释核心问题——既然 Skill 能让我写脚本，脚本也能做任何事，MCP 不是多余吗？

---

第二层：关键差异在状态和可靠性

Claude 举了一个很实在的例子：

Skill + 脚本方案上传 20 个视频：

每次上传都要启动新进程 → 打开浏览器 → 登录 → 上传 → 关闭。20 个视频就是 20 次登录。而且每次 Claude 都得先猜你的脚本叫什么、参数是什么、放在哪个文件夹——翻文件、读 --help、试运行，搞不好第三遍才跑通。

MCP 方案上传 20 个视频：

Server 启动一次，浏览器窗口常开，登录态一直在内存里。20 个视频就是 20 次函数调用，毫秒级响应。参数有 Schema 约束，不存在「猜参数名」这回事——一次就通。

这开始触及核心了，但还是没到根。

---

第三层（这层最关键）：脚本和 MCP 本质一样，差的是确定性

我继续追问：「MCP 底层不也是跑脚本吗？那不就跟脚本一样？为什么不全部用 Skill + 脚本？」

Claude 的回答是——你说得对，本质上都是跑代码，没有区别。

然后它给了一个让我豁然开朗的类比：

「HTTP REST API 本质上不就是 curl 调一个后端函数吗？为什么不全部用 curl + 文档？」

答案是一样的：文档是给人看的，Schema 是给机器读的。人能读文档但会犯错，机器读 Schema 不会犯错。

MCP 的本质，就是给脚本包了一层机器可确定性理解的结构化接口：

脚本方案：Claude 读你的 README → 理解 → 猜命令 → 拼参数 → 执行
         ↑ 每一环都有可能出错，成功率 ~70-90%
​
MCP 方案：Claude 收到 JSON Schema → 函数调用 → 执行
         ↑ 没有猜测环节，成功率 ~99%+

---

所以终极答案是什么

Claude和我说了很多，但我自己总结了一句话：

mcp的核心是为了稳 主要用于多人的场景中 个人场景纯skill+脚本完全够用

mcp这层壳在你一个人用的时候看起来多余——为了稳那 10-20%，要多写一个 MCP Server 的包装代码，费那劲干嘛？80-90% 的场景，Skill + 脚本完全够用。

但场景换成：

• 分享给 100 个人用——100 个人不用各自猜参数，直接调

• 一天调用 200 次——常驻进程不用反复启动，省掉巨大开销

• 跨 IDE 分发——同一套 MCP，Claude Desktop 能用、Cursor 能用、Zed 也能用。Skill？只有 Claude Code 认识

• 需要常驻状态——数据库连接池、浏览器窗口、WebSocket，Skill 做不到

在这些场景下，那层壳不是多余，是临界点。

---

后记

这篇文章的核心内容，是我跟 Claude Code 深夜聊出来的。我觉得这个对话本身就是一个很好的例证——当你想不通一个技术设计的时候，把问题直接丢给 AI，一层层追问下去，往往比看文档更快触达本质。

Claude 没有给我塞书单和链接，就用逻辑和类比把我问的每一个「为什么」都怼穿了。这也是我选择把这番对话整理成文章的原因。

---