别一上来就写插件，先手工跑通
写插件最大的误区是「直接开写代码」。正确的做法是先把逻辑手工跑通，再固化成插件。逻辑都对不上，插件写得再漂亮也没用。
这一节，从一个真实需求出发，写你的第一个插件——我们就用 mcp-hub 的第一个功能来练手。
选一个要固化的操作
先选一个你「反复做、规则固定」的操作。对 mcp-hub 来说，最该先固化的不是「接入十个服务」，而是**「接入一个服务的完整流程」**——这个流程一旦稳定，剩下只是重复。
以「接入一个外部 MCP 服务」为例，每次都要做：
- 确认服务的地址 / 启动命令
- 检查它要什么认证（API key、token 等）
- 校验服务能正常返回
- 把它写进 mcp-hub 的服务清单
这套操作是固定的，值得固化。一次把「接入一个」跑通，比一次想「接入所有」靠谱得多。
/mcp-hub add——把「手工接入一个 MCP 服务」的四步，固化成一个命令。你先手工跑通一次真实接入，再把它封装起来。下一节我们继续做打包发布。第 1 步：手工把逻辑跑通
先别写插件。你就用 Claude Code 手工执行这套操作，把「每一步到底怎么做、输出什么」确定下来：
帮我接入一个 MCP 服务：
1. 检查服务地址是否可达（curl 试一下）
2. 看它需要什么认证
3. 确认它能返回一个可用的工具列表
4. 把结果写进 mcp-hub 的服务清单
把每一步的命令和期望输出记下来。这是插件的「原料」。
对 mcp-hub 来说，这个「原料」就是你以后判断 /mcp-hub add 做得对不对的基准——手工跑通一次，你就知道正确结果长什么样，后面才知道自动化的版本有没有做对。
第 2 步：写成插件
把上面这套逻辑，整理成插件：
---
description: mcp-hub 接入一个外部 MCP 服务
---
# mcp-hub add
触发：注册一个新 MCP 服务时执行。
参数：
- server-name：服务名
- config：服务的地址 / 启动命令
步骤：
1. 检查服务地址可达（`curl -sI <url>`）
2. 读取并校验认证要求（API key / token）
3. 调用服务，确认返回可用的工具列表
4. 写入 mcp-hub 服务清单（registry）
输出规范：
按「已接入 / 接入失败 + 原因」汇报，失败的给出修复建议。
这份定义本身，就够 Claude Code 照着去执行了。
第 3 步：让 AI 帮你写，然后审
其实，你甚至可以让 Claude Code 帮你把插件搭出来：
帮我把「接入一个 MCP 服务」这套操作整理成一个插件，
包含描述、参数、步骤、输出规范，放到 mcp-hub 的标准目录。
要求：能处理认证、能校验服务可用性。
它生成后，你要审查：步骤对不对？命令准不准？输出够不够清晰？AI 起草、你把关，这是生产级开发的基本姿势。
审查 mcp-hub 时，重点盯三件事：
- 认证有没有被安全处理——有没有把密钥直接写死在步骤里
- 失败路径有没有覆盖——服务不可达时，有没有给「可行动的修复建议」
- 写清单的格式稳不稳定——团队后来要读它，格式乱了对不齐
第 4 步：在真实任务里验证
插件写完，别急着宣布成功。真跑一次：
- 用一个真实的 MCP 服务去调
/mcp-hub add - 看它是否正确地「检查可达 → 校验认证 → 写入清单」
- 有偏差就回插件定义里改
一次改一处，改完再验证。
对 mcp-hub，最狠的验证是故意用一个坏的地址去跑一次：如果它能像手工排查那样，报出「地址不可达」而不是报一堆乱码，说明失败路径做对了。
开发插件的心法
- 先逻辑后封装：手工跑通，再固化成插件
- 最小可用：第一版只做核心，别堆功能
- AI 起草、人审查：让 AI 搭，你负责把关
- 真实验证：在真实任务里跑，别只看文本
落地练习：给 mcp-hub 做「接入一个」的最小版本
这一节不追求功能全，只求把 mcp-hub 的 /mcp-hub add 做出一个最小可用版。
跟着这三步走：
- 手工跑通一次「接入一个外部 MCP 服务」，把步骤和输出记下来（就按上面的手工 prompt 来）
- 让 Claude Code 帮你把它固化成
/mcp-hub add插件定义，你审查认证、失败路径、写清单格式三件事 - 用一个真实服务跑一次，再用一个坏地址跑一次，验证两种路径
你会怎么判断做对了？——正常地址能跑通、坏地址能报出「可行动的修复建议」（而不是乱码），而且步骤里没有硬编码任何密钥，就算过关。
卡住了怎么办？ 找不到真实 MCP 服务？先用一个本地小服务（比如一个返回 JSON 的本地接口）顶替，重点是流程跑通。Claude 生成的插件审查不过关？不要自己重写，直接把问题丢回给它改，你来复审。
常见坑：让 AI 全权代劳，自己不做「原料」
新手常见坑是：把「让 AI 帮我写插件」做成了「让 AI 全权搞定」，于是自己从不手工跑通逻辑，也不知道正确输出长什么样。结果 AI 写的插件看似完整，跑起来却对不上真实情况。
插件质量的天花板，取决于你对「正确逻辑」的理解——而这个理解只能来自你亲手跑通一次。mcp-hub 的 /mcp-hub add 尤其如此：你亲手接通过一次真实服务，你才知道「可达检查」到底该用什么命令、报错该长什么样。别跳过「原料」这一步，它是整条链的起点。
小结
- 先手工跑通逻辑，再固化成插件
- 四步：跑通逻辑 → 写成插件 → AI协助+人审查 → 真实验证
- 最小可用，别一上来堆功能
- AI 起草、人审查，生产级基本姿势
- 本节的
/mcp-hub add就是 mcp-hub 的第一个功能
下一节，学插件的打包、发布与分发。