前阵子有个做 AI 办公的朋友问我：能不能在公司台式机和家里笔记本上同时登录同一个 WorkBuddy 账号，而且两边都要能接着昨天的对话往下聊，项目记录、技能、规则也得互通。我一听就知道他要的不是那种"手动导出再导入"的原始方案，而是真正的跨机双写同步。正好我自己也在这个坑里爬了很长一段时间，踩过不少软链、锁库、冲突文件的雷，这篇就把我最终跑通的方案和完整排查过程整理出来。
先说结论：多机共用一个 WorkBuddy 账号这件事，难点从来不在"账号登录"上，而在"WorkBuddy 的记忆和项目数据到底存哪里、怎么在两台机器之间保持一致"。账号只是个身份外壳，换台机器登录后，你原来那个账号的记忆不会自动跟过来，很多人以为是自己操作不对，其实是没搞清楚 WorkBuddy 的数据架构。所以要实现两台机器真正的无缝切换，核心问题就一个：怎么让本地数据目录完成双向实时同步。这篇文章就是围绕这个目标展开的。
1. WorkBuddy 的账号机制与本地数据分布
1.1 账号只是身份凭证，记忆默认长在本地
先看一个大家踩得很高频的坑：在 A 机器上用了很久 WorkBuddy，积累了大量的会话记录、自定义规则、技能和项目上下文，换到 B 机器登录同一个账号，结果发现界面干干净净，啥记忆都没有。很多人第一反应是去骂账号系统，但实际原因很简单——WorkBuddy 的账号体系主要负责身份认证、收费订阅和云端偏好设置，而会话历史、项目索引、记忆片段这些重数据，默认是写在本地磁盘上的，不会全量上传到账号云端。
这个设计其实有它的合理性。AI 工作台的会话和记忆文件往往体积不小，而且高频读写，如果全部走云端实时同步，离线场景就没法用了。所以 WorkBuddy 选择把"账号"和"数据存储"分开：账号负责告诉系统你是谁，本地目录负责告诉系统你做过什么。这也就解释了为什么"换账号如何获得原来账号的记忆"会成为高频问题——因为答案不是登录同一个账号，而是得把原来的本地目录搬过去或者做同步。
我一开始也试图在 WorkBuddy 里找那种"一键云同步"开关，结果发现它只同步了账号层面的设置项，比如主题、快捷键、模型选择这些轻量配置。真正值钱的记忆文件、会话 JSON、规则配置，全都老老实实躺在本机目录里。所以想多机共用，就必须自己动手把数据目录打通。
1.2 数据目录里到底装了什么
想做好同步，得先弄清楚 WorkBuddy 在本地到底放了哪些东西。不同版本、不同操作系统的路径会有差异，但核心目录结构通常长这样：
| 目录/文件 | 作用 | 双写同步建议 |
|---|---|---|
| config 或配置目录 | 存放模型地址、账号设置、界面偏好 | 可同步，但因为绝对路径问题容易踩坑 |
| sessions/ | 每次会话的完整记录 | 必须同步，这是双写的主体 |
| memory/ 或记忆目录 | 长期记忆、向量索引、摘要快照 | 必须同步 |
| rules/ | 用户自定义规则文件 | 必须同步，但建议单写多读 |
| skills/ | 自定义技能定义 | 必须同步 |
| projects/ | 项目索引和关联文件路径 | 必须同步 |
| cache/ 或临时目录 | 临时缓存、日志、锁文件 | 坚决不同步 |
| 登录态/凭据文件 | token、session 凭据 | 选择性同步，注意安全 |
我在自己的 Linux 机器上做了一次完整排查，用find / -iname "*workbuddy*" 2>/dev/null把相关路径全部列出来，发现数据分布得比较分散：一部分在~/.local/share/workbuddy下面，一部分在~/.config/workbuddy下，还有日志和临时文件散落在~/.cache/workbuddy。Windows 上则是典型的%APPDATA%和%LOCALAPPDATA%双目录结构。
这里想强调一点：缓存目录是唯一可以放心忽略、而且必须忽略的部分。它里面装的是临时索引、网络缓存的响应片段、日志滚动文件，这些内容同步过去除了制造冲突和垃圾，没有任何意义。
1.3 把"缓存目录"和"数据目录"分清楚
热搜词里有个高频问题叫"workbuddy 缓存目录怎么更改"，这说明有相当一部分用户把缓存目录当成了数据目录。从同步的角度来说，这个区分特别重要：改缓存目录解决的是磁盘占用问题，跟记忆同步半毛钱关系都没有。
我见过一个用户，他在两台机器上分别把缓存目录改到了云盘同步文件夹里，以为这样就能实现记忆互通，结果同步了一堆.log和临时文件，真正的 sessions 目录还留在本地默认位置。这种操作不仅没用，还会让云盘客户端频繁扫描不断变化的临时文件，导致严重的 IO 占用。
正确的思路是：只挑"有价值的、需要跨机延续的"目录做同步。简单说就是 sessions、memory、rules、skills、projects 这几个关键目录必选，cache 和日志目录必须剔除。后面写 Syncthing 忽略规则的时候，我会给出可以直接抄的配置。
2. 三种跨机同步方案实测对比
2.1 云盘软链接：最省心，但最脆
这是大多数人第一个想到的方案：把 WorkBuddy 的数据目录做成软链接，指向 OneDrive、坚果云、Dropbox 这类云盘同步目录，云盘负责把文件同步到另一台机器。听起来很美好，实际上问题不少。
先说优点：云盘客户端有图形界面，不需要学习任何新工具，而且两台机器只要登录同一个云盘账号，文件就会自动同步。如果你只是想在 A 机导出、B 机导入，那这个方案足够用。但如果你追求的是"双写"——也就是两台机器都在高频写入，那么云盘方案有几个致命伤。
第一是文件占位符问题。很多现代云盘默认启用"仅在线"模式，本地只有一个占位文件，真正内容在云端。WorkBuddy 在启动时会大量读取记忆文件和会话记录，遇到占位文件可能直接报错或者读取到空内容。我实测过，把数据目录放到 OneDrive 里，WorkBuddy 经常出现"找不到会话"的诡异问题，必须右键逐一"固定到本地"，而数据文件一多根本固定不过来。
第二是锁和句柄占用。云盘客户端会持续监控同步目录里的文件变化，而 WorkBuddy 这类 AI 工作台恰恰会频繁地写文件、改记忆、更新索引。两边同时操作同一个文件时，Windows 上经常出现文件被占用无法写入的错误提示，Linux 上则可能出现同步混乱。
第三是冲突处理能力几乎为零。云盘遇到双端同时修改，通常只会生成一个副本或者让后写者覆盖先写者，不会像专业同步工具那样保留冲突版本。对 WorkBuddy 来说，最坏的情况是两台机器各自写了不同的记忆片段，结果云盘粗暴覆盖，一边的记忆直接消失。
我把这个方案定义为"适合单向备份，不适合双向协作"。如果你能保证每天都只用一台机器干活，另一台只是偶尔看看，那云盘软链接还能凑合；如果想实现真正意义上的双写同步，请往下看。
2.2 Git 仓库：版本管理强，双写很痛苦
用 Git 管理 WorkBuddy 数据目录，是很多技术型用户天然会想到的思路。毕竟数据也可以被视为一种"代码"，会话记录可以提交，记忆可以回溯版本，看起来优雅得很。实际上我试过一周，体验非常拧巴。
核心问题在于 Git 的设计初衷是"多人协作，但文件彼此独立修改"，而 WorkBuddy 的数据文件恰恰是一台机器独占性的高频读写。双机同时开着 WorkBuddy，两边都在写同一个记忆文件，这时候你执行 pull 就会遇到大量冲突。Git 会要求你手动解决每个冲突文件，而记忆文件内部是结构化数据，人工 merge 基本不可行。
另一个问题是敏感信息泄露风险。WorkBuddy 数据目录里的登录凭据、token、账号信息，一旦被你git add .提交到了仓库里，再推到远程 Git 服务上，就相当于把自己的账号密钥公开了。即便后来删除，历史记录里还是留存的。我自己的做法是给仓库加了gitignore，把 token 类文件全部排除，但这就又回到了"哪些文件要同步"的选择题上，复杂度直线上升。
当然 Git 也不是完全没有用武之地。如果你想做的是"每周一次的版本留档"或者"某次重大调整前的手动快照"，Git 或者简单的 tar 打包都挺好用。但把它作为跨机双写的核心手段，我是坚决劝退的。
2.3 Syncthing 双写：唯一真正满足"双写"的方案
最后说说我最终采用的方案——Syncthing。这是一个开源的、点对点的文件同步工具，不经过任何第三方云服务器，两台设备之间直接加密传输。它天生就是为"多设备、多端双写、实时同步"设计的，正好对口 WorkBuddy 跨机共用的需求。
为什么它适合 WorkBuddy 场景？关键有三点。第一，双写友好：它采用双向同步，两端任何一端的修改都会实时合并到另一端。第二，冲突处理完善：当同一文件在两台机器上都发生修改时，Syncthing 不会直接覆盖，而是生成冲突副本，命名为xxx.sync-conflict-日期-时间-设备名.ext，保留两版内容，给你人工处理的机会。第三，忽略规则强大：可以精确到子目录和文件名模式，把 cache、锁文件这些垃圾内容彻底排除在同步范围之外。
部署成本也不高。Syncthing 有 Windows 图形客户端、Linux 二进制包、Docker 镜像，手机端也有对应 App。配置好设备互信之后，只要两台机器处于同一个局域网或者都能连通对方，同步就会自动进行，延迟通常只有几秒钟。
我最终的工作流就是"Syncthing 双写 + 版本控制 + 单写多读规则"。下面把完整落地过程写出来。
3. Syncthing 双写落地：目录定位、忽略规则与登录态处理
3.1 先定位 WorkBuddy 的真实数据目录
这一步是重中之重，目录找错了，后面全部白干。不同操作系统的定位方式不太一样，我分别来说。
Linux 和 macOS 可以直接用命令全文搜索，我的实际执行结果是：
find ~ -maxdepth 5 -iname "*workbuddy*" 2>/dev/null | head -50在 Ubuntu 上，我最终确认主要数据位于~/.local/share/workbuddy/和~/.config/workbuddy/，缓存则在~/.cache/workbuddy/。Windows 上我建议先看环境变量，直接在资源管理器地址栏输入%APPDATA%\WorkBuddy和%LOCALAPPDATA%\WorkBuddy，通常这里面藏着会话记录和配置文件。
定位之后别急着同步，先记下两个关键信息：第一，数据目录的整体大小，如果好几个 G 那估计把缓存也包进去了，需要细分；第二，目录内部的子结构，确认哪些是 sessions、哪些是 cache。我自己的做法是先用du -sh *按大小排序，把最大的几个目录列出来，再用find查文件类型，基本就能判断出个子丑寅卯。
3.2 同步目录的初始化与忽略规则编写
Syncthing 的配置过程可以分成三步：设备配对、目录分享、忽略规则。设备配对最省事的方式是用二维码互相扫一下,前提是两台机器在同一个局域网；如果跨网络，就填写对方的设备 ID 并做"引入 device"。
目录分享这一步要特别注意：我建议在一台机器上新建一个干净的目录作为同步根目录，然后让另一台机器以"接受"的方式加入，而不是两台机器各自创建同名目录再手动引入。前者能确保初始状态完全一致，后者容易出现目录结构对不上的问题。
接下来是忽略规则，这是双写方案里技术含量最高的一部分。我的最终配置如下：
// 忽略所有缓存和临时文件 cache/** Cache/** *.tmp *.log *.pid // 忽略锁文件和数据库临时文件 *.lock *.db-journal *.db-wal // Syncthing 自身文件不参与同步 .stfolder .stignore这里我想特别解释一下*.db-wal这个忽略项。很多 AI 工作台会用嵌入式数据库存索引，SQLite 的 WAL 文件记录了未落盘的写入操作。理论上 WAL 也必须跟着主数据库文件一起同步，否则另一端读到的可能是旧数据。但如果 WorkBuddy 正在运行，WAL 在退出的瞬间会合并回主库文件，所以我的做法是：先彻底关闭 WorkBuddy，再触发同步，等同步完成后再启动。
一句话总结忽略规则的核心：优先同步数据类目录，禁止同步锁文件和临时文件。犹豫不决的文件宁可先排除，也不要放进来制造污染。
3.3 登录态和会话数据的同步顺序
双写方案里最容易翻车的点，是两台机器同时启动、同时登录同一个账号，在 Syncthing 还没来得及完成合并的时候就各自写入新会话。这时候两台机器的 sessions 目录都会新增文件，Syncthing 会把两边的新文件都合并进来，这是没问题的；真正出问题的是那种"同一个会话文件两端同时追加内容"的情况。
所以我给双机同步定了一个默认规则：
切换机器时，先让 WorkBuddy 完全退出，等待 Syncthing 状态显示"已同步"，再在另一台机器上启动 WorkBuddy。任何云同步方案都适用这个原则——双写不等于无脑并发写同一个文件。
关于登录态文件，我的建议是同步，但要做好安全准备。WorkBuddy 的登录凭证如果不同步，那每台机器第一次启动后都要重新扫码登录一次，虽然不麻烦，但记忆文件已经同步过去了，体验会有点分裂。如果同步登录态，要注意两点：一是不要把这个同步目录分享给不信任的设备；二是云端备份层面尽量加密。家里两台自己的机器之间同步登录态，风险和便利权衡下来，我选择便利。
4. 五个坑的完整排查记录
4.1 退出不彻底带来的 SQLite 锁库
第一个坑来得很快，第一天配置完 Syncthing 我就遇到了。现象是：Windows 笔记本上正常关掉 WorkBuddy 界面，然后触发同步，几分钟后打开桌面台式机上的 WorkBuddy，直接崩溃，日志里全是"database is locked"。
排查链路是这样的：先用 Windows 的任务管理器检查 WorkBuddy 相关进程，发现主界面虽然关了，但后台还有一个常驻的workbuddy-server进程没退干净。这个进程一直占着 SQLite 数据库文件，Syncthing 同步过去的是一个"正在被写入、尚未完整落盘"的数据库副本，另一台机器打开自然出错。
解决方式也简单：在任务管理器里把所有 WorkBuddy 相关进程全部结束后再同步。同时我在 Syncthing 里对数据库类文件设置了"只在特定时间段同步"的规则，虽然最后觉得鸡肋删掉了，但"先彻底退出再触发同步"这条铁律算是刻进脑子里了。
4.2 跨机路径不一致导致项目全部失踪
同步跑通三天后，我在台式机上发现 WorkBuddy 里的项目索引全部失效，点击任何项目都提示路径不存在。排查之后发现原因令人哭笑不得：我笔记本上的项目放在D:\Users\me\WorkBuddyProjects，而台式机上同样名字的目录在C:\Users\me\WorkBuddyProjects。
WorkBuddy 项目索引里保存的是绝对路径，同步这个索引文件到另一台机器，路径不一致，系统自然找不到项目。这类问题还容易蔓延到 config 文件里：记录了模型缓存位置的绝对路径、某些资源的本机路径，换机后全部失效。
解决办法是统一两端目录结构。我花了一个晚上把两台机器的项目目录、WorkBuddy 数据目录调整成完全一致的相对路径布局，这样同步过去的文件才有意义。这里也呼应了热搜词里"workbuddy 搬迁项目 win"的需求——搬迁本身不难，难的是搬迁后让所有路径在另一台机器上继续有效。
4.3 忽略规则正则误伤记忆目录
第三个坑是我自己写忽略规则时踩的。某个版本我图省事，写了一行类似(?i)*cache*的模糊规则，本意是排除带 cache 字样的所有目录，结果它把名字里任何位置包含 "c-a-c-h-e" 的路径全部排除了。更糟的是我有个 memory 子目录叫cache_memory_hooks，直接中招，导致所有会话记忆完全没有被同步，我在台式机上怎么也看不到笔记本上的新对话记录。
排查过程中我先确认 Syncthing 状态正常，设备连接也好好的，然后去查看了"当前忽略列表"，才发现那个记忆子目录被静默忽略了。Syncthing 有条命令能列出某目录的忽略命中情况，一查就暴露了。
教训就是：忽略规则必须精确到路径片段，比如/cache/而不是全局*cache*。我现在用的是明确子目录加正斜杠限定的写法，宁可多写两行，也不贪图通配符的省事。
4.4 Windows 符号链接权限难题
这个坑属于"云盘软链接方案"的遗留问题，但也值得记录。曾经一度我想在 Windows 上把 WorkBuddy 数据目录软链到云盘目录，执行mklink /D后 WorkBuddy 启动完全正常，但只要一写文件就报"没有足够的权限"或者"文件句柄无效"。
根因是 Windows 的符号链接创建需要管理员权限或者开发者模式，我用普通权限创建了一个"伪链接"，系统虽然接受了，但在实际读写时会受到权限限制。加上云盘客户端会监控链接指向的真实目录，两边一叠加，行为就非常怪异。
排查到最后，我选择了放弃软链接方案，直接用 Syncthing 的本地目录作为 WorkBuddy 的数据目录。这个决定反而让配置简单了一大截，也让我明白了一个道理：在跨机数据打通这件事上，原生同步工具永远比"软链接+云盘"这种组合拳可靠。
4.5 冲突文件与规则文件的单写多读
跑通双写之后，最大的困扰变成了一堆冲突文件。Syncthing 里每天都会出现rules_user.md.sync-conflict-20250112-001.dat这种文件，用倒是能用，但目录越来越脏，强迫症很难受。
查下来发现，冲突主要集中在我两台机器上都会编辑的规则文件上。WorkBuddy 有个特性——通过规则文件控制 AI 的行为方式和输出风格，也就是热搜词里说的"给 workbuddy 定几条规则"。这类文件体积小、编辑频繁、双方都在改，自然是冲突重灾区。
我最后的解法是"单写多读"策略：rules 和 skills 这类配置型文件，只在固定的主力机上修改，另一台机器只读并用。而 sessions 和记忆目录保持双写。这个策略执行之后，冲突文件数量从每天十几个降到了基本为零。中间我为规则文件额外开启过 Syncthing 的"版本控制"，保留最近 30 天版本，即使偶尔改坏了也能快速回滚。
5. 现在我的双机日常与改进建议
5.1 一套务实的双机切换流程
配置稳定运行后，我给自己定了一套切换机器的标准化流程，供参考：
- 下班或离开主力机前，确认 WorkBuddy 里当前会话已经保存，然后彻底退出所有 WorkBuddy 相关进程。
- 打开 Syncthing 界面，看一眼"已同步"状态，确认没有待处理的变化。
- 到另一台机器上，先启动 Syncthing，等待同步完成后再打开 WorkBuddy。
- 如果 Syncthing 弹出了冲突文件提示，先不急着删，点进去看一眼是哪个文件冲突。如果是配置类文件，人工决定保留哪一版；如果是会话记忆文件，通常两边都会保留，不影响使用。
这套流程听起来有些繁琐，但实际做下来也就一分钟以内的事。Windows 上我建议把 Syncthing 设置成开机自启，Linux 上则用 systemd 服务托管，省得每次手动启动。
5.2 围绕双写还能做的备份与安全增强
双写同步解决了"多机一致"的问题，但没解决"误删回滚"和"备份安全"的问题。所以我额外做了两件增强。
第一是启用 Syncthing 的版本控制功能。在目录设置里开启"版本控制—错开版本"模式，保留最近若干天的文件历史。这样即使某天在 A 机上误删了记忆目录中的一个大文件，它在 B 机上的历史版本也还在，随时能捞回来。
第二是给同步目录做定期镜像备份。我写了一个每天凌晨执行的 tar 脚本，把整个 WorkBuddy 数据目录打包到本地另一个磁盘，同时在关键里程碑节点（比如完成一个项目问答库的构建）手动再打一份快照。云端的登录态文件和 token 类内容，我特意从备份脚本里排除掉了，避免备份文件泄露后连带账号一起曝光。
安全性方面还可以更进一步。如果你工作环境对数据隐私要求高，建议对整个同步目录做一层磁盘加密，Windows 上可以用 BitLocker，Linux 上用 LUKS。这类加密是透明的，WorkBuddy 完全无感知，但任何第三方拿到同步文件都只能看到密文。
最后分享一点个人体会：多机共用一个 WorkBuddy 账号，真正考验人的不是"登录"这个过程，而是你对数据流的管理意识。只要搞清楚了哪些数据值得同步、哪些该隔离、什么时候允许双写、什么时候必须单写，这个问题就能稳定地解决。希望这篇实践记录能帮你少走我踩过的那几个坑。
