写 MCP 的，终于能看见插件被谁装了

一个 MCP 服务能在自己电脑上跑通，和它真的被别人装上、用下去，中间差的往往不是一行代码。

差的是安装说明，权限边界，版本变了谁负责，还有那个有点扎心的问题，装完的人到底有没有用。

9 月 25 日，Claude 给付费计划开发者开放了插件目录提交门户。官方公告讲得很直接。一个远程 MCP 服务可以单独提交，也可以把 MCP、Agent Skills 打成一个插件包放到 GitHub。提交后有自动验证和安全扫描，能看审核反馈，过了以后由开发者自己决定什么时候发布。插件上线后还能看到按产品界面、版本统计的安装量，以及页面被怎么搜到。

好家伙，终于不只是「我这里能跑」。

这条更新真正有意思的地方，是它把一堆散在仓库里的提示词、脚本和连接器，推到了一个更像产品的位置。不是把 README 写长一点，而是开始面对分发、审查、版本和反馈这四件麻烦事。

先别急着把所有东西都打成插件

很多人会把「可复用」理解成「该上架」。我自己的判断没这么乐观。

如果一段 Skill 只服务一个仓库，规则紧紧绑着团队的目录、命名和发布流程，留在仓库里通常更舒服。上下文就在旁边，改动跟着代码走，也不用给陌生用户解释一堆前置条件。硬拆出去，最后大概率变成一份谁都不敢升级的配置文件。真的就是一声叹息。

反过来，下面三种情况就该认真考虑插件化了。

第一种，是同一个能力已经跨项目、跨团队重复出现。比如每个项目都要接同一套知识库查询、同一套设计规范检查，或者同一套发布前验收。复制粘贴的次数一多，维护成本会像积灰一样悄悄长出来。

第二种，是你的能力不只有一段说明文字。它同时带着工具调用、默认配置、检查步骤和失败时的退路。此时把它当成一个完整交付物，会比在群里扔四个链接靠谱得多。Claude 的插件包可以组合 MCP 和 Skills，Claude Code 里还可以带 commands、hooks、agents、LSP。这个边界已经不是「一段好 prompt」了。

第三种，是你确实需要知道它有没有被采用。官方这次给的是安装量、目录浏览和搜索词。它们不能证明任务做成了，却能先回答一个很朴素的问题，用户到底看没看见你做的东西。没有这层信号，插件作者很容易在自己的终端里自嗨到天荒地老。

官方示意图里把提交、安全扫描、审核和发布拆成连续状态。这个顺序比一张市场首页更值得开发者看。

真正该补的是三份交付物

这次入口开了，不代表把仓库丢上去就万事大吉。官方的自动验证和安全扫描很重要，但它不是替你接管后续维护的魔法盾牌。

我会先把下面三样东西补齐，再考虑点提交。

一份能力合同。 用一句人话写清楚插件替谁完成什么任务，也把它会读什么、写什么、连到哪里写清楚。一个插件只解决一个主问题，通常比塞进十个半成品功能更容易安装，也更容易排错。MCP 第一次出现时总容易被说得很玄，它其实就是让模型按约定访问外部工具或数据的连接方式。连接得越多，权限账就越要先算。

一份可重复的安装与验收说明。 别只放一张成功截图。把依赖、环境变量、最短安装路径、一个预期输入和一个可验证输出写出来。若需要 API key，就说明它保存在哪里。若网络断开会退化，也提前讲明白。用户第一次安装时最怕的，不是失败，而是失败后只看到「something went wrong」。这种报错，程序员看了都想把电脑合上。

一份发布后的观察表。 官方已经提供安装和发现信号，自己的项目还应补两个更贴近任务的指标。首次运行是否成功，和用户在哪一步退出。前一个发现安装摩擦，后一个发现任务设计是否把人绕晕。这里不需要摆一桌大屏仪表盘，先把数据定义写在 README 里就够。棒棒的，至少以后知道该改哪里。

官方示意的安装、版本与目录漏斗数据，正好说明发布后还要看什么。

先在陌生环境里把它装一遍

一个很朴素的判断办法，是把自己从作者的位置挪开。

想象拿到插件的人不知道你的目录结构，不认识你的缩写，也没有你电脑里那些「早就装好了」的依赖。把仓库克隆到干净环境，从安装命令走到第一次成功输出。中间每一次需要口头解释的地方，都是说明、默认配置或错误提示欠的一笔债。

这个测试不需要伪装成大规模压测。找一个同事，或者用一个隔离目录按新用户的路径走一遍就够。重点盯三件事。

一是它什么时候需要凭据。最差的体验不是要求登录，而是用户跑到一半才发现权限不够。提前提示权限用途，给出最小权限范围和撤销方法，至少让人能判断是否值得继续。

二是它失败时留下什么。网络不通、服务端返回异常、缺少可执行文件，这些都不是罕见事故。错误信息最好把下一步说清楚，比如缺少哪个配置、该检查哪一项，而不是给人一个模糊的失败码。很多插件的流失，并不发生在能力不行，而是发生在第一次安装后的两分钟里。

三是升级会不会把旧工作流撞翻。插件一旦进入多人环境，版本号就不再是装饰。哪怕第一版只维护一条更新记录，也应该标出行为变更、兼容性和回退方法。用户不是反对更新，他们只是讨厌周一早上打开终端，发现昨天还能跑的流程突然失忆了。

把这轮陌生环境测试做完，再回头看提交门户，顺序就很清楚了。门户负责帮你把合格的东西送进目录，它不负责替你把一团私人习惯收拾成公共产品。这个活儿绕不过去。

安全扫描不是权限外包

这里有个很容易被一笔带过的边界。

Claude 的中文帮助页明确提醒，本地 MCP 服务器的权限和电脑上其他程序一样。也就是说，目录审核、安全扫描、品牌认证这些步骤能提高门槛，但不能替安装者判断一个工具到底该不该碰到本地文件、公司知识库或生产环境。

所以插件的第一版，权限越窄越好。只读就别申请写入，只连一个服务就别顺手把所有账号都接进来。把最小权限做进去，不是为了显得谨慎，是为了以后出了问题还能看清责任边界。要不然模型替你干了活，收拾残局的还是人，厉害了。

这也是为什么我不建议把「安全扫描通过」写成营销话术。扫描能帮你及早发现问题，不是永久担保。一个值得被安装的插件，应该让使用者一眼知道它会做什么，也一眼知道它不会做什么。

现在怎么选

如果你已经有一个稳定的远程 MCP 服务，路线很直接，按单独 connector 去提交。

如果你的能力依赖一组 Skills、MCP 和固定工作流，把它整理成插件包，用公开仓库做版本源。这时提交门户的价值最大，因为验证、审查、发布和后续数据终于接起来了。

如果它只是某个仓库里的临时约定，或者还说不清使用者是谁，先别着急打包。把任务边界收窄，找两三个真实使用者跑一遍，再决定要不要走到目录里。不是所有脚本都要有产品经理的命运，很多时候让它安静待在仓库里反而更好。

我很喜欢这次更新里最不显眼的一点，发布后可以看版本和搜索词。它提醒我们，Agent 时代的分发不该停在「我写出来了」。更难也更有价值的部分，是有人装得上、敢授权、能完成任务，然后你知道下一版该往哪里修。

你手里有没有一个已经在团队里反复复制的 Skill 或 MCP？如果要把它做成插件，最担心的是安装、权限还是后续维护？