摘要： 很多人对MCP和Skills存在误解，认为MCP就是API调用、Skills就是提示词。本文从大模型“只会生成文字”这一本质出发，系统梳理MCP和Skills各自解决的问题：MCP是解决AI与外部世界连接问题的标准化协议，Skills是解决做事方法论问题的工程化知识包。二者分工明确、互相配合，共同将AI从“每次都要手把手教的实习生”转变为“教一次就会持续执行的系统”。本文基于相关视频内容整理，部分要点通过Ai好记完成结构化转录和提炼。

目录

• 1 两个常见的误解
• 2 大模型的本质局限
• 3 MCP：解决连接问题
• 4 Skills：解决方法论问题
• 5 MCP与Skills的关系
• 6 总结：标准化与工程化

1 两个常见的误解

关于MCP和Skills，技术社区里经常能看到两种说法：

“MCP就是API调用，多包了一层而已。”

“Skills就是提示词，换个名字罢了。”

这两句话对也不对。说它对，是因为从技术实现层面看，确实可以这样理解。说它不对，是因为这种说法丢掉了最关键的东西——标准化和工程化。

MCP不只是API调用，它是一套让AI能自主发现、理解和使用工具的标准化协议。Skills不只是提示词，它是将做事方法打包成可版本化、可自动触发的工程化文件包。

要理解这两者到底是什么，得先从大模型本身说起。

2 大模型的本质局限

先说一个容易被忽略的事实：大模型本质上只会做一件事——生成文字。

它接收一串文字，输出下一串文字。它没有记忆——对话窗口一关，它就不认识你了。它没有眼睛，看不到你的文件；它没有手，点不了按钮、发不了邮件、查不了数据库。

你跟他聊天的时候感觉他什么都能干，那是因为有人在他周围搭了一整套基础设施——搜索、读文件、调API，这些都是外挂的。

想让一个只会说话的东西变得真正有用，得解决两个完全不同的问题：

1. 连接问题：让他能摸到外面的世界——能读文件、查数据库、调API、发消息。
2. 方法论问题：让他知道怎么做事——不是随便调个API就完了，而是按照你的流程、你的标准、你的方法来做事。

MCP解决的是连接问题，Skills解决的是方法论问题。一个管“能不能”，一个管“怎么做”。

3 MCP：解决连接问题

3.1 Function Calling的痛点

要理解MCP是什么，得先搞清楚一个在它之前就存在的东西——Function Calling。

2023年6月，OpenAI给ChatGPT加了函数调用功能。逻辑很简单：调用API时附上一堆工具定义，告诉模型有哪些函数可以用、每个函数接收什么参数。模型觉得需要某个工具时，就输出一段结构化的JSON，告诉你要调哪个函数、参数是什么。

但Function Calling有几个很头疼的问题：

格式绑定厂商：OpenAI的Function Calling是一种格式，Claude是另一种，谷歌又不一样。同一个工具要给三家写三份定义。

每次请求带全量：有50个工具，每次调API都得把50个工具的定义全塞进去。50个工具的描述大概要吃掉1到2万token，模型还没看到用户说了啥，光工具描述就占了一大片。

工具逻辑与应用代码耦合：工具的定义和执行都在你的代码里。想让别人用这个工具，就得把代码给他。想把同一个工具接到10个不同的AI应用上，就得集成10次。

这几个问题加在一起就是所谓的N×M问题——N个工具对接M个AI应用，需要写N×M份集成代码。工具多了、应用多了，指数级爆炸。

3.2 MCP的解决方案

MCP做的事情就是把N×M变成N+M。

怎么变的？思路非常简单：把工具从应用里拆出来，变成一个独立的服务。这个服务自己声明自己有什么能力，自己处理执行逻辑。任何一个AI应用都可以连上来问一句“你有什么工具可以用”，服务就把自己的工具清单返回去。

从这一刻起，工具是工具，应用是应用，各写各的。

MCP与API的关键区别

传统API的消费者是代码——你写好了调用逻辑，精确地知道该调哪个Endpoint、传什么参数、怎么处理返回值，这一切都是人写的、确定的。MCP的消费者是AI——它需要自己看工具描述、自己判断该不该用、自己构造参数。

这就要求工具不光能被调用，还得能被理解。所以MCP在API上面加了一层专门让AI看得懂的标准描述。

3.3 MCP的架构

MCP有三个角色：

• Host（宿主） ：AI应用本身，比如Claude桌面端、Cursor、VS Code
• Client（客户端） ：Host里负责跟Server通信的组件，一个Client对一个Server
• Server（服务端） ：提供能力的独立服务，可以跑在本地也可以跑在云端

Server对外暴露三种东西：

• Tools（工具） ：可执行的函数，模型觉得需要的时候可以调用，比如查数据库、发消息
• Sources（数据源） ：只读的数据源，给模型提供上下文
• Prompts（提示词模板） ：可复用的提示词，帮助模型更好地跟Server交互

通信方式有两种：stdio走标准输入输出，适合本地进程，几乎零延迟；HTTP走网络请求，适合远程服务。

3.4 MCP的生态与现状

MCP由Anthropic于2024年11月推出。2025年12月，Anthropic将MCP捐赠给Linux基金会旗下的Agentic AI Foundation，由谷歌、微软、AWS、Block、Cloudflare等共同支持。截至2026年中，MCP已成为事实上的行业标准，官方npm SDK月下载量突破9700万次，公开MCP服务端超过14000个。

2026年6月24日，Anthropic联合微软、OpenAI等正式发布MCP 1.0正式版。主流AI工具已原生支持MCP，包括Claude Desktop、Claude Code、OpenAI Agents SDK、Cursor、Windsurf、JetBrains AI等。

4 Skills：解决方法论问题

