企业官网建设流程全解析

1. 为什么单账号多端用着用着就“人格分裂”了

如果你也在公司一台电脑、家里一台电脑之间反复横跳，大概会懂这种感觉：白天在办公室给 WorkBuddy 调好的一套规则、顺手教给它的几个技能，晚上回家登录同一个账号，它愣是一脸陌生。对话历史在线还能翻到，但脾气、习惯、技能包全都不见了，像换了一个人。更糟的是，你在家这台机器上跟它聊出来的新记忆，第二天到公司又得从头教。

我的设备比较杂：公司是一台 Windows 11 台式机，家里是一台 Ubuntu 22.04 工作站，出差还有一台 Windows 轻薄本。三台机器共用同一个 WorkBuddy 账号，听起来很自然，实际用起来却是一场灾难。最开始的认知误区是：只要账号一样，数据就自动一致。后来被现实反复教育才发现，账号只是“钥匙”，本地那一堆数据文件才是真正的“身体”。

这篇内容想解决的，就是这个问题：如何让一个 WorkBuddy 账号在多台机器上各自落地，数据还能保持双向一致。我会把“跨机双写同步”从原理讲到实操，再把我踩过的几个大坑完整还原，适合所有把 WorkBuddy 当主力工具、又不得不多设备切换的人。

1.1 我的实际场景：三台机器，一个脑子的诉求

先说清楚我想要的到底是一种什么体验。我理想中的多机共用账号是这样的：

• 在公司电脑上新增了一个技能，回家打开笔记本，这个技能直接就能用；
• 在家给 WorkBuddy 定了几条回答规则，改了语气风格，第二天到公司它还能保持同样的风格；
• 昨天在出差路上聊过一个项目调研，今天到公司能接着这个话题继续，不用重新喂资料；
• 任何一端的配置改动，另一端不会偷偷覆盖掉。

这本质上就是数据层面的“双写”：不只在一个地方写入，而是确保多处保持同一份有效数据。很多人以为登录账号就自动完成了，实际上 WorkBuddy 的账号体系只解决“你是谁”的鉴权，不负责把本地产物搬来搬去。

最崩溃的一次经历，是我在公司花费整个下午整理了一套很详细的规则文件，包括回答长度、术语偏好、禁用词列表，一共几十条。回家打开笔记本后，我问它“你还记得下午那套规则吗”，它回复了一个问号脸。翻遍设置也没找到导入入口，最后只能手动复制文本重新教。从那天起，我决定不再相信“账号同步”，开始认真做跨机双写。

1.2 账号同步的边界：哪些东西跟着账号走，哪些留在本地

要理解双写，先得理解 WorkBuddy 的存储边界。我把它所有数据粗略分成两类：跟着账号走的云端状态，和跟着机器走的本地文件。

这个表格是我花了很长时间整理出来的。很多人会问，为什么云端会话记录已经有了，还要手动同步本地记忆？因为云端会话只是“历史对话列表”，而 WorkBuddy 真正调用的本地记忆库、规则库、技能库，是在运行时直接读取的磁盘文件。跨机共用账号但本地文件分裂，表现出来就是同一个人换了副脑子。

有一个很容易误导人的说法是“换账号后还能获得原来账号的记忆”，我实测之后可以负责任地讲：记忆不在账号里，在本地数据目录里。换账号如果不同时迁移本地目录，新账号看到的就是白纸一张。这个点也是我做跨机双写最初的动机。

1.3 为什么说双写优于备份

可能有人会说，多机同步不就是备份吗？我把公司电脑的配置复制到 U 盘，回家再拷贝过去就好了。备份思维和双写思维有本质区别：

• 备份是单向的、快照式的，你复制的时候是什么时间点，恢复的时候就是什么时间点，中间的新改动全丢；
• 双写是持续双向的，任何一端产生新数据，另一端很快也能拿到，两边始终往同一份“真相”收敛；
• 备份适合“怕丢”，双写适合“要一致”。

做双写最理想的形态，其实是“单写多读”的简化版：让多台机器读写同一个物理目录，目录本身由同步工具负责在多端之间搬运。这样任何一端写入，另一端通过同步拿到更新，形式上像是双写，实际上数据只有一份权威版本。

听起来很美好，实现起来全是细节。比如 WorkBuddy 的数据目录到底在哪、缓存目录怎么改、符号链接会不会引发软件罢工、两台机器同时打开会不会锁文件——这些问题我下面一个个拆开讲。

2. 动手前先摸清 WorkBuddy 的本地数据布局

做任何同步方案之前，必须先搞清楚数据在哪里。这一步如果偷懒，后面所有操作都是在盲人摸象。WorkBuddy 在不同系统上的数据目录差异很大，我一开始就因为在 Windows 上找不到目录浪费了一个晚上。

2.1 数据到底藏在哪：三个容易被混淆的目录

WorkBuddy 实际会维护三个职能不同的目录，它们经常被人混为一谈：

配置目录保存账号信息、界面偏好、配置文件列表，通常体积很小，但是最敏感，一旦丢失就需要重新登录和设置。数据目录是最核心的，里面放着技能、规则、记忆库、会话数据，这才是你真正“养”出来的资产。缓存目录则存放临时文件、索引、缩略图，它最大的特点是：可以随时删除，删了不影响核心数据，只是下次启动会重新生成。

