起因

我的笔记散在四个地方：Obsidian 里一部分、几个 AI 工具的会话记录里一部分、浏览器书签里一部分、
还有一部分在「等我有空再整理」的文件夹里。

结果是：收藏越多，越找不到。

真正让我下决心的是一个很具体的问题——我想找半年前写过的一段
「Cloudflare Workers 怎么复用连接」的笔记，翻了三个 App 都没找到。
那一刻我意识到，我缺的不是存储，是检索和结构。

我想要的到底是什么

我把需求写成了四条，后来整个系统都是围绕这四条长出来的：

  1. 一个地方：所有笔记最终汇到一个仓库，不管原来在哪；
  2. 搜得到：关键词能搜，语义也能搜；
  3. 看得见关系：这篇笔记和哪些文档有关，为什么有关；
  4. 判得准：我的知识库有没有违反自己定的规范（缺元数据、断链、过期、含密钥）。

第 4 条听起来最玄，其实是最后落地时最有用的一条——见下面。

为什么不用现成的

我试过几个方向：

  • 云笔记 + 全平台同步：同步没问题，但检索只有关键词，没有关系；
  • 现成的 RAG 工具：能问答，但索引是黑盒，我改不了它的分片策略；
  • 笔记软件自带的图谱：好看，但只是”双链的可视化”，不是可计算的图。

共同的问题是：它们不让我碰索引。

而知识库的价值恰恰在索引层——分片怎么切、实体怎么抽、规则怎么判。
所以我决定自己写一个，只在索引层花功夫，其他都尽量简单。

最后的形态

  • 存储：Markdown 仓库（GitHub 私有仓），跨设备靠 git 同步；
  • 索引：GitHub Actions 里跑，产出切片、向量、三元组、判定结果；
  • 查询：Cloudflare Worker + D1 + Vectorize，全部落在免费额度内；
  • 入口：一个网页门户 + 一个桌面客户端 + 一套 MCP 工具。

关键取舍是：不绑卡。所以没有用 R2，索引产物直接写 Workers KV，
原文由 Worker 通过 GitHub API 直读。

第 4 条需求意外地有用

我原本以为”规范判定”是个锦上添花的功能，直到它第一次跑出结果：

warn  标题重复    knowledge/memory/dsh/profiles/desktop/cordis.yml
      与 1 篇文档同名，容易混淆
warn  双链断链    31 处 → 过滤掉代码示例里的伪链接后剩 7 处
info  孤立文档    756 篇没有入链

756 这个数字很刺眼，但它是对的：那批文档是机器导入的会话记录，本来就没有入链。
规则的价值不是”发现问题”，而是”让问题可度量”。有了度量，才知道先修什么。

下一步

语义检索和关系图谱已经能用了，但我还想加两件：

  • 中文分词后再进全文索引（现在 unicode61 会把整句中文当成一个 token）；
  • 增量索引（现在每次全量重建都吃一次嵌入额度）。

这两件事都不难，难的是别把系统搞复杂。这个博客大概会记录它们。