当 LLM-Wiki 遇见真实生活：为什么 AI 知识库需要一个"操作系统"

本文是「AI 生活操作系统」系列的第一篇。

我想先问你一个问题：你上一次真正"用到"自己笔记库里的内容，是什么时候？

不是打开 Obsidian 往里面塞东西，不是整理文件夹，不是安装新插件——是真实地从你建立的知识体系里检索出一段内容，然后它帮你解决了一个实际问题。

如果你需要想一会儿，那这篇文章是写给你的。

一个新范式的诞生

2024 年底，Andrej Karpathy 在推特上描述了他正在实践的一种知识管理方式，随后在 Hacker News 引发了大量讨论。这个方式被社区称为 LLM-Wiki。

它的核心逻辑非常简单，简单到近乎颠覆：

不要自己写笔记。让 LLM 来写。你负责输入素材，LLM 负责组织、总结、维护整个知识库。

具体来说：你把原始素材——论文、文章、播客转录、对话记录——扔进一个目录里。然后让 AI 把它们编译成互联的 Markdown 文件，形成一个概念图谱。每个重要概念一个页面，页面之间用 wikilink 交叉引用，AI 持续维护和更新这张网络。

Obsidian 是浏览器，LLM 是维护者。你几乎从不自己写 Wiki——你负责的是提供素材、探索知识、和提出正确的问题。

这个范式的吸引力是真实的。它解决了知识管理领域一个长期以来无解的问题：维护成本。

Zettelkasten 的理想是美好的——每个概念一张卡片，卡片之间形成思维网络——但维护这张网络需要大量时间。卢曼能做到，是因为他把 Zettelkasten 当成了全职工作的核心工具，每天投入数小时。普通人做不到。

LLM-Wiki 的本质洞察是：维护工作可以外包给 AI。阅读是你的，判断是你的，但分类、摘要、交叉引用、更新——这些重复性的编辑工作，AI 比人类做得更快、更一致、更不知疲倦。

这个洞察是正确的。问题在于：这个范式是在一个隐含的假设下成立的，而当你试图用它管理真实生活时，这个假设会被打破。

一、LLM-Wiki 隐含的三个假设

任何系统都建立在假设之上。大多数时候，这些假设是隐而不显的——设计者在某个具体场景下思考问题，场景本身就是假设的来源。

LLM-Wiki 是在"专业知识管理"这个场景下设计的。这个场景给它带来了三个核心假设：

假设一：输入的素材是同质的。

论文是知识，技术博客是知识，播客讨论的内容是知识。它们的形态不同，但性质相同——都是"可以被编译成概念的信息"。Wiki 的处理逻辑对所有素材都适用。

假设二：用户的需求是"查询"导向的。

你想知道某个概念是什么，你去 Wiki 里查。你想了解某个领域的来龙去脉，你去 Wiki 里找。需求的形态是："我想获取关于 X 的知识。"

假设三：信息组织的最佳单位是"概念"。

所有知识都可以拆解为概念，概念之间存在关联，这些关联构成知识图谱。因此，以概念为中心组织信息是最合理的方式。

在专业知识场景下，这三个假设完美成立。一个 AI 研究员用 LLM-Wiki 管理他读过的论文和技术文章，是理想用法：素材同质（都是知识型内容），需求明确（想了解某技术细节时去查），组织方式匹配（Transformer 架构、注意力机制、位置编码——都是可以独立成页的概念）。

但当一个真实的人试图用 LLM-Wiki 管理"全部信息"时，这三个假设一一崩溃。

二、真实生活如何打破这些假设

让我们从一个具体场景开始。

设想你是一个 AI 领域的产品经理，某个普通工作日的下午，这些信息在 90 分钟内向你涌来：

• 同事发来了一篇 RAG 优化的论文，建议你读一下
• 老板在群里说，周五的产品 Demo 要提前到周三
• 家人发消息提醒你周末要带孩子打疫苗
• 你突然想到一个关于产品定价的新思路，觉得值得记下来
• 一个朋友推荐了一款 Mac 效率工具，说特别好用

五条信息，五种性质，同时到达。

如果你把这五条全部扔进 LLM-Wiki，会发生什么？

假设一崩溃：素材不再同质

RAG 论文可以被编译成概念页，没有问题。但"Demo 提前到周三"不是知识——它是一个需要触发行动的事件。"打疫苗"也不是知识——它是一个有时间约束的任务。

当这些内容进入 Wiki 的编译流水线时，AI 会面临一个根本性的困境：它无法正确处理这类信息，因为这类信息的正确处理方式根本不是"编译为概念页"。

AI 要么忽略它（信息流失），要么强行编译（产生无意义的 Wiki 页面，比如"Demo 时间变更 - 产品管理实践"这样的奇怪词条），要么把它和真正的知识混在一起返回给你（信噪比下降）。

