ARTICLE · 1196769
换台电脑AI助手就失忆?我踩了三个坑
公司一台电脑，家里一台电脑，同一个账号登录。
技能装在公司的机器上，回到家打开，全没了。更难受的是记忆——你在公司那台机器上跟它磨了两个月，把你的脾气、规矩、项目的坑一条条喂进去；换台机器，它又变回一个客气而陌生的新助手，什么都要从头说一遍。
这不是你没配置好。这是本地 AI 助手的通病：人格和技能存在本地文件里，而本地文件不会自己长腿跑到另一台机器上。
我用 Syncthing 把这件事解决了，跑了两个月。这篇写清楚怎么配，以及——更重要的是——哪些东西绝对不能同步，这部分我踩过坑。
WorkBuddy 的所有本地状态都在 ~\.workbuddy\ 这个目录下。但这个目录不能整体同步，里面混着三类物理上就不该跨机器的东西。
数据库那条最容易想当然。有人觉得"加条忽略规则不就行了"——不行。规则会写错，写错一次数据库就废了。
我的做法是让 Syncthing 直接指向五个目标子目录，而不是同步整个 .workbuddy\ 再用规则往下排除。这样数据库从物理上就不在同步范围内，不存在"规则写错了"的可能。
五个同步文件夹的分工
注意第四和第五个——这两个是最容易搞混的地方，也是我踩得最狠的一个坑，下面单说。
真正的凭证藏在 ~/.workbuddy/connectors/<用户ID>/ 里，名字是 .credentials.v3.json 和 .master.key。
这两者是设备绑定的，两台机器的 .master.key 不一样。同步等于让两台机器抢着写同一个文件——我实测产生了 3 个 sync-conflict 副本，然后两边的连接器都开始随机掉线。
解决办法是在 ~/.workbuddy\connectors\ 建一份 .stignore：
.credentials.v3*.master.key**sync-conflict*~syncthing~*
这样凭证各自保管、互不覆盖，而 mcp.json、connector-states.json 照常同步。
.stignore 这个文件本身不会被同步，两台电脑要各建一份。这点很多人漏掉。这是全文最值钱的一段。
WorkBuddy 每次会话开头注入的那份记忆，实际读的是：
~\.workbuddy\user-<uid>-personal\MEMORY.md
不是~\.workbuddy\memory\ 里那份。
区别在于：~\.workbuddy\memory\<uid>_memory.md 是服务端生成的画像缓存，版本号和更新时间由云端管，本地写会被覆盖——它跨机本来就自动一致，同步它没有意义。而 user-<uid>-personal\MEMORY.md 才是每次会话真正读的那份，里面是你所有的硬规矩。
我原来的四个文件夹没覆盖这个目录，结果第二台机器读到的全是它自己几个月前的旧版本。
更隐蔽的是，我写的 push-profile.cmd 原先同步的是 ~\Sync\WorkBuddy-Profile\MEMORY.md——那份是 2026-08-14 的、209 字节的旧版，跟真正在用的版本早就脱节了。也就是说，我一度以为在同步记忆，其实在同步一份化石。
修好之后，脚本分成两路：
rem 身份文件仍在 .workbuddy 根robocopy "%SRC%" "%DST%" SOUL.md IDENTITY.md USER.md settings.jsonrem 记忆文件改走 user-<uid>-personal\robocopy "%PSRC%" "%DST%" MEMORY.md MEMORY-INDEX.md
pull-profile.cmd 里还加了一道保护——目标目录不存在就直接中止：
if not exist "%PDST%" ( echo ERROR: %PDST% not found. echo Aborting to avoid overwriting %DST%\MEMORY.md with memory-layer content. exit /b 1)
没这道保护，一旦目录名对不上，记忆内容会被错写进根目录，把旧的假文件覆盖成新的假文件，更难发现。
自动化任务存在 workbuddy.db 里。数据库不能同步，所以任务也不会自动跟过去。
只能导出成 JSON，在第二台上逐条重建。导入前有两件事必须注意：
1. 路径是写死的。 我那批 Sequoia-X 的定时任务，提示词里硬编码了 C:\Users\czarg\... 的项目目录和 Python 虚拟环境。第二台用户名不同、或者没配那个环境，任务必然失败。
2. 别两台都激活。 两台机器同时跑定时任务 = 数据重复同步、消息重复推送。建议只在一台上启用，另一台留作备用。
导出时我把状态统一设成 PAUSED，就是防止一导入就在两台机器上同时炸开。
搞清楚边界，比搞清楚方法更重要。
历史会话列表。我一开始以为是配置问题，后来发现 WorkBuddy 另有独立的云同步通道 EdgeSync（日志在 ~\.workbuddy\logs\<日期>\edge-sync.log，本地映射库是 edge-sync-mapping-v4.db）。
我建了个测试任务实测：
云端记录里几个关键字段说明了原因：会话被打成 "type": "local"、带 sourceDeviceId 绑定源设备，而列表接口按这个字段过滤。
所以历史任务列表跨设备不可见，是产品当前的设计，不是你配置错了。别在这上面浪费时间。
开机自启。两台机器都要配。脚本我写了路径探测，因为 winget 安装和手动解压的路径不一样，单一硬编码路径换台机器就静默失效：
set "ST=%LOCALAPPDATA%\Microsoft\WinGet\Links\syncthing.exe"if not exist "%ST%" set "ST=%LOCALAPPDATA%\Programs\Syncthing\syncthing.exe"
如果不想长期维护同步，还有个一次性方案：技能市场里有 workbuddy-migration-assistant，打包成一个 zip 搬到新机器再恢复。
我扒了期讲这个的视频（11 分钟），实测数据是这样：3.1GB 资产压成 352MB（约 8:1），打包 20 分钟、恢复 20 多分钟，消耗 3.3 积分。三种预设里 lite 适合换电脑。
两条路怎么选：
我的看法：长期双机用 Syncthing，偶尔换机器用迁移助手。 那 40 分钟的等待，重复三次就超过配置同步的时间了。
另外说一句，视频方案也有它没讲透的地方——迁移完技能可能缺几个，缺的恰好是依赖连接器的那批，因为连接器授权没跟过去。这个坑跟上面凭证撞车是同一类问题：凡是跟设备身份绑定的东西，都跨不过去。
1. 两台必须同时在线才能传。关机期间的改动会攒着，下次同时在线补传——不会丢，但也不会凭空过去。
2. 首次全量同步要把整个技能目录传一遍（我现在是 116MB），之后每次改动才是秒级。
3. 别再用网盘同步同一批目录，两套机制会打架。
4. 别在同步进行时两台机器同时大量改技能，容易出冲突副本。
5. 跨局域网时走中继，能同步但速度下降。
这套东西真正难的不是装 Syncthing——那十分钟就能搞定。难的是搞清楚哪些文件代表"你"，哪些文件只是这台机器的临时产物。
技能是通用的，可以搬。记忆是通用的，可以搬。人格设定是通用的，可以搬。
数据库不是。凭证不是。缓存不是。
配完之后，我在公司机器上改一句 SOUL.md，回家打开电脑，它已经知道了。这个感觉值那两小时的折腾。
*文中所有路径、脚本、实测数据均来自本机真实配置（Syncthing v2.1.5，设备 Windows-BACKUP ↔ DESKTOP-0EVUAVO，2026-09-14 起运行）。*
