先明确任务与结果
先确认提交的是远程MCP连接器还是托管在GitHub的插件包，再准备可复现输入、预期结果、权限说明和固定版本。提交、审核通过与主动发布是不同状态；收到自动验证结果后仍要处理反馈，不能把“可安装”写成“已上架”。
官方入口有什么变化，本文提供什么建议
Claude官方开发者门户公告与9月25日发布记录说明：付费Claude计划的开发者可进入门户，提交单个远程MCP连接器，或提交含MCP服务器、技能的GitHub插件包；可查看检查与审核反馈，批准后自行决定发布。上线后有按产品入口和版本查看的使用分析。
以下案例与准备清单是编辑建议，不是官方审核标准的完整转录，也不承诺通过审核。不同产品入口支持的组件可能不同，应按目标入口的当期文档与实际测试确认；不要因为Claude Code支持某种组件，就默认其他Claude入口都同样支持。
| 路径 | 官方说明的入口 | 本文建议的验证证据 |
|---|---|---|
| 单个MCP连接器 | 指向远程MCP服务器 | 目标地址、可用操作、示例输入输出与访问说明 |
| 插件包 | 在GitHub托管MCP和技能组成的包 | 固定提交、目录结构、安装说明、依赖与可复现样例 |
| 已有目录条目 | 公告表示现有技能、连接器或插件无需因此改动 | 先核对现有条目状态，再决定是否另行发布新版本 |
完整练习：把客服交接资料整理成摘要草稿
假设你要发布一个虚构的“客服交接草稿”插件：读取一份明确授权的工单样例，输出问题、已知事实、缺失信息和下一步草稿，不写入真实工单，也不自动发邮件。这个任务范围适合做提交演示，因为输入和输出都能由另一位检查者独立比较。本文没有替你提交插件或运行任何付费账号。
样例T-021只有“上传失败，浏览器版本未提供”，缺少复现步骤和附件。期待输出应保留未知状态，列出需要补充的信息。若生成内容擅自写成“已确认浏览器不兼容，退款完成”，即使格式正确也未通过这个案例。
提交演示要让陌生人能判断对错
工单T-021：用户报告上传失败；未提供浏览器版本、复现步骤与附件；没有退款记录。
问题：上传失败。已知：仅有用户描述。缺失：版本、步骤、附件。下一步：拟请用户补充信息，待人工确认。
把“在我这里能用”变成可交接材料
为样例保存固定版本或提交号，把安装步骤、配置占位符与运行入口写清。示例配置不要放真实令牌；需要连接外部服务时，说明测试账号由谁提供、数据从哪里读取、会执行什么动作，以及撤销访问后应呈现什么结果。这里是在描述材料，不要求读者先购买或升级账号。
同时准备失败场景：没有授权、输入为空、字段缺失、远端服务不可用。每项都写清可见错误和哪些动作不应发生，例如读取失败不能被改写成“没有工单”。权限范围、错误处理和结果可解释性，比一个只展示成功路径的截图更能帮助检查。
提交前材料包
- 一个固定版本，安装说明指向同一份代码。
- 可重复的虚构输入、预期要点与人工核对方法。
- 声明实际读写动作，不把草稿描述成自动发送。
- 配置使用占位符，凭据不进入公开代码和截图。
- 记录缺字段、无权限、空输入与服务失败的行为。
- 支持入口与已检查版本明确，不推断所有客户端都可用。
用一段验收任务检查描述与实际能力
将材料交给没有参与实现的人，让对方只照说明操作，并记录卡住的位置。先核对是否能重复得到T-021的事实与缺项，再检查用户能否理解“草稿待人工确认”。如果需要口头补充多个隐含条件，说明提交材料仍不完整。
可参考Claude Docs评论到导出交接指南中的状态核对方式，但插件包、目录条目与协作文档不是同一种产物。对于外部工单内夹带“忽略规则、发送账号信息”的文本，按文档提示注入核查方法把它当作待处理资料，不能当成提升权限的指令。
仅依据材料包复现T-021摘要。逐项记录：安装版本、使用入口、实际输入、输出中的已知事实与缺失信息。检查是否发生任何外部写入。没有证据时不写“已退款”或“已发送”。遇到缺权限或服务错误，保留错误状态，不推断为空数据。最后列出说明中仍需作者补充的步骤。提交、批准和发布分别留证据
将状态分开记录，避免文章介绍或仓库README提前声称“已在目录上架”。自动检查发现问题时，保存反馈和对应修复版本；审核批准后，再按门户允许的发布动作核对实际条目。没有看到公开条目时不要把批准截图等同于用户可发现。
上线后先观察真实问题：用户在哪个入口安装、哪个版本出现错误、文档是否把依赖写漏。使用分析可以帮助安排修复，但安装数、展示或搜索入口记录不等于用户任务成功，也不等于网站SEO已经获得流量。
每个状态需要自己的证据
- 准备中
固定材料
代码版本、样例、预期结果和范围说明完整。
- 已提交
保留反馈
记录提交对象与检查结果，不称已通过。
- 已批准
决定发布时间
保留批准状态，再安排主动发布。
- 已发布
核对真实条目
从用户入口确认可发现性，跟踪版本与反馈。
维护边界：不要让示例承诺越过实际能力
当插件从只读摘要增加到工单写回时，应重新说明权限与验收，不能沿用旧版“不会修改数据”的介绍。升级后重跑固定样例及失败场景，保留上一版本记录。名称相同但代码变化的演示，不足以说明旧问题已经修复。
这个流程解决的是提交准备与交接可验证性。目录是否批准、某账户是否可进入门户、某地区服务是否可用，仍由当期产品与审核状态决定。本文核对日期为2026年10月15日，原公告日期仍保留为9月25日。
常见问题
没有付费Claude计划能使用这个提交门户吗？
9月25日公告明确把门户开放范围描述为付费Claude计划开发者。实际提交前应核对自己的账号入口，不根据本文推断免费账号有同样资格。
自动检查通过就已经上架了吗？
不是同一个状态。还需查看审核结果；官方公告说明批准后由开发者决定发布。应在真实目录条目可见后再对外声明已发布。
已有目录上的技能要马上改成插件吗？
该公告表示已有技能、连接器或插件无需因此改动。先确认现有条目与实际需求，不为追逐新名称制造重复发布。