4.1 没有Skills的痛苦

用Claude或GPT认真写过东西的人应该知道：每次开启新对话，它就什么都不记得了。上次跟它说的写作风格、代码规范、处理某类任务的流程，全部归零，得重新说一遍。

有人说把规则写成prompt不就行了？但prompt是绑在某次对话里的，换个场景开新对话又得重新粘贴。而且它只是一段文字，没法在里面附一个Python脚本让它在特定步骤执行。

有人说用Claude Code的全局配置，但没法做到只在做PPT时加载这套规则、做别的事时不加载。

Skills解决的就是这个问题。

4.2 Skills的定义与结构

Skills是一种把做事方法打包成文件，让AI自动识别、自动加载的机制。

一个Skill物理上就是一个文件夹，核心文件是skill.md。这个文件开头有一段元数据，写着Skill叫什么名字、什么时候应该被触发。后面是Markdown写的具体指令，告诉AI遇到这类任务应该怎么做。

文件夹里还可以放脚本（用于验证输出格式）、参考资料（如品牌风格指南、API文档）、模板和素材。

4.3 渐进式披露

Skills有一个很聪明的设计叫渐进式披露。它分三层加载：

• 第一层 - 元数据：AI启动时只加载每个Skill的名字和描述，大概30到50个token。装几十个Skills也不会撑爆上下文窗口。
• 第二层 - 完整指令：只有当AI判断当前任务跟某个Skill相关时，才会去读完整的指令。
• 第三层 - 资源文件：只有在执行过程中真正需要时，才去读参考资料或运行脚本。

这个设计的价值在于：你可以装几十个Skills，但每次对话只有相关的那一个会被完整加载，其他的都只占一点点空间。

实测数据显示，在处理长链条业务流程时，这种架构能将上下文Token消耗降低60%到80%，同时显著提升指令遵循准确率。

4.4 Skills与提示词的本质区别

有人说Skills就是更好组织的提示词。这就像说“一家公司就是一群人坐一起”——技术上没毛病，但忽略了组织架构的价值。

原始提示词和Skills的区别：

• 提示词是一次性的：写了、用了、关掉对话，没了，下次还得重新写。Skills是持久化的：写一次、装上以后自动触发，跨对话、跨项目。
• 提示词是平面的：就是一段文字，没法在里面嵌脚本做确定性检查。Skills是立体的：有层级结构、触发条件、脚本执行能力、引用外部资源的机制。
• 提示词靠人记：你得记住什么时候该用什么提示词，然后手动粘贴。Skills靠AI判断：它自己看当前任务，自己决定要不要加载。

Skills本质上是被工程化管理的提示词——有版本控制、有自动触发、有分层加载。它对提示词做的事情，就像Git对代码文件做的事情——把一个原本靠手动管理的东西，变成了有体系的基础设施。

5 MCP与Skills的关系

MCP和Skills解决的是不同层面的问题。

有一个比喻说得很形象：MCP是五金店的货架，Skills是懂行的店员。

你走进一家五金店想修一个坏掉的柜子，货架上什么都有——木胶、夹具、各种螺丝——但你可能不知道买哪些、不知道先用哪个后用哪个、不知道木胶要涂多厚。

MCP就是那个货架，它让AI能摸到外部的工具和数据——连GitHub、连数据库、连Slack，都是MCP的事。Skills就是那个懂行的店员，他告诉AI修这种柜子应该先检查什么、再做什么、最后做什么。

没有MCP的Skills，是知道怎么修但手边没工具。没有Skills的MCP，是工具都在但不知道怎么修。

用一个具体场景来说明：

每周出一份竞品分析报告。MCP负责的部分是连接Google Drive读取内部研究资料、连接GitHub拉取竞品代码库更新、连接搜索引擎查行业新闻——这些都是连接的事。Skills负责的部分是定义分析框架（先看产品更新、再看技术动向、最后看市场反应）、定义输出格式（用什么模板）、定义质量标准（数据必须有出处、结论必须有论据）——这些都是方法的事。

MCP让AI能拿到数据，Skills让AI知道拿到数据之后该怎么处理。一个管连接，一个管方法。

6 总结：标准化与工程化

MCP和Skills在技术层面都不是颠覆性的创新。MCP用的Client-Server架构、JSON-RPC 2.0、JSON Schema描述工具，都是已有的东西。Skills在操作层面确实就是提示词加脚本。

但它们真正的贡献在于两种思维：

MCP的贡献是标准化思维：统一接口、统一外部服务，让所有人按同一个规矩来做工具集成。它统一的是AI和外部工具之间的接口，就像USB-C统一了各种充电接口。

Skills的贡献是知识工程化思维：把人脑里的做事方法变成机器可读、可版本化、可自动触发的文件。它把原本靠人脑记忆、靠口口相传、靠每次重新来的东西，变成可复用、可传播、可版本化的基础设施。

这个转变的意义比任何一个具体技术都大。它让AI从一个每次都要手把手教的实习生，变成一个教一次就能持续执行的系统。

回到开头那两个误解：

Skills是不是提示词？是。但提示词可以被工程化管理、自动触发、分层加载、脚本验证，那它就不只是提示词了。

MCP是不是API调用？是。但API调用可以被标准化、动态发现、跨厂商使用，那它就不只是API调用了。

给一个东西起一个更精确的名字，不是为了装，是因为原来的名字已经装不下它新长出来的那些属性。

参考资料

• 本文基于B站@数字生命情酱《AI认知——什么是MCP和Skills》核心观点，由音视频转笔记工具Ai好记辅助创作，参考Ai好记生成的精华速览、思维导图、文本大纲、模版总结进行撰写。如果你也经常看长视频来学习，可以通过这个工具理清思路，提高效率～