Claude Code 的 MCP、Skills、Plugin 有什么区别？扩展机制对比

搜索 Claude Code 扩展方案时，MCP、Skills 和 Plugin 经常被放在一起讨论。它们都能让开发工作流更方便，但解决的问题并不相同。把三者混为一谈，最容易出现的结果是安装了不需要的组件，或者在不了解权限的情况下把生产数据暴露给外部工具。

先给一个简短结论：MCP 关注“让 AI 连接什么工具或数据”，Skills 关注“这类任务应该怎样做”，Plugin 更关注“如何把一组扩展能力组织和分发”。不同版本、客户端和社区实现可能有细节差异，下面的表格是帮助决策的概念框架，不代表所有环境的具体命令完全一致。

一张表看懂三者区别

维度	MCP	Skills	Plugin
核心作用	连接外部工具、资源或数据	复用一类任务的步骤和知识	打包和分发一组扩展内容
典型问题	“Claude 如何查询这个系统？”	“每次怎样按同一流程做检查？”	“如何把这套能力交给团队使用？”
可能包含	工具、资源、服务器	说明、模板、脚本或参考资料	Skills、命令、钩子、MCP 或其他资源
主要风险	外部读取、写入、执行和网络权限	规则误导、脚本行为和范围过宽	供应链、组件叠加和权限不透明
适合起点	只读测试数据	低风险可重复任务	已验证、需要团队复用的扩展包

三者可以组合使用，但组合不等于默认信任。每一层的权限都要单独检查，不能因为某个 Plugin 看起来方便，就跳过其中 MCP 服务器或脚本的审查。

MCP 解决的是连接问题

MCP 通常指 Model Context Protocol。它提供一种让 AI 应用连接外部工具、资源和数据的思路，例如查询项目资料、读取测试数据库或调用某个内部服务。MCP 服务器暴露什么能力，取决于具体实现；它并不会自动获得“访问所有文件”的许可。

使用 MCP 前，先回答四个问题：

• 服务器是谁维护的，代码和版本从哪里来。
• 它能读取、写入、执行或上传哪些内容。
• 凭证保存在哪里，数据会发送到哪个服务。
• 发生误操作时如何停止、撤销和审计。

已有Claude MCP 入门说明可以帮助你建立基础概念。第一次连接时，建议只允许列出测试目录和读取公开样例，不要直接接入客户资料、生产数据库或含有密钥的仓库。

Skills 解决的是流程问题

Skill 不一定连接外部系统。它更像一份可复用的任务剧本，告诉 Claude Code 什么时候使用、先检查什么、怎样修改、失败后怎么处理以及最终如何报告。例如“为一个模块补测试”可以规定先读取现有测试和接口，再列出覆盖缺口，修改后运行指定命令，最后报告未覆盖分支。

Skills 的效果取决于流程是否具体。下面这类写法比较容易执行：

先只读分析目标模块和现有测试。
输出覆盖缺口与不确定项，等待确认后再编辑。
只修改指定源码和测试文件。
完成后运行相关测试，报告命令、退出结果和变更摘要。
测试失败时停止，不要删除锁文件或扩大修改范围。

如果想深入实践，可以查看Claude Code Skills 安装与创建指南和CLAUDE.md 写法。

Plugin 解决的是组织和分发问题

Plugin 往往是把多种扩展资源组织在一起的方式，方便个人或团队安装、版本管理和复用。一个 Plugin 可能包含命令、Skills、脚本、钩子或 MCP 配置，具体组成取决于实现。

因此，Plugin 的审查不能只看名称和介绍页。应继续检查它打包的每个组件：是否会运行脚本、调用网络、修改文件、读取环境变量，是否携带不透明的二进制文件，以及升级时是否会改变行为。团队使用时还应固定来源和版本，避免每次安装到不同内容。

按需求选择扩展方式

只需要固定一套工作流程

先用 Skill 或项目说明文件解决，不必接入 MCP。比如文章 SEO 检查、代码格式检查、发布前清单都可以从只读 Skill 开始。

需要读取外部数据

评估 MCP，但从只读和最小数据范围开始。明确查询条件、返回字段和操作日志，避免给一个简单问答任务开放写入权限。

需要把多项能力交给团队

在各组件分别验证后，再考虑用 Plugin 组织和分发。应给出版本、来源、权限、依赖和卸载说明，方便新成员理解和审查。

需要接入模型 API

MCP、Skills 和 Plugin 是客户端扩展概念，不能直接等同于 API 供应商。若需要把模型接入自有应用或开发工具，可以了解 ZeoAPI，它是独立第三方 API 网关。模型、费率、数据处理和可用性以其官方控制台和文档为准。

一套更稳妥的落地流程

1. 先写清楚要解决的具体任务，不以“安装更多扩展”为目标。
2. 画出数据流，列出输入、外部服务、输出和可能的副作用。
3. 从只读测试目录和脱敏数据开始。
4. 每次只启用一个组件，记录版本和权限。
5. 用故意错误的输入测试失败处理和停止机制。
6. 查看文件 diff、网络请求、日志和成本，再决定是否扩大使用范围。
7. 团队采用前补充审计、升级和撤销流程。

常见误区

“能看到工具”不代表“结果一定正确”；“安装成功”也不代表“权限合理”。工具返回的数据仍需核对来源、时间和查询条件，模型对工具结果的总结不能代替人工判断。

另一个误区是把网上的配置片段直接复制到生产环境。命令、路径、字段和配置格式可能随版本变化，第三方教程也可能包含过时或不安全的做法。任何涉及删除、发布、发信、支付、数据库写入和生产部署的动作，都应保留人工确认。

结论

MCP、Skills 和 Plugin 可以协同，但分工不同：连接外部世界用 MCP，复用任务方法用 Skills，组织和分发一组能力时考虑 Plugin。先从小范围、只读、可审计的场景开始，理解每个组件的实际权限后再自动化，才是更适合团队长期使用的方式。