Claude 开放插件提交门户:发布前多了一段审核与验证

把一个技能文件、远程 MCP 服务或两者的组合放到 GitHub，并不等于它已经成了 Claude 目录里的可安装产品。Claude 在 9 月 25 日宣布的变化，是为这段“从做出来到被找到”的路补上了提交门户：开发者可以提交插件、查看审核状态和反馈；上线后再看安装与发现数据。

这不是多了一个发布按钮。代码可以准备好，自动检查可以通过，审核可以获批，发布时间仍由开发者决定；用户是否能添加、在哪个 Claude 端工作，则还在更后面。新增加的是一条可追踪的目录发布流程，而不是一张“安全、可用、所有人都装得上”的通行证。

这次开放的是什么

公告把插件定义为 Claude 的第三方扩展载体：它可以打包 MCP connector、Agent Skills，或两者都有。新的 directory submission portal 面向付费 Claude 计划的开发者开放，提供两条提交路径：一条是指向远程 MCP server 的单一 connector；另一条是把 MCP servers 和 skills 组合为 plugin bundle，托管在 GitHub 后提交。对于 Claude Code，包里还可以有 LSP、commands、hooks 和 agents。

“可以提交”只描述进入目录流程的资格，不等于每一种组件都会在每一个 Claude 产品端以相同方式加载。官方构建文档提示，Chat、Cowork 与 Claude Code 会加载插件的不同部分。选择结构应先从目标使用端倒推：只需让 Claude 接到外部服务，可能只需 connector；要表达固定工作流，才考虑 skills；需要对话内交互界面时，MCP App 是可选项，而非上架必需项。

四个状态，别压成一个“已发布”

自动校验和安全扫描的作用，是让提交者尽早发现问题；它们没有被官方描述成对第三方服务、数据处理、OAuth 授权或每次工具调用结果的背书。审核也是目录治理的一环，不替代开发者对认证、权限范围、故障处理和持续维护的责任。

上架前，先把“在哪里用”验一遍

官方的构建顺序很清楚：布局和清单、编写 skills、实现 MCP server、可选地增加交互 UI、按各目标端测试，然后才是提交和维护目录条目。它还写明，目录里的插件会先经过 Anthropic 检查；而已列在目录中的 skill、connector 或 plugin 不需要因这次变化而改造。

提交前可留三项小记录：目标是 Chat、Cowork 还是 Claude Code；插件实际包含哪些部件；每个目标端分别完成了什么测试。收到审核反馈时，团队讨论的就是一个可回放的发布版本，而不是笼统地问“为什么插件不工作”。发布之后，门户提供的安装、产品端与版本使用情况，以及目录页面浏览和搜索来源，才适合用来安排修复或迭代；这些是运营线索，不是产品效果、数据正确性或商业价值的自动结论。

来源

• Claude《Build plugins for Claude》，2026-09-25：核验提交门户、提交形态、自动校验／安全扫描、审核、发布决定与发布后分析。
• Claude Documentation《Build for Claude》，2026-09-28 查阅：核验插件组成、各产品端差异、构建／测试顺序、目录检查和已存在目录条目的过渡说明。