知识库 4.0：本体化 —— 569 个孤儿、一次 80.5 的暴跌，和让清理不再回潮的机制

我给自己那个本地知识库打了两年多的分。

上一篇文章（知识库 3.0：从 9.3 到 9.7）收尾时我以为质量这条线已经走到头了：死链清零、frontmatter 覆盖 99.9%、九维审计全绿。直到我发现两个对不上的数字。

第一个：我的本体图谱里躺着 5,318 个节点，但没有任何一张表能告诉我「frontmatter 里的 ENT-B3-0002 对应图谱里哪一个」。两套 ID 体系，各自完整，互相沉默。

第二个：我用孤儿扫描器跑了一遍全库——569 个文件，入链为零。写了、存了、没人知道它们存在。

这就是本篇的主题：知识库 4.0，本体化。全部数字来自 2026-10-06 至 10-07 的现场实测，可复现。

一、先说清「本体化」到底解决什么

我的知识库一直有三层：

本体层的尴尬在于：图谱是建的（九个域、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，不猜。 事后证明这个决定救了命（见 §四）。

二、孤儿清零：569 个文件的三种死法

孤儿扫描器的判据很朴素：入链为零的文件。569 个——占全库内容文件的 15%。

我的第一反应是「删」。但正确的做法是先分类，再动手。569 个文件最后落进四类：

A 类 · 建链（426 件）——内容有价值，只是没被索引发现。处理方式不是删，是在其所属域的索引里登记一行。30-RESOURCES 分区做完后孤儿从 456 降到 19，降幅 96%。

B 类 · 应入图（24 件）——实体型内容（书卡、思维卡、治理文档），适合进图谱。写进 JSONL 队列，交给注入工具。

C 类 · 归档（55 件）——聊天记录导出、流水线报告、旧快照。Gary 拍板后移入 40-ARCHIVE，原路径全部清出生效区。

D 类 · 设计即叶子（by-design）——这是最容易误判的一类，也是这次学到的最重要的一课：

transcripts 原貌存档、任务记忆逐日件、_stubs 占位件、_section_summaries 摘要——它们零入链不是病，是设计。 内容早已通过聚合节点或衍生节点进了图谱，wikilink 看不见 SQLite。

20-AREAS 分区重扫后孤儿数从 113 涨到 522，看起来像恶化。拆解之后：169 件 by-design、约 400 件是扫描日之后每天自动产出的新件（任务记忆、转录、摘要每天都在生成）。真正的结论不是「清了 113 又涨回来」，而是这类分区应该按目录白名单豁免，而不是逐件追杀。

三、80.5：量化评分在关键时刻的背叛与忠诚

战役收尾后我跑了官方体检脚本（六维加权、准确性 ×1.5、可复现）。

80.5 / 100。

比月初的 95.2 暴跌 14.7 分。结构维度直接 0 分——库根有 10 项未登记的顶层条目。

这就是量化评分和「六维全绿」文字描述的本质区别：文字可以说「结构健康」，数字必须给出 0 分的理由。 那十项里，有五个 .bak 备份散落在库根、一个 204 字节的脚本误输出文件（e）、一个零字节空文件（o）、一个空目录，和两个从未登记的协作目录。

修复本身只要十分钟。但我在这十分钟里又错了一次：把 kb-board-preview.png 移进了备份区——然后发现它本来就在白名单里，是合法文件，又移了回来。评分脚本的白名单和文档里的白名单是两套，改了文档不改脚本，分数不会变。

最后：95.8 / 100，超过战役前的 95.2。修复轨迹 80.5 → 92.8 → 95.8，每一步都有对应动作。

四、交叉复核抓出了我自己的错报

这次战役是三个 agent 并发执行的。有一幕值得单独写：

接管超时任务时，我用批量脚本给 113 个孤儿分了类，产出 9 条「应入图」清单。另一个负责图谱的 agent 做交叉复核时发现——其中 3 条（投资类文件）其实早已在图（B7:INV:* 节点实测命中），是我的批量分类没做「是否已在图」的核对。

它撤下了这 3 条，留了备份和更正说明。后来注入阶段的覆盖核对又证实：24 条入图候选全部早已在图，实际注入数为零。

两件事拼在一起是一个教训：「已入图」的判定必须独立于「谁说它没入图」。孤儿扫描器看 wikilink，图谱看 SQLite，两套证据源交叉才算数。三次清单误报（3 条、6 条、18 条）全部被覆盖核对拦下——如果直接照单注入，图谱里会多出 13 个重复实体。

方法论：任何「X 不存在」的断言，都要用与「X 被创建」不同的证据源复核一遍。

五、和「一次性清理」的本质区别：机制

3.0 时代我也清过一次（9.3→9.7 那次）。三个月后呢？部分问题回潮了。

这次不一样的地方在于战役结尾装了三个机制：

