ChatGPT Custom GPT 迁移到 Plugin 完整操作指南

Custom GPT 的退场已经进入倒计时。官方给出的迁移路径是把现有的 GPT 转成 Plugin，但这条路径并不是一键完成：Instructions、Knowledge files、Connected apps 会被自动带走，Custom Actions、模型选择、下划线草稿、历史会话则不会。对于只用指令和资料文件搭起来的 GPT，迁移基本是点几下按钮的事；对于调用外部 API 的 GPT，迁移等于一个小型开发项目。这篇教程面向正在创建和运营 Custom GPT 的开发者和业务用户，按准备、迁移、重建、验证四个阶段把流程讲清楚。如果你还没接触过 ChatGPT 的自定义能力，可以先看看 ChatGPT 的基础用法。

准备工作

迁移是单向操作，按下确认之后无法回退。所以在动手之前，先把下面几件事处理完，能省掉大量返工。

确认自己的迁移时间窗口

官方公布的日程里，所有日期都附带了「可能变更」的说明，实际执行时要以账号内通知和官方 FAQ 为准。按当前公开的节奏，大致分成几个节点：

面向管理员的公告先行发布，Enterprise 与 Edu 工作区会先收到通知。
迁移入口和用户横幅按工作区分批开放，属于目标时间而非保证时间。
新 Custom GPT 的创建通道关闭，但已存在且未迁移的 GPT 仍可继续编辑。
标准下线日到来后，GPT 本体和 GPT 页面都无法再访问。
已获批延期的 Enterprise 工作区适用更晚的下线日，前提是延期申请通过。

这套日程已经调整过一次，早期报道里流传的日期是旧版本。核对时间时不要依赖第三方文章，直接看官方 FAQ 和产品内通知。Edu 工作区以各自收到的通知为准。个人账号（Free、Plus、Pro 等）需要额外留意：官方说明迁移影响所有 ChatGPT 套餐，但个人账号的下线日是否与企业版一致，目前没有明确表述，只能以产品内通知为准。

把草稿发布出去

迁移只处理最新一个已发布版本。如果某个 GPT 花了几周时间修改但一直停在草稿状态，这些改动不会被带走。建议在创建通道关闭之前先把草稿发布，发布范围不必设为公开，只要处于已发布状态即可。

整理 Custom Actions 清单

把每个 GPT 调用的 API 端点、认证方式、所需权限范围逐条写下来。这份清单决定了迁移之后需要重建的工作量，也是估算工时的依据。

记录模型设置和对话开场白

这两项都不在自动迁移范围内。把当前选择的模型、开场白文案、共享设置抄下来，迁移完成后重新配置到 Skill 的指令文本或 Plugin 的设置里。

确认迁移权限

能执行迁移操作的只有 GPT 的创建者或管理员，且对象必须是已发布的 GPT。权限不符时，界面上不会出现迁移入口。

操作步骤

第一步：从 My GPTs 进入迁移入口

迁移入口位于 My GPTs 页面下的 Created by me 列表，选中目标 GPT 后可以看到 Migrate to plugin 选项。这个按钮的出现时间因账号和工作区而异，属于分批开放。如果暂时看不到，等待产品内通知即可，不要尝试通过其他路径绕过。

第二步：核对 migration details

选择迁移后，界面会展示一份迁移明细，说明哪些内容会去往何处。这一步需要逐项确认三件事：

Instructions 转换成的 Skill 内容，是否包含已发布版本中最新的指令文本。
Knowledge files 是否全部被纳入 reference files 的迁移范围。
Connected apps 是否作为 Apps 被正确继承。

确认无误后，按界面提示创建 Plugin。

第三步：测试迁移后的 Skill 与资料文件

迁移完成后，原来的 GPT 会变成只读状态，无法再编辑，但在下线日之前仍然可以使用。这给了一个对照验证的窗口：把原 GPT 和新建的 Plugin 并排打开，用同一批问题分别提问，比较回答是否一致。重点观察资料文件的检索和引用行为，官方明确提示这部分的表现可能与原来 GPT 的 Knowledge 机制不同。

