











LLM Wiki 的三层架构。
| 层级 | 管理者 | 职责 |
|---|---|---|
| Raw Sources | 用户 | 原始来源文档,不可变 |
| Wiki | LLM | LLM 生成的摘要和知识 |
| Schema | 用户 + LLM | 工作流规范和约定 |
精心收集的来源文档集合:
LLM 生成的 Markdown 文件目录:
定义维基组织的文档:
来源: LLM-Wiki-karpathy[5]
利用 LLM 构建个人知识库的模式。
传统 RAG:上传文件 → 查询时检索 → 生成答案。每次都要从头发现知识,没有积累。
LLM Wiki 的理念: LLM 逐步构建并维护一个持久化的维基,位于用户和原始数据源之间。新来源到达时:
关键区别:维基是持续更新、不断完善的资源。
| 角色 | 职责 |
|---|---|
| 人类 | 策划来源、探索、提出正确问题 |
| LLM | 总结、交叉引用、归档、维护 |
Obsidian 是 IDE;LLM 是程序员;维基是代码库。
摄取新来源到维基的工作流。
单个来源可能影响 10-15 个维基页面。
| 方式 | 特点 |
|---|---|
| 逐个摄取 | 保持参与,阅读摘要,检查更新 |
| 批量摄取 | 减少监督,适合更多来源 |
针对维基提问的工作流。
根据问题不同,答案可以呈现为:
好的答案可以作为新页面归档回维基。
| 工作流 | 输入 | 输出 |
|---|---|---|
| Ingest | 原始来源 | 维基页面 |
| Query | 用户问题 | 答案(可归档) |
定期对维基进行健康检查。
保持维基在增长过程中健康。
LLM 擅长:
请 LLM 进行 Lint:
"请对维基进行健康检查"
利用 LLM 构建个人知识库的模式。
这是一个概念文件,旨在复制粘贴到您自己的 LLM 代理(例如 OpenAI Codex、Claude Code、OpenCode/Pi 等)中。它的目标是传达高层次的概念,但您的代理将与您协作构建具体细节。
大多数人与 LLM 和文档的交互体验都类似于 RAG:您上传一系列文件,LLM 在查询时检索相关片段,然后生成答案。这种方式虽然可行,但 LLM 每次都要从头开始重新发现知识,没有积累。当您提出一个需要综合五个文档的微妙问题时,LLM 必须每次都找到并拼凑相关的片段。没有任何积累。NotebookLM、ChatGPT 文件上传以及大多数 RAG 系统都是这样工作的。
这里的理念有所不同。与其仅仅在查询时从原始文档检索,LLM 逐步构建并维护一个持久化的维基 —— 一个结构化的、相互链接的 Markdown 文件集合,位于您和原始来源之间。当您添加新来源时,LLM 不仅仅是为后续检索而索引它。它读取来源,提取关键信息,并将其整合到现有维基中 —— 更新实体页面,修订主题摘要,指出新数据与旧声明相矛盾之处,强化或挑战不断发展的综合分析。知识只需编译一次,然后保持最新,而不是在每次查询时重新推导。
这就是关键区别:维基是一个持久的、不断积累的产物。 交叉引用已经存在。矛盾之处已经标记。综合分析已经反映了您所阅读的一切。维基随着您添加的每个来源和提出的每个问题而变得更加丰富。
您几乎从不(或者很少)亲自编写维基 —— 所有内容都由 LLM 编写和维护。您负责策划来源、探索和提出正确的问题。LLM 负责所有繁琐的工作 —— 总结、交叉引用、归档和记录,使知识库能够长期发挥作用。实际上,我一边打开 LLM 代理,一边打开 Obsidian。LLM 根据我们的对话进行编辑,我实时浏览结果 —— 跟随链接、检查图谱视图、阅读更新后的页面。Obsidian 是 IDE;LLM 是程序员;维基是代码库。
这可以应用于许多不同的情境。以下是一些例子:
有三层:
原始来源 —— 您精心收集的来源文档集合。文章、论文、图片、数据文件。这些是不可变的 —— LLM 从中读取但从不修改它们。这是您的事实来源。
维基 —— 一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、对比、概述和综合。LLM 完全拥有这一层。它创建页面,在新来源到来时更新页面,维护交叉引用,并保持一切一致。您阅读它;LLM 编写它。
模式 —— 一个文档(例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md),告诉 LLM 维基是如何组织的,有哪些约定,在摄取来源、回答问题或维护维基时应该遵循什么工作流程。这是关键的配置文件 —— 它使 LLM 成为规范的维基维护者,而不是通用的聊天机器人。您和 LLM 共同随着时间的推移完善这一点,因为您会弄清楚什么对您的领域有效。
摄取。 您将新来源放入原始集合,并告诉 LLM 处理它。流程示例:LLM 读取来源,与您讨论关键要点,在维基中编写摘要页面,更新索引,更新整个维基中相关的实体和概念页面,并在日志中追加条目。单个来源可能会影响 10-15 个维基页面。就个人而言,我更喜欢一次摄取一个来源并保持参与 —— 我阅读摘要,检查更新,并指导 LLM 强调什么。但您也可以一次性批量摄取多个来源,并减少监督。您可以开发适合自己风格的工作流程,并将其记录在模式中,以便将来会话使用。
查询。 您针对维基提问。LLM 搜索相关页面,读取它们,并综合整理出带有引用的答案。答案可以根据问题的不同呈现不同的形式 —— Markdown 页面、对比表格、幻灯片(Marp)、图表(matplotlib)或画布。重要的洞察:好的答案可以作为新页面归档回维基中。 您要求的对比、分析、您发现的联系 —— 这些都是有价值的,不应该消失在聊天历史中。这样,您的探索就像摄取的来源一样,在知识库中积累。
整理。 定期请 LLM 对维基进行健康检查。寻找:页面之间的矛盾、被更新的来源取代的过时声明、没有入站链接的孤立页面、提及但缺少自己页面的重要概念、缺失的交叉引用、以及可以通过网络搜索填补的数据空白。LLM 擅长建议新的研究问题和寻找新的来源。这使维基在增长过程中保持健康。
两个特殊文件帮助 LLM(以及您)在维基增长时导航。它们有不同的用途:
index.md 是面向内容的。它是维基中所有内容的目录 —— 每个页面都列出链接、一行摘要,以及可选的元数据如日期或来源数量。按类别组织(实体、概念、来源等)。LLM 在每次摄取时更新它。在回答查询时,LLM 首先读取索引以找到相关页面,然后深入阅读它们。这在中等规模(约 100 个来源,数百个页面)下效果出奇地好,避免了对基于嵌入的 RAG 基础设施的需求。
log.md 是时间顺序的。它是只追加的记录,记录发生了什么以及何时发生 —— 摄取、查询、整理。有一个有用的技巧:如果每个条目都以一致的前缀开头(例如 ## [2026-04-02] ingest | Article Title),日志就可以用简单的 unix 工具解析 —— grep "^## \[" log.md | tail -5 给出最后 5 个条目。日志为您提供了维基演变的时间线,并帮助 LLM 了解最近做了什么。
在某些时候,您可能想要构建帮助 LLM 更高效操作维基的小工具。在维基页面上构建搜索引擎是最明显的 —— 在小规模下索引文件就足够了,但随着维基的增长,您需要适当的搜索。qmd 是一个不错的选择:它是一个本地 Markdown 文件搜索引擎,结合了 BM25/向量搜索和 LLM 重排序,全部设备上运行。它既有 CLI(所以 LLM 可以调用它),也有 MCP 服务器(所以 LLM 可以将其作为原生工具使用)。您也可以根据自己的需要构建更简单的东西 —— LLM 可以帮助您随心所欲地编写一个简单的搜索脚本。
raw/assets/)。然后在设置 → 热键中,搜索"下载"找到"下载当前文件的附件"并绑定到热键(例如 Ctrl+Shift+D)。剪藏文章后,按下热键,所有图片都会下载到本地磁盘。这是可选的,但很有用 —— 它让 LLM 直接查看和引用图片,而不是依赖可能失效的 URL。请注意,LLM 不能原生地在一次传递中读取带有内联图片的 Markdown —— 解决方法是让 LLM 先读取文本,然后分别查看一些或所有引用的图片以获得额外的上下文。这有点笨拙,但效果足够好。维护知识库中最繁琐的部分不是阅读或思考,而是记录工作。更新交叉引用、保持摘要最新、注意新数据何时与旧声明矛盾、保持数十个页面之间的一致性。人类放弃维基是因为维护负担增长速度快于价值。LLM 不会感到无聊,不会忘记更新交叉引用,可以一次修改 15 个文件。维基保持维护,因为维护成本接近于零。
人类的工作是策划来源、引导分析、提出好问题并思考这一切意味着什么。LLM 的工作是其他一切。
这个理念在精神上与 Vannevar Bush 的 Memex (1945) 相关 —— 一种具有文档间联想路径的个人、策划的知识存储。Bush 的愿景比 Web 最终成为的样子更接近这个 —— 私人的、主动策划的,文档间的连接与文档本身一样有价值。他无法解决的部分是:谁来维护?LLM 解决了这个问题。
本文档有意保持抽象。它描述的是理念,而不是具体的实现。确切的目录结构、模式约定、页面格式、工具 —— 所有这些都取决于您的领域、您的偏好和您选择的 LLM。以上提到的所有内容都是可选的和模块化的 —— 选择有用的,忽略没用的。例如:您的来源可能只有文本,那么您根本不需要图片处理。您的维基可能很小,索引文件就是您所需的全部,不需要搜索引擎。您可能不关心幻灯片,只想要 Markdown 页面。您可能想要完全不同的输出格式集。使用它的正确方式是将其分享给您的 LLM 代理,并与它协作实例化一个适合您需求的版本。本文档的唯一工作是传达这个模式。您的 LLM 可以弄清楚其余部分。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
检索增强生成。传统 LLM 与文档交互的方式。
LLM Wiki[1:1] 不是在查询时检索,而是 LLM 逐步构建并维护一个持久化维基,知识编译一次后保持最新。
Vannevar Bush 于 1945 年提出的概念 —— 个人策划的知识库,文档间有联想路径。
Bush 的愿景更接近 LLM Wiki[1:2] 的理念,而非后来的 Web。
Bush 无法解决的是:谁来维护?
LLM Wiki[1:3] 回答了这个问题 —— LLM 负责维护工作。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。