你的笔记是唯一事实源：gbrain 怎么对待你写的东西

设想你决定把多年的投资笔记、人脉、想法都交给一个 AI 系统。第一个涌上来的不安大概是：我的东西会不会被它「吃掉」？哪天它的数据库坏了，我的知识是不是就没了？如果我换台电脑，这些积累能不能跟着走？

gbrain 对这几个本能的担忧，给了一个干脆的回答，也是它一切设计的地基：你写的 markdown 文件是唯一的事实，数据库只是它的影子。

一、影子永远可以重新长出来

gbrain 把你的笔记存成普通的 markdown 文件（带一段 frontmatter 元信息），放在一个 git 仓库里。你看到的、你编辑的、你备份的，都是这些文件。数据库（不管是本机一个文件还是自托管的 Postgres）只是为了提高检索速度而生成的派生索引——分块、向量、去重、图谱，全都能从 markdown 重新算出来¹。

这意味着一件让人安心的事：数据库崩了不用备份恢复，直接 gbrain sync && gbrain extract all 就从仓库原样重建。换电脑更简单——把 git 仓库推上去、在另一台拉下来，下一次 sync 时那台的数据库自己长出来²。你怕的「数据库坏了知识就没了」，在 gbrain 里根本不会发生，因为数据库从一开始就不被当作真相。

一个建筑师会在这里停下来想：这个取舍的代价是什么？代价是所有数据库里的东西都必须能从 markdown 再生。所以 gbrain 拒绝任何「只活在数据库、回写不到文件」的设计——每加一种衍生结构，都要保证有路能从 markdown 重建它。这是它用 CI 门禁强制守住的契约³。

二、你的知识不是一个大杂烩

刚用的人常困惑：我几百个笔记、几十个话题，全倒进一个库吗？gbrain 用两个维度帮你组织，理解这两个维度，后面所有命令的 --brain / --source 参数就不陌生了。

维度一：大脑（brain）。 一个 brain 就是一个独立的数据库。谁拥有这些数据，就划一道 brain 的边界——你个人的知识是一个 brain，公司团队是另一个 brain，两者绝不混⁴。

维度二：来源（source）。 同一个 brain 内部，可以按话题或仓库再分。你的投资笔记、工作笔记、技术笔记，是同一个 brain 下的三个 source。slug（页面路径）只在一个 source 内部保证不重复，不同 source 可以有同名页面⁴。

经验法则其实很直觉：数据主人变了 → 换 brain；主人没变、只是话题不同 → 用 source 分。绝大多数个人用户，一个 brain 配一个 default source 就够了。

三、敏感的东西可以不进 git

把笔记存进 git 仓库带来一个新问题：有些内容你只想自己本地能搜到，不想提交进版本历史、不想哪天同步到别的机器时泄露。比如一笔还没落定的投资决策。

gbrain 的做法是 storage tiering（第 2 课专讲）：你可以把某些目录标记为 db_only——内容照样进数据库、照样能检索，但被 gitignore，只留在你这台机器的磁盘上⁵。这就把「能不能搜」和「进不进版本控制」两件事拆开了：所有内容都能被 gbrain 用，但只有你愿意的才进 git。

四、远程读取时，隐私会自动剥掉

还有一种更细的隐私场景：你把自己的 brain 通过 MCP 接给一个远程 agent 或子任务去用。这时 gbrain 会自动做三级剥离——在分块阶段就把标了私有的 fact 文本剔除、不进向量也不进搜索；远程调用时连整个「观点 fence」都看不到（本地调用才看得到）；加上 db_only 不进 git 那一层⁶。

对使用者来说，这三个层级基本是无感的——你只要知道：标了私有的东西，在远程视角下就是不存在的。这是「把控制权留给你」这条主线在第一课就露出的端倪。

五、这一课带走的

• 你的 markdown 是根，数据库是影子；影子坏了、丢了、换了机器，都能从根重新长。
• 组织知识用 brain（按主人）/ source（按话题）两个维度，个人最简单的形态就是一个 brain 一个 default source。
• 不想进 git 的敏感内容，可以只留本地库（db_only），照样能搜。
• 远程用你的 brain 时，私有内容会被自动剥掉。

后面每一课，都是在这块地基上盖房子。

练习题

参考出处