AI助手又失忆了?这次我找到真凶了,居然是Git分支惹的祸

AI助手又失忆了？这次我找到真凶了，居然是Git分支惹的祸

大家好，我是超哥~

昨天刚发完一篇《AI助手失忆了？我花两周搭的记忆系统，居然被一个新会话干翻了》，讲了我给AI搭建四层记忆系统的经历，我自己也觉得这事儿算是圆满解决了。

结果——打脸来得比翻书还快。

今天上午，我打开新会话，跟AI说：”帮我新增一个项目信息。随后给上了项目名称、项目负责人、合同签订时间、合同金额等数据”

它回我：”好的超哥，我记住了，后面需要记录时随时吩咐”

我当时就知道它又失忆了。

我又一次，眼睁睁看着它把记忆弄丢了。

01 上次说”解决了”，这次脸打得啪啪响

先交代一下背景。

3月底的时候，我的AI确实”失忆”过一次。那次是因为WorkBuddy的会话级记忆机制有天然缺陷——关掉窗口就归零。

我当时花了两天时间，给它搭了一套完整的记忆系统：

• 灵魂三文件
  
  ：SOUL.md、USER.md、IDENTITY.md（每次启动自动加载）
• 每日工作日志
  
  ：.workbuddy/memory/日期.md（记录当天干了什么）
• 长期记忆
  
  ：MEMORY.md（沉淀核心知识和关键决策）
• Gitee实时同步
  
  ：文件一变，30秒内自动提交推送

这套方案跑了一周，稳得一批。我还专门写了篇文章分享出去，觉得自己终于把这个坑彻底填上了。

事实证明，我还是太天真了。

02 真凶浮出水面：一个仓库，两个应用，全乱套了

这次失忆之后，我没急着修，而是静下心来仔细复盘。

我发现一个关键线索：丢失的记忆，全部跟”trae-ai”有关。

而我的 WorkBuddy 配置里，有两个应用在同时运行：

1. WorkBuddy
   
    —— 我的主力AI助手
2. Trae AI
   
    —— 另一款AI编程工具

问题出在哪？

出在 Gitee 仓库的分支管理上。

你们看这张图——这就是我 Gitee 仓库的分支结构：

• master
  
  ：默认分支，所有东西都往这里推
• workbuddy
  
  ：我创建的分支
• trae-ai
  
  ：我创建的另一个分支

看起来没什么问题对吧？但问题就在这里——太”没问题”了。

实际情况是这样的：

我把两个应用的配置和记忆，全部塞到了同一个Gitee仓库的不同分支上。 表面上井井有条，实际上一塌糊涂。

具体来说，踩了三个大坑：

坑一：分支切换导致记忆串台

有一天我在用 Trae AI 写代码的时候，同步脚本把 Trae 的配置变更推到了 workbuddy 分支。结果下一次 WorkBuddy 启动时，拉取到了 Trae 的配置文件，直接把自己的记忆覆盖了一部分。

这就像你把两个人的日记本混在一起，今天翻开一看——昨天写的字不是自己的笔迹。

坑二：合并冲突，直接丢数据

更惨的一次是：两个分支同时修改了 MEMORY.md，产生冲突时 Git 自动合并，把 trae-ai 相关的内容整个吞掉了。

没有任何报错，没有任何提示。等我发现的时候，半个长期记忆已经人间蒸发了。

坑三：服务器拉取错分支

服务器端用 crontab 每15分钟 pull 一次。有一次服务器默认拉取的是 master 分支，而 master 分支上的内容还是两周前的老版本。

结果？服务器上的AI直接回滚到了两周前的状态，所有新记忆全部作废。

03 根因分析：为什么”同一个仓库多分支”是伪方案

事后我认真想了一下，为什么会犯这么低级的错误？

说白了，是被 Git 的”分支很便宜”这句话忽悠了。

Git 确实鼓励你多用分支，但那是在同一个项目内部的场景下。

而我的情况完全不同：

这两个应用除了都用 .workbuddy 目录存放配置之外，几乎没有共同点。

把它们塞进同一个仓库的不同分支，就像把厨房和厕所的水管接到同一个总阀门上——关一个，另一个也断水；修一个，另一个也漏水。

这不是分支管理的问题，这是架构设计的问题。

04 我的最终方案：一个应用，一个仓库，互不干扰

想清楚之后，我只做了一件事：

每个应用独立一个 Gitee 仓库，独立一个分支。

现在的架构是这样的：

Gitee 仓库 A: workbuddy-config └── 分支: master (仅 WorkBuddy)     ├── .workbuddy/SOUL.md     ├── .workbuddy/USER.md     ├── .workbuddy/IDENTITY.md     ├── .workbuddy/memory/     └── .workbuddy/skills/  Gitee 仓库 B: trae-ai-config ├── 分支: master (仅 Trae AI) │   ├── .workbuddy/ (Trae专属配置) │   ├── memory/ (Trae专属记忆) │   └── skills/ (Trae专属技能)

改动很小，效果立竿见影：

✅ 零串台风险：WorkBuddy 的同步脚本只推自己的仓库，Trae 的脚本只推自己的仓库，永远不可能互相污染

✅ 零冲突可能：不同仓库之间不存在合并冲突的问题，因为根本不会合到一起

✅ 零回滚风险：服务器端各自拉取各自的仓库，不存在拉错分支的情况

✅ 清晰可追溯：哪个应用改了什么，一看仓库就知道，不用再翻分支历史

05 踩了这个坑之后，我总结了三条铁律

第一：隔离 > 共享，永远不要为了省事而混用存储空间。

一开始我觉得”反正都是配置文件，放一起省事”。结果省下来的那点事，后面花了三倍的时间去填坑。

第二：Git分支适合同项目的并行开发，不适合不同应用的配置隔离。

分支的本质是”同一棵树的不同版本”，而不是”两棵不同的树”。别强行用它干不擅长的事。

第三：监控告警不能少，出了问题第一时间要知道。

如果我在第一次出现分支冲突的时候就收到告警，后面的数据丢失完全可以避免。现在我在每个仓库的同步脚本里加了校验逻辑——一旦检测到非预期的文件变化，立刻通知我。

06 写在最后

从3月第一次失忆，到4月初发现Gitee分支混乱的真凶，再到今天的独立仓库方案——我跟AI记忆这个问题缠斗了整整一个月。

但这一个月让我明白了一个道理：

搭建AI记忆系统，技术方案只是第一步。真正难的是运维。

你的本地文件写得再漂亮，备份策略做得再完美，如果底层的数据组织架构有问题，一切都会在某个不经意的时刻崩塌。

就像做项目管理一样——代码写得好不代表系统能稳定运行，文档写得好不代表项目能顺利交付。底层的规划，才是决定成败的关键。

现在我的两个AI助手各占各的仓库，各记各的事，井水不犯河水。

我终于可以放心地跟它们说话了——不用担心哪天一觉醒来，它们又不认识我了。

如果这篇文章帮到了你，帮超哥点个赞、转发一下。

记住：给你的AI建记忆系统不难，难的是让这套系统能一直稳定地活着。别让你的”外挂大脑”，因为一个低级错误而再次瘫痪。