引言知识的困境五年几千篇笔记。起初一切井井有条目录清晰、标签完善、双向链接完整。两年后秩序开始瓦解。找某条笔记翻半天也想不起存在哪儿某个主题涉及十几篇文章想整理却发现要改的地方太多干脆放弃链接断了懒得修新写的内容不知道该归到哪个分类。知识库像一间不断塞满东西的房间——东西越多越有价值但也越来越乱。这不是工具的问题。Obsidian 已经足够优秀。问题在于知识的价值随积累增长但维护成本增长得更快。我们期望的是一个数字分身随叫随到的智能秘书——记得看过什么、知道要找什么、能主动提醒关联信息。现实却是花在整理知识上的时间经常超过学习和思考的时间。维护——更新链接、调整分类、补充摘要——是纯粹的事务性工作。它们不创造新知识只是让已有的知识保持可用。人类不擅长这些也不该做这些。核心悖论如果由人维护积累越多腐化越快如果由机器维护积累越多价值越高。LLM Wiki 的赌注就是把这个维护工作交给 LLM让知识积累重新变成好事。传统方案的局限先看看已有的工具。双链笔记Obsidian、Logseq用双向链接建立知识网络图谱视图可视化关联。但链接要手动创建图谱要持续维护——反链只是机械显示哪些笔记提到了这个概念不会理解概念之间的真正关系。Notion 之类的结构化工具提供模板和数据库但结构需要预先设计——知识演化时僵化的结构反成束缚。传统搜索和 RAG 走的是另一条路分块存储文档查询时检索相关片段LLM 基于片段生成答案。这种方式有三个问题无状态。每次查询都是独立推导。问一个需要综合五篇文档的问题LLM 要重新找、重新读、重新理解、重新合成。同一个问题问十次推导十次。碎片化。文档被切分成孤立的块段落之间、文档之间的上下文和关联在切分时丢失了。被动。只在查询时工作闲置时不整理、不关联、不更新——知识没有被编译只是被重复解释。这些工具的共同局限维护工作留给了人类。双链依赖人工建链接Notion 依赖人工更新结构RAG 虽然自动索引文档但从不主动整理关联——它只在被查询时才活过来。这不是设计缺陷而是设计权衡在 LLM 出现之前机器无法理解知识语义维护只能由人做。但人类不擅长、也不该把时间花在整理链接和补充摘要上。我们擅长创造、思考、判断不擅长做图书管理员。缺的不是一个更快的检索工具而是一个活的知识库——自己生长、整理、建立关联像一个理解内容的助手而不是关键词匹配的搜索引擎。LLM Wiki 的核心思想核心创新很简单在用户和原始文档之间增加一个由 LLM 维护的 Wiki 层。这个 Wiki 不是搜索引擎不是向量数据库不是笔记文件夹——它是一套 LLM 持续编写和更新的 Markdown 文件是知识的编译结果。这对应一种范式转换。传统方案的核心动作是检索存好文档查询时找到片段立即生成答案。LLM Wiki 的核心动作是编译新文档进入后LLM 主动提取、整合、更新 Wiki 中的相关页面。一次编译多次直接回答。传统 RAG 像每次考试都要重新翻书。LLM Wiki 像提前上过课知识点已经记住考试时直接答。Wiki 是知识的内存原始文档是硬盘——从内存读比每次查硬盘快得多。另一个关键特性是复利效应。Wiki 不是静态存档而是随每个新文档持续演化。每读一篇论文它更新相关概念的解释补充交叉引用标记与旧知识的矛盾。积累越久Wiki 越丰富已有的关联越完整吸收新知识的成本越低。老专家吸收新信息比新手快因为已有完整的认知地图——Wiki 也是这样。LLM Wiki 还重新定义了人与机器的分工。LLM 做事务性工作阅读文档、提取要点、编写摘要、维护链接、标记矛盾。人类做判断性工作决定研究什么问题、寻找什么来源、判断知识有没有意义。这不是用机器替代人而是用机器承担它擅长的苦活把人的精力解放出来做真正需要人的事情。这个想法早在 1945 年就有雏形。Vannevar Bush 在《诚如我所思》中提出了Memex——一种个人知识库通过联想式链接把文档关联起来。但这台设备从未真正普及因为面临一个无法解决的核心问题谁来维护这些链接手动链接的工作量远远超过任何个人的承受能力。LLM Wiki 是对这个问题的迟到八十年的回答让机器做维护。架构与实现三层架构LLM Wiki 分三层各有明确职责。Raw Sources原始来源是你的文档库——论文、文章、书籍、网页、笔记。所有原始材料放这里这些文档是不可变的LLM 读取但从不修改。它们是整个系统的唯一真相来源。Wiki维基是 LLM 生成的 Markdown 文件集合——概念页、实体页、摘要、比较、索引。LLM 每处理一个新文档就更新相关 Wiki 页面补充摘要、更新定义、增加交叉引用、标记矛盾。Wiki 不是原始文档的副本而是对知识的编译——把散落在各处的知识提取出来重新组织成可导航的结构。Wiki 存储在本地文件系统每个概念对应一个 Markdown 文件文件内通过[[双向链接]]相互引用文件头用 YAML frontmatter 标注标签、日期、来源数量等元信息。这套链接网络可以直接用 Obsidian 打开Obsidian 的图谱视图自动渲染出知识网络的拓扑图——哪些是中心节点哪些是孤立页面一目了然。LLM 负责写内容和建链接Obsidian 负责渲染图谱。Schema模式是整个系统的大脑。它告诉 LLM Wiki 应该长什么样、遵循什么规范、如何处理新文档、如何回答问题。通常是一个 Markdown 文件类似 Claude Code 中的CLAUDE.md在其中定义页面格式、命名约定、工作流程、质量标准——本质上是给 LLM 的一份Wiki 维护手册。随着使用深入Schema 会不断演化反映你对系统理解的加深。三层关系Raw Sources 是输入Wiki 是输出Schema 是规则。Sources 提供素材Schema 指导 LLM 如何处理Wiki 沉淀结果。Wiki 的质量取决于 Schema 的清晰程度Schema 的清晰程度取决于你对领域的理解深度。三大操作围绕 Wiki有三个核心操作不断循环。Ingest摄取是最关键的操作。把新文档放入 Raw SourcesLLM 读取文档、提取关键信息、更新 Wiki写摘要、更新相关概念、补充交叉引用、建立与旧知识的关联。一篇文档可能触发十几处 Wiki 修改。你不是旁观者阅读摘要、检查更新、引导 LLM 强调什么。一个 Ingest 完成后知识已经从刚读的文档变成Wiki 中的一页。Query查询是向 Wiki 提问。LLM 读取相关页面综合信息给出有出处的答案。关键区别读的不是原始文档的碎片而是已经编译好的 Wiki——交叉引用已存在综合已完成矛盾已标记不需要重新推导。Lint检查是定期的健康扫描。让 LLM 检查 Wiki 的一致性有没有矛盾有没有被新来源推翻的说法有没有孤立页面有没有重要概念被提到但没有自己的页面LLM 主动修复可修复的部分让 Wiki 保持健康而不是随时间腐化。Index 和 Log两个特殊文件帮助导航不断增长的 Wiki。index.md是内容目录列出 Wiki 中所有页面每个页面附一句摘要按类别组织。LLM 读取 index 来找到相关页面而不是漫无目的地搜索整个 Wiki。在中等规模百篇来源、数百页面下这比向量检索简单得多也更可靠。log.md是时间线日志按时间顺序记录所有操作哪天 Ingest 了什么文档、回答了什么查询、做了哪次 Lint。每次操作有时间戳和简要描述。这让你看到 Wiki 的生长过程LLM 也能通过 log 了解最近发生了什么避免重复工作。一个具体的例子假设你正在研究机器学习领域Wiki 中已有transformers.md、attention.md、nlp.md它们已经互相链接。其中transformers.md包含 RNN、CNN 作为 backbone 的历史背景以及注意力机制最早用于序列模型的说法标注了 2 个来源。你把论文“Attention Is All You Need”Vaswani et al., 2017放入 Raw Sources告诉 LLM“请处理这个文档。”LLM 读取 SchemaSchema 规定摄取论文时更新相关概念页面而非仅新建摘要页、建立双向链接、标记与旧知识的差异、在 log.md 中记录本次操作。还规定了命名约定摘要页放在papers/子目录概念页放在concepts/子目录。于是 LLM 开始工作。第一步更新已有的 transformers 页面。LLM 在concepts/transformers.md基础上融合找到模型架构一节将RNN 作为 backbone更新为彻底抛弃 RNN仅用注意力机制找到注意力机制一节补充多头自注意力成为主流frontmatter 中sources从 2 改为 3保留原有的[[attention]]和[[nlp]]链接新增[[../papers/attention-is-all-you-need]]作为来源引用。第二步标记矛盾而非掩盖。LLM 注意到 Wiki 中原本说注意力机制最早用于序列翻译任务但这篇论文的实验结果显示注意力在机器翻译上效果最佳于是在页面底部新增一节潜在矛盾注意力的定位——是辅助 RNN 的工具还是独立的核心架构本 Wiki 中存在两种说法详见 [[attention]] 和 [[papers/attention-is-all-you-need]]。待后续来源验证。第三步新建论文摘要页。在papers/目录下新建attention-is-all-you-need.md包含摘要、核心贡献、与现有 Wiki 的关系分析。第四步更新 index.md 和 log.md。整个过程LLM 做了所有链接维护、内容融合和矛盾标记的工作。你只需要在 Obsidian 中打开transformers.md看看融合后的内容是否准确、矛盾标记是否有道理。这就是 Schema 驱动的 IngestSchema 定义规则LLM 执行规则Wiki 沉淀结果。关键不是新建而是融合已有——同一概念被多篇文档提及时Wiki 越来越丰富、越来越准确而不是越来越冗余。应用场景个人知识管理。目标、健康、心理、成长——这些领域的知识零散分布在书籍、文章、播客、健身记录、饮食日志里。LLM Wiki 把所有这些整合成一张个人地图今天读了篇关于睡眠的文章Wiki 自动更新睡眠页面补充与压力管理的交叉引用甚至提醒你这篇新内容和上个月的某篇笔记有冲突。学术研究。花几周或几个月深入一个领域读几十篇论文。LLM Wiki 帮你构建研究维基每读一篇论文就 Ingest 一次Wiki 生成摘要页、更新相关概念的解读、标记哪些论文结论一致、哪些互相矛盾。几个月后你拥有了一份完整的领域综述——不是复制粘贴的笔记而是经过编译和关联的知识网络。阅读一本书。读《百年孤独》这样的长篇可以边读边 Ingest 每章内容Wiki 构建人物页、地点页、主题页、情节线页并建立它们之间的关联。读完后你拥有了一本书的维基百科——比任何书评都更贴合你的阅读视角。团队知识库。Slack 讨论、会议纪要、项目文档、客户访谈——团队知识散落在各个工具里。LLM Wiki 作为团队的记忆中心LLM 读取所有对话和文档维护一份不断更新的团队知识库。新人入职不用翻遍半年的 Slack 历史直接问 Wiki。商业分析、尽职调查。LLM Wiki 追踪一个行业或公司的方方面面新闻、财务数据、监管文件、研究报告。新信息进入时LLM 更新相关分析、标记与战略的关联、对比历史数据。投资者或分析师拥有了一个持续更新的竞争情报系统。旅行规划。把目的地的文章、攻略、文化背景、历史介绍都丢进 Raw SourcesLLM 编译成旅行百科每个景点有自己的页面页面之间标注地理关系、历史文化脉络、最佳游览顺序。出发前对目的地的了解已经成体系而不是碎片化的攻略集合。兴趣爱好。园艺、摄影、烹饪、历史——任何想深入的主题都可以像做研究一样构建 Wiki。一年后在这个爱好上积累的知识已经形成完整的知识网络而不是文件夹里一堆未整理的笔记。本质上任何需要持续积累、期望知识能够复利增长的场景LLM Wiki 都适用。优点、代价与权衡核心优势维护成本趋近于零。这是最核心的变化。传统知识库会随时间腐化链接断裂、分类过时、新知识无法整合。LLM Wiki 不存在这个问题——维护工作由 LLM 完成它不会疲倦、不会遗忘。每次 Ingest 触发十几处 Wiki 更新成本几乎为零。人类只需要持续提供新的 Sources。知识复利增长。Wiki 越积累越有价值。LLM 不是从零开始理解新文档而是基于已有 Wiki 上下文来处理。已有的关联越多新知识越知道该往哪儿归档、该和什么建立链接。积累加速积累。主动整理而非被动检索。传统方案只在被查询时工作闲置时什么都不做。LLM Wiki 在你阅读新文档时就在整理在你没有提问时就在检查一致性。这种主动性是传统工具无法提供的。人机各尽所长。LLM 承担重复性阅读、跨文档关联、格式调整人类做真正需要判断的事情决策研究什么问题、评估知识有没有价值。这是合理的分工。代价与挑战LLM Wiki 也有真实的代价不是所有场景都适合。LLM 调用成本。Ingest 一篇文档可能触发十几处 Wiki 更新每次更新都是一次 LLM 调用。长期使用需要规划是否用更小的模型处理简单任务是否在后台批量处理而非实时调用隐私风险。LLM Wiki 需要把文档内容发送给 API 提供商。对于商业机密、研究未公开数据这可能不可接受。应对方式使用本地部署的开源模型如 Ollama、使用承诺不上传数据的提供商、或只把非敏感内容放入 Wiki。AI 质量依赖。Wiki 的内容由 LLM 生成LLM 会犯错理解偏差、错误关联、过时信息。人类需要审阅 Wiki不能完全信任 LLM 的输出。Wikipedia 有人类编辑审查LLM Wiki 也需要人参与质量把控。Schema 维护成本。Schema 需要随你对领域的理解加深而持续调整。一开始的 Schema 往往不够完善需要在实践中迭代——这意味着一定的初始学习曲线。场景局限性。LLM Wiki 适合文本密集、逻辑关联重要的知识工作。对于高度视觉化、高度结构化、或涉及大量多媒体的场景Wiki 的价值有限。它擅长处理文字能描述清楚的知识。适用与不适用最适合需要持续积累大量文本知识的场景、知识之间存在复杂关联的场景、愿意投入时间维护 Schema 的用户。不适合数据量大但关联少的场景、高度敏感不便上传的场景、需要精确事实保证的场景。反思与启发LLM Wiki 首先是一种思想然后才是一种实现方式。核心洞察是三个原则知识应该被编译而不是被重复推导维护工作应该由机器承担而不是由人承担知识库的形态应该是一张不断生长的网络而不是一堆文档的集合。这些原则不依赖某个特定的软件实现。你可以在 Obsidian 中实践用 LLM 生成笔记摘要、主动建立链接、检查知识一致性。也可以用纯文本文件和脚本搭建简化版本。或者按原文设计构建完整的三层架构。关键是思路的转换不再问我应该用什么工具来管理知识而是问知识应该怎么被维护才能在我需要时随时可用。工具会演进API 会变化但这个思路的寿命可能比任何工具都长。1945 年 Vannevar Bush 提出了 Memex 的愿景受限于当时的技术无法实现。今天LLM 让这个愿景第一次变得可以实践。让机器做苦活、让人做判断这个核心思想会一直适用。如果你用 Obsidian 或类似工具不妨换一个角度看待它不是我的笔记库而是我的知识维基。问自己这份知识下周还能找到吗明年还能理解吗新的笔记有没有地方归档知识管理的目标从来不是存储更多内容而是让知识在下一次需要时能够被轻松找到、被正确理解、被可靠使用。参考https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94fhttps://github.com/nashsu/llm\_wiki文章首发于 「小小寰宇」