把攒了三年的对话搬到新助手：个人 AI 资产的导出与保真验收
一、文本搬得走，关系搬不走
据公开报道，有作者把自己在一个助手里积累三年的对话与自定义能力，尝试整体迁到另一家办公助手里，并顺带对比了几款办公工具。本篇不评价任何一家的迁移能力强弱，也不引用没有公开过的迁移成功率与字段清单，只把这件事里可复用的工程部分拆出来。
拆开的结论就是那位作者的落差：能带走的是文本，带不走的是让那个助手显得认识你的东西。这不是修辞，它是一个产品结构问题。个人 AI 资产里真正有价值的部分往往不是内容本身，而是内容之间的引用关系与生效条件：哪句偏好是在什么前提下说过的、哪个自定义能力当时绑了哪个外部账号、哪份附件被后来的对话反复指过。导出格式通常只保留内容，关系在导出这一刻就断了。
对做产品的人来说，这里还有一层更冷的读法：用户把迁移设想成搬家，实际上迁的是备份。备份的价值在于可查，在于能在新环境里继续生效，两者差得很远。本篇给出四类资产的保真度对照、一键迁移的三种真实语义、搬完之后的三项验收判据，最后是合同与产品侧该怎么写。
二、四类资产的可导出性与保真度对照
先按资产类别判断能带走多少，再谈迁移方案，顺序不能反。四类资产的性质不同，导出难度不是同一道题。
| 资产类别 | 通常能导出的形态 | 保真度损失点 | 迁移后可达到的状态 |
|---|---|---|---|
| 文本会话 | 逐条消息记录，常为结构化文本或压缩包 | 消息与文件的关系、上下文分组、会话标题的层级 | 可读可查，但不等于继续可用 |
| 文件与图片 | 原件下载，或仅保留引用链接 | 命名规则、目录层级、原件与生成物的区分 | 链接类内容可能整体丢失 |
| 自定义指令与技能 | 有导出时多为文本描述 | 内部提示组织方式、生效条件、参数与边界设定 | 需人工重述，语义大概率漂移 |
| 外部连接与授权 | 基本不可导出 | 授权范围、令牌有效期、最小权限设定 | 只能在新环境重新授权 |
这张表里最需要注意的是最后一行的确定性和第三行的不确定。授权不可导出是好事，边界清楚，用户知道要做一次重连。第三行最坑，因为自定义指令看起来是可以复制粘贴的东西，用户会默认粘贴过去就等效，实际差的正是那些没有写成文字的隐含约定：什么情况下不要主动扩展、哪些口径必须沿用、上次被纠正过的那类错误是什么。这类东西在导出文本里不存在，所以迁移后表现为助手变得不听话，而没人能指出为什么。
顺带说明保真度的判定标准不该是内容条数，而该是关系是否仍可解析：一条会话如果失去了它引用的附件和它所属的分组，内容再完整也是降级的。
三、一键迁移的真实语义
把历史内容放进新环境，至少有三档实现，成本与效果差别很大。用户看不到区别，是因为界面上都叫导入完成。
第一档只搬标题与时间线，正文按需再取。它对旧数据的处理更像建立目录，好处是快、体积小，坏处是新助手对你的了解为零，检索体验依赖旧平台是否仍在被引用。第二档把历史正文灌入，作为可检索语料。这样老会话能被搜到，但默认不参与当前推理，用户会感到搜得到却想不起来。第三档是把历史提炼成偏好与规则条目，再注入新会话。这是最接近原来体验的做法，也是最容易失真的一档，因为提炼环节把三年压缩成几句话，压缩掉了原本起作用的前提条件。
所以验收不能问迁了多少条，要问三句：搬过去的是原文、摘要，还是重述；新助手回答问题时引用的是哪一档；如果引用了旧内容，能不能指出来源是哪一次会话。这三句问不出答案，就只能认定迁移完成度未知，不能算迁完。
四、搬完之后要做的三项验收
这三项验收建议个人用户在迁移当天就做完，而不是用了两周才发现不对。每项都要有可判定的通过条件，凭感觉不行。
| 验收项 | 具体怎么做 | 通过条件 | 常见的假通过 |
|---|---|---|---|
| 老会话能否检索到 | 准备五到十个只在自己旧对话里出现过的事实，逐条提问，记下命中几条、命中的是原文还是重述 | 多数命中且能给出原文内容 | 只命中标题或主题词，正文取不到 |
| 旧引用能否打开 | 挑出以前上传过的文件与生成过的图片，要求新环境真正取到原件 | 能取到字节内容，而不只是显示名字 | 只剩文件名，点开是空白或失效 |
| 偏好是否继续生效 | 用几条自己过去纠正过的写法测试，例如格式偏好、称呼习惯、明确说过不要用的表达 | 稳定按约定输出，且能追溯到存档的重述文本 | 靠感觉判断像不像，没有可比对的底稿 |
如果自定义指令是人工重述过去的，重述文本必须存档，日后助手行为漂移时能回到这份存档比对，而不是靠记忆争论。
三项之外还有一项留底建议：导出文件本身做完整备份并记录哈希，注明它是哪一次导出的产物。日后即使不迁移，也可以作为内容归属与生成时间的凭证。
五、做产品的人要接住的两条反向提醒
第一条，自己的产品要不要提供可携导出。如果要，就要提前定三件事：导出的粒度是账号级还是会话级；导出包里带不带附件原件；生成物与用户上传件是分开标注还是混在一起。这三件事在没设计时都会长成实现细节，事后补很贵，因为它牵涉存储结构与权限模型。把这三件事写进需求，比承诺支持数据导出这句话有用得多。
第二条，迁移入口是留存手段还是负担。把入口做得很重，等于在自己的产品说明里承认搬家很容易，反而降低用户对你数据价值的感知；做得完全封闭，用户会把不信任写进对品牌的长期印象里。更平衡的做法是：提供格式清晰、字段完整的导出，同时在界面上如实说明哪些带不走，尤其是授权类和自定义指令类。诚实的局限声明比一键迁移的宣传更能留住人，因为它把预期管理放在了迁移之前。
对做企业交付的人，同一条逻辑落在合同上。数据可携的条款要写到能验收的程度：导出格式与字符编码、字段清单与层级、附件与图片是否包含原件及其命名规则、导出频率与单次范围、导出内容的保存期限。只写支持数据导出六个字，验收时谁都拿不出结论。
六、可携的真实边界
最后给一条判断线，用于决定这项资产该不该指望迁移。可携的最小价值是事后能查，可携的完整价值是继续生效。绝大多数导出只覆盖前者，这不是缺陷，而是格式本身的限制。把目标定在可查，迁移会顺利很多；把目标定在继续生效，就得接受一部分资产只能在新环境重新养成。
我们在洹拓的用户侧访谈里也碰到过类似落差，用户把可携权理解成体验无损的权利，产品把可携理解成提供了一份压缩文件，两边说的是同一件事的不同档位。这件事没有工程捷径，只有把保真度摊开讲清楚：哪一类资产可原样带走、哪一类需要重做、哪一类根本无法带走，并且每一类都有对应的验收问题。摊开讲的产品和摊开讲的项目，迁移事故都更少，因为用户的预期和系统的能力之间没有缝隙。