第四步：重建 Custom Actions

Custom Actions 不会迁移。官方给出的方向是：用受支持的连接器替代，或者改写成自定义 MCP 连接，并在团队切换之前完成测试。判断顺序如下：

先看现有的 App（受支持的连接器）能否覆盖原本需要的操作。
覆盖不了的部分，改写成自建的 MCP（Model Context Protocol）服务器。

重建连接可能涉及认证、权限范围、审批流程和安全审查的重新走一遍，而且重建后的连接不一定能完全复现原 Action 的全部功能，这一点要提前纳入预期。

第五步：把 MCP 服务器接入 ChatGPT

自建 MCP 服务器的接入流程大致如下：

在 ChatGPT 的 Settings 中找到 Security and login，开启 Developer mode。
进入 ChatGPT Plugins 页面，点击加号按钮，填入服务器 URL，注意要包含 /mcp 路径。
在普通对话和 deep research 中分别发送提示词，确认工具能被正确调用。

ChatGPT 只能连接远程的 HTTPS 服务器，传输方式为 SSE 或 Streamable HTTP。部署在内网、无法从公网访问的服务器，需要使用 Secure MCP Tunnel 打通。另外，一些较早的教程里提到的设置路径已经和当前界面不一致，按实际界面为准。Developer mode 对套餐的具体要求，官方文档中没有明确说明。

第六步：补齐共享设置与开场白

不使用 Custom Actions 的 GPT，走到这一步基本就结束了：把共享范围和对话开场白在 Plugin 侧重新配置一遍即可。使用 Custom Actions 的 GPT，则需要等第五步的联调通过之后再收尾。

一个完整示例

下面以一个「内部知识问答 GPT」为例，走一遍从准备到上线的完整流程。这个 GPT 的特点是：只用 Instructions 和 Knowledge files，没有接任何外部 API。

准备阶段。打开这个 GPT 的编辑页，确认它处于已发布状态而不是草稿。把当前的 Instructions 全文复制到一个文本文件里备份，把上传的 Knowledge files 列一份清单，记录文件名和用途。因为这个 GPT 没有 Custom Actions，清单里这一栏留空。同时记下当前选择的模型和配置好的开场白。

迁移阶段。进入 My GPTs，在 Created by me 里找到它，选择 Migrate to plugin。在 migration details 页面逐项核对：Instructions 是否是最新版本、Knowledge files 是否全部列出、Connected apps 是否为空（本例中本来就没有）。确认后创建 Plugin。

验证阶段。原 GPT 此时变为只读但仍可用。准备五个有代表性的问题，分别向原 GPT 和新建的 Plugin 提问，对比回答。如果发现 Plugin 引用资料文件的方式和原来不同，回到 Skill 的指令文本里，把「应当参考哪些文件」「回答应当采用什么格式」写得更明确一些。

收尾阶段。在 Plugin 侧重新设置共享范围和开场白，把迁移完成的消息同步给团队成员，并提醒他们旧链接的行为变化。

如果这个 GPT 带有 Custom Actions，流程会在验证阶段之后多出一整条支线：先判断现有 App 能否替代，不能替代的按 MCP 服务器重建，实现 OAuth 2.1 授权流程，再走一遍工作区审批，最后在对话中实测工具调用。

注意事项

迁移范围的分界线

把迁移明细整理成一张表，判断起来更直观：

项目	是否迁移	迁移后的形态
Instructions	迁移	Plugin 内的 Skill
Knowledge files	迁移	作为 reference files 复制
Connected apps	迁移	Plugin 的 Apps
Custom Actions	不迁移	用现有 App 替代或重建为 MCP 服务器
所选模型	不迁移	Enterprise 下适用企业默认值
草稿与未发布编辑	不迁移	仅最新已发布版本参与迁移
历史会话	不迁移	需要的话提前导出留存
开场白与共享设置	不迁移	在 Plugin 侧重新配置

Plugin、Skill、Apps 的关系

