No. 33: 我删掉了 2.4 万行知识库，换回了一条更可信的整理流程

我曾经把 Obsidian 知识库做成一套很完整的系统。原始资料、Wiki、References、工作流、模板、项目、数据库、任务和热缓存各有位置，AI 还会负责 Ingest、补字段、更新索引和留下处理记录。

它看起来越来越专业，使用起来却越来越不像一个知识库。保存一篇文章以后，我需要判断它进入了哪一层、状态是否完整、索引有没有更新；想查一个主题时，又要先理解系统怎样处理过这批资料。

规则越来越多，信息并没有因此更可信。自动生成的字段很整齐，却不一定代表真实判断；一篇来源被加工成多个中间文件，也不等于我更理解它。

最后我做了一次逆向重构。那次提交删除了 24,659 行，把知识库重新收回到一条很短的路径：保存原文，明确触发整理，按主题形成 Wiki。

复杂流程最容易制造一种虚假的完成感

旧流程要求每份资料经过摄入、标准化、分类、索引和状态更新。它的出发点没有问题，我希望任何知识都能被机器稳定处理，也希望以后查找时不再遗漏。

但当元数据和中间状态多到一定程度，系统开始把「字段已经填满」当作「内容已经理解」。AI 可以迅速生成摘要、主题和标签，却可能没有识别资料里的冲突、证据强弱和适用边界。

这种完成感很危险。页面数量增长了，索引看起来完整了，可当我需要把某条结论用于产品决策时，仍然要回到原文检查。既然最终必须回看来源，流程就应该优先保护这条核对路径，而不是继续堆积机器生成的状态。

我把知识库缩成 raw 和 wiki 两层

现在的主链路只有两个核心位置。

raw/ 保存原始来源。Chrome Web Clipper 把网页资料放到这里，原文在整理前后都不能被改写或重命名，只允许移动到 Agent、Design、Prompts、Self-media、Skills 五个分类目录。移动前后的正文还要保持 SHA-256 一致。

wiki/ 保存经过判断后的主题知识。它不是原文摘要的镜像，也不要求一篇 raw 对应一篇 Wiki。一篇 Wiki 可以综合多个来源，一篇 raw 也可以暂时不生成任何 Wiki。

这两层分工很简单：raw 对来源负责，wiki 对判断负责。前者要尽可能保真，后者要明确区分事实、来源主张、我的判断、尚待验证的假设和行动建议。

只有一句明确指令可以触发写入

旧知识库希望自动工作。仓库一打开，AI 就可能根据流程继续摄入、补索引或更新状态。自动化看起来省事，却让「什么时候会改文件」变得不清楚。

现在只有我明确说出「整理知识库」，写入流程才会开始。普通对话、打开仓库或查询资料都不会触发整理。查询也先读 Wiki，只有现有知识不足以支撑回答时，才回到 raw 补证据。

这条规则减少了很多自动化，却换回了可预期性。我知道什么动作会改变知识库，也能在整理前检查待处理资料，在整理后核对移动、合并与新增结果。

对于个人知识库，自动化程度并不是越高越好。只要自动写入会改变长期上下文，它就应该有清楚的触发条件和可审查的结果。

不是每篇收藏都值得生成一篇新笔记

我给整理动作划分了四个处理高度，但不再把它们写成长期状态字段。

高度 0 只是归档，资料被分类保存，不进入 Wiki。高度 1 把新证据合并进已有主题。高度 2 在确有独立价值时新增一篇 Wiki。高度 3 则跨多个来源做综合，形成新的结构或判断。

这个分层改变了知识库的增长方式。过去一篇收藏往往推动一篇新笔记，现在系统先问：它是否增加了新的事实，是否修正了已有结论，是否值得形成独立主题，还是只需要留在 raw 等待以后使用。

页面变少并不是损失。相似信息被合并以后，查询入口更稳定，冲突也更容易被看见。知识库不再按照收藏次数增长，而是按照认知变化增长。

低质量资料可以保留，但不能混进结论

整理不等于把不喜欢的资料删除。营销内容、低质量文章和互相冲突的来源，仍然可以留在 raw，因为它们也是当时信息环境的一部分。

只有两类内容允许删除：经过 SHA-256 或全文比较确认的精确重复，以及完全没有可恢复正文的无效文件。质量不足只是跳过编译的理由，不是销毁来源的理由。

遇到冲突时，Wiki 也不能替我悄悄选一个答案。流程需要优先核对一手资料，记录不同来源各自主张什么，再说明当前判断和不确定性。无法验证的内容就保留为无法验证，不能为了让页面顺滑而补出一个结论。

这条边界对 AI 尤其重要。模型很擅长把碎片连接成通顺叙述，而知识库需要它在证据不足时停止连接。

验证器只检查机器能够确定的部分

简化流程并不意味着完全依赖人工记忆。我保留了一个轻量验证器，用来检查 frontmatter、链接、索引和目录规则。这些问题有明确答案，适合交给程序稳定执行。

但验证器不会宣称一篇 Wiki 已经正确。它只能确认结构合法、引用可达、必要字段存在。观点是否忠于来源，综合是否跨越证据边界，仍然需要阅读和判断。

我也没有为这次重构引入 REST API、MCP、向量数据库或定时自动写入。它们以后也许有价值，但应该由真实失败来证明需求，而不是因为知识库看起来应该拥有这些组件。

删除 2.4 万行以后，我重新看见了知识本身

这次重构没有让我保存更多内容，却让我更容易回答三个问题：原文在哪里，这条判断依据什么，什么时候是我主动改变了知识库。

过去我试图用更多流程消除不确定性，结果只是把不确定性藏进了自动生成的状态。现在的系统承认一部分资料暂时不会被理解，一部分冲突暂时无法解决，一部分收藏只需要安静地留在 raw。

一个可信的知识库不需要假装所有内容都处理完了。它需要在未来重新使用一条知识时，仍然能回到来源，分辨事实与判断，并知道哪些地方还没有答案。

知识库可以少一半页面，但不能少掉来源、判断边界和一条能重新核对的路径。

项目：Obsidian Wiki

← Writing