无论哪种结果，都是坏的。

更深的问题在于：随着使用时间增长，这种"异质内容"会不断累积。你的 Wiki 会逐渐从一个清晰的知识图谱，变成一个混杂了任务、提醒、随手记、感想、真正知识的大杂烩。它的质量会以你感知不到的方式悄悄退化，直到有一天你发现在里面查东西越来越费劲。

假设二崩溃：需求不再是"查询"导向

"Demo 提前到周三"需要什么？不是查询，是追踪——你需要知道它的当前状态，你需要在某个时间点被提醒，你需要记录与它相关的准备进展。

"打疫苗"需要什么？不是查询，是提醒——在特定时间触发，完成后标记为已完成，消失。

Wiki 没有"状态"这个概念。它不知道什么是"待办"、"进行中"、"已完成"、"等待他人"。Wiki 里的内容存在于一种永恒的当下——每个概念页都是一个静态的知识快照，不随时间推移而改变状态。

这对知识来说是对的——"Transformer 的注意力机制原理"不会随时间改变状态。

但对任务来说是错的。任务的本质是有生命周期的：它从"待办"变成"进行中"，再变成"完成"，然后消失。把任务放进 Wiki，就像把一个需要流动的东西放进了一个静止的容器。

假设三崩溃：不是所有信息都适合以"概念"为单位组织

那个关于产品定价的新思路，应该怎么处理？

它是未成熟的——你还不确定它是否值得发展。如果现在把它编译成 Wiki 概念页，你实际上是在强行给一个还没准备好的想法盖棺定论。过早固化会扼杀进一步思考的可能性。

那款 Mac 效率工具推荐呢？它是纯参考性质的——你可能用到，可能不用，不需要和其他任何内容建立深层关联，更不需要交叉引用。把它编译成概念页，是大炮打蚊子。

概念图谱是为"稳定的、可引用的、相互关联的知识"设计的。未成熟的想法需要的是孵化空间，参考信息需要的是索引，两者都不是概念。

三、更深层的问题：维度混淆导致的系统熵增

我们现在可以更精确地描述这个问题。

信息并不是铁板一块，它天然地分布在五个维度上：

每个维度都有自己天然适合的组织方式。这不是个人偏好的问题，而是信息性质决定的：任务之所以适合状态机，是因为任务的本质就是状态的流动；知识之所以适合概念图谱，是因为知识的本质就是概念间的关联。

LLM-Wiki 是为知识维度精心设计的系统，它用概念图谱这种组织方式做到了极致。但当你把其他四个维度的信息也推进来，这种组织方式就变成了普罗克汝斯忒斯之床——它会把所有信息削足适履，强行纳入同一种形态。

结果是：知识维度被服务得很好，其他四个维度被扭曲、流失、或制造噪音。

这就是维度混淆。而维度混淆会导致一种特定的系统退化模式，我称之为系统熵增——

不是一次性的崩溃，而是缓慢的、难以察觉的质量退化。你的 Wiki 越来越大，但越来越难用。你放进去的东西越来越多，但能找到的越来越少。维护它的边际成本在上升，而使用它的边际价值在下降。

直到有一天，你意识到自己又一次建了一座废墟。

四、"多开几个库"为什么也不是答案

面对这个问题，最直觉的解法是：分库。

知识一个库（LLM-Wiki），任务一个库（Things/Notion），生活一个库（另一个 Obsidian Vault）。每个库专注自己最擅长的维度，互不干扰。

这个方案有直觉上的合理性，但它引入了三个新问题，而这三个问题在长期使用中往往比原来的问题更致命。

问题一：信息在库边界处大量流失。

那篇 RAG 论文，相关的内容应该在知识库。但你在推进一个使用 RAG 的产品项目——这个项目在任务库里，项目里应该链接到那篇论文的核心内容。怎么链接？你要在任务库里手动粘贴一个知识库的路径，或者复制一段摘要，或者在两个地方各维护一份信息。

无论哪种方式，这都是手动维护的接口，而手动维护的接口注定会随时间腐烂。随着两个库各自增长，它们之间应该存在的关联会越来越多地流失，知识和任务之间的上下文断裂会越来越严重。

问题二：切换成本杀死使用习惯。

切换成本不只是点击几下的物理成本，更重要的是心智切换成本。当你的思维在一个场景中流动时，切换到另一个工具需要重新加载不同的心智模式。频繁的工具切换会打断思维的连贯性，降低使用频率，最终让你只用最顺手的那一个，其他的荒废。

问题三：维护成本乘以 N。

