适用场景

场景一：同一件事分好几次做

这是最常见、也最容易验证价值的场景。

周三你让 AI 帮你设计一套同步协议，聊了两小时，最后定下”本地优先、冲突按时间戳后写赢”。 周五你开新会话说”接着上次那套同步方案往下做”。

没有小本本时，你要么重新讲一遍，要么指望 AI 猜。有小本本时，AI 会先 recall_topic 一次，把周三的决策、当时否掉的备选方案、你明确说过的约束一起取回来，然后从”上次停在哪”继续。

判断标准很简单：这件事你会做不止一次，且第二次开始不想再解释一遍。

场景二：几个 AI 客户端共用一份记忆

真实的工作状态往往是分工具的：写代码用 opencode 或 Claude Code，讨论方案用 WorkBuddy，临时问一句用手机上的豆包。

只要这些客户端都指向同一个 ~/.xiaobenben/memory.db，记忆就是同一份。不存在”每个 AI 一套记忆、还要人工同步”的问题——它们的记忆是同一个文件。

一个必须遵守的前提：所有客户端都用默认路径。任何一方自定义了库路径，记忆就会分裂成两份，而且分裂之后没有任何提示，只会表现为”AI 有时候记得、有时候不记得”。

场景三：三个月后要回答”当初为什么这么定”

代码里有注释，但注释只写”是什么”。真正难复原的是为什么否掉了另一条路。

小本本里的决策记忆带类型标记，且不可覆盖。三个月后你问”当时为什么不用 WebSocket”，AI 能取出那条决策及其上下文；如果后来改主意了，库里会同时留下两版，以及后者取代前者的时间点。

这一点对交接尤其有用：新同事不必问人，直接让 AI 把这条线上的决策按时间排一遍。

场景四：不写文档也能留下经验

大多数人的经验散在聊天记录里，而聊天记录既搜不到也不结构化。

让 AI 在对话中把结论性内容记下来，等于每次聊天都顺手写了一句笔记，且这句笔记会被下次的 AI 主动读到。成本是零，因为它发生在你本来就要说的话里。

它不擅长的事

一、替代文档。 记忆是碎片、按需召回；文档是结构、可以通读。要给别人看的东西仍然要写成文档——比如你正在读的这一页。

二、当数据库用。 它是给 AI 读的记忆，不是给你做报表的数据源。要做统计请直接读 memory.db（SQLite），别指望 MCP 工具给你聚合。

三、保存机密。 密钥、口令、身份证号不要指望它帮你记。写入时它们会被抹成占位符——这是保护，不是缺陷；真需要存凭据，用密码管理器。

四、替你做判断。 记忆只提供”上次是怎么定的”，不提供”这次该怎么做”。AI 该重新判断的时候，一条旧记忆反而会把它带偏；这也是为什么记忆可以被打上”已过时”的标签。

一个判断口诀

会重复出现、且重复时要重新解释的信息 → 值得记。 一次性、随手、看一眼就够的信息 → 不值得记。

记得太多和记得太少一样糟：噪声会淹没信号，检索出来的东西一旦经常是废话，AI 就学会不再信任它。