自定义 GPT 停用时间表：各套餐期限与迁移方案

自定义 GPT 是针对特定任务配置的 OpenAI ChatGPT 版本，计划于 2026 年 12 月 11 日停用，指定工作区的停用时间则更晚。如果公司正在依赖这些 GPT，应先保存指令和源文件，再按任务选择去向：可复用的方法迁到插件，需要持续积累的共享上下文放进 Project，自定义操作则要重新搭建集成。只有实际负责工作的同事能用上替代方案，迁移才算完成。

本文已于 2026 年 10 月 30 日对照 OpenAI 在线文档核实。 OpenAI 的停用常见问题现已列出标准停用日期和明确的例外情况。如果你收到的时间安排不同，以账号或工作区通知为准。

自定义 GPT 何时停用？各套餐的安排有何不同？

OpenAI 正在逐步停用各 ChatGPT 套餐中的自定义 GPT。这里要分清新建 GPT、编辑现有 GPT、获得迁移功能和 GPT 停止提供服务：这是几个不同的节点。

来源：OpenAI 的新建与编辑指南及停用时间表。统一的停用日期已经公布，但并非每个套餐都公布了各自的迁移功能开放日期。没有单独公布日期时，不要拿 Enterprise 的计划上线时间代替。

不能新建 GPT，不等于现有 GPT 已经不能用

看不到 Create 按钮，并不代表现有 GPT 已停止工作。在访问规则允许的前提下，OpenAI 允许继续使用，直到相应的停用日期。不过，迁移完成后，原 GPT 会变成只读状态，因此应先完成必要的修改。参见 OpenAI 现行编辑规则。

Enterprise 的相关节点包括：2026 年 9 月 11 日向管理员发送通知，计划于 9 月 22 日推出迁移功能，以及计划于 10 月 1 日向此前已选择延迟显示横幅的工作区展示横幅。这些是功能发布的目标时间，并不保证每个账号当天都能迁移。参见 OpenAI 的 Enterprise 时间表。

务必查清每个 GPT 是在哪个工作区创建的。即使同事用个人账号打开，一个在受影响 Enterprise 工作区内创建的公开 GPT，也会按该工作区的安排过渡。只记录使用者的订阅套餐，会漏掉这层依赖。

企业如何迁移 GPTs？先看要保住哪类工作

先保留有用的方法，再决定迁到哪里。不要因为清单里的每一项现在都有一个 GPT 链接，就把它们全部塞进同一种替代方案。

对于常见的企业工作流，我的建议是：

• **跨多个互不相关的商机使用的提案审核助手：**选插件。它的价值在于可复用的审核方法，以及经过认可的参考资料。
• **处理不断变化的需求说明、会议记录和草稿的客户助手：**选 Project。它的价值在于持续积累某个客户的上下文。
• **会修改其他系统记录的运营 GPT：**先盘点自定义操作。只有现成应用能完成所需操作时，才选择该应用；否则就要安排重建集成。
• **准备嵌入自有产品的企业助手：**评估 API 实现方案。OpenAI 明确表示，GPT 用于 ChatGPT 内部；需要嵌入产品的开发者应使用 API。

这些能力分别见 OpenAI 的插件指南、Projects 指南及 GPTs 指南。

可以把插件看作一本随身可用的操作手册，把 Project 看作一间工作室。手册说明如何审核提案，工作室存放某个客户不断更新的资料。至于真正修改业务系统的连接，则是另一项需要单独处理的组件。

团队负责人应优先处理那些一旦失效就会影响交付或业务运转的 GPT；构建者应优先处理集成和行为验证；工作区所有者应优先完成盘点，并确保用户能访问替代方案。如果只是使用别人创建的 GPT，需要的是创建者提供的替代方案说明，而不是一份迁移操作指南。

将可复用的方法迁到 ChatGPT 插件

ChatGPT 插件可以封装可复用的指令、参考资料和已连接的应用。**技能（skill）**是其中的指令组件；插件可以包含技能，而不必连接外部应用。OpenAI 的 ChatGPT 插件页面展示了产品，设置指南则解释了具体操作。

以提案审核为例，应保留审核标准和经过认可的示例。某个客户专属的资料，如果不是每次审核都需要，就不要混进通用方法里。这样，替代方案的职责才清晰，也能避免照搬一个不断堆积无关任务的旧助手。

迁移功能开放后，按 OpenAI 的流程操作

请使用拥有该 GPT 的账号或工作区。以下步骤依据 OpenAI 的迁移常见问题和编辑器说明：

1. 1

   先完成需要保留的版本

   打开 Explore GPTs，再进入 My GPTs，选中目标 GPT；如果有 Edit GPT 选项，就进入编辑，并用 Update 应用必要的修改。迁移采用最新发布的版本，未发布的修改不会带过去。发布并不要求公开分享。

