1. 为什么单账号多端用着用着就“人格分裂”了如果你也在公司一台电脑、家里一台电脑之间反复横跳大概会懂这种感觉白天在办公室给 WorkBuddy 调好的一套规则、顺手教给它的几个技能晚上回家登录同一个账号它愣是一脸陌生。对话历史在线还能翻到但脾气、习惯、技能包全都不见了像换了一个人。更糟的是你在家这台机器上跟它聊出来的新记忆第二天到公司又得从头教。我的设备比较杂公司是一台 Windows 11 台式机家里是一台 Ubuntu 22.04 工作站出差还有一台 Windows 轻薄本。三台机器共用同一个 WorkBuddy 账号听起来很自然实际用起来却是一场灾难。最开始的认知误区是只要账号一样数据就自动一致。后来被现实反复教育才发现账号只是“钥匙”本地那一堆数据文件才是真正的“身体”。这篇内容想解决的就是这个问题如何让一个 WorkBuddy 账号在多台机器上各自落地数据还能保持双向一致。我会把“跨机双写同步”从原理讲到实操再把我踩过的几个大坑完整还原适合所有把 WorkBuddy 当主力工具、又不得不多设备切换的人。1.1 我的实际场景三台机器一个脑子的诉求先说清楚我想要的到底是一种什么体验。我理想中的多机共用账号是这样的在公司电脑上新增了一个技能回家打开笔记本这个技能直接就能用在家给 WorkBuddy 定了几条回答规则改了语气风格第二天到公司它还能保持同样的风格昨天在出差路上聊过一个项目调研今天到公司能接着这个话题继续不用重新喂资料任何一端的配置改动另一端不会偷偷覆盖掉。这本质上就是数据层面的“双写”不只在一个地方写入而是确保多处保持同一份有效数据。很多人以为登录账号就自动完成了实际上 WorkBuddy 的账号体系只解决“你是谁”的鉴权不负责把本地产物搬来搬去。最崩溃的一次经历是我在公司花费整个下午整理了一套很详细的规则文件包括回答长度、术语偏好、禁用词列表一共几十条。回家打开笔记本后我问它“你还记得下午那套规则吗”它回复了一个问号脸。翻遍设置也没找到导入入口最后只能手动复制文本重新教。从那天起我决定不再相信“账号同步”开始认真做跨机双写。1.2 账号同步的边界哪些东西跟着账号走哪些留在本地要理解双写先得理解 WorkBuddy 的存储边界。我把它所有数据粗略分成两类跟着账号走的云端状态和跟着机器走的本地文件。数据类别是否跟着账号同步典型内容我的建议账号信息是登录态、订阅、配额、基础偏好不用管云端会话记录部分在线能翻到的聊天记录、搜索历史不依赖它本地记忆库否长期记忆、人物关系、项目上下文重点同步自定义规则否用户写的 rules 文件、语气约束、禁用词重点同步私有技能否自己制作的 skill 文件夹或脚本重点同步附件与素材否上传的参考文档、图片、生成结果按需同步缓存文件否临时文件、索引、缩略图绝不同步日志与锁文件否运行日志、锁文件绝不同步这个表格是我花了很长时间整理出来的。很多人会问为什么云端会话记录已经有了还要手动同步本地记忆因为云端会话只是“历史对话列表”而 WorkBuddy 真正调用的本地记忆库、规则库、技能库是在运行时直接读取的磁盘文件。跨机共用账号但本地文件分裂表现出来就是同一个人换了副脑子。有一个很容易误导人的说法是“换账号后还能获得原来账号的记忆”我实测之后可以负责任地讲记忆不在账号里在本地数据目录里。换账号如果不同时迁移本地目录新账号看到的就是白纸一张。这个点也是我做跨机双写最初的动机。1.3 为什么说双写优于备份可能有人会说多机同步不就是备份吗我把公司电脑的配置复制到 U 盘回家再拷贝过去就好了。备份思维和双写思维有本质区别备份是单向的、快照式的你复制的时候是什么时间点恢复的时候就是什么时间点中间的新改动全丢双写是持续双向的任何一端产生新数据另一端很快也能拿到两边始终往同一份“真相”收敛备份适合“怕丢”双写适合“要一致”。做双写最理想的形态其实是“单写多读”的简化版让多台机器读写同一个物理目录目录本身由同步工具负责在多端之间搬运。这样任何一端写入另一端通过同步拿到更新形式上像是双写实际上数据只有一份权威版本。听起来很美好实现起来全是细节。比如 WorkBuddy 的数据目录到底在哪、缓存目录怎么改、符号链接会不会引发软件罢工、两台机器同时打开会不会锁文件——这些问题我下面一个个拆开讲。2. 动手前先摸清 WorkBuddy 的本地数据布局做任何同步方案之前必须先搞清楚数据在哪里。这一步如果偷懒后面所有操作都是在盲人摸象。WorkBuddy 在不同系统上的数据目录差异很大我一开始就因为在 Windows 上找不到目录浪费了一个晚上。2.1 数据到底藏在哪三个容易被混淆的目录WorkBuddy 实际会维护三个职能不同的目录它们经常被人混为一谈配置目录保存账号信息、界面偏好、配置文件列表通常体积很小但是最敏感一旦丢失就需要重新登录和设置。数据目录是最核心的里面放着技能、规则、记忆库、会话数据这才是你真正“养”出来的资产。缓存目录则存放临时文件、索引、缩略图它最大的特点是可以随时删除删了不影响核心数据只是下次启动会重新生成。常见的默认位置如下不同版本和安装方式可能有差异以你机器上的实际路径为准系统配置目录数据目录缓存目录Windows%APPDATA%\WorkBuddy%LOCALAPPDATA%\WorkBuddy%TEMP%\WorkBuddyWindows 便携版安装目录下data安装目录下data安装目录下cacheLinux~/.config/workbuddy~/.local/share/workbuddy~/.cache/workbuddymacOS~/Library/Application Support/WorkBuddy同上~/Library/Caches/WorkBuddy刚开始我在 Ubuntu 上只找到了~/.config/workbuddy里面只有几十 KB 的配置文件翻了半天没看到规则和技能差点以为数据全在云端。后来用文件监控工具一查才发现真正的资产都在~/.local/share/workbuddy下面。判断哪些目录值得同步原则很简单凡是删除后会让你重新“养一遍”的目录都要同步凡是删了会自动再生成的目录都不要同步。2.2 缓存目录为什么必须先改我把缓存目录单独拿出来讲是因为它最容易坑人也最容易被忽略。WorkBuddy 默认会把缓存放在系统临时目录里好处是系统不会乱动它坏处是它和配置、数据混在一起时你会误以为整个数据目录都需要同步。缓存目录有什么特点第一是体积膨胀快我仅仅用了两周缓存目录就涨到 2.3GB第二是文件琐碎几千个小文件在同步时会极大拖慢速度第三是随时可以删除它和账号资产没有半毛钱关系。为了跨机双写第一步不是在同步盘建目录而是打开 WorkBuddy 的设置面板找到存储或缓存相关选项把缓存目录手动改到一个“不参与同步”的本地位置。我给每台机器都设置成各自的系统临时目录下的固定子目录例如 Windows 用%TEMP%\workbuddy-cacheLinux 用~/.cache/workbuddy-sync-off。改完之后即使同步盘出了问题缓存重建也只是时间问题核心资产完全不受影响。网上很多人讨论“WorkBuddy 缓存目录怎么更改”其实入口就在设置里并不难。关键在于你要意识到缓存必须从同步范围里剔除这是一个战略性动作不是可选项。2.3 用文件监控确认写入路径光看默认目录还不够因为有些版本会把会话数据、数据库引擎文件偷偷写到别的角落。我不会盲目信任文档直接用了文件监控来确认。Windows 上我用的方法是任务管理器里的性能监视或者更细一点用 Process Monitor过滤进程名为 WorkBuddy并监视文件写入事件。Linux 上更简单可以用lsoflsof -p $(pgrep -f workbuddy) 2/dev/null | grep -E REG|cwd|txt | awk {print $NF} | sort -u也可以直接监听目录变化inotifywait -m -r -e modify,create,delete --format %w%f ~/.local/share/workbuddy用这种方式我能清晰看到每次对话、每次新增技能时真正被写入的是哪些文件。结果发现 WorkBuddy 会把一个memory.sqlite数据库放在数据目录下会话记忆全在里头而规则和技能则是纯文本文件散落在rules和skills子目录。这些信息比任何教程都靠谱也直接决定了我后面同步范围的划分。3. 跨机双写同步的落地目录迁移 符号链接我的最终方案可以概括成一句话把 WorkBuddy 的数据目录从系统默认位置挪到云同步盘然后在原位置创建一个符号链接让程序无感知地读写同步盘。这也是网上讨论“WorkBuddy 搬迁项目到 Windows”时最值得参考的思路。3.1 先想清楚方案复制文件夹还是让程序直接读写同步盘多机数据一致的做法大体有三种我对比过之后才确定方向。方案优点缺点适合人群手动导出/导入最轻量不依赖任何工具容易漏文件忘记导就白干无法做到双向一致偶尔切换设备定时脚本双写灵活可以自定义同步范围脚本要处理冲突、锁、日志复杂度很高有编程能力的人目录迁移 符号链接单一数据源程序直读同步盘一致性最好需要处理同步冲突对符号链接机制有要求追求长期稳定的人我选第三种。它的本质是让所有设备不再各自维护一套独立数据而是共用同一份数据文件。你看看这像不像“双写”从用户视角看两台机器都在向同一份数据写入确实等效于跨机双写。为什么不用脚本因为脚本只有在“你记得运行它”的时候才有效。有一次我在公司改完规则直接关了电脑忘了跑导出脚本回家打开发现一切都还是昨天的状态那一刻我就决定不再依赖自己的记性。3.2 第一步把 WorkBuddy 数据迁到同步盘准备工作是在每台机器上装好云同步客户端。我用的是 Syncthing 自建同步商业网盘文件锁定和冲突处理策略通常不如它灵活如果你不想折腾用坚果云、OneDrive 这类产品也可以但后面踩坑章节会提到它们的局限性。迁移步骤我按顺序记录如下每一步都不要跳完全退出 WorkBuddy包括托盘图标和后台进程。Windows 下打开任务管理器确认所有带 WorkBuddy 字样的进程都消失。在同步盘里新建一个目录名叫WorkBuddyData这个目录就是未来的“数据主权中心”。把本机默认数据目录整体复制到WorkBuddyData。注意是复制不是移动原目录先保留着这是保险。复制完成后核对文件数量和总大小确认没有遗漏。把原数据目录重命名为WorkBuddyData.old原路径暂时空缺。在原路径位置创建符号链接指向同步盘里的WorkBuddyData。启动 WorkBuddy确认它能正常读取技能、规则、历史记忆。验证通过后删除WorkBuddyData.old。这里特别强调第五步的作用如果直接把原目录删掉再去建链接中间存在一个“空窗期”程序一旦在空窗期内被某个服务触发启动就会自动初始化一套全新目录污染整个同步体系。重命名可以最大限度缩短空窗期。3.3 第二步原路径做符号链接让程序“找到”新家数据在同步盘里WorkBuddy 还不知情因为我动的只是数据文件本身没有改任何程序配置。符号链接就是那座桥。Windows 下我建议用目录联接而不是普通符号链接mklink /J C:\Users\你的用户名\AppData\Roaming\WorkBuddy D:\Sync\WorkBuddyData注意第一段路径必须是原数据目录的完整路径不同安装方式可能落在%APPDATA%或%LOCALAPPDATA%先确认。Linux 下用软链接就可以ln -s ~/sync/workbuddy-data ~/.local/share/workbuddy为什么 Windows 上我推荐/J而不是/D因为/D创建的符号链接在有些软件眼里会被当作“快捷方式”处理扫描目录时直接跳过甚至触发ERROR_ACCESS_DENIED。/J创建的是目录联接从应用层看和真实目录几乎完全一致兼容性更好。另外/J通常不需要管理员权限遇到权限问题再考虑用开发者模式或管理员命令行。创建完链接后用资源管理器看一眼原路径如果进去能看到完整的文件夹结构而且地址栏上标注着“链接”或“联接”就说明成功了。3.4 第三步第二台机器如何接入第二台机器接入的顺序比第一台更容易出错。我到了第三台设备才总结出正确流程先不要急着装 WorkBuddy。先把同步盘里的WorkBuddyData同步到本机确认数据完整性之后再安装软件。如果软件已经装过并启动过它会自动生成一个默认数据目录。这时候按这个顺序处理退出软件检查默认数据目录里有没有你本机产生的旧资产。如果从来没有用过直接删除即可如果没有旧资产可以放心地把自动生成的目录删掉创建符号链接指向已同步到本机的WorkBuddyData启动软件验证。最容易翻车的动作是先让软件以默认模式启动一次创建出一堆无关的配置然后这些配置又通过同步盘传到了其他机器。虽然不致命但会污染数据目录让每一端都多出一些噪声文件。3.5 初始化后自检怎么确认“双写”真的生效了链接建好不等于同步成功。我每次换新机器都会做一组自检几秒钟就能确认状态在 A 机器上打开规则文件加一行注释比如“这是来自 Windows 的标记”保存后等待同步工具完成上传。再在 B 机器上打开同一个文件看这行注释是否出现。如果出现说明读写链路打通。再用 WorkBuddy 实际测试一轮在 A 机器新建一个空白技能命名一个独一无二的名字看 B 机器是否出现。如果技能没有出现大概率是同步范围没覆盖skills目录而不是同步没生效。最后一步检查缓存目录是否还在本地看 Volume 大小增长是否异常。如果缓存目录也被同步到云盘你会看到大量临时文件在两端飘来飘去这时候必须回去把缓存目录改掉。4. 踩坑实录跨机同步最容易翻车的四个场景方案听起来简单实际操作时我摔了不止一次。下面这四个坑每一个都是真金白银换回来的经验从现象、排查到解决完整记录方便你复现排查思路。4.1 符号链接创建后程序直接罢工第一次在 Windows 上做完迁移启动 WorkBuddy结果界面闪了一下就没了。重启还是同样的问题。当时第一反应是数据目录坏了吓得赶紧把WorkBuddyData.old改名想恢复结果一恢复就能启动。这说明问题不在数据而在链接本身。排查链路如下先用命令行检查链接是否真实存在dir C:\Users\用户名\AppData\Roaming\WorkBuddy输出显示JUNCTION字样说明链接创建成功。继续检查指向的目标路径是否能正常访问结果发现目标路径里多了一层嵌套——我把数据放在了D:\Sync\WorkBuddyData但建链接时不小心把链接指向了D:\Sync\WorkBuddyData\WorkBuddyData里面的结构自然不对了。重新把链接删掉检查目标路径的层级确认里面直接就是rules、skills这类子目录而不是再套一层同名目录重新建链接后程序恢复正常。教训链接指向的目录层级必须是软件认的那个“数据根目录”多一层少一层都不行。还有一些情况是权限问题。如果 WorkBuddy 以管理员权限运行而链接路径所在磁盘不允许快速写入也会表现成启动失败或无法保存配置。解决方法把同步盘路径放到一个有完整读写权限的本地磁盘不要用纯虚拟盘或 WebDAV 盘。4.2 两台机器同时在线SQLite 锁片与文件冲突我的方案是让两台机器共用一个memory.sqlite数据库文件。这个文件就是本地会话记忆的存储引擎。一开始很天真觉得既然同步工具能传文件那两边同时开应该也没问题。结果就是一条报错database is locked。SQLite 这类文件型数据库本身就不适合被两个进程同时跨网络写入哪怕只是毫秒级的并发也会产生锁冲突。更麻烦的是锁冲突时同步工具还在后台同步可能把锁状态或半写入的文件也当成正常文件传到另一端造成数据损坏。折腾很久之后我把策略调整为错峰使用同一时间只在一台设备上运行 WorkBuddy 做高频写入另一台需要查阅记忆时只读不写。如果确实需要两台同时干活就把memory.sqlite排除在同步范围之外只保留规则、技能、配置这类低频纯文本文件的同步。错峰使用听起来笨但实际最稳。同步工具适合传“静态文件”不适合传“正在被进程写入的文件”。理解了这个本质很多问题就能提前避开。4.3 冲突副本把新规则覆盖回旧版本这个坑是我踩得最深的一次直接让我丢了一整天的劳动成果。事情经过是这样的周五下午在公司电脑上我把规则文件改了一个多小时保存后正常退出。下班时我以为同步工具已经把文件传上去了可以安心回家。但我忽略了一件事——家里的笔记本从早上起一直开着WorkBuddy 和同步工具都活着它持有的还是一个旧版本的文件。到了周六我打开笔记本同步工具发现公司上传的新版本和本地旧版本不一致按默认策略生成了冲突副本。而笔记本上的 WorkBuddy 依然在运行某个后台任务把旧版本写回了文件并把这个旧版本再次同步到云端。周日晚上回到公司打开电脑看到规则文件已经变成旧版新规则全部消失冲突副本里才有完整的新内容。排查过程很痛苦先看文件修改时间发现公司版本和家庭版本的时间戳互相矛盾再看冲突副本才确定新内容被旧版本覆盖了。恢复方法是把冲突副本里最新的内容手动合并回主文件。从那以后我把所有同步工具的冲突策略都改成了“保留两侧”而不是“自动覆盖”。即使产生冲突副本至少不会再悄无声息地丢数据。其次凡是规则、技能这类核心资产我都在改动后立即手动触发一次同步确认不依赖自动同步。4.4 Windows 路径分隔符在 Linux 上失效同步盘里的文件是纯文本本身没有平台差异。但配置文件里如果写了硬编码的绝对路径跨机同步就会出问题。我在 Windows 上某个规则文件里引用了附件目录写的路径是D:\Sync\WorkBuddyData\attachments。Windows 上一切正常但这份文件同步到家里的 Ubuntu 后WorkBuddy 尝试读取这个路径时直接报错因为它根本不存在D:这个概念。排查过程很直白在 Linux 上打开规则文件发现里面的路径分隔符全是\一眼就看出问题。解决方式有两个要么把附件路径改成相对路径比如attachments/这种写法让程序基于数据根目录解析要么在每台机器上单独维护一个“本机路径映射”的配置文件把这个文件排除在同步之外。更彻底的方案是让所有设备统一用~/WorkBuddyData这样的结构各平台都把数据目录放到用户目录下路径前缀保持一致。Windows 上虽然真实路径是C:\Users\xxx\WorkBuddyData但程序内部如果用相对路径解析就不会被盘符差异影响。现在我会给所有规则和技能文件立一条规矩任何路径都写相对路径绝对路径一律不允许进入同步文件。5. 让“记忆”和“脾气”也跟着走的进阶配置解决完基础同步下一步是把 WorkBuddy 的“人格”完整搬过去。所谓人格就是它的记忆、技能、规则也就是网上很多人讨论的“给 WorkBuddy 定几条规则”“减少 AI 味”的实现基础。5.1 技能包、规则库、会话记忆分别怎么同步技能包本质上是文件夹里面装着指令文本、参考文件、可执行脚本。它的同步最简单只要skills目录在同步盘里新增技能就会自动传到其他设备不需要任何额外操作。规则库则是一组纯文本文件。我自己维护了一个rules.md把语气约束、禁用词汇、回答长度、术语习惯全部写进去。这个文件是整个“人格”的核心它同步好了所有设备的回答风格就一致了。会话记忆最复杂因为它存在memory.sqlite和几个 JSONL 日志里。我的建议是把即时会话日志排除在同步之外因为这些文件写入频率太高很容易触发锁冲突。长期记忆如果很重要可以单独导出成摘要文本放进规则库作为“可迁移的人设包”。这也是我解决“换账号如何获得原来账号的记忆”这个问题的终极方式不追求复制整个数据库而是把关键事实和偏好沉淀成规则文件跟账号无关跟设备无关。5.2 如何用规则文件降低“AI 味”网上关于“WorkBuddy 减少 AI 味”的讨论很多我的实践经验是靠规则文件最有效。每次给 WorkBuddy 定规则我都会明确写清楚“不做什么”回答不要以“首先、其次、最后”这样的逻辑词开头不要用“总的来说”“综上所述”这类套话收尾不要每句话都说“您”“亲”默认称呼用“你”不要堆砌过多的同义形容词直接给结论允许在信息不完整时直接说“我不确定”而不是编造。这些规则全部维护在一份rules.md里通过跨机双写同步到所有设备。只要这份文件在不管我在哪台机器上打开 WorkBuddy它都保持同样的说话习惯。换个角度理解规则文件就是它的“性格快照”有了快照换机器换账号都不怕。5.3 用 git 给 WorkBuddy 数据做版本管理当同步范围越来越小、只剩核心资产时我引入了一个比云盘更可靠的版本管理工具git。在WorkBuddyData目录里初始化仓库只跟踪配置、规则、技能这些文本资产忽略缓存和数据库cd ~/sync/workbuddy-data git init.gitignore示例.git/ cache/ *.sqlite *.log attachments/ tmp/每次改动后手动或定时执行提交git add -A git commit -m update rules多台机器之间用git pull/git push同步相当于给双写方案加了一层保险丝。云盘负责文件搬运git 负责版本历史。一旦出现冲突副本或误删我随时可以回滚到之前的提交不再只能依赖云盘的审计日志。这个方案虽然不是零门槛但一旦习惯你会觉得云盘的冲突策略压根不够看。规则文件本来就是高频小改动git 的合并能力完全够用。6. 一些想劝退你、但遇到时能保命的细节写这篇内容的时候我反复提醒自己不要只讲做法不讲边界。跨机双写同步不是万金油有些场景真不适合硬上。下面这些判断标准是我踩完坑之后的真实体感。6.1 什么样的多机场景根本不该用双写如果两台机器需要同时在 WorkBuddy 里高频写入比如这边开着自动处理任务那边还有人机对话那双写方案大概率会让你崩溃。文件型存储撑不住这种并发sqlite 会疯狂报错同步盘会疯狂产生冲突。如果同步盘本身是一个只有网页入口、没有本地同步客户端的云服务那就更别折腾了。符号链接必须指向本地磁盘程序读写的是本地路径不可能直连一个网页接口。如果只是偶尔出差用一次 WorkBuddy我更建议轻量方案把rules.md和skills手动打包微信发给自己另一个设备上导入。几分钟搞定比维护一整套双写体系划算得多。6.2 同步范围必须做减法哪些要同步哪些绝不同步我见过不少人配置同步时一上来就把整个数据目录全选结果同步盘体积瞬间被缓存撑爆冲突副本堆积如山。同步范围应该做减法我最终的划分是同步范围具体内容原因必须同步配置、rules.md、skills、记忆摘要文本构成“人格”和核心资产按需同步附件、参考素材体积大容易产生冲突绝不同步缓存、临时文件、日志、sqlite 锁文件高频写入同步会锁死这个划分花了我好几个星期才稳定下来。现在同步盘里总共只有不到 5MB 的核心文件同步速度流畅到没感觉再也不担心云盘限速。6.3 我的最终配置与一点心里话现在我的每台机器都是这套结构Windows 公司机%APPDATA%\WorkBuddy通过目录联接指向D:\Sync\WorkBuddy\RootLinux 家庭机~/.local/share/workbuddy通过软链接指向~/sync/workbuddy/root缓存目录各机独立不参与同步核心资产统一由 Syncthing 做文件级同步再用 git 做版本管理最后分享一个我自己的心得折腾双写这么久收获最大的一句话是——数据目录才是真正的本体账号只是钥匙。每次换机器、换账号、重装系统我第一反应永远是“把数据目录带过去”而不是“登录一下就好”。想保持 WorkBuddy 在多台机器上的一致性记住这一点你已经赢了 80%。剩下的 20%就是耐心处理同步冲突、把缓存挡在门外以及接受“同步工具永远比你的习惯慢半拍”这个现实。