通用方法 · 熟练
定制助手要退场了，先搬哪三样？
能带走的是「指令」和「文件」，带不走的是「对话」
平台方退役一个「配置型助手」，退掉的不是一个按钮，而是你攒在里面的一整套上下文。这一页做的是一张迁移清点表：先把资产分成「能带走的」与「带不走的」两栏 —— 能带走的是指令与知识文件，带不走的是选定的模型、已有对话、分享设置与自定义动作；再按 先搬指令、再搬文件、最后重挂连接 的顺序落到新的载体上；搬完拿旧的三个典型问题回灌一次，看回答是否还守得住原来的边界。关键动作只有一个：在创建通道关闭之前，先把「指令全文」导出来存成你自己的文件。
方法 · 一图看懂
1
分两栏 — 先按「能带走 / 带不走」把资产过一遍，别把能搬的和搬不走的一起处理
2
先导指令 — 指令是最容易丢也最值钱的一块，导出成你自己的文件再谈其它
3
再搬文件与连接 — 知识文件逐个上传 · 已连接的应用按最小必要重挂
4
回灌验证 — 用旧的三个典型问题问一遍，看它还守不守原来的边界
原理 · 为什么有效
退役公告里最容易读漏的一句是「哪些不会自动随迁」—— 因为「可迁移项」写得具体（指令、知识文件、已连接应用），而不可迁移的那几样（选定的模型、已有对话、分享设置、自定义动作）用的是「不自动」这三个字。它不是「迁不了」，是「需要你自己动手重做，平台不会顺带帮你做」。这决定了顺序：先做那些只能手做、且不做就永久丢失的（对话与指令），再做那些可以重配的（模型与连接）。另一条原理是「配置与上下文不是一回事」：配置（指令、文件）是可复制的文本，上下文（对话历史、你对它的调教）沉淀在会话里，跟着平台走。所以真正的止损动作，是在窗口关掉之前把配置文本落到你自己的硬盘上。
适用场景
适用于任何「在平台里养了一个配置型助手」的人：定制 GPT / 自定义 Agent / 团队里的固定提示词助手 / 挂在某个客户端里的角色预设。尤其适用于把它当工作工具、而不是玩具的人 —— 你的价值全在那段指令里。不适用于：只临时问过几次、没有任何自定义指令的账号（没有资产就没有迁移问题）；也不适用于完全自建、跑在自己环境里的方案（那属于另一条线）。
自测 · 5 问
我能不能在自己这一侧说清：这个助手一共做过哪几件事（而不只是「我有个助手」）
指令全文有没有一份平台之外的副本（本地文件 / 笔记 / 代码仓都算，⛔ 只存在于平台里不算）
知识文件里有几份是别处拿不到的（只有这里有 = 必须先下载，⛔ 不能指望迁移帮你搬）
它接过哪些外部服务（邮件 · 日历 · 文档 · 数据库）—— 逐条能说出授权给过谁
新载体上跑过一遍之后，有没有出现过「以前会拒绝、现在什么都答」的情况
怎么上手 · 验证步骤
一轮大约 40 分钟。先把「指令全文」复制到一个本地文件（文件名建议带日期，便于日后对比版本），再把知识文件逐个下载 —— 这两步做完，最坏情况已经兜住了。接着搬指令：把旧的指令原文贴进新载体，先原样跑一遍，确认基本行为一致，再做小幅调整（⛔ 不要一边搬一边大改，那样出了问题分不清是搬迁还是改动导致的）。然后重挂连接：只挂这次真的会用到的服务，给最小权限；挂完立刻用一个真实任务试一次，确认授权链是通的。最后回灌：把旧的三个典型问题（含一个它以前会拒绝的）问一遍，逐条对答案。
回灌时重点看「拒绝边界」有没有变松 —— 配置型助手最值钱的地方，往往是它在什么情况下会说「这个我不能替你决定」。如果新载体上它变得有求必应，说明指令里的约束没搬全（约束常写在指令的后半段，最容易被顺手删掉）。另外核一条：知识文件的版本是不是最新的那一份 —— 迁移时很容易上传成旧文件，而旧文件不会报错，只会答错。