2. 2

   使用已开放的迁移功能

   在 My GPTs 中选择 Migrate to plugin，并查看迁移详情。如果没有这个选项，先核对 GPT 所属的工作区及其通知，再请管理员检查插件访问权限。不要把计划上线时间当成迁移入口必然出现的保证。

3. 3

   核对实际迁移了什么

   指令会变成技能，知识文件会变成参考文件，已连接的应用会作为应用加入。原先选择的模型不会迁移，替代方案采用 Enterprise 默认设置。自定义操作需要另行安排替代方案。

4. 4

   同时测试方法和集成

   用熟悉的提示词和一个棘手案例进行对比。检查是否采用了正确的指令和资料、交付结果是否符合格式要求，以及连接到其他系统的操作是否正常。文字回答看起来合理，不足以证明系统记录已被正确更新。

5. 5

   分享、安装，并验证接收者的使用体验

   通过单独迁移生成的插件起初为私有状态。如果提供 Share Plugin 功能，可用它预填原来的共享对象，检查后选择 Save。请一位预期使用者安装并试用替代方案。原有的 GPT 访问权限不会自动转成插件访问权限。

针对 GPT 数量较多的 Enterprise 工作区，OpenAI 现已提供通过 ChatGPT Admin plugin 批量迁移的说明。获取工作区完整清单需要工作区**所有者（Owner）**权限。批量任务是异步执行的，必须核查结果后才能认定完成。这与符合条件的创建者或管理员进行单独迁移是两回事。参见 OpenAI 批量迁移指南。

如果要新建可复用的工作流，OpenAI 指引用户先安装 Plugin Creator，再与 @plugin-creator 开始对话，描述要构建的内容。在功能可用的情况下，按文档给出的路径创建，然后测试。参见 Plugin Creator 设置说明。

Projects 与自定义 GPT 有何不同？持续积累的上下文迁到哪里？

ChatGPT Projects适合资料需要不断积累的工作。对于客户管理，这意味着已确认的需求说明、当前文件和持续进行的讨论可以放在一起。如果要搭建定期报告工作流，可以参考 ChatGPT Projects 指南。

重建这类工作流时，在侧边栏选择 New project，为其命名，上传相关源文件，再通过更多选项菜单中的 Project settings 添加工作指令。Project 指令在该 Project 内生效，并优先于全局自定义指令。这些是 OpenAI 文档中的 Project 设置步骤，并非将 GPT 迁入 Project 的工具。

如果原来使用的是客户报告 GPT，应围绕该客户重写指令：哪些资料具有权威性、报告必须包含什么，以及哪些决策需要复核。保留有用的规则即可，不要默认旧助手的每条指令都适合搬进新的工作室。

GPT 对话无法移入 Project。 OpenAI 将这类对话与提供 Move to project 选项的可迁移聊天明确区分。请在 Project 中新建聊天，并加入相关源资料。GPT 停用后，现有对话仍可访问，但这不代表它们会成为 Project 中导入的历史记录。参见 Project 聊天限制及对话保留说明。

自定义 GPT 有记忆功能吗？

自定义 GPT 不会使用已保存的记忆或此前的对话；每次对话都是重新开始。Projects 则可以将其中的聊天和文件作为后续工作的上下文。因此，不断更新的客户档案往往更适合放在 Project 中。参见 GPT 的记忆机制及 Project 上下文说明。

自定义 GPT 的内容是私密的吗？

GPT 的共享范围取决于设置，创建者无法查看用户各自的对话。共享 Project 的协作方式不同：成员可以查看其中的聊天和文件，还可以下载文件。将旧工作资料放入其中之前，应先检查共享对象。参见 GPT 隐私说明及共享 Project 的可见范围。

例如，通用的员工政策助手，与管理者针对某个具体案例的讨论，不应默认合并到同一个共享工作室中。复制资料前，先划清访问边界。

自定义操作怎么迁？先决定如何替换集成

如果 GPT 会更新业务系统，仅保留提示词是不够的。自定义操作不会通过迁移流程转移。 OpenAI 建议先查找合适的应用；替代方案也可能需要自建 MCP 服务器，通过连接向助手提供工具。可用的集成选项取决于账号和工作区。参见 OpenAI 的自定义操作迁移指南。

对于订单管理助手，应列清它实际执行的操作：读取订单、修改地址和提交取消请求，是不同的需求。随后，逐项检查替代方案是否支持。一个应用能够查询订单，并不能证明它也能修改订单。

尽早为这类 GPT 指定技术负责人，由其核实目标记录、允许执行的操作和失败时的行为。在替代方案通过这些检查之前，保留人工处理流程。

如果助手要放进自己的网站或服务中，就需要另行决定如何开发。OpenAI 的 GPTs 文档明确将这种场景指向 API。不要向相关方承诺，完成 ChatGPT 内的迁移，就能同时交付嵌入自有产品的助手。

