MCP 与 Skills：让 AI 从“会聊天”变成“会干活”

MCP 与 Skills：让 AI 从"会聊天"变成"会干活" 🚀

最近学习 AI Coding 工具时，经常会看到几个词：MCP、插件、Skills。刚开始很容易把它们混在一起：好像都是给 AI 扩展能力的东西，那到底有什么区别？什么时候用 MCP，什么时候用 Skill？插件又夹在中间干什么？

读完这一节后，我对它们的理解变得清晰很多：MCP 解决"AI 能不能连接外部世界"的问题，Skills 解决"AI 能不能记住工作流程"的问题，而插件则更像是把这些能力打包好的一键安装方案。

一句话概括：

MCP 让 AI 够得到外部服务，Skills 让 AI 记得住你的做事方法，插件让这些能力更容易安装和分发。

---

1. 为什么需要扩展 AI 的能力？

在普通对话里，AI 看起来很聪明，但它其实有明显边界。

比如你让它：

帮我查一下 PostgreSQL 数据库里最近 7 天新增了多少用户。

如果没有额外工具，AI 只能说：我没有访问数据库的能力。

再比如你每次提交代码前都要让 AI 做一套固定检查：

先跑测试，再检查类型错误，再看有没有 console.log，最后检查安全问题。

这件事 AI 能做，但问题是：每次新开会话，你都得重新说一遍。

所以 AI Coding 不只是"模型变聪明"这么简单，还需要两类扩展：

• 一类是连接外部工具和数据；
• 一类是沉淀固定流程和经验。

前者对应 MCP，后者对应 Skills。

---

2. MCP：给 AI 接一根"数据线" 🔌

MCP 的全称是 Model Context Protocol，可以理解为模型上下文协议。它的作用是让 AI 连接外部服务，比如数据库、API、文件系统、GitHub、Figma、浏览器、搜索工具等。原文把 MCP 比作一根"数据线"：一头连着 AI，一头连着外部服务；没有这根线，AI 再聪明也碰不到外部数据。

比如：

AI  <------ MCP ------> PostgreSQL
AI  <------ MCP ------> GitHub
AI  <------ MCP ------> Figma
AI  <------ MCP ------> Web Search

有了 MCP 之后，你就可以让 AI 做这些事：

查询 PostgreSQL：获取最近 7 天的注册用户数
查看 GitHub 仓库最近 5 个 PR
搜索 Next.js 最新特性
读取某个文档链接并总结内容

MCP 的重点不是"让 AI 更会推理"，而是让 AI 有权限、有通道去访问外部世界。

所以它适合这些场景：

场景	是否适合 MCP
查询数据库	适合
调用外部 API	适合
读取 GitHub 仓库	适合
读取网页和文档	适合
执行固定代码审查流程	不一定，Skills 更适合
写一次性页面修改需求	不需要，直接自然语言即可

原文也强调：不是所有任务都需要扩展。读取项目文件、运行命令、实现一个普通功能，很多时候 AI 内置工具已经够用；只有当任务涉及数据库、外部 API、网络搜索、外部服务时，才需要 MCP 或插件。

---

3. 插件：更省事的扩展容器 📦

在 MCP 和 Skills 之间，还有一个很实用的东西：插件。

插件可以理解为一个扩展包。它里面可以包含很多东西，比如：

插件
├── Commands 斜杠命令
├── Agents 子代理
├── Hooks 钩子
├── Skills 技能
└── MCP Servers 配置

也就是说，插件不是和 MCP、Skills 平级竞争的东西，而更像是一个分发容器 。一个插件里可以打包 MCP，也可以打包 Skills，还可以打包命令、Agent 和 Hooks。原文中给出的插件结构里，插件目录可以包含 skills/ 和 .mcp.json，说明插件本身可以同时承载技能和 MCP 配置。

所以新手更推荐先用插件，因为插件通常更省事：

想快速试试：用插件
需要细调参数：手动配 MCP
团队要统一工具：插件或 MCP 都可以

举个例子，你想让 AI 连接 PostgreSQL。

用插件可能是：

/plugin
搜索 postgres
安装
完成

