Claude 插件怎么提交?两条路径与审核流程

9 月 25 日，Anthropic 发布了一篇面向开发者的公告：Claude 插件可以通过新的目录提交门户进入审核流程。开发者能在门户中查看校验与审核反馈，通过审核后再决定何时公开发布。原文

对准备做插件的人，这个变化很具体：提交入口、审核节点和上线后的使用数据有了明确的位置。官方目录发布文档目前要求提交者使用付费 Claude 计划；团队组织还需满足相应角色要求。目录发布文档

但开始动手前，最好先回答一个更基础的问题：你要给 Claude 增加什么能力？

连接产品，还是教它工作流

官方把插件描述为可以包含 MCP 连接器、Agent Skills，或两者的组合。原文

如果 Claude 需要访问你的产品、数据或动作，核心部件是 MCP 连接器。它指向你托管的远程 MCP 服务器。Claude 的构建文档也把连接器放在“接入产品或数据”的位置。构建文档

如果你要让 Claude 按某套方法完成工作，Skill 负责描述步骤、默认选择，以及合格结果是什么。同一份构建文档把 Skills 放在“教授工作流”的位置。

只做远程连接器可以作为单个连接器提交；只做 Skill 则需放进插件包，不能把 Skill 当成独立的目录提交类型。两者也可以组合在同一插件包里。目录发布文档

需要交互式界面时，还可以评估 MCP Apps；它是可选能力，不能由“用了 MCP”直接推导出“已经有 App 界面”。构建文档 MCP 扩展说明

提交有两条路径

公告给出的第一条路径，是提交单个 MCP 连接器：向门户提供远程 MCP 服务器地址。

第二条路径，是提交托管在 GitHub 上的插件包。它可以组合连接器与技能；在 Claude Code 场景下，插件还可包含命令、hooks、agents、LSP 等组件。原文

这里有个实际差别：官方目录发布文档要求，插件包对应的 GitHub 仓库在正式上架前公开；单个远程连接器提交的是服务器 URL。若插件包引用了你运营的远程 MCP 服务器，文档还要求把该服务器作为连接器单独提交，以获得连接器列表及其健康、工具使用数据。目录发布文档

这意味着，选路径不能只看“哪个按钮更快”，而要看你交付的是一个远程服务，还是包含工作流和其他组件的完整插件。

审核通过，不等于立刻上线

新门户会在提交时自动校验并进行安全扫描。开发者可以查看审核状态、扫描结果、反馈和建议修改。通过审核后，再由开发者决定何时在 Claude 目录发布。原文

这几个节点要分开：提交成功只说明资料进入流程；自动扫描是检查环节；审核通过才进入可发布阶段。原文没有承诺固定审核时长，也没有给出“扫描通过即自动公开”的说法。

上线后，插件开发者可查看按产品界面和版本划分的安装情况、目录列表展示次数，以及引导用户发现它的搜索词。这些信息能帮助维护版本和介绍文案；它们不是收入、留存或转化率的保证。原文

一个插件包，也要按使用界面测试

官方支持矩阵明确写着，Chat、Cowork、Claude Code 加载同一插件包时，组件支持并不完全相同。例如，agents 在 Chat 中会被忽略；本地 MCP 服务器不会在 Chat 中运行，而远程服务器的连接方式又有各自要求。平台支持矩阵

所以，做插件时要先写下用户准备在哪个界面使用它，再用那个界面验证关键流程。不能仅凭 Claude Code 中运行正常，就推断 Chat 与 Cowork 中的表现相同。

原文还提到，跨 Claude 与 Claude Code 的统一发现体验会在“随后几周”逐步推出。已经在目录中的 skill、connector 或 plugin 暂时不需要为了这次公告立即改动。这是当时的产品计划，不宜改写成所有界面已经同步完成。原文

给开发者的实际顺序是：先确定连接器和 Skill 的分工；按提交类型准备服务器或插件仓库；在目标界面测试；再根据门户的校验和审核反馈修正。上线后，才用实际使用数据决定下一个版本要改什么。