Vault Curate：让笔记"自己找到彼此"的 Obsidian 插件

你有没有这种感觉？

打开 Obsidian，金库里有几千条笔记，越存越多。想找"那条关于知识管理的笔记"，却发现关键词怎么搜都搜不到——你记得写过大意，但措辞早就忘了。点开图谱，全是密密麻麻的线和节点，看不出什么信息。

更扎心的是，有些笔记写了之后，再也没打开过。笔记从"待消化"变成了"事实上的垃圾堆"。

Vault Curate 试图解决的不只是搜索问题，而是整个"知识再发现"的闭环。

Vault Curate 将语义搜索、关系图谱与遗忘曲线融入 Obsidian，打造本地优先的"第二大脑"。

---

背景：Obsidian 生态的痛点

Obsidian 是过去几年最火的双链笔记工具，核心是 .md 文件 + wikilink，图谱视图可以可视化笔记间的链接关系。但这套机制有一个天然局限：它只能看到你手动连上的线。

如果你写了一篇"AI 知识管理"和一篇"第二大脑实践"，但没有手动给它们加链接，图谱里这两篇笔记就是两个孤立的点。Obsidian 不知道它们在语义上可能高度相关。

RAG（检索增强生成）概念火热之后，很多人尝试把 AI 引入笔记系统——但主流方案要么需要一个外部 API（意味着数据上云），要么直接让 AI 重写你的笔记（意味着失去控制权）。

Karpathy 曾提出"让 LLM 自动编译笔记成维基百科"的想法，很有启发性，但 Vault Curate 选择了更保守的路线：AI 只负责发现和呈现，用户才是最终拍板的人。

核心功能：Find → Connect → Rediscover

Vault Curate 围绕一个三层闭环设计，每层解决一个痛点。

第一层：Find——语义搜索，找到对的笔记

普通搜索只能匹配字面。Vault Curate 的搜索同时跑三个引擎，结果融合排名：

搜索类型	擅长场景
BM25 关键词	精确短语、专业术语
WebGPU 向量语义	含义相近但措辞不同
模糊标题匹配	拼写错误、缩写

向量语义搜索依赖本地 embedding 模型（默认 bge-small-zh-v1.5，约 110MB），通过 WebGPU 在浏览器/GPU 上运行，无需 GPU 显卡——普通 CPU 也能跑，只是稍慢。首次索引 5004 个文本块约 1 分 23 秒，之后增量更新。Ollama 可选接入，支持自定义 embedding 模型。

特别值得关注的是中文/CJK 优化：内置模型对简体中文、繁体中文、宗教术语、口语表达都有专项调优，切换到 Ollama/OpenAI 则适合其他语言。多语言 vault 也能各用其所长。

搜索结果可直接拖入 Canvas，形成临时工作区。

第二层：Connect——看到从没连上的线

找到一篇笔记之后，Vault Curate 可以围绕它生成一张关系图谱（Canvas 格式）：

• 紫色边：语义相近但尚未 wikilink 的笔记（核心价值：发现隐形关联）
• 灰色边（带箭头）：你已 wikilink 的笔记
• 青色节点：Cold（冷门）笔记——很久没访问过的

紫色边是这套功能最有意思的地方。你写了两篇笔记，自己都没意识到它们在说同一件事——Vault Curate 把这条线画出来了。

语义路径功能更进一步：选两篇笔记，它会搜索整个语义地图，找到连接它们的"跳板笔记链"——每一步都有语义相似度评分，告诉你这条路径有多强。如果两篇笔记之间没有可靠的路径，它会诚实地告诉你具体数值，而不是假装没问题。

你的决定决定一切：紫色边可以一键转 wikilink（永久），也可以点 ✕ 彻底忽略（永久不再提示）。Hot/Cold 热度同样会响应你的行为——编辑过的笔记会自动升温，单纯打开则不会。

第三层：Rediscover——让冷门笔记重新发光

Hot/Cold 分层帮你对抗"遗忘曲线"：长期未访问的笔记被标记为 Cold，图谱视图里显示为青色节点。你可以选择只探索 Cold 笔记，重新发现那些被你遗忘的积累。

可选：AI 辅助 curation（默认关闭）

设置里打开后，Vault Curate 会调用 Ollama（本地 LLM）或 OpenAI API：

• 自动生成描述：给没有 description frontmatter 的笔记补充一行简介
• MOC 生成：将笔记按主题分组，生成 Maps of Content 结构

全程可选，不开 API key 就无法使用，数据不会离开本地。

---

技术架构

Vault Curate 是一个标准的 Obsidian 插件（TypeScript + esbuild），核心架构分层清晰：

嵌入层（embedding/）：WebGPU/WASM 环境运行 @huggingface/transformers 的 BGE 向量模型，文本被切分为 chunks 后一次性编码存入 IndexedDB/本地文件系统。备选 Ollama 模式通过本地 API 调用。

搜索层（search/）：混合检索融合 BM25（sql.js 内置 FTS5）、向量相似度和模糊匹配。HDBSCAN 聚类算法（hdbscan-ts）用于发现语义社区结构。

图谱层（canvas/）：将语义邻居关系渲染为 Obsidian Canvas 格式，节点和边的元数据存储在 JSON 中。

热力层（heat/）：基于访问时间、编辑事件维护笔记热度分数，支持热力衰减算法。

存储层（storage/）：使用 sql.js（SQLite in WASM）存储索引快照，支持导出/导入。

关键依赖：

库	用途
@huggingface/transformers	WebGPU 向量编码
sql.js	本地全文搜索索引
hdbscan-ts	语义聚类
vitest	单元测试

代码质量方面：使用 TypeScript 严格模式，模块划分明确（有 indexer、searcher、search-view、settings 等独立模块），有完整的 Vitest 测试覆盖（test/ 目录），文档丰富（README 约 19000 字，含繁体中文翻译）。

---

争议与局限

1. 性能上限明显：5000+ 笔记时 WebGPU 索引时间在分钟级，语义路径计算在大 vault 上可能卡顿。没有 GPU 时完全依赖 WASM fallback，性能更差。

2. 中文语义模型仍有局限：即使内置了 bge-small-zh-v1.5，专业领域（医学、法律）的术语仍然容易与通用语料混淆，效果不如 GPT-4 加持的云端 embedding。

3. Obsidian 版本强依赖：作为插件，必须跟随 Obsidian 主程序版本，Obsidian 大版本更新可能导致插件暂时不可用。

4. Canvas 格式隐患：生成的图谱是 .canvas 文件，如果 Obsidian 未来改变 Canvas 格式，旧文件可能无法打开。

5. 隐私并非绝对：虽然 embedding 发生在本地，但 Hot/Cold 行为数据、部分缓存仍会写入本地磁盘，理论上可通过文件取证重建访问记录。

---

行业意义

Vault Curate 代表了本地优先 AI 笔记的一个务实路线：不追求用 LLM 重写一切，而是把 AI 的能力框定在发现和呈现的边界内。

这种"AI 辅助，用户决策"的哲学正在形成一种趋势——不把所有信息处理都交给 AI 代理，而是让人始终处于回路中心。Vault Curate 的语义路径、关系图谱、Hot/Cold 分层，本质上都是在帮用户对抗数字遗忘。

加上 WebGPU 让浏览器跑 embedding 成为可能，未来会有更多笔记工具走向"零 API 依赖"的本地 AI 路线。Vault Curate 是这个方向上目前最成熟的开源实现之一。

---