用 MCP 可能是：

找配置文档
编辑 .mcp.json
检查格式
重启工具
验证连接

功能可能差不多，但插件降低了上手成本。原文的建议也很直接：先用插件，发现不够用再换 MCP。

---

4. Skills：让 AI 记住你的工作流 🧠

如果说 MCP 解决的是"连接外部服务"，那 Skills 解决的就是"沉淀工作流程"。

原文用了一个很形象的比喻：AI 像一个能力很强但每天早上都会失忆的实习生。你昨天教了它代码审查流程，今天新开会话又要重新教一遍。Skills 就像贴在墙上的操作清单，AI 每次做这类任务时都能照着执行。

比如你每天都要写日报，格式固定：

日期
今日完成
遇到的问题
明日计划

没有 Skill 时，你每次都要描述格式。

有了 Skill 后，你可以把格式写进 SKILL.md，以后只需要说：

帮我写今天的日报。

AI 就会自动按照你的固定格式输出。

这就是 Skills 的核心价值：

把一次性的提示词，变成可复用的工作流资产。

---

5. Skills 和普通脚本有什么区别？

一开始我以为 Skills 就是"脚本的自然语言版本"，但其实不是。

脚本更像刚性流程：

步骤 1
步骤 2
步骤 3

只要中间环境不满足，脚本可能就会报错退出。

Skills 更像指导原则。它告诉 AI 应该怎么做，但允许 AI 根据实际情况调整。比如一个代码审查 Skill 要求"检查测试覆盖率"，但当前项目还没有测试框架。脚本可能会卡住，但 AI 可以继续检查类型、安全、代码风格，然后提醒你"这个项目还需要先配置测试框架"。原文也指出，Skills 和传统自动化脚本的区别就在于：脚本更刚性，Skills 更柔性。

这也是 Skills 很适合 AI Coding 的原因。AI 写代码时，经常会遇到不确定情况：项目结构不同、技术栈不同、依赖不同、错误不同。如果流程太死，反而不好用；如果只是自然语言提醒，又容易被忘掉。Skills 正好处在中间：既能固化经验，又保留模型的灵活判断。

---

6. MCP 和 Skills 的本质区别

可以用一句话区分：

MCP 管"能不能访问"，Skills 管"应该怎么做"。

更具体地看：

对比项	MCP	Skills
解决问题	连接外部工具和数据	固化工作流程
典型对象	数据库、API、GitHub、Figma、网页	代码审查、测试流程、日报、文档生成
核心价值	给 AI 外部能力	给 AI 长期经验
触发方式	配好后由 AI 调用外部工具	AI 根据描述自动判断，或通过命令触发
更像什么	数据线 / 接口	操作清单 / 工作手册
是否适合复用	复用连接能力	复用做事方法

举个具体例子：

你说：

帮我检查这个项目最近一次 PR 的质量。

这件事可能同时用到 MCP 和 Skill。

MCP 负责：

连接 GitHub
读取 PR 文件变更
获取评论和 CI 状态

Skill 负责：

按照固定审查流程检查代码
先看功能正确性
再看类型安全
再看测试覆盖
最后输出 Markdown 表格

所以真正高效的 AI 工作流往往不是 MCP 或 Skills 二选一，而是组合使用：

MCP 提供外部上下文
Skills 提供执行规范
插件降低安装成本

---

7. 什么时候该创建自己的 Skill？

不是所有任务都值得写 Skill。判断标准很简单：只要你发现自己在反复说同一套要求，就可以考虑写 Skill。

比较适合创建 Skill 的场景包括：

场景	适合原因
每天重复同样格式的任务	一次配置，长期复用
代码审查流程固定	避免每次重新描述
团队输出格式要统一	放到项目目录，全员共享
文档生成有固定结构	保持跨会话一致性
实验记录、论文笔记格式固定	特别适合科研和学习场景

比如可以为自己的学习和项目创建这些 Skills：

paper-reading-skill：读论文时固定总结研究问题、方法、创新点、实验设置和不足
code-review-skill：提交前检查类型、测试、安全和可维护性
experiment-log-skill：整理训练配置、指标、loss 曲线和下一步计划
blog-polish-skill：把技术笔记润色成适合发布的博客