文件数量上限，也会影响迁移去向

选择 Project 前，先检查源文件清单。一个 GPT 最多可包含 20 个知识文件，而 Project 的文件额度随套餐变化。参见 GPT 文件上限。

OpenAI 还规定，每次最多上传 10 个文件。这些是 Project 的限制，不是插件迁移的限制。参见 OpenAI 的 Project 文件额度。

假设一个 GPT 用满了 20 个文件名额，就会比 Free 套餐的 Project 额度多出 15 个文件。这只是根据文档上限计算出的差额，并非实际迁移结果。先确认哪些文件仍有用；如果工作所需的源文件放不下，就选择容量足够的去向，不要悄悄丢掉依据资料。

别高估迁移：搬过去，不代表工作就能照常继续

停用公告是真的，但“每一种替代方案都能保持完全相同的行为”这一说法，并没有 OpenAI 指南的支持。

新闻报道不等于现行时间表。 PCWorld 于 2026 年 9 月 18 日报道了停用消息，介绍了当时的 Enterprise 时间安排，并建议使用 Projects。OpenAI 当前页面则已经列出标准停用日期、具体例外情况，以及更新后的新建规则。制定计划时，应以这些官方在线规则为准。

保留了指令，不代表行为也会原样保留。 模型选择、可用工具和技能的调用方式，都可能影响结果。判断替代方案是否合格，应看它能否完成所需工作，而不是生成的文字听起来是否熟悉。参见 OpenAI 的迁移测试指南。

各套餐均有插件功能，不代表每个人都能使用每个插件。 能否安装和使用，取决于套餐、工作区、角色、地区及插件所含能力。应让一位预期使用者实际检查替代方案。功能覆盖各套餐，也不能据此认定插件一律免费或一律收费。参见 OpenAI 的插件可用性规则。

本周可以完成哪些准备？

整理一份别人拿到就能执行的替换清单。在用户切换之前，优先保住工作流，并明确负责人。

• 列出正在使用的 GPT。 记录所有者、创建时所属的工作区、用途、使用者、通知中的截止日期，以及连接的应用或自定义操作。员工依赖但并不拥有的公开 GPT，也要列入清单。
• 将指令和文件导出到自己的工作档案中。 对于有权限编辑的 GPT，复制指令文本和对话开场白，并从日常维护这些资料的源位置收集原始知识文件。这是一份手工备份，保存配置及持续维护的原始文件。使用文档所述的 GPT 编辑器检查配置，缺失的源文件则与其负责人一起补齐。
• 逐一确定替代方案。 标明迁到插件、Project、重建集成或通过 API 开发；已不再使用的工作流也可以不替换。每个仍在使用的项目，都要有明确负责的人，以及一项用于验证的典型任务。
• 让接收者完成一次实际检查。 宣布切换前，请构建者以外的人访问替代方案，并完成那项典型任务。遵循 OpenAI 的迁移与共享指南。

准备替代方案期间，只要适用的时间安排和权限允许，就可以继续使用现有 GPT。尚未测试的集成可以暂缓切换，但盘点不能拖延。如果没有依赖任何 GPT，也就没有需要迁移的 GPT 工作流。

常见问题

什么是自定义 GPT？

自定义 GPT 是按特定用途配置的 OpenAI ChatGPT 版本，结合了指令、参考知识和所选能力。例如，企业可以用它执行自己的提案审核规则。参见 OpenAI 的 GPTs 指南。

自定义 GPT 现在还能用吗？

在相应停用日期到来之前，只要符合访问规则，现有 GPT 仍可使用。新建和继续使用适用不同规则，请查看上方的套餐表及工作区通知。参见 OpenAI 的当前状态说明。

可以免费使用自定义 GPT 吗？

OpenAI 表示，各 ChatGPT 套餐的已登录用户，都可以使用自己有权访问的 GPT，其中包括 Free 用户。个人账号无法新建或发布 GPT；能否使用插件，则是另一个问题。参见 GPT 可用性说明。

OpenAI 正在淘汰自定义 GPT 吗？

是的。OpenAI 当前的常见问题将标准停用日期定为 2026 年 12 月 11 日；FedRAMP 工作区及符合条件且已获批延期的工作区，则为 2027 年 2 月 11 日。如果 OpenAI 向你提供了不同的账号或工作区时间安排，以该通知为准。参见官方停用常见问题。

自定义 GPT 已经下线了吗？

截至 2026 年 10 月 30 日核实时，还没有。停用后，GPT 及其页面将无法访问，但现有对话仍可访问。看不到新建按钮，是另一项限制。参见 OpenAI 的停用说明。

想了解产品不断变化时，如何让企业 AI 工作流继续发挥作用，欢迎订阅邮件通讯。