# 换电脑后， WorkBuddy 如何迁移？
**一句话前提：**WorkBuddy 是账号制的，登录同一账号，对话记录和个人画像会自动同步。但你在旧电脑上装的技能、配的自动化任务、MCP 连接器、记忆文件——这些全存在本地硬盘里，**不会跟着账号走**。换电脑后，这部分需要手动迁移。
本文目录
一、先搞清楚：什么会同步，什么不会
二、需要迁移的完整清单
三、三种迁移方案（按推荐排序）
四、迁移后的验证清单
五、避坑指南
六、一劳永逸：长期同步方案
一、先搞清楚：什么会同步，什么不会
这是迁移的第一步——你得知道哪些东西需要搬，哪些不用管。
| ☁️ 云端自动同步
换电脑登录同一账号，自动出现
• 对话 / 任务记录
• 个人画像（服务端生成）
• 历史对话检索功能
• 基础账号设置
| 💻 本地存储（需迁移）
换电脑后全部空白，需手动搬
• Skills 技能库
• 自动化任务
• MCP 连接器配置
• 身份文件（SOUL/IDENTITY/USER）
• 记忆文件（MEMORY.md + 日志）
• 团队配置
|
**关键认知：**WorkBuddy 的设计理念是「这台机器的设定」而非「这个账号的云资产」。本地配置存在 `~/.workbuddy/` 目录里（Windows 路径：`C:\Users\你的用户名\.workbuddy\`），它不跟账号走。 | | |
|---|
| `skills/` | | 必须迁移 |
| `workbuddy.db` | SQLite 数据库：自动化任务、运行状态、执行历史 | 必须迁移 |
| `mcp.json` | | 必须迁移 |
| `SOUL.md` | | 必须迁移 |
| `IDENTITY.md` | | 必须迁移 |
| `USER.md` | | 必须迁移 |
| `MEMORY.md` | | 必须迁移 |
| `experts/` | | 建议迁移 |
| `teams/` | | 建议迁移 |
| `argv.json` | | 建议迁移 |
**注意：**项目级记忆文件 `{项目目录}/.workbuddy/memory/`（每日日志 + 项目记忆）不在 `~/.workbuddy/` 下，而是跟着各自的项目走。如果你的项目在 Git 管理下，这些文件会跟着代码仓库一起迁移。C:\\Users\\你的用户名\\.workbuddy\\ → C:\\Users\\你的用户名\\OneDrive\\WorkBuddy备份\\.workbuddy\\
**第 2 步 · 创建软链接**（以管理员身份打开 PowerShell）：在原位置创建一个指向云盘的符号链接：
mklink /D "C:\\Users\\你的用户名\\.workbuddy" "C:\\Users\\你的用户名\\OneDrive\\WorkBuddy备份\\.workbuddy"
**第 3 步 · 在新电脑上操作：**确保云盘已同步完成，然后在相同位置创建同样的软链接。WorkBuddy 会自动从软链接指向的云盘路径读取所有配置。
**优点：**设置一次后全自动，无需重复操作。两台电脑的配置永远一致。
**适用场景：**有固定两台以上电脑（公司 + 家里），且都安装了同一云盘客户端。
方案二：GitHub 私有仓库（适合有版本管理需求）
把 `~/.workbuddy/` 初始化为 Git 仓库，推送到 GitHub 私有仓库。天然有版本记录，传错了能回滚，比普通网盘更稳。
**第 1 步 · 在旧电脑初始化仓库：**
cd ~/.workbuddy
git init
git add .
git commit -m "备份 WorkBuddy 配置"
git remote add origin https://github.com/你的用户名/workbuddy-backup.git
git push -u origin main
**第 2 步 · 在新电脑上拉取：**
cd ~
git clone https://github.com/你的用户名/workbuddy-backup.git .workbuddy
**第 3 步 · 后续更新：**每次在任一电脑上修改配置后，`git add . && git commit && git push` 推送；在另一台电脑上 `git pull` 拉取。
**优点：**有完整版本历史，误操作可回滚，适合配置经常变动的场景。
**注意：**`workbuddy.db` 是二进制文件，Git 对二进制文件的版本管理效果一般（无法做行级 diff），但作为备份和同步仍然可用。
方案三：U盘 / 网盘手动拷贝（最简单，适合一次性迁移）
如果你只需要做一次性迁移，不想搞云盘或 Git，直接拷贝整个目录就行。
**第 1 步：**关闭旧电脑上的 WorkBuddy（确保数据库写入完成）。
**第 2 步：**复制整个 `.workbuddy` 目录到 U盘或网盘。
**第 3 步：**在新电脑上，把目录覆盖到相同位置。
**第 4 步：**打开新电脑上的 WorkBuddy，检查配置是否生效。
**优点：**零门槛，人人会操作。
**缺点：**每次换电脑都要手动操作一次，无法自动保持同步。
四、迁移后的验证清单
迁移完成后，按这个清单逐项检查，确认所有配置都生效了：
☐ Skills 技能列表：打开「专家 · 技能 · 连接器」→ 技能，确认所有技能都在
☐ 自动化任务：打开自动化列表，确认所有定时任务都在
☐ MCP 连接器：打开连接器列表，确认已连接的服务还在（注意：部分连接器可能需要重新授权）
☐ 身份文件：开一个新对话，问 AI「你是谁？我是谁？」，确认 AI 能正确回答
☐ 记忆文件：问 AI「你还记得我之前跟你说过什么吗」，确认长期记忆存在
☐ 专家包：打开专家中心，确认已安装的专家都在
☐ 对话历史：确认云端同步的历史对话能看到（这个不需要迁移，自动同步）
五、避坑指南
**坑 1：直接拷贝 workbuddy.db 导致数据库报错**
workbuddy.db 包含本地路径记录，如果两台电脑的 Windows 用户名不同（如一台是 `Administrator`，另一台是 `zhangsan`），数据库中的路径记录会不匹配。解决方案：迁移后如果自动化任务无法执行，删除 workbuddy.db 中的 automation\_runtime\_state 表数据，让运行状态重新初始化。或者更保险的做法——用 automation\_update 工具逐条导出 JSON 再导入，而不是搬数据库文件。**坑 2：MCP 连接器需要重新授权**
即使迁移了 `mcp.json`，部分连接器（如飞书、企业微信、GitHub 等）的授权 token 可能已过期或绑定到了旧机器的会话。迁移后需要到「连接器管理」页面重新点击「Trust / 授权」。**坑 3：项目级记忆不会跟着走**
`~/.workbuddy/` 只包含用户级配置。每个项目自己的记忆文件（`{项目目录}/.workbuddy/memory/`）是独立存储的。如果项目目录不在 Git 管理下，这些记忆也不会自动迁移。解决方案：把项目目录也纳入 Git 管理或单独拷贝。**坑 4：云盘同步时的文件冲突**
如果两台电脑同时打开 WorkBuddy 且都在写入记忆文件（如每日日志），云盘同步可能出现冲突副本（如 `2026-07-28 (1).md`）。解决方案：避免两台电脑同时使用同一项目；或采用 Git 方案（二选一），Git 有冲突解决机制。**坑 5：第三方登录导致账号不一致**
如果一台电脑用微信扫码登录，另一台用邮箱密码登录，可能产生两个独立账号，导致云端对话记录都无法同步。解决方案：所有设备统一使用同一种登录方式（推荐邮箱 + 密码）。
六、一劳永逸：长期同步方案
如果你经常在两台以上电脑之间切换，建议设置一个长期的自动同步机制，而不是每次换电脑都手动搬一次。
**第 1 步 · 用户级配置**（`~/.workbuddy/`）→ 用云盘 + 软链接方案（方案一），设置一次后全自动同步。
**第 2 步 · 项目级记忆**（`{项目}/.workbuddy/memory/`）→ 把项目纳入 Git 管理，记忆文件跟着代码仓库走。
**第 3 步 · 自动化任务** → 如果两台电脑用户名不同，不要搬 `workbuddy.db`，而是用 `automation_update` 工具逐条导出为 JSON，在新电脑上逐条导入。安全且不会损坏数据库。
总结
WorkBuddy 的迁移本质上就是搬一个目录：`~/.workbuddy/`。关键记住三件事：
• **云端同步的**：对话记录 + 个人画像 → 不用管，自动跟账号走
• **本地存储的**：技能 + 自动化 + MCP + 身份 + 记忆 → 需要手动迁移 `~/.workbuddy/`
• **项目级记忆**：跟着各自项目目录走，不在 `~/.workbuddy/` 里
最佳实践：云盘 + 软链接搞定用户级配置，Git 管理搞定项目级记忆，自动化任务用 JSON 导出导入。一次设置，终身受用。