OpenAI已经公布Custom GPT逐步退场并迁移到插件的计划。对只做过几个个人助手的用户，这可能只是一次产品入口变化；对企业来说，它涉及提示词、知识文件、连接动作、共享范围和责任人的整体迁移。最危险的做法是等旧功能停用前一天再复制内容。正确方式是先盘点依赖，再建立可验证的迁移清单。
一、先确认时间与影响范围
官方FAQ列出了企业工作区的计划节点，包括迁移体验、停止新建以及最终退役日期，同时提醒不同账号和方案的可用时间可能不同。因此第一步不是照搬某个日期，而是查看自己工作区内的通知。管理员应记录受影响的GPT数量、所有者、活跃用户、最近使用时间和业务重要度，优先处理每天使用、对外输出或连接业务系统的项目。
二、给现有GPT做资产盘点
每个GPT至少记录六项：名称与用途、系统指令、上传知识、启用能力、外部Action、共享对象。还要标记谁能解释它为什么这样设计，因为只复制提示词无法复制隐含业务规则。长期无人维护、重复功能或没有真实用户的GPT可以直接下线，不必把历史负担全部迁移。盘点表中增加“保留、合并、淘汰、待确认”四种状态，能显著降低迁移工作量。
三、区分提示词与插件能力
Custom GPT常把角色说明、处理步骤和外部连接混在一起。迁移时应拆成三个层次：稳定的行为规则、可复用的任务流程、需要授权的数据与动作。稳定规则描述语气和边界；流程说明什么时候执行哪些步骤；连接则负责读取或写入外部系统。拆开后更容易测试，也能让同一套规则复用于不同应用，而不是继续形成新的孤岛。
四、知识文件不能只复制
先检查知识文件是否仍然有效，是否包含过期制度、重复版本或敏感信息。给每份资料补上来源、更新时间、负责人和适用范围。迁移后用一组固定问题测试检索效果，既要包含能回答的问题，也要包含应该拒答的问题。如果答案引用了旧版本，说明问题可能在知识管理而非模型。重要制度应保留版本号，避免用户无法判断依据。
五、建立回归测试集
从真实使用记录中挑选二十到五十个典型任务，覆盖正常输入、边界输入、错误输入和敏感请求。测试结果不要只看“像不像”，而要量化字段完整率、事实准确率、拒绝是否正确、响应时间和工具调用是否成功。旧GPT与新插件同时跑同一批问题，记录差异。涉及计算、审批或客户承诺时，必须由业务负责人签字确认。
六、重新审查共享和权限
迁移可能改变可见范围与连接方式，不能默认继承旧设置。检查插件是仅本人、指定成员、工作区还是更广范围可见；检查连接账号是否属于个人；检查写操作是否需要确认；检查离职人员是否仍是唯一所有者。企业最好设置至少两名维护者，但生产发布只由明确角色负责，避免所有人都能改又没人承担后果。
七、采用并行切换而不是硬切
新插件先在小范围试用，旧GPT保持只读或继续服务一段时间。观察常见问题、失败调用和用户反馈，修正后再扩大范围。正式切换前发布简短说明，告诉用户入口变化、能力差异和问题反馈渠道。完成切换后不要立即删除旧资产，先导出必要配置和测试记录，保留审计周期，再按数据政策清理。
八、迁移后的长期治理
插件不是迁移终点。为每个生产插件设定负责人、版本记录、季度复测和停用标准。提示词、知识和连接任何一项变化，都应触发对应测试，而不是只看页面能否打开。把迁移当作一次清理AI资产的机会，可以让团队从“谁都能做一个助手”走向“每个助手都有人负责、可以解释、能够回滚”。
资料来源：官方资料。本文依据官方信息独立整理与扩展，结合实际使用场景进行说明。
