从「会写技能」到「开发插件」
进阶课里你学了技能（Skill）——把最佳实践固化成指令包。插件（Plugin）是它的「正式升级版」：更完整的封装、可配置、可分发，适合在生产环境里对外发布、团队安装的能力。
理解两者的关系：
| 技能 Skill | 插件 Plugin | |
|---|---|---|
| 定位 | 一套指令包 | 更完整、可分发的能力组件 |
| 形态 | 轻量 | 可含代码、资源、配置 |
| 分发 | 放仓库 | 可打包发布、一键安装 |
| 场景 | 个人/团队流程 | 团队乃至更广范围复用 |
不是所有东西都要做成插件。个人小流程用技能就够，要对外分发、要复杂配置时才升级成插件。
mcp-hub——一个「真正可以发布给团队的 Claude Code 插件」，用来让团队**集中管理、接入、分发各种 MCP 服务**。本节要做的，就是先把 mcp-hub 的插件架构和生命周期想清楚：它分几层、从哪儿长出来、在哪一步会被团队安装。**先别写代码，先把骨架画对。**插件架构：三层
一个插件通常有三层，想清楚再动手：
| 层 | 内容 | 问的是 |
|---|---|---|
| 描述层 | 插件做什么、何时用 | 解决什么问题 |
| 指令层 | 执行的步骤与规范 | 怎么做 |
| 入口/配置层 | 如何被调用、可配置参数 | 怎么被使用 |
一个插件 = 描述清楚「是什么」+ 写清「怎么做」+ 提供「怎么用/怎么配」。
套到 mcp-hub 上，这三层对应的就是：
- 描述层：mcp-hub 是「让团队统一接入、管理 MCP 服务的插件」
- 指令层：怎么发现新服务、怎么校验配置、怎么把它接进 Claude Code
- 入口/配置层：团队在哪里配置可用的 MCP 服务清单、每个服务用什么凭据
分层想清楚了，后面每一块内容都有归属，不会越写越乱。
生命周期：从想法到废弃
插件的生命周期，你要心里有数：
想法 → 开发 → 测试 → 发布 → 使用 → 维护 → 废弃
- 想法：确认这是个「值得固化的重复操作」
- 开发/测试：先手工跑通，再固化成插件
- 发布：打包、分发、让团队能装
- 维护：跟随实践迭代
- 废弃：过时了要能下线，别留着腐烂
每一步都有产出和检查点，别跳过「测试」就急着发布。
对 mcp-hub 来说，生命周期最大的意义在于：它不是一个「写一次就完」的脚本，而是一个要长期跟随团队变化迭代的组件。今天支持三个 MCP 服务，下个季度可能支持十个；某个服务下线了，要有能力把它从 hub 里干净地摘掉——这就是「废弃」这一环的价值。
什么时候该做成插件
判断标准，问三个问题：
- 要反复用吗？ 一次性的东西不值得
- 要分发吗？ 只自己用，技能就够了
- 要配置吗？ 有参数、有环境差异，才需要插件的「配置层」
三个里有「要分发」或「要配置」，就值得升级成插件。
mcp-hub 三条全中：它是团队反复用的、要分发给全员的、且涉及大量配置（每个 MCP 服务都有自己的地址、凭据、暴露的工具）。所以它天然该做成插件，而不是一堆零散技能——这是本课选择它做贯穿项目的原因。
一个插件该长什么样
以「部署」插件为例：
# 部署插件
描述：把当前服务部署到指定环境
用法：/deploy --env production --version v1.2
配置：
- TARGET_HOST：目标主机
- SSH_KEY：密钥路径
步骤：
1. 校验版本号存在
2. 构建产物
3. 备份旧版本
4. 上传并切换
5. 验证健康检查
有描述、有用法、有配置、有步骤——这就是一个完整插件的骨架。
再看 mcp-hub 的第一版骨架会是什么样：
# mcp-hub 插件
描述：集中接入、校验、分发团队的 MCP 服务
用法：/mcp-hub add <server-name> # 注册一个服务
/mcp-hub list # 查看已接入的服务
/mcp-hub validate # 校验全部配置是否可用
配置：
- MCP_HUB_DIR：服务清单存放目录
- MCP_HUB_REGISTRY：共享的服务仓库地址
步骤：
1. 读取服务清单（registry）
2. 逐条校验配置与凭据
3. 接入 Claude Code 的 MCP 配置
4. 汇报接入结果与不可用项
现在你看到的可能只是几个 /mcp-hub 命令，但后面 15 节里，它会一点点长出接入外部 MCP、优化成本、团队共享、生产级交付这些能力。这一节先把这个骨架放在脑子里。
落地练习：画出 mcp-hub 的三层 + 生命周期
这一节不用写代码，动笔画出 mcp-hub 的「地图」就行——这是接下来每一节都会用到的定位工具。
跟着这三步走：
- 打开一个空文档，写下「mcp-hub」标题，下面画出三层架构（描述层 / 指令层 / 入口配置层），每一层填一句 mcp-hub 对应要做什么
- 在下面画出生命周期链条（想法→开发→测试→发布→使用→维护→废弃），标出你觉得 mcp-hub 现在处于哪一步
- 用「三个问题」检查一遍：mcp-hub 是否值得做成插件？三条各打一个勾或叉
你会怎么判断做对了？——如果你能把这张图对着同事讲清楚「mcp-hub 分几层、为什么值得做插件、现在走到哪一步了」，而且对方不用追问就听得懂，就算过关。
卡住了怎么办？ 三层分不清？就照抄上面的骨架示例，先把每层对应的一句话填进去。生命周期标不准？先标「开发」就好，后面学到发布时你会更清楚。
常见坑：把「架构」当成「文件夹结构」
新手最容易踩的坑，是以为「架构三层」就是要建三个目录、写三份文件。于是 mcp-hub 一上来就 description/、steps/、config/ 三个文件夹，里面却都是空壳。
架构讲的是每个能力在逻辑上归谁管，不是物理上的目录划分。三层可以混在同一个文件里，也可以按别的方式组织。先想清逻辑分层，再决定怎么放文件——顺序反了，目录会先长出来，逻辑却还是糊的。
小结
- 插件 = 技能的安全「正式升级版」，可分发的完整能力组件
- 三层架构：描述 / 指令 / 入口配置
- 生命周期：想法→开发→测试→发布→使用→维护→废弃
- 要分发、要配置时才做成插件，否则技能够用
- 本课的 mcp-hub 三条全中，所以它天然该做成插件
下一节，动手写你的第一个插件。