本体

我给自己那个本地知识库打了两年多的分。 上一篇文章（知识库 3.0：从 9.3 到 9.7）收尾时我以为质量这条线已经走到头了：死链清零、frontmatter 覆盖 99.9%、九维审计全绿。直到我发现两个对不上的数字。 第一个：我的本体图谱里躺着 5,318 个节点，但没有任何一张表能告诉我「frontmatter 里的 ENT-B3-0002 对应图谱里哪一个」。两套 ID 体系，各自完整，互相沉默。 第二个：我用孤儿扫描器跑了一遍全库——569 个文件，入链为零。写了、存了、没人知道它们存在。 这就是本篇的主题：知识库 4.0，本体化。全部数字来自 2026-10-06 至 10-07 的现场实测，可复现。 一、先说清「本体化」到底解决什么 我的知识库一直有三层： 层 作用 3.0 时代的状态 内容层 文件本身 ✅ 一直健康 检索层 RAG 向量化，「搜得到」 ✅ 3.0 已解决 本体层 图谱与实体，「问得出口」 ⚠️ 建了库，但没通电 本体层的尴尬在于：图谱是建的（九个域、5,318 个节点），frontmatter 实体锚点是挂的（1,963 个声明），但两者之间没有一张机器可读的映射表。图谱用语义 ID（B3:ART:letters:001），frontmatter 用数字 ID（ENT-B3-0002），映射关系只存在于人类可读的 MOC 文档里。 后果：本体无法被程序查询。 你问「ENT-B3-0002 关联了哪些概念」，答案是人去读文档，不是 SQL 返回结果。一座通好电线杆但没接电线的城市。 本体化战役的第一件事就是接线：扫全库 frontmatter、解析九个域的 MOC、与图谱节点名称精确匹配——产出一张 1,963 行的映射表，98% 匹配，JOIN 实测 ENT-B3-0002 → B3:ART:letters:001 一次命中。 剩下 33 条匹配不上的怎么办？如实标 unmatched，不猜。 事后证明这个决定救了命（见 §四）。 ...