开发日记 · 2026-09-20
为什么坚守本地优先与设备端 SQLite：在大模型时代捍卫数据主权
绝大多数现代笔记软件将数据推向中心化云端，而我们选择 SQLite + 本地 Markdown 的纯设备端架构。本文记录我们在本地离线环境下实现高吞吐双链查询、实体关系图谱和零成本数据主权的工程选型与权衡。
结论先说
思想与知识资产是不可再生的个人数字资产。我们从第一天起就决定：Accrue Notes（复利笔记）不设立任何中心化用户数据库，不架设中转后端，所有笔记、双向链接拓扑、实体索引与向量缓存 100% 存放在用户设备本地的 SQLite 数据库与 Markdown 沙盒中。大模型能力通过 BYOK（自带 API Key）直连官方端点，中间没有任何黑盒拦截。
背景与痛点
在立项之初，我们调研了市面上几乎所有主流笔记与知识库软件：
- 中心化云笔记的脆弱性：厂商服务器宕机或政策调整时，知识库瞬间不可用；当停止订阅时，用户的历史笔记甚至被格式锁定或限制导出；
- 严重的隐私隐患：AI 笔记普遍要求用户将个人工作总结、读书札记和私人灵感上传至云端服务器；哪怕厂商宣称加密，在多租户服务器环境下，数据被内部人员误读或被用作未经授权的模型微调已屡见不鲜；
- 延迟与离线断点：在高铁、飞机或弱网环境下，云端笔记常常卡在“加载中…”或出现冲突合并覆写，打断心流。
为什么选择 SQLite + 本地 Markdown？
我们考虑过三种本地架构方案：
| 方案 | 优势 | 缺陷 | 最终选择 |
|---|---|---|---|
| 纯松散 Markdown 文件树 | 通用性高，用户可直接用外部编辑器查看 | 双向链接反查、全文检索、星系图谱遍历在超过 5,000 篇时极其缓慢 | 仅作为导出/同步格式 |
| 纯本地 SQLite 单一数据库 | 毫秒级 SQL 索引，事务完整性，关系图谱秒开 | 用户难以用普通文件浏览器直接提取单篇笔记 | 作为核心运行期引擎 |
| SQLite 引擎 + 本地 Markdown 镜像持久化 | 兼具 SQLite 的毫秒级查询与 Markdown 的开放可携带性 | 每次写入需要双重持久化与状态同步校验 | 最终选型 |
通过这一架构，我们在 SQLite 中建立了高效的 notes、entities、links 与 backlinks 虚拟表，配合 FTS5 全文搜索与向量索引。即使笔记数量突破 10,000 篇，[[关键字]] 联想依然能在 3 毫秒内响应。
踩坑与教训
最大的坑在于多端私有同步的无冲突合并。我们选择接入 iOS 的原生私有 iCloud 文稿容器与标准文件导出，而不是自建 WebSocket 同步服务。早期曾出现过因两台设备离线编辑导致冲突生成副本的问题。最终我们引入了基于逻辑时钟与原子操作的差异补丁（Diff-based patching）机制，在本地 SQLite 中自动比对段落哈希，实现了真正的无感静默合并。
下一步
我们正在进一步压缩本地向量索引的存储体积，使长达数百万字的知识库在本地手机存储中占用不超过 50MB。