如果你和我一样，在办公室台式机和家里笔记本上各装了一份 WorkBuddy，想着同一个账号登录，就能像在手机上接着看聊天记录那样无缝续聊，那你大概率会和我一样翻车。WorkBuddy 这类“本地优先”的 AI 助手工具，账号只是身份的锚点，真正影响你日常体验的记忆、技能、规则、项目笔记，默认都落在各自的本地数据目录里。跨机双写同步并不是“两台机器的文件保持一致”这么简单，它真正难的地方在于：两台机器同时在写同一份记忆和规则文件时，怎么合并不丢、不乱、不互相覆盖。这篇文章就是我折腾近一个月的完整心路，包含从翻车到稳定运行的全套方案，适合所有正在或准备在多台电脑上共用 WorkBuddy 账号的人。
1. 先把问题说清楚：同一个账号，数据到底存在哪
1.1 账号体系与本地数据的边界
很多刚接触 WorkBuddy 的朋友会有一个错觉：登录了同一个账号，云端就会像微信一样把你的聊天记录、技能配置、记忆文件统统同步到所有设备。实际并不是这样。WorkBuddy 的账号体系主要负责三件事：身份认证、订阅状态、以及部分云端的会话索引。它刻意把“重数据”留在本地，也就是我常说的本地优先设计。
这种设计的优势非常明显：离线可用、启动快、隐私数据不出本机。但代价就是你换了机器以后，账号是同一个，AI 的“人格”却完全是另一套。你在公司电脑上辛辛苦苦调教出来的规则、沉淀下来的记忆、写好的技能，回到家里电脑上统统不认账。你会发现这台机器上的 WorkBuddy 像一个刚从盒子里拆出来的新手机，什么都不记得。
默认情况下，WorkBuddy 的数据目录分散在三个常见位置：Windows 一般在%APPDATA%\WorkBuddy，macOS 在~/Library/Application Support/WorkBuddy，Linux 在~/.config/workbuddy。如果你在安装时指定过自定义目录，那路径就按你的配置走。我建议你打开文件管理器，先把这个目录结构摸清楚，因为后面所有同步方案，本质上都是在跟这个目录打交道。
1.2 跨机双写冲突的本质
多机共用同一个账号，最核心的技术问题不是“怎么把文件复制过去”，而是“两台机器同时在写同一份文件时，怎么合并”。举个例子你就明白了：你和同事同时在编辑一份会议纪要，你负责补充第三项议程，他负责补充第四项议程。你的电脑先保存，他的电脑后保存。如果没有合并机制，后保存的版本会直接覆盖先保存的版本，你补充的第三项议程就无声无息地消失了。
WorkBuddy 里的记忆文件、规则文件、技能目录，就是这份“会议纪要”。我在实际使用中观察到的典型翻车场景是这样的：白天在公司，WorkBuddy 根据工作对话不断往记忆文件里写入条目；晚上在家里，另一台机器上的 WorkBuddy 也在根据阅读笔记和家庭事务写入记忆。两边都在写，而且写入的往往是同一个 JSON 结构的不同条目。如果同步只是“整个文件覆盖”，那结果一定是某一边的改动全部丢失。
我把这类问题统称为“跨机双写冲突”。它和普通的单向备份是两码事。单向备份只需要关心“新文件覆盖旧文件”，而双写场景下，你必须回答三个问题：谁先写、谁后写、谁的版本应该保留。这三个问题不解决，任何同步方案都是定时炸弹。
1.3 什么样的人需要“真正的双写”
先别急着上方案，我建议你对照一下自己的使用场景，判断是否真的需要双向同步。如果你只是“一台主用、另一台偶尔翻阅”，那根本不需要折腾 Git 和合并脚本，一个简单的单向同步就足够了。但如果你属于下面这几类情况，就需要认真处理双写：
- 白天在公司电脑上写工作日志，晚上在家里电脑上写阅读笔记，两边都会触发 WorkBuddy 的记忆写入。
- 两台电脑轮流使用同一套技能和规则，今天在 A 机上改了一个 skill，明天在 B 机上又改了另一个 skill。
- 你有一台台式机和一台笔记本，并且希望不管坐在哪台机器前面，和 WorkBuddy 对话时它都记得最近几天发生过什么。
- 你想把 WorkBuddy 的数据目录直接放在 NAS 或同步盘里，并且允许两边同时在线运行。
我属于第二种和第三种的混合体，所以最后选择了“主从 + Git 定期合并”的架构。在展开实操之前，先聊聊我对比过的几种主流同步方案，帮你少走弯路。
2. 三种主流同步方案，先对比再选择
2.1 方案 A：官方账号自带的同步能力
如果你完全不想折腾，最省心的当然是直接用 WorkBuddy 账号体系自带的云同步。它的优点是开箱即用，不需要懂命令行，也不需要维护仓库。但我实测下来，它更适合轻量使用，而不是重度双写。
问题在于，云同步为了简化用户体验，通常会采用“最后写入者胜”的策略。什么叫最后写入者胜？就是同一份记忆文件，谁后保存，就以谁的版本为准。这个策略对手机聊天记录这种“追加式数据”没什么问题，因为聊天记录天然只会新增，不会互相修改同一行。但 WorkBuddy 的记忆文件里包含的是结构化条目，两台设备的 AI 会在不同时间往里面插数据，一旦同步触发，后保存的设备很可能把先保存设备的几条新记忆一起冲掉。
更头疼的是会话上下文。我曾经遇到两台设备同时在线，WorkBuddy 的云会话把两边的对话历史串在一起，A 机上的问题跑到 B 机上被回答了，B 机的回答又出现在 A 机的历史记录里。那种感觉就像你打电话打到一半，突然接入了另一个人的电话会议，体验非常割裂。如果你只用单台设备，官方同步没问题；但只要你真的需要“两台都写”，我建议往后看。
2.2 方案 B：第三方同步盘直接同步数据目录
这也是很多人的第一反应：把 WorkBuddy 整个数据目录丢进 OneDrive、Dropbox、坚果云或者自建 NAS 的同步文件夹里，让网盘帮我同步。我最初也是这么干的，但踩坑踩得最狠的就是这条路。
同步盘最典型的问题是“冲突副本”。当两台机器同时改同一个文件时，网盘不会帮你智能合并，而是把两边的版本各自存成memory (冲突副本).json和memory.json。WorkBuddy 只认固定文件名，根本不认识那个带“冲突副本”后缀的文件，它只会安静地加载其中一个，另一个就变成孤儿文件躺在目录里。等你发现不对劲的时候，往往已经过去好几天，冲突副本攒了一堆，哪份是新的、哪份是旧的，完全分不清。
还有一个我之前完全没预料到的坑：WorkBuddy 的缓存目录和索引文件变化非常频繁，几乎每次对话结束都会有几毫秒的写盘动作。把这些文件放进同步盘，意味着网盘客户端会持续监听到海量的小文件变更，然后不停地上传下载。我那时候的笔记本风扇在夜里疯狂转，打开网盘客户端一看，后台正在同步几千个碎片文件。这不仅是性能浪费，还会显著缩短笔记本的续航时间。同步盘适合低频更新的文档目录，但不适合高频写入的本地优先应用。
2.3 方案 C：Git 版本管理 + 定时合并脚本
如果说前两种方案都有天然的缺陷，那 Git 就是目前我找到的最优解：用版本控制来管理“人写的、可以合并的文件”，用.gitignore把“机器生成的、容易冲突的缓存文件”挡在门外。这个思路可以把跨机双写变成一个有迹可循、可回滚、可解决冲突的流程。
为什么 Git 能解决双写问题？因为它不是简单覆盖整个文件，而是基于文本差异做合并。两边都改了一个文件的不同区域，Git 能自动把两边的改动拼在一起；如果改了同一行，它会明确标出冲突位置，让你来决定保留哪个版本。这比“最后写入者胜”和“冲突副本”都要安全得多。代价是需要一点命令行基础，以及每次合并冲突时花几分钟手动处理。
我把三个方案的核心差异整理成一张表，方便你快速决策：
| 对比维度 | 官方云同步 | 第三方同步盘 | Git + 合并脚本 |
|---|---|---|---|
| 冲突处理 | 最后写入者胜 | 生成冲突副本，不会合并 | 自动合并，冲突时人工裁决 |
| 可回滚 | 一般不提供 | 依赖网盘版本历史 | 每次提交都是快照，随时可回退 |
| 离线可用 | 依赖网络 | 依赖本地缓存 | 完全离线，推送时才需网络 |
| 适合人群 | 单设备或轻中度使用 | 低频更新场景 | 需要双写、有一定动手能力 |
| 风险点 | 静默丢数据 | 缓存风暴、文件错乱 | 学习成本高，遇冲突需人工处理 |
我个人最终选择了方案 C，因为它能同时满足我“两台机器都写”和“数据不能丢”这两个硬性要求。下面我把完整实操过程写出来，每一步都可以直接照着做。
3. 我的最终方案：主从 + Git 定期合并
3.1 目录规划：先分清三类文件
在初始化仓库之前，我先把 WorkBuddy 数据目录里的内容分成了三类，这个分类是整个方案的地基。
第一类是“可合并的人写文件”，包括记忆文件、技能目录、规则文件、项目笔记。这类文件的特点是内容由你或你与 AI 的对话产生，语义明确，可以被 Git 做差异合并。第二类是“易冲突的机器文件”，包括索引数据库、缓存文件、日志文件。这类文件是纯机器生成的，很大、变更频繁、对用户体验没有直接价值，应该直接排除在版本控制之外。第三类是“身份类文件”，包括账号凭据、设备 ID、本地设置。这类文件每台机器应该有各自独立的一份，不能强行同步，否则会造成设备识别错乱。
我实际整理出来的目录结构大概是这样的：
workbuddy/ ├── accounts/ # 账号与身份信息，不同步 ├── memory/ │ ├── memories.json # 长期记忆，纳入 Git │ └── index.db # 索引文件，Git 忽略 ├── skills/ # 技能目录，纳入 Git ├── rules/ # 规则文件，纳入 Git ├── projects/ # 项目笔记，纳入 Git ├── cache/ # 缓存目录，Git 忽略 └── logs/ # 日志目录，Git 忽略对应到仓库根目录下的.gitignore，我写的是：
accounts/ cache/ logs/ *.db *.log *.tmp .DS_Store把accounts排除掉的原因很简单：WorkBuddy 的登录凭据和本地设备标识如果跟着 Git 仓库跑到另一台机器，可能触发账号安全机制要求重新登录，而且每台机器的设备指纹本来就该不同。我一开始试图把整个目录都纳入 Git，结果在 A 机上提交的凭据文件到了 B 机上导致登录态互相打架，连续几天都遇到会话掉线。
3.2 自动同步脚本：commit -> pull --rebase -> push
目录规划好之后，我写了一个同步脚本，放在每台机器的 PATH 目录下，名字叫wb-sync。脚本核心逻辑只有 4 步：先检查 WorkBuddy 是否在运行，然后把本地改动提交，接着从远端拉取并用 rebase 方式合并，最后推送。
#!/usr/bin/env bash set -euo pipefail WB_DIR="$HOME/.config/workbuddy" cd "$WB_DIR" # 1. 检查 WorkBuddy 进程是否在运行 if pgrep -f WorkBuddy > /dev/null 2>&1; then echo "Warning: WorkBuddy is still running, please quit before sync" exit 1 fi # 2. 先把本地改动提交 git add -A git commit -m "sync from $(hostname) at $(date '+%F %T')" || echo "nothing to commit" # 3. 拉取远端并变基 git pull --rebase --autostash || { echo "Rebase conflict detected, please resolve manually." echo "Files with conflict:" git diff --name-only --diff-filter=U exit 2 } # 4. 推送 git push echo "Sync done at $(date '+%F %T')"你可能会问：为什么非要先 commit 再 pull？顺序反过来的话，如果远端有新提交，直接 pull 可能会和你本地未提交的改动冲突，Git 会拒绝操作。先把本地改动提交成一个快照，再通过 rebase 把本地的这个提交“回放”到远端最新提交之上，这样就把双写过程变成了一个有明确历史记录的流水线。
--autostash这里是双保险，即使有漏掉没提交的零散改动，也会被 Git 临时保存起来，rebase 完成后再自动恢复。如果 rebase 遇到真正的冲突，脚本会停下来并列出冲突文件，不会强行覆盖任何数据。
我在两台机器上都配了同步频率：公司台式机每 30 分钟执行一次，家里笔记本每 1 小时执行一次。为什么这么定？我统计过自己的数据写入量，记忆文件平均 2MB 左右，skills 目录几十个文件加起来不到 5MB，rules 文件几百行，单次同步的增量通常不超过 100KB。Git 对文本文件的增量同步非常高效，每次同步实际耗时在 2 到 5 秒之间，对正常办公几乎没有感知。如果你发现自己的数据量远大于这个数值，建议先看是不是忘了把缓存文件加进.gitignore。
3.3 让两台机器“错峰写入”
Git 能解决文件层面的冲突，但解决不了“会话上下文串线”的问题。两台机器如果同时在线，并且同时与 WorkBuddy 的云端会话相连，即使文件最终能合并，对话体验也会很混乱。
我的做法是给两台机器定了一个简单的“角色约定”：公司台式机是主设备，负责工作时间和白天的一切对话；家里笔记本是从设备，负责晚间和周末的阅读笔记、生活记录。这个约定落实在 WorkBuddy 的规则文件里，AI 的判断逻辑大致是：如果当前时间在工作日 9 点到 19 点，并且在主设备上，则正常回应并写入记忆；如果在从设备上遇到同样的请求，就优先读取记忆、暂缓写入。
你可能注意到，这本质上是在做“错峰写入”，而不是“同时双写”。我个人的经验是：真正的双写在 AI 助手场景里往往是伪需求，因为人一天只有一个主要工作场景。策略上把时间切分好，两台机器就不会抢着写同一个记忆文件，Git 的冲突几率也会大大降低。当然，周末有时候我也会把笔记本拿到书房，这时候两台机器确实可能出现同时在线。遇到这种情况，我依赖的就是下一节的语义级合并方案。
3.4 会话和记忆的语义级合并
文件级的自动合并只是第一步，真正让我觉得“这方案成了”的，是给记忆和技能条目增加source_device字段之后的语义级合并。WorkBuddy 导出的记忆文件通常是结构化的 JSON，每条记忆有自己的时间戳、内容、关联技能等信息。如果直接用 Git 合并两个版本，Git 会尝试把两个 JSON 文件的文本差异拼接起来，结果往往是语法正确但语义混乱——同一轮对话的记忆被切成两半，穿插进另一台机器的内容。
我的解决办法是写了一个独立的 Python 小脚本，在 Git 自动合并之后跑一次，专门负责记忆条目的去重和排序。
import json from collections import OrderedDict MEMORY_FILE = "memory/memories.json" def load_entries(path): with open(path, "r", encoding="utf-8") as f: data = json.load(f) return data.get("entries", []) def merge_entries(left_entries, right_entries): merged = OrderedDict() for entry in left_entries + right_entries: key = entry.get("id") or entry.get("raw_text") if not key: continue if key not in merged: merged[key] = entry else: old = merged[key] # 保留时间戳较新的版本，并合并 device 来源标记 if entry.get("timestamp", "") > old.get("timestamp", ""): merged[key] = entry merged[key]["devices"] = list( set(old.get("devices", []) + entry.get("devices", [])) ) else: merged[key]["devices"] = list( set(old.get("devices", []) + entry.get("devices", [])) ) return list(merged.values()) if __name__ == "__main__": left = load_entries("memory/memories.left.json") right = load_entries("memory/memories.right.json") result = merge_entries(left, right) with open(MEMORY_FILE, "w", encoding="utf-8") as f: json.dump({"entries": result}, f, ensure_ascii=False, indent=2) print(f"merged {len(result)} entries")脚本的逻辑很简单：用记忆条目的唯一 ID 或原始文本做 key，先到先得；如果同一个 key 出现在两边，就保留时间戳比较新的版本，同时把两个来源的设备标记合并到一个devices字段里。这样做的效果是：每一条记忆都记录它从哪台机器来，合并之后我还能通过devices字段知道哪些条目在家里的笔记本上补过内容。
规则文件就更简单了。我约定规则只在主设备上修改，从设备上的规则改动先写到rules/pending/待审区，每隔几天人工合并一次。这个做法也回应了很多人都在问的“怎么给 WorkBuddy 定规则才不乱”——规则的生命周期需要明确的归属设备，两边各写一套规则再让 Git 自动合并，最终一定会出现互相矛盾的指令，AI 的行为会变得非常难以预测。
4. 踩坑实录：五个让我抓狂的问题与排查方法
4.1 坑一：同步盘把记忆文件搞成“我中有你，你中有我”
这个问题出现在我还没切到 Git 方案之前，用的是方案 B 的网盘同步。某天我突然发现 WorkBuddy 的回答开始前言不搭后语，上午它还清楚记得我上周写的项目方案，下午就问我要不要从零开始介绍。我打开记忆文件一看，整篇 JSON 的结构已经被网盘冲突副本搞乱了，同一个 ID 出现了多条记录，时间戳互相穿插，AI 读取的时候拿到了错乱的上下文。
排查思路其实不复杂：先看记忆文件里有没有重复的条目 ID，再看每一条的时间戳是否大致按序排列。如果时间戳是无序的，基本可以断定文件在同步过程中被多次覆盖和合并。那次我丢了好几天的规则沉淀，因为没有版本历史可以回滚。也正是在这个教训之后，我才彻底放弃了同步盘直接同步的路线。
4.2 坑二：Windows 和 macOS 文件名字段冲突
我公司在 Windows，家里是 macOS，两台机器共用同一个 Git 仓库之后，很快发现一个诡异的问题：Rules.md和rules.md这两个文件在同步时一会儿消失一会又出现。原因是 Windows 文件系统默认大小写不敏感，而 macOS 的默认文件系统大小写不敏感但保留大小写，Git 会认为这是两个不同的文件，但 WorkBuddy 加载规则时只认其中一个，另一个就变成了无法引用的孤儿文件。
这个问题的解决方案非常朴素：统一命名规范。我花了一个下午把数据目录里所有文件都改成全小写英文、下划线分隔，比如memory_work.md、skill_meeting_notes.md。从那以后再也没有因为文件名字段踩过坑。这里也提醒你，如果未来加入第三台 Linux 机器，Linux 文件系统对大小写完全敏感，小写命名的好处会更加明显。
4.3 坑三：两台机器同时在线，会话串线
场景是这样的：周五晚上我在客厅打开笔记本，准备把这一周的阅读笔记整理进 WorkBuddy，忘了关书房的台式机。结果两边同时连着云端会话，我问笔记本上的 WorkBuddy“这周有哪些阅读笔记要整理”，它回答我的是书房那台机器正在处理的工作任务内容。那一刻我真的以为 AI 出了灵异事件。
排查方法是在 WorkBuddy 的设置里查看当前活跃设备列表，关掉不必要的那台设备的云会话。长期来看，我前面提到的“角色约定”才是根治方案。另外，如果你用的是 Git 方案，可以给两台机器的主机名加上不同前缀，比如wb-office和wb-home，这样每次同步的 commit message 里一眼就能看出改动来自哪台机器，排查会话问题时非常有用。
4.4 坑四：git pull 报 non-fast-forward / 冲突标记刷屏
切到 Git 方案之后，最常见的报错是 pull 时提示non-fast-forward。这个问题的根源是：远端已经有新的提交，而本地也有新的提交，Git 不知道该怎么把两边的历史接上。如果直接git pull，他可能会拒绝或产生一个无意义的合并提交。正确做法就是我在 3.2 节脚本里写的：先 commit 本地改动，然后git pull --rebase。
遇到真正的冲突时，不要慌，不要直接删冲突文件。先用git diff --name-only --diff-filter=U查一下哪些文件有冲突，再打开文件找<<<<<<<、=======、>>>>>>>这些标记。每次冲突的修复原则很固定：把<<<<<<<到=======之间的一段当作 A 机版本，把=======到>>>>>>>之间的一段当作 B 机版本，结合内容决定保留哪个、或者两个都留。保存之后依次执行：
git add . git rebase --continue git push这个流程我走过至少十次，熟练之后每次处理冲突不超过五分钟。我想再强调一遍：看到冲突标记不要慌，那说明 Git 保护了你的数据，而不是弄坏了数据。最怕的是有人为了省事，直接git checkout -- .回滚，那才会真正丢掉另一台机器上刚写好的内容。
4.5 坑五：缓存目录膨胀，同步变“硬盘搬运工”
很长一段时间里，我发现不管怎么优化，Git 仓库的体积都在快速增长。查了半天才意识到，是我某次调整.gitignore的时候漏了一个子目录，导致索引数据库和大量临时文件被 Git 追踪了。WorkBuddy 运行一段时间后，缓存目录里的碎片文件可能有几千上万个，每次同步都在反复比对、上传、下载这些垃圾文件，仓库体积很快膨胀到几百 MB。
解决办法有两个：一是把缓存目录、索引文件、日志全部彻底加进.gitignore，然后执行一次git rm -r --cached cache logs把它们从 Git 追踪列表中移除；二是定期清理本地的缓存目录，WorkBuddy 的设置里一般有缓存大小显示，我每周清一次，腾出来的空间相当可观。把这个习惯养成之后，我的 Git 仓库稳定在 30MB 以内，同步速度快了很多。
4.6 常见问题速查表
我把这段时间遇到的所有问题浓缩成一张速查表，方便你直接按图索骥：
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| 记忆内容丢失，回答断续 | 同步覆盖了旧版记忆文件 | 切换 Git 方案，使用版本历史回滚 |
| 规则文件时而失效 | 大小写文件重名 | 统一小写英文和下划线命名 |
| 两台设备回复内容混在一起 | 云端会话串线 | 设置设备角色，错峰写入 |
| git pull 失败 | 本地和远端都有提交 | 先 commit 再 pull --rebase |
| 仓库体积疯涨 | 缓存/索引被 Git 追踪 | 加入 .gitignore，执行 git rm --cached |
| 登录状态频繁掉线 | 账号凭据被同步 | 把 accounts 目录排除在同步范围外 |
5. 进阶技巧：从“文件级同步”走向“体验级一致”
5.1 先给 WorkBuddy 定一套设备规则
很多人忽视了规则文件本身就是双写冲突的高发区。WorkBuddy 的规则决定了它的行为风格和边界，也是“减少 AI 味”的关键所在。我后来把规则文件拆成了两个部分：base_rules.md是全设备共用的基础规则，比如语气、回答长度、禁用事项；device_rules/是每台设备自己的补充规则，比如公司设备上的规则会更偏向会议纪要和任务管理，家庭设备上的规则更偏向阅读笔记和灵感收集。
这样拆的好处是：共用基础规则的修改频率很低，不容易产生冲突；设备补充规则各写各的，Git 合并时几乎不会撞车。我还在规则文件里明确写了一条：设备角色切换时，AI 需要优先加载对应设备的规则段，而不是把两套设备规则平等混在一起。这个小改动对体验的提升非常明显，AI 不再“一会儿像工作助理，一会儿像私人书童”。
5.2 同步前的“冻结”魔法
即使有了 Git 方案，同步时机仍然很讲究。如果 WorkBuddy 正在后台执行任务，比如正在生成长回答、正在写入记忆，这时强行同步会导致文件在写入中途被读取，容易产生半截 JSON。半截 JSON 即使能被 Git 提交，后续合并脚本读到它时也会直接报错。
我的做法是在同步脚本里增加进程检查，也就是 3.2 节里那段pgrep -f WorkBuddy。如果检测到进程还在运行，脚本就退出并提示你先退出 WorkBuddy 再执行同步。在工作日中，我会把自动同步任务设在整点，并且尽量避开自己正在连续提问的时间段。实际运行下来，因为每 30 分钟才同步一次，错过一次也无所谓，真正需要的是“要么不同步，一旦同步就保证数据完整”。
5.3 从一个账号扩展到多项目、多人协作
如果你和我一样只是一个人用多个设备，前面的方案已经够用了。但如果你想把同一个 WorkBuddy 账号共享给家人或同事，那就还需要额外的隔离机制。我的建议是利用 WorkBuddy 的项目目录做隔离：每个项目有自己的rules/和skills/子目录，并且每个项目单独建一个 Git 仓库，而不是整个数据目录一个仓库。
这样做的好处是：不同项目的同步节奏可以不一样，比如团队项目可以每天同步一次，个人知识库可以每周同步一次；一旦某个项目的仓库出现灾难性合并错误，也不会影响其他项目的数据。如果你走得更远，还可以给每个人单独建一个设备标识，在记忆条目的devices字段里区分“谁参与了这条记忆”，这样即使多人共用账号，AI 也能大概判断出当前对话的人是谁、应该调用哪一套规则。
我个人的体会是：多机共用一个 WorkBuddy 账号完全可行，但你不能把它当成“云笔记”来用，而要从一开始就接受“本地数据为主、版本控制为辅”的架构理念。跨机双写同步的核心不是把文件复制得越快越好，而是分清哪些文件允许双写、哪些文件只能单写、哪些文件压根不应该同步。这条界限想清楚了，Git 只是工具，真正的稳定来自你的约定和管理习惯。
最后再分享一个小技巧：每次手动同步之前，先花十秒钟把当前 WorkBuddy 数据目录复制到带日期后缀的备份文件夹，比如workbuddy_backup_20250607，然后再执行wb-sync。这个习惯让我在遇到极端情况时，永远有一条退路。我靠它少丢了至少三天的记忆数据，也希望你能一直保留这个简单的后备动作。