① 每日 05:30 automation。 增量注入工具自动发现新文件、判定域归属、幂等注入、anchors 自检、失败自动回滚。次晨首跑成功：发现 37 个文件、plan=0（图谱已最新）、六库 anchors 全 PASS。「新文件自动入图」从今天起是常态，不再依赖人记得跑。

② 重建恢复工具。 建库器是全量重建式的——手工注入的 25 个节点+8 条边，一次重建就会消失。解法不是改建库器（有破坏风险），而是做一个恢复工具：内置全部手工节点（从现行图谱实测导出，不手抄），重建后跑一次 --apply 即恢复。演练验证：删 25 节点 → 恢复 → 四表逐行与删除前一致。

③ 引用甄别口径。 归档移动前必须验证「零入链」——但什么算入链？工具会话状态、回滚镜像、处置报告自身，这三类不算。口径裁决权在 Owner，口径之外一个文件都不动。最后 59 个唯一候选：移动 55、保留 4（都有真实 wikilink 引用）。

六、用法到底变了什么：三个真实场景

以上是工程叙事。读者更关心的问题是：用这个知识库的方式，到底和以前有什么不同？ 三个场景，全部今天现场实测，输出原样贴出。

场景一 · 实体追溯：从「翻文档」到「一条 SQL」

问题：ENT-B3-0002 这个实体编号，对应图谱里的哪个节点？

3.0 时代的做法：打开 B3 域的 MOC 文档，肉眼扫 418 行映射列表，找到「ENT-B3-0002 = 11 Insights I Wish I Knew…」，再凭记忆去 SQLite 里查语义 ID。整个过程 3–5 分钟，且只有 B3 域有这份人读映射，其他八个域连翻都没得翻。

4.0 的做法（映射表 join 图谱，一条命令）：

1
2
3
4

查询: ENT-B3-0002 对应图谱哪个节点？
结果: B3:ART:letters:001 | article | 11 Insights I Wish I Knew To
      Make My One-Person Business A Success
attrs: anchor / date / file / num

3 秒，且九个域通用。 这就是「本体可被程序查询」和「本体存在但沉默」的差别。

场景二 · 跨域人物分布：从「凭印象」到「精确回答」

问题：「沈奕斐」这个人在我的知识库里出现在哪些域？

3.0 时代：要么 grep 全库文本（返回一堆正文提及的噪音，分不清「被提到」和「作为实体建模」），要么凭印象说「在家庭教育区吧」。事实上她同时是 B1（课程域）的教学者和 B5（家庭域）的方法来源——这个双重身份以前没有任何工具能直接回答。

4.0 的做法（九库按 name 查 person 节点）：

1
2
3

查询: 「沈奕斐」在哪些域？
  B1: B1:P:沈奕斐  (person)
  B5: B5:P:沈奕斐  (person)

顺带说一个反直觉的发现：「知道自己有什么」和「知道自己没有什么」是同一个能力。这场战役里图谱明确回答过的「没有」包括：脱不花不在 B1、NVIDIA 不在 B5——5 条 not-in-graph 与 24 条「已在图」一样，都是精确答案。模糊的库只会把「没有」伪装成「大概有」。

场景三 · 当天入库，当天可检索：从「等同步」到「已命中」

问题：昨天刚写的思维框架卡《亲手区》，今天能搜到吗？

3.0 时代：新文件要等手工触发增量同步，忘了跑就是「写了但搜不到」——和孤儿问题同源。

4.0 的实测（kb_auto_hook，今天上午）：

1
2

查询: 亲手区 判断力
rank1: 0.965  → 20-AREAS/02-reading-and-thinking/思维框架/亲手区.md

昨天上午写的卡片，今晨 05:31 automation 入图、之后 RAG 同步入向量索引，写作当天即可被检索命中。双轨各司其职：本体层（05:30）负责「结构上在图里」，检索层（12:15）负责「语义上搜得到」。

变化的本质，一句话

七、这轮战役的账本

过程里翻过的车也照实记：我接管超时任务后写的分类清单有 3 条错报（被交叉复核抓出）；我曾误判「anchors 20 行失败」——实际是我的验收 SQL 大小写写错；我曾误移一个白名单文件。agent 的产出要交叉复核，我自己的产出也一样。

八、遗留与下一步

• 孤儿扫描器应内置 gcf 覆盖核对（三次清单误报同源）；20-AREAS 加目录白名单豁免参数
• 注入规则 R1 目前只认思维框架卡，通用化待下批次
• RAG 向量层的增量同步是每日 12:15 的另一条 automation——本体层（05:30）和检索层（12:15）双轨，互为冗余

系列前作：知识库 2.0 升级全解 · 卡片索引层 · 知识库 3.0：从 9.3 到 9.7 · 从零搭建本地 AI 知识库