对我来说，Skills 最有价值的地方不是"自动化"，而是把自己的经验沉淀下来 。以前经验散落在一次次对话里，会话结束就没了；现在可以写进 SKILL.md，变成长期可复用的工作流。

---

8. Skill 的基本结构

一个 Skill 通常由 SKILL.md 定义，核心包括 name 和 description，再加上具体指令、示例和限制。

一个简化结构类似这样：

---
name: code-review
description: Use when reviewing code changes before commit or pull request.
---

# Code Review

## Instructions

1. Run tests if available.
2. Check type safety.
3. Check security risks.
4. Check readability and maintainability.
5. Output findings as a Markdown table.

## Output Format

| Level | Problem | Suggestion |
|---|---|---|

这里最关键的是 description。因为 AI 是否会自动调用这个 Skill，很大程度取决于描述是否清楚。原文也提到，如果 AI 没有自动使用 Skill，应该优先检查 description 字段；描述越具体，AI 越容易判断什么时候该用它。

比如：

代码审查工具

就比较模糊。

更好的写法是：

Use when the user asks to review code before commit or PR. It checks type safety, tests, security risks, and outputs a Markdown table.

它明确说明了三个信息：

什么时候用
检查什么
输出什么格式

---

9. 安全：别让 AI 拿到不该拿的权限 ⚠️

MCP 和 Skills 都很强，但越强越要注意权限。

MCP 连接的是外部服务，所以一定要谨慎授权。比如数据库 MCP 最好使用只读账号，不要直接给生产数据库写权限；文件系统 MCP 只开放必要目录，不要开放根目录；GitHub MCP 尽量使用有期限、最小权限的 token。原文也专门提醒，MCP、插件和 Skills 都需要做好权限控制。

Skills 也要注意工具权限。比如一个只负责读取文件的 Skill，就不应该拥有修改文件或执行危险命令的能力。可以通过 allowed-tools 限制它能使用的工具。

例如：

---
name: safe-file-reader
description: Read files without making changes. Use when read-only file access is needed.
allowed-tools: Read, Grep, Glob
---

这个思路很重要：不要为了方便，把所有权限都交出去。

AI Coding 里的安全原则可以概括成三句话：

能只读就不要写入
能限定目录就不要开放全盘
能最小权限就不要全权限

尤其是 API Key、数据库连接字符串、GitHub Token 这些敏感信息，千万不要直接写进仓库。

---

10. 我的理解：MCP、插件、Skills 是 AI Coding 的三层扩展体系

学完这一节后，我觉得可以把它们看成三层：

插件：最容易安装的扩展入口
MCP：连接外部工具和数据的协议
Skills：沉淀个人或团队工作流的能力包

对于新手来说，最合理的路线不是一上来就自己写 MCP Server 或设计复杂 Skill，而是：

先用内置能力
再安装现成插件
然后配置必要 MCP
最后沉淀自己的 Skills

这和原文的建议也一致：能用内置能力就不要扩展，能用插件就不要手动配置，熟悉之后再根据需求配置 MCP 或创建 Skills。

---

总结

MCP 和 Skills 都是 AI Coding 走向 Agent 化的重要能力，但它们解决的问题完全不同。

MCP 让 AI 连接外部世界。

它解决的是"AI 能不能访问数据库、GitHub、网页、API、Figma"等问题。

Skills 让 AI 记住工作方法。

它解决的是"AI 能不能稳定按照我的流程做事，不要每次都重新教"的问题。

插件让扩展变得更简单。

它把 MCP、Skills、Commands、Agents、Hooks 等能力打包起来，降低安装和使用门槛。

最终可以这样记：

MCP = 给 AI 接工具
Skills = 给 AI 写说明书
插件 = 把工具和说明书打包安装

对个人开发者来说，MCP 能让 AI 真正参与项目上下文；Skills 能把自己的经验沉淀为可复用资产。一个负责"连接"，一个负责"规范"，组合起来，AI 才不只是一个会回答问题的聊天助手，而更像一个能持续协作的开发伙伴。✨