常见的默认位置如下，不同版本和安装方式可能有差异，以你机器上的实际路径为准：

刚开始我在 Ubuntu 上只找到了~/.config/workbuddy，里面只有几十 KB 的配置文件，翻了半天没看到规则和技能，差点以为数据全在云端。后来用文件监控工具一查，才发现真正的资产都在~/.local/share/workbuddy下面。

判断哪些目录值得同步，原则很简单：凡是删除后会让你重新“养一遍”的目录都要同步；凡是删了会自动再生成的目录，都不要同步。

2.2 缓存目录为什么必须先改

我把缓存目录单独拿出来讲，是因为它最容易坑人，也最容易被忽略。WorkBuddy 默认会把缓存放在系统临时目录里，好处是系统不会乱动它，坏处是它和配置、数据混在一起时，你会误以为整个数据目录都需要同步。

缓存目录有什么特点？第一是体积膨胀快，我仅仅用了两周，缓存目录就涨到 2.3GB；第二是文件琐碎，几千个小文件在同步时会极大拖慢速度；第三是随时可以删除，它和账号资产没有半毛钱关系。

为了跨机双写，第一步不是在同步盘建目录，而是打开 WorkBuddy 的设置面板，找到存储或缓存相关选项，把缓存目录手动改到一个“不参与同步”的本地位置。我给每台机器都设置成各自的系统临时目录下的固定子目录，例如 Windows 用%TEMP%\workbuddy-cache，Linux 用~/.cache/workbuddy-sync-off。改完之后，即使同步盘出了问题，缓存重建也只是时间问题，核心资产完全不受影响。

网上很多人讨论“WorkBuddy 缓存目录怎么更改”，其实入口就在设置里，并不难。关键在于你要意识到：缓存必须从同步范围里剔除，这是一个战略性动作，不是可选项。

2.3 用文件监控确认写入路径

光看默认目录还不够，因为有些版本会把会话数据、数据库引擎文件偷偷写到别的角落。我不会盲目信任文档，直接用了文件监控来确认。

Windows 上我用的方法是任务管理器里的性能监视，或者更细一点用 Process Monitor，过滤进程名为 WorkBuddy，并监视文件写入事件。Linux 上更简单，可以用lsof：

lsof -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 这类产品也可以，但后面踩坑章节会提到它们的局限性。

迁移步骤，我按顺序记录如下，每一步都不要跳：

1. 完全退出 WorkBuddy，包括托盘图标和后台进程。Windows 下打开任务管理器，确认所有带 WorkBuddy 字样的进程都消失。
2. 在同步盘里新建一个目录，名叫WorkBuddyData，这个目录就是未来的“数据主权中心”。
3. 把本机默认数据目录整体复制到WorkBuddyData。注意是复制，不是移动，原目录先保留着，这是保险。
4. 复制完成后，核对文件数量和总大小，确认没有遗漏。
5. 把原数据目录重命名为WorkBuddyData.old，原路径暂时空缺。
6. 在原路径位置创建符号链接，指向同步盘里的WorkBuddyData。
7. 启动 WorkBuddy，确认它能正常读取技能、规则、历史记忆。
8. 验证通过后，删除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同步到本机，确认数据完整性之后，再安装软件。

如果软件已经装过并启动过，它会自动生成一个默认数据目录。这时候按这个顺序处理：

1. 退出软件；
2. 检查默认数据目录里有没有你本机产生的旧资产。如果从来没有用过，直接删除即可；
3. 如果没有旧资产，可以放心地把自动生成的目录删掉；
4. 创建符号链接，指向已同步到本机的WorkBuddyData；
5. 启动软件验证。

最容易翻车的动作是：先让软件以默认模式启动一次，创建出一堆无关的配置，然后这些配置又通过同步盘传到了其他机器。虽然不致命，但会污染数据目录，让每一端都多出一些噪声文件。

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 同步范围必须做减法：哪些要同步，哪些绝不同步

我见过不少人配置同步时一上来就把整个数据目录全选，结果同步盘体积瞬间被缓存撑爆，冲突副本堆积如山。同步范围应该做减法，我最终的划分是：

这个划分花了我好几个星期才稳定下来。现在同步盘里总共只有不到 5MB 的核心文件，同步速度流畅到没感觉，再也不担心云盘限速。

6.3 我的最终配置与一点心里话

现在我的每台机器都是这套结构：

• Windows 公司机：%APPDATA%\WorkBuddy通过目录联接指向D:\Sync\WorkBuddy\Root
• Linux 家庭机：~/.local/share/workbuddy通过软链接指向~/sync/workbuddy/root
• 缓存目录各机独立，不参与同步
• 核心资产统一由 Syncthing 做文件级同步，再用 git 做版本管理

最后分享一个我自己的心得：折腾双写这么久，收获最大的一句话是——数据目录才是真正的本体，账号只是钥匙。每次换机器、换账号、重装系统，我第一反应永远是“把数据目录带过去”，而不是“登录一下就好”。想保持 WorkBuddy 在多台机器上的一致性，记住这一点，你已经赢了 80%。剩下的 20%，就是耐心处理同步冲突、把缓存挡在门外，以及接受“同步工具永远比你的习惯慢半拍”这个现实。