迁移目标的结构和 Custom GPT 不一样，理解这一点能避免配置时找错地方。Plugin 是一个容器，用来把 Skill 和 Apps 打包在一起，同时也是跨 ChatGPT 与 Codex 的发现单位。Skill 承载可复用的指令、示例、辅助文件和代码，实体是一个包含 SKILL.md 的文件夹。Apps 负责连接外部服务，对应原来的 Connected apps。Skill 可以引用资料文件，这些文件就是 Knowledge files 迁移后的落点。

Skill 的创建方式有三种：通过对话创建、通过编辑器创建、从本地上传。部分账号中会预置一个用于创建 Skill 的 Skill。

MCP 服务器的认证要求

带认证的 MCP 服务器需要实现符合 MCP 授权规范的 OAuth 2.1 流程，具体包括：公开 /.well-known/oauth-protected-resource、授权服务器支持 PKCE（S256）、MCP 服务器侧校验令牌的签名以及 iss、aud、exp、scope 等字段。只读且匿名的模式也被允许，但如果要暴露客户专属数据或写入类操作，应当要求用户认证。

原来的 GPT Actions 可以选择 API 密钥认证，迁移到 MCP 之后认证方式需要重新设计，这往往是整个迁移工作中最费时的部分。API 密钥认证的 Action 能否以非 OAuth 的方式直接迁移，目前没有明确说明。

工作区层面的运营差异

在工作区中运营 MCP 应用时，有几个行为需要提前知道（相关说明带有 beta 标记，后续可能变化）：

管理员首次批准应用时，当时的工具定义会被固定为快照，服务器后续的改动不会自动同步。
如果服务端做了不向后兼容的修改，在管理员从 Workspace settings 执行刷新之前，工具调用可能持续失败。
Business 套餐下应用发布后无法更新，只能重建并重新发布；Enterprise 和 Edu 可以通过刷新更新，但新增的操作默认处于关闭状态。
Plugin 的安装状态和其中 App 的访问权限是两套独立控制。Enterprise 和 Edu 下新的 Plugin 与 App 默认关闭，Business 下 App 默认开启。因此可能出现「Plugin 装了但 App 用不了」的情况，验证时要用普通成员权限再走一遍。

不迁移会怎样

下线日之后，Custom GPT 会停止运行，并从 GPT 目录中移除。目前没有看到可以归档后恢复的说法。已经迁移的 GPT 链接，会对有访问权限的人重定向到对应的 Plugin，所以内部 Wiki 或手册里贴过的 GPT 地址，迁移之后有可能继续可用。迁移操作本身在下线之后仍然可以执行，只是那时 GPT 已经无法运行。对于业务上正在使用的 GPT，比较稳妥的做法是在下线日之前完成迁移和验证，避免中间出现无法使用的空档。

常见问题

看不到 Migrate to plugin 选项。迁移功能按账号和工作区分批开放，开放时间是目标而非保证。等待产品内通知即可。同时确认自己具备创建者或管理员权限，且目标 GPT 已经发布而不是停在草稿状态。

迁移后回答风格变了。原来选择的模型不会继承，Plugin 会使用目标环境的默认模型。资料文件的检索和引用行为也可能与原来的 Knowledge 机制不同。可以在 Skill 的指令文本里显式写明应当参考哪些文件、回答采用什么结构，用这种方式把输出拉回预期。

Plugin 装好了却连不上外部服务。Plugin 的安装和 App 的访问权限是分开控制的。Enterprise 和 Edu 下新 App 可能默认关闭，需要管理员启用并授予权限。

迁移难度怎么预估。难度基本由是否使用 Custom Actions 决定。只用 Instructions、Knowledge、Connected apps 搭起来的 GPT，官方工作流能承担大部分工作；带 Actions 的 GPT 则涉及 OAuth 2.1 与 PKCE 的 MCP 服务器实现、工作区审批、快照更新运维，工作量接近一个小型开发任务。建议在盘点阶段先把带 Actions 的 GPT 挑出来，把工时集中投在这些上面。

最后提醒一句：涉及套餐可用范围、功能开放时间、配额与价格的信息变动频繁，动手之前请以官网当前公布的内容和账号内的实际界面为准。