每个库都需要维护。Schema 需要维护，结构需要调整，旧内容需要整理。三个库就是三倍的维护工作。AI 在单库中可以理解整体上下文，做出一致的决策；跨库运作时，它需要被重复配置，而且无法建立跨库的关联。

分库的本质是用"物理隔离"解决"逻辑组织"的问题。它消除了维度混淆，但代价是消除了维度之间应有的关联。这不是一个更好的架构，而是一个用不同方式失败的架构。

五、问题的精确定义

经过前四节的推演，我们现在可以精确定义需要解决的问题：

如何在单一 Vault 中，既保持 LLM-Wiki 对专业知识的深度编译能力，又能容纳生活全域信息的多维度管理需求，且不产生维度混淆导致的系统熵增？

注意这个定义里的每一个约束：

• 单一 Vault：不能靠物理分离解决问题
• 保持 LLM-Wiki 的深度编译能力：不能为了兼容其他维度而降低知识库的质量
• 容纳多维度管理需求：不是"忽略"其他维度，是"用对的方式管理"
• 不产生维度混淆：解决方案本身不能引入新的混乱

这四个约束同时满足的解，指向一种特定的架构方向：

不是单层的系统，而是分层的系统。

一层负责生活全域，有足够的弹性容纳五个维度的信息，能理解"任务"和"知识"和"参考资料"之间的区别，为每种信息提供适合它的组织方式。

另一层嵌套在这个系统内部，专门负责知识维度，保持高信噪比，让 LLM-Wiki 的编译逻辑在一个被保护的空间里完整运转。

两层之间有精确定义的接口：什么信息从外层流入内层，什么时候从内层提取出来供外层使用。

这个分层架构不是"两个系统拼在一起"，而是一个有内核和外壳的有机整体。外壳是生活操作系统，内核是知识引擎。

六、为什么是 PARA

现在的问题是：外壳用什么？

它需要满足几个条件：

• 能处理五个维度的信息（而不只是其中一个）
• 以"可操作性"而非"主题"组织信息（因为同一个主题的内容可能属于不同的操作状态）
• 有清晰的边界，能接纳 LLM-Wiki 作为内嵌子系统，而不是把它淹没
• 理念上的轻量，不需要复杂的前置设置

PARA 是目前已知最接近这些要求的框架。

PARA 的设计核心不是按主题分类，而是按可操作性梯度分层：

• Projects（项目）：有明确终点和时间边界的承诺，需要立即推进
• Areas（领域）：没有终点但需要持续维护标准的生活面向
• Resources（资源）：感兴趣但暂时不需要行动的材料
• Archives（归档）：不再活跃的一切

这个梯度的关键洞察是：同样的内容，对你今天的可操作性不同，应该在不同的位置。

一篇关于 RAG 的论文，如果你正在推进一个使用 RAG 的项目，它应该在 Projects 里，紧贴着项目笔记。如果你只是感兴趣但暂时用不到，它应该在 Resources 里。如果项目结束了，知识沉淀到了 Wiki，原始论文应该进 Archives。

这种组织方式让"找到你现在需要的"变得极其容易，同时不丢弃"未来可能需要的"。

更关键的是：PARA 的 Resources 层天然可以作为 LLM-Wiki 的入口。普通资源放在 Resources 的普通子目录，专业知识素材进入嵌套在 Resources 层的 Wiki 子系统。Wiki 是 Resources 的深度增强版，而不是与 PARA 并列的独立系统。

这个接口的设计是整个架构的精妙之处：LLM-Wiki 没有被降级，它保持着完整的专业知识编译能力；PARA 没有被复杂化，它仍然是那个四层结构；两者之间的关系是"包含"而非"并列"，这种关系既清晰又可扩展。

写在最后

本文的核心论点可以用三句话概括：

LLM-Wiki 是一个为专业知识场景精心设计的优秀范式，它的局限不是缺陷，而是边界。

真实生活中的信息不是单维度的，强行用单一系统处理多维度信息，结果必然是维度混淆和系统熵增。

解决方案不是更好的知识库，而是一个能容纳知识库的生活操作系统——PARA 作为外壳管理生活全域，LLM-Wiki 作为内核管理专业知识，两者在单一 Vault 中以分层架构共存。

这个架构长什么样？每一层的边界如何划定？两层之间的接口如何设计？

这是第二篇文章要回答的问题：《一个 Vault，两套逻辑：PARA × LLM-Wiki 融合架构的设计推演》。

「AI 生活操作系统」系列文章：

第一篇（本文）：当 LLM-Wiki 遇见真实生活——为什么 AI 知识库需要一个"操作系统"

第二篇：一个 Vault，两套逻辑——PARA × LLM-Wiki 融合架构的设计推演

第三篇：AI 作为系统管理员——用 Agent Schema 激活你的 Obsidian 生活操作系统