先说我为什么折腾这件事。白天在实验室或者工位用一台主力机跑 WorkBuddy晚上回家想在另一台机器上接续白天的工作又或者办公室两台工作站一台 Windows 一台 Linux都装了同一个 WorkBuddy 账号想共享同一套项目记忆、角色规则和会话上下文。听起来最简单的方式就是“两台机器登录同一个账号”但真正操作过的人才知道多机共用一个 WorkBuddy 账号最核心的难题是跨机双写同步——两台机器都在同一个账号体系下产生写入一旦写不同步项目文件互相覆盖、AI 记忆错乱、会话历史消失各种怪问题接踵而至。这篇文章是我自己在一台 Windows 和一台 Linux 之间做跨机双写同步的完整实践记录内容包括如何摸清 WorkBuddy 的数据存储边界、如何做配置目录软链接、如何救回换账号后的记忆、以及我在实践过程中踩过的几个典型坑和最终修复思路。适合工作环境不固定、需要在多台电脑之间切换使用 WorkBuddy 的朋友阅读如果你只是初学多机同步也可以在这里建立一套比较立体的思路。1. 先弄清楚跨机共用账号到底在同步什么东西1.1 WorkBuddy 在本地到底存了什么WorkBuddy 这类 AI 编程助手和普通聊天软件最大的区别就是“有状态”。它不是只做一次网络请求然后把结果丢给你而是在本地维护一批与账号、项目、会话相关的数据。只要这些数据没有跟着你走换一台机器登录同一个账号AI 照样“不认识你”。我拆过两台机器的数据目录整理下来大致有这么几层全局账号配置登录态、用户标识、账号凭证。这层不同步换机器等于换了个人。自定义规则与技能你自己写给 WorkBuddy 的规则、预设的技能文件、角色设定。这层决定两台机器上 AI 的“性格”是否一致。项目工作区代码、文档、脚本以及 WorkBuddy 在项目目录下生成的会话记录和局部索引。全局缓存和临时文件对话过程中产生的临时状态、搜索结果缓存、附件缓存等。这类数据高频读写不适合长期同步。本地数据库或索引文件一些版本会把对话记忆和向量索引放进本地数据库跨机同步时非常容易出问题。这五层数据的同步需求完全不一样。最典型的错误是“一股脑全同步”看起来简单实际上后患无穷。1.2 双写的真正难点不在“拷贝”而在并发先明确一个概念如果只是在一台机器上改完另一台开机的时候拉取一下这叫单向同步用 rsync 或者 git 都能搞定。真正的双写场景是两台机器上都运行着 WorkBuddy并且它俩都在工作过程中往同一个项目目录或者同一份配置目录里写数据。我在实验中最常遇到的情况是机器 A 上让 WorkBuddy 重构一个函数它会直接修改项目里的utils.py与此同时机器 B 上又让 WorkBuddy 修复另一个 bug也改了同一个文件。两边各自保存之后只要同步工具把这些版本合到一起几乎必然冲突。更麻烦的是会话状态WorkBuddy 生成回复时会不断写入临时状态文件两边同时进行的时候两个进程会把对方的文件当成过期数据互相覆盖最后谁的状态都不完整。所以做多机共用账号第一原则是能避免并发写就尽量避免实在避免不了就要把“状态类数据”和“文件类数据”分开处理。乐观锁、冲突副本这些解决方案只能减少损失不能从根本上解决并发写入问题。1.3 找到 WorkBuddy 的配置目录和缓存目录动手同步之前必须先把本地的数据目录摸清楚。WorkBuddy 在不同系统上的默认路径不太一样以我实际接触过的位置来说Windows 上常见的位置是C:\Users\用户名\.workbuddy\或者%APPDATA%\WorkBuddy\取决于安装版本。Linux 上一般在~/.workbuddy/或~/.config/workbuddy/。macOS 上则通常是~/Library/Application Support/WorkBuddy/。如果你不确定自己的目录在哪最省事的方法是在 WorkBuddy 设置面板里找到“缓存目录”或“数据目录”相关选项它会直接显示当前路径。另一种办法是看最近修改时间找一个你在 WorkBuddy 里做过操作的时间点然后去用户目录下按修改时间排序看看哪些目录刚刚被改动过基本就是程序在写数据的地方。1.4 同步边界什么该同步什么该隔离经过多轮踩坑我给自己总结了一条同步边界表基本覆盖了我后来所有配置逻辑数据种类是否跨机同步原因账号配置、登录态要同步不带账号信息换机后 AI 等于不认识你规则、技能文件要同步否则每台机器的 AI 风格和技能不一致项目源码与文档要同步这是实际工作的核心会话记录、记忆文件有条件同步适合交接式同步不适合并发实时双向写缓存、临时文件、索引不同步高频读写同步只会制造冲突和额外流量只看这个表会觉得方案很简单但真正执行起来每一行都有对应的技术和工程细节。接下来挨个说。2. 方案选型为什么我没选纯 NAS也没选纯 Git2.1 常见的几种同步手段横向对比我先列一个对比表方便不同场景的人快速定位方案适合内容优点主要缺点网盘OneDrive、坚果云等轻量配置、普通文档部署简单几乎零成本实时性差文件锁支持弱大目录性能下降自建 NASSMB/NFS大文件、团队共享内网延迟低容量大文件锁在某些系统上识别弱小文件性能差Syncthing需要双向实时同步的目录免费开源、双向增量、冲突副本机制没有版本历史合并冲突需要人工介入rsync单向定时备份快、稳定、增量复制单向不能处理并发合并Git源码、文本配置版本可回溯、冲突可管理不适合二进制大文件和高频临时文件2.2 纯 NAS 方案的失败过程最开始我不信邪想的是把 WorkBuddy 的工作区整体挂载到公司的 NAS 共享盘上。这样办公室和家里访问的是同一份文件看起来“天然同步”。实际用了不到一周就放弃了原因有两类。第一是小文件性能。AI 编程助手对项目目录的读写非常频繁经常生成索引文件、临时快照。原来在本地磁盘上毫秒级的操作换到网络共享盘之后延迟明显上升最直观的感受就是 WorkBuddy 执行任务时像“卡住”了一样。第二是文件锁问题。SMB 协议对文件锁的支持跟本地 NTFS、ext4 不一样两个进程同时读写同一个文件的场景下另一方经常读到半截数据。我真的见过同一份 JSON 配置文件两台机器分别读到的长度都不一样随后规则加载直接出错。2.3 纯 Git 方案的失败过程NAS 挂了之后我想不如干脆一点反正项目本身就在用 Git把所有配置、会话记录、缓存全部纳入 Git 管理不就行了结果问题更多缓存目录里有不少较大的二进制文件Git 仓库体积很快膨胀会话记录几乎是分钟级变化提交历史里全是垃圾 commit两台机器同时 commit 再互相 pull冲突数量完全失控最要命的是 WorkBuddy 运行时会自动写入工作区Git 永远提示“有未提交的变更”导致我无法判断哪些是真正需要提交的内容。后来我才想明白Git 适合管理“由人主导、有明确版本意义”的内容比如项目源码、规则文件、技能定义。对于机器自动产生的高频状态数据Git 并不擅长。2.4 最终选型分级处理最后落地的方案不复杂就是按数据类型分层各类用不同的工具项目源码和全局配置走 Git 仓库手动或定时 commit跨机拉取。会话历史和轻量数据用 Syncthing 做双向实时同步但只同步同步目录里的那部分并且排除大量临时文件和锁文件。索引和系统级缓存完全不参与跨机同步修改 WorkBuddy 的缓存目录指向本机独立位置。账号切换统一写成一个脚本保证两台机器切换账号时的步调一致。说白了这个组合拳的难度不在工具本身而在于先接受“不能全盘同步”这个前提。3. 落地实战配置目录软链接 缓存隔离 双向同步3.1 把全局配置统一到一个“可同步”的目录这里的第一步是把 WorkBuddy 默认写在用户目录下的全局配置转移到一个专门的同步目录再用软链接指回去。这样做的好处是程序依然认为自己在原来的位置读写但实际上数据落在了同步目录里由同步工具接管。我在 Linux 上的操作大致是这样# 假设默认目录是 ~/.workbuddy mkdir -p ~/wb-sync/config mv ~/.workbuddy/config/* ~/wb-sync/config/ rm -rf ~/.workbuddy/config ln -s ~/wb-sync/config ~/.workbuddy/configWindows 上的思路一样只是命令改成了目录符号链接mklink /D %USERPROFILE%\.workbuddy\config D:\wb-sync\config需要特别提醒做软链接之前一定先把原始目录完整备份。我见过有人为了省事直接删掉原目录结果程序启动时找不到配置自动生成一个新的空目录导致所有规则全部丢失。3.2 缓存目录必须本机隔离缓存目录是跨机同步里最容易翻车的地方。WorkBuddy 在生成对话时会频繁写入临时状态文件多台机器同时读写同一份缓存目录基本必出问题。正确做法是把缓存目录改到本机单独的位置并确保它不参与任何跨机同步。Windows 下我建议放到类似D:\workbuddy-cache的独立目录不要放在 C 盘用户目录里免得和权限、同步软件纠缠不清。Linux 下建议使用~/wb-cache这样单独的目录不要放在项目里也不要放在同步目录里。修改缓存目录后一定要重启一次 WorkBuddy 验证是否生效。有的版本在设置面板改了并不会立即生效需要重启还有的版本在修改后会自动生成旧路径的遗留文件这时候把旧目录清理掉即可。提示如果程序没有提供图形化修改入口可以看看命令行启动参数很多同类 AI 工具都支持类似--cache-dir的参数。实在不行再直接改配置文件里的 cache 字段。改完要确认目录权限避免程序因为写权限不足而悄悄恢复默认路径。3.3 Syncthing 的忽略规则我只同步想要的那部分在我这套方案里Syncthing 负责会话记录和轻量数据的实时同步。你可以用 Syncthing 同步整个~/wb-sync目录但一定要配置忽略规则否则缓存和临时文件还是会被带进来。参考忽略规则//.git//* //node_modules//* //cache//* //tmp//* //logs//* *.lock 20MB其中//.git//*是为了避免 Syncthing 和 Git 同时操作同一个仓库20MB表示超过 20MB 的文件不同步。这样可以大幅减少冲突同步流量也能保持在很低的水平。还有一个细节Syncthing 对同一文件的并发修改会生成“同步冲突”副本默认文件命名是xxx (Sync Conflict)。如果发现大量冲突副本不要直接全选删除先确认哪一边的版本是新的再手工保留那边。3.4 Git 自动提交适合“交接式”同步对于项目源码和全局配置我最终是用 Git 仓库同步。为了图省事我写了一个自动提交脚本在每天工作结束时跑一次#!/bin/bash # 文件名: wb-git-sync.sh在主力机上执行 cd ~/wb-sync git add -A git commit -m wb auto sync $(date %Y-%m-%d %H:%M:%S) git push origin main在另一台机器上设置定时任务自动拉取# crontab -e每天 22 点拉取 0 22 * * * cd ~/wb-sync git pull --rebase origin main有朋友问为什么不设置成每 5 分钟同步一次。我的经验是自动 commit 过于频繁会把关键提交淹没在垃圾日志里真出了问题反而不方便回看。每天一次或半天一次配合 Syncthing 处理实时性较强的会话数据已经足够覆盖绝大多数跨机协作场景。4. 踩坑实录四个让人头大的同步问题及定位过程4.1 会话历史“串台”A 机器说的话跑到了 B 机器上先描述具体现象我在办公室的机器 A 上写完一段代码让 WorkBuddy 生成解释晚上回到家打开机器 B 想复盘结果对话记录里根本没有下午那一条。再反向操作机器 B 上新建的对话第二天又被机器 A 上的同步覆盖得无影无踪。我的排查过程是这样的先用ls -lt查看两台机器上会话历史目录的文件修改时间看到两边文件修改时间交替变化说明确实存在双向覆盖打开 Syncthing 的冲突列表发现大量xxx (Sync Conflict)副本随机打开冲突副本和原始文件做对比发现它们各自只保存了某个对话的一部分状态。最终定位到的根因是会话状态文件被 WorkBuddy 设计成“本地完整副本”它本身不提供跨进程合并能力。两个进程同时写入同一份会话状态谁也不会拿到完整数据。解决方式就是我前面说的会话记录不参与实时双向同步改为每天结束时单向推送平时即使开着 Syncthing也不让它同步这部分内容。4.2 角色规则被另一台机器的旧版本覆盖这个坑特别典型。某天我发现自己给 WorkBuddy 定的几条规则全部消失连之前导入的技能文件也不见了。一开始我以为是账号被登出了后来排查才发现是另一台机器在几小时前同步了一个旧配置过来把 A 机器上的最新规则覆盖了。定位时做了三件事在全局配置目录下找到规则文件用git log看提交历史果然有一个来自备用机的旧提交覆盖时间和问题出现时间完全吻合查看备用机的同步设置发现它后台自动上传了本地旧配置而备用机的配置从来没拉取过主力机的最新版本根因是两台机器都启用了“自动上传”等于两边都在抢先上传的那台就赢了哪怕它的数据更旧。解决方式很直接对于配置类文件关闭自动上传只做单向拉取改动配置时只在主力机上改改完 push再从另一台机器 pull。这样就不会出现“旧版本覆盖新版本”的问题了。4.3 换账号后如何找回原来账号的记忆这个问题被很多人问过因为搜索热词里频繁出现“workbuddy 换账号如何获得原来账号的记忆”。我先说结论WorkBuddy 的很多记忆数据其实绑定账号标识存在本地换账号后读不到旧账号的数据AI 自然就“失忆”了。我的定位过程在数据目录里找到记忆相关文件目录名一般会包含账号标识例如memory_166xxx之类的切换账号后程序会读取新账号标识对应的目录如果这个目录是空的AI 就表现得像一个完全陌生的人想把旧账号记忆迁移到新账号时不要直接改文件里的账号标识因为数据文件内部可能有校验机制硬改容易导致读取失败正确做法是把旧账号目录下的数据文件整体复制到新账号目录下然后重启 WorkBuddy。多机场景下还有个更隐蔽的坑一台机器登录在旧账号另一台已经切换到了新账号然后同步工具把两边的记忆数据往一起合结果两边都不识别。后来我写了一个“账号切换脚本”强制两台机器按固定顺序操作先退出所有 WorkBuddy 登录再同步账号数据目录最后再登录新账号。实践下来顺序不能乱乱了就出问题。4.4 缓存目录改不了安装方式和权限的坑在 Windows 上第一次尝试修改缓存目录时设置面板改完重启发现缓存又回到了默认路径。排查后才发现是安装版程序的权限问题程序安装在系统目录下普通用户修改配置时没有写入权限软件每次尝试改配置都静默失败所以看起来“改了没生效”。解决方案是二选一以管理员身份运行一次 WorkBuddy在设置中把缓存目录改好之后再正常使用干脆把 WorkBuddy 装到用户目录下绕开系统目录权限限制。这个问题在 Linux 上基本不存在因为用户目录默认可写。但我在 Ubuntu 上还遇到过另一个变种用 Snap 方式安装时程序被放进沙箱环境所有数据都映射在~/snap下面改配置无法直接影响真实系统路径。遇到这种情况优先考虑改用普通安装包不要和图省事用 Snap 版。5. 把方案收敛成一套可以长期复用的工作规则5.1 给双写定边界主写与副本经历了上面那些问题我最终不追求“两台机器实时互相同步”这种理想状态而是把工作流收敛成一套明确规则同一时刻只有一台机器对项目工作区做高频写操作另一台做查看、评审、简单搜索等低负载操作如果确实需要两台机器同时改代码就分配不同的 Git 分支或不同子目录不要共享同一个工作目录。这套规则听起来像妥协实际上是尊重工具机制。WorkBuddy 这类 AI 编程助手本质是单写多读的模型强行做成实时并发双写工具本身没有任何协调机制支撑最后只会变成无穷无尽的冲突。5.2 一个可以复制的同步脚本组合把前面内容整理成一个最简单的“全家桶”脚本供参考#!/bin/bash # wb-sync-main.sh在主力机上执行 set -e WB_SYNC_DIR~/wb-sync # 1. 用 Git 同步项目源码和全局配置 cd $WB_SYNC_DIR git add -A git commit -m wb-main $(date %F %T) || true git push origin main # 2. 用 rsync 单向推送会话历史到备用机的临时目录 rsync -avz ~/.workbuddy/sessions/ backup-host:/tmp/wb-sessions/备用机配合一个拉取脚本#!/bin/bash cd ~/wb-sync git pull --rebase origin main rsync -avz backup-host:/tmp/wb-sessions/ ~/.workbuddy/sessions/实时性要求不高的其他数据可以开着 Syncthing但忽略规则一定要配好。5.3 冲突恢复手册按优先级处理不管怎么配置总数还是会遇到冲突。我的处理顺序是不急着删先看冲突副本两边的修改时间配置类文件以主力机版本为准源码类文件看哪一边的提交逻辑更合理先用git stash保护当前工作区再解决冲突避免在冲突状态下继续同步解决完后本地测试一次确认 WorkBuddy 能正常加载配置再 push 到远端一个大原则如果某个目录反复出现冲突就把它移出实时双向同步改成单向推送。5.4 多机共用账号下我如何调整 WorkBuddy 的“AI 味”搜索热词里频繁出现“workbuddy 减少 ai 味”说明这是个非常普遍的需求。多机同步后更麻烦如果不统一规则两台机器的输出风格会完全不一样同一个账号在不同机器上像两个 AI。我自己给 WorkBuddy 定的规则放在rules.md里主要内容包括禁止使用“通过本文”“综上所述”“首先/其次/最后”这类模板句式回复必须优先给出结论和可执行步骤理论解释放在后面给代码示例时必须注明是在什么系统、什么终端下运行避免跨机环境下直接复制报错不要为了显得严谨而堆砌空泛结论能少说就少说能上代码就上代码。这套规则通过 Git 同步到两台机器后两边的输出风格基本一致。这里再提醒一点规则文件的编辑一定要在主力机上完成并 push避免两台机器同时改完再合并那样的话冲突概率极高。6. 用了一段时间之后的几条固定习惯6.1 固定节奏比实时同步更省心经过这段时间实践我最大的体会是固定节奏比强实时效率更高。每天下班前手动 commit 并 push 一次这个简单习惯比任何全自动同步工具都可靠。自动同步适合处理无状态的数据但对于会话、记忆这类有逻辑上下文的数据一天一次固定推送足够完全不需要秒级同步。6.2 遇到异常先查本地状态别急着怀疑账号多机共用账号后只要 WorkBuddy 行为变得奇怪我的第一反应已经不再是“是不是账号出问题了”而是去看三样东西本地缓存目录是不是被占满了、会话状态有没有被同步覆盖、规则文件是不是被另一台机器拉回成旧版本。这三样查完大概率能定位到问题。说到底跨机双写同步这件事想做得稳就要接受一个现实再好的同步工具也只能负责文件层面的一致性程序自身的状态管理机制决定了哪些文件适合同步、哪些不适合。顺着 WorkBuddy 的数据分布机制去分层处理比强行追求实时完全一致性轻松太多这也是我这个项目里最大的收获。