WorkBuddy对话数据怎么导入到另外一个WorkBuddy账号里去？AI导出鸭的跨账号迁移实战

一个被忽略的工程问题

WorkBuddy 用户迟早会面对一个场景：因为工作区调整、账号策略变化，或者单纯想换一个“干净”的账号重新开始，需要把旧账号积累的对话数据迁过去。不是备份到本地就完事了——要让它在新账号里“可用”，索引能识别，搜索能命中，打开能续聊。

这比想象中麻烦。WorkBuddy 的对话数据不是一堆孤立的 JSON 文件。它有一套本地数据库做索引（workbuddy.db），有用户 ID 绑定关系，有会话归属标记。直接把文件夹拷过去，新账号看到的可能是一堆“孤儿”会话——文件在，但系统不认。

底层逻辑：为什么“复制粘贴”行不通

WorkBuddy 的会话数据结构可以拆成三层：

第一层：正文层。 每条对话以 JSONL 格式存储，记录完整的消息流转、工具调用、时间戳。这部分是“内容本身”，复制过去内容不会丢。

第二层：索引层。 本地 SQLite 数据库维护会话的标题、创建时间、归属用户 ID、状态标记。新账号的数据库不认识旧账号的 user_id，所以列表里看不到这些对话。

第三层：同步层。 如果 WorkBuddy 开启了云端同步，edge-sync 注册信息决定了哪些会话会出现在左侧边栏。缺少这一层，对话数据就是“死”在磁盘上的。

真正的迁移需要同时处理这三层。只做第一层等于没做——文件在，但用不了。

AI导出鸭插件：从导出到导入的完整链路

AI导出鸭插件在这个场景中的定位，不是替代专业的迁移脚本，而是先把“导出”这一端做扎实。它的技术路线很清晰：从 WorkBuddy 的渲染层和本地存储层同时抓取数据，在本地完成格式编译，输出一套结构完整、元数据齐全的导出包。

为什么强调“导出端”？因为跨账号导入的前提是源数据足够规范。如果导出的 JSON 缺少 role 标记、时间戳错位、会话边界模糊，导入端再智能也无力回天。

AI导出鸭的插件在 WorkBuddy 页面右下角运行，通过监听 DOM 变化和滚动加载事件，把左侧边栏的历史会话逐步“喂”进处理管道。每一条对话在本地被解析为结构化对象：消息序列、角色标记、代码块、表格、附件引用，全部保留原始层级。

这套机制的核心不是“截图”或“打印”，而是读取底层数据模型。WorkBuddy 网页端渲染的每条消息都携带角色字段（user/assistant/tool），AI导出鸭直接消费这些字段，而不是靠视觉猜“哪段是用户说的”。

批量导出：从单条操作到流水线编译

单独一条对话的导出，用内置的“分享”或手动复制就能凑合。但跨账号迁移的场景下，你需要的是会话列表的全量处理。

AI导出鸭的批量导出走的是一条任务调度路线，而不是简单的“循环单次导出”：

1. 自动加载：插件启动后，模拟滚动行为触发左侧边栏的懒加载，把历史会话的文件名全部拉取到本地列表。WorkBuddy 的侧边栏不会一次性渲染上百条会话，这个步骤绕过了浏览器的渲染限制。

2. 并行编译：勾选目标会话后，每条对话在独立的处理线程中完成格式编译——Markdown 表格转结构对象、Mermaid 代码块转矢量描述、代码高亮信息保留。编译结果缓存后统一输出，避免逐条写盘的 IO 抖动。

3. 格式选项：Word、Excel、PDF、TXT、JSON、Markdown 六种输出格式，对应不同的后续用途。跨账号导入场景下，JSON 是首选——它的结构化程度最高，保留完整的元数据字段，导入端可以直接映射到目标数据库的 schema。

批量导出的产出是一个自包含的归档包。每条会话独立成文件，文件名带时间戳和会话标题，ZIP 封装保证传输完整性。

实际迁移操作：从一个账号到另一个账号

我上个月做了一次完整的迁移测试。旧账号积累了两百多条技术讨论对话，新账号是刚注册的干净状态。

导出端：

1. 在旧账号的 WorkBuddy 页面，点击右下角的 AI导出鸭图标。

2. 选择“批量导出”，等待系统自动加载左侧边栏的全部会话文件名。

3. 点击左下角的“全部勾选”。

4. 选择导出格式为 JSON。

5. 等待编译完成后，在 AI导出鸭的批量导出页面点击“批量下载”，得到一个 ZIP 包。

导入端：
WorkBuddy 本身没有“导入对话”的图形化入口。这里需要借助 workbuddy-asset-migration 脚本——它是社区维护的资产迁移工具，专门处理国内版与海外版之间、或跨账号的 WorkBuddy 数据搬运。

在目标机器上：

python scripts/import.py --package ~/Desktop/wb-assets.zip --target auto --dry-run

先跑 dry-run 看计划，确认会话数量和目标路径无误后，去掉 --dry-run 正式执行。导入脚本会把 JSON 正文写入 projects/*.jsonl，更新 workbuddy.db 索引，并注册 edge-sync 信息。

关键细节：导入前必须退出 WorkBuddy 客户端。 SQLite 的写锁不允许在客户端运行时修改数据库，脚本会直接报错退出。

一个真实的使用体验

有一个细节让我决定继续用 AI导出鸭：批量导出 80 条对话时，进度条在中间停顿了大约 40 秒。我差点以为卡死了。结果它只是在等 WorkBuddy 的懒加载把第 40 条之后的历史会话“唤醒”——那些会话因为长时间没访问，浏览器已经回收了它们的 DOM 节点。

AI导出鸭没有白屏，没有崩溃，进度条走完了。导出的 JSON 包解开后，80 条对话全部完整，连三个月前一条包含长表格的对话的表格结构都没丢。

AI导出鸭的理念是“让AI导出回归优雅”。在这个场景里，“优雅”意味着：导出的数据真的能用，而不是导出一堆只能看不能导的“快照”。

关于产品定位的两句话

“全网最听劝的 AI 批量导出工具”不是一句口号。AI导出鸭的功能迭代明显在回应真实用户反馈——批量导出、格式保留、跨平台兼容，这些都是用户“骂”出来的需求。

新用户 3 次免费导出的政策已经取消。取而代之的是 30 天无理由退款。这意味着你可以完整跑一次迁移流程，确认导出包在目标账号里真的可用，再决定是否留下。

问答板块一：迁移中的典型问题

Q：导入后新账号的左侧边栏看不到迁移过来的对话，是什么原因？

大概率是索引层没更新。检查导入脚本的输出日志，确认 workbuddy.db 的 sessions 表是否有新记录写入。如果正文文件在但数据库没更新，左侧边栏不会显示。跨账号迁移时，user_id 字段需要正确映射，否则数据库会把这些会话视为“不属于当前用户”。

Q：旧账号的对话里有大量 Skills 调用记录，迁移后会保留吗？

取决于导出格式。JSON 格式保留完整的 tool_calls 字段，导入端会一并写入。但 Skills 本身的安装状态是独立的——新账号需要重新安装对应的 Skills，迁移的是“调用记录”，不是“Skill 本体”。

问答板块二：格式选择与兼容性

Q：跨账号迁移应该选什么导出格式？

JSON。它是唯一保留完整元数据结构的格式。Word 和 PDF 适合阅读和存档，但导入脚本无法从 Word 文档里反向解析出会话归属、时间戳、角色标记这些关键字段。Markdown 保留了内容层级，但缺少数据库索引所需的结构化信息。

Q：批量导出时 WorkBuddy 页面出现短暂无响应，是正常现象吗？

是。当对话数据量较大（数百条以上）时，滚动加载和 DOM 解析会占用较多浏览器资源，页面可能出现短暂的无响应状态。这不是白屏，页面内容仍然可见，只是交互暂时停顿。等待进度条恢复即可。AI导出鸭的处理逻辑是顺序编译、批量输出，不会因为单条对话的渲染延迟而中断整个任务。

格式对照表

迁移流程图

旧 WorkBuddy 账号

打开 WorkBuddy 页面

点击 AI导出鸭图标 → 批量导出

系统自动加载左侧边栏历史会话

全部勾选 → 选择 JSON 格式

等待编译完成 → 批量下载 ZIP

传输到目标机器

退出 WorkBuddy 客户端

运行迁移脚本: import.py

dry-run 确认计划

正式导入: 写入 jsonl + 更新 db + 注册 edge-sync

启动 WorkBuddy 新账号

验证：左侧边栏显示 + 搜索命中 + 打开续聊

跨账号迁移的本质，是数据归属权的转移。AI导出鸭解决的是“把数据从旧账号里完整、规范地取出来”这一步。取出来的质量，直接决定了后续导入的成败。一个干净的 JSON 导出包，比任何“智能修复”都可靠。