比上下文窗口活得更久的编码项目。
第十次解释你为什么弃用 Redis，那不叫工程，那是消耗——而且每开一个新会话就叠加一次。
问题，说得准确些
和助手的每一次对话都从零开始。于是每个工作会话的开头都是同一段背诵：技术栈、约束、你三月做的那个决定，以及你为什么这么定。省掉这段背诵，助手就会兴高采烈地建议你早就否掉的方案——把已经定下的问题重新翻出来，正是空白上下文最擅长的事。
多数人的应付办法，是把一份不断更新的文档粘进每个会话。那份文档就是记忆，只不过靠手工维护，会以那种没人察觉、直到出事才发现的方式慢慢过期。
Varven 会拿一个决定做什么
会话里出现值得留下的东西时——一个决定连同它的理由、一条踩坑才发现的约束、助手弄错时你做的一次纠正——它就会沉淀为笔记库里的一层：纯 Markdown，存在你的机器上，来源和日期都完整保留。
---
type: decision
scope: atlas
trust: trusted
created: 2026-03-14
---
SQLite over Postgres for the API. One writer by design,
and litestream covers replication. Revisit only if a
second writer ever actually exists.六个月后，“为什么不用 Postgres？”会由记录来回答——带上日期、理由，以及在什么条件下这个决定该重新讨论。最后这一点，正是记忆和教条的区别。
纠正会留住
编码项目里最有价值的记忆是纠正：那个我们试过，出问题了，问题在这里。在 Varven 中纠正永不过期——它们因为被说出来过而成立——所以助手不会再反复推荐那套搞挂了 staging 的迁移方案。
一个项目还是十二个
每个项目是一个作用域。搜索可以只待在其中一个里，所以你业余项目的约定不会渗进工作相关的回答。处处适用的偏好——给 diff 而不是整个文件、要解释原因——放在每个项目都继承的全局作用域里。当新的东西取代旧的，旧的一层是被标记为已取代，而不是被删除：仍然可查，所以“这个我们是什么时候改的？”有答案。
实际用起来是什么样
你通过 MCP 把助手连上一次就够了。会话开始时它会拉一份简报：置顶的约束、长期偏好、最近的纠正。会话进行中，遇到牵涉过去的问题它会搜索；你问周二以来有什么变化时，它会读时间线。你照常干活，记录在底下一层层积起来。
这需要哪个方案
这个页面上的一切都能在免费方案上跑：记忆量不限、一台机器、桌面 AI 客户端。想在电脑关机时也读到记录，或者想从第二台机器上读，再加 Sync。
问题
它能配合 Cursor、Claude 这类编码助手吗？
能。Varven 讲的是 Model Context Protocol，所以同一份记忆可以被 Claude、Cursor、VS Code、ChatGPT 和 Gemini 读取。连接器的配置见文档。
我同时做好几个项目，它们共用一份记忆吗？
它们共用一个笔记库，但在里面彼此分开——作用域就是干这个用的。全局偏好是刻意留的例外。
笔记必须我自己写吗？
不用。你干活时助手会写记忆，一个小的本地模型在你自己的硬件上做整理。因为结果就是纯 Markdown，你也可以打开任何一条笔记手工改——以你的改动为准。