技术知识库 · 工具评测 · · 国科智飞 Gavin

LLM Wiki：把文档库变成可检索的知识图谱

RAG 每次都在从零重新发现知识，而这个模式让 LLM 持续维护一个会生长的 wiki。思路很轻，门槛在纪律。

大多数人和 LLM 一起处理文档的方式是 RAG：上传一堆文件，提问时检索相关片段，生成答案。这套流程能用，但有个结构性缺陷——LLM 每次都在从零重新发现知识，没有累积。问一个需要综合五份文档的微妙问题，它每次都要重新找、重新拼。知识没有被沉淀下来，问题越复杂，这种浪费越明显。

LLM Wiki 是另一种思路。这个模式由 Andrej Karpathy 提出，初衷是写给 AI Agent 看的一份理念文档：让 LLM 持续构建并维护一个持久的 wiki，作为你和原始资料之间的中间层。

它是什么

系统分三层。

原始资料层（raw sources）：你收集的文章、论文、图片、数据文件。这一层是只读的，LLM 只读不改，是事实的来源。

Wiki 层：一个由 LLM 生成的 Markdown 文件目录。摘要、实体页、概念页、对比、综述，全部由 LLM 创建和维护。它负责建立交叉引用、保持内容一致、在新资料到来时更新相关页面。你阅读它，LLM 写它。

Schema 层：一份约定文件（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM 这个 wiki 如何组织、有哪些约定、摄取资料和回答问题时要遵循什么流程。这是整个模式的关键配置——它让 LLM 成为有纪律的 wiki 维护者，而不是一个通用聊天机器人。

运作方式有三种操作。

Ingest（摄入）：往原始资料目录放一份新文档，让 LLM 处理。典型流程是读资料、和你讨论要点、写摘要页、更新索引、更新全库相关的实体页和概念页、追加日志。一份资料可能牵动十几页 wiki。

Query（提问）：针对 wiki 提问，LLM 检索相关页面、阅读、带引用地综合回答。答案的形式可以是 Markdown 页、对比表、幻灯片（Marp）、图表。关键点在于：好答案可以归档回 wiki。你问出来的对比、分析、发现的关联，不应该消失在聊天记录里。

Lint（体检）：定期让 LLM 给 wiki 做体检——页面之间的矛盾、被新资料推翻的旧结论、没有入链的孤立页、被提到但没有独立页面的重要概念、缺失的交叉引用。这一步让 wiki 随着增长保持健康。

导航靠两个特殊文件：index.md 面向内容，按类别列出每个页面、一行摘要和元数据，LLM 每次摄入后更新；log.md 面向时间，只追加，记录每次摄入、提问和体检。如果日志条目用统一前缀，还可以用简单的命令行工具统计，比如 grep 出最近五条。

能力与亮点

知识是编译一次、持续维护的，不是每次查询重新推导的。 交叉引用已经建好，矛盾已经被标记，综述已经反映了读过的所有内容。这是它和 RAG 的本质区别：wiki 是一个持久、复利的资产。

维护成本接近零，这是它成立的前提。 知识库最难的部分不是阅读和思考，而是记账：更新交叉引用、保持摘要新鲜、记录矛盾、维护几十个页面的一致性。人类放弃 wiki 是因为维护负担增长得比价值快；LLM 不会厌倦，不会忘记更新一个交叉引用，一次能改十几个文件。

规模门槛比想象中低。 index.md 方案在中等规模（约 100 份资料、几百个页面）下工作得相当好，不需要 embedding 基础设施。超过这个规模，可以引入面向 Markdown 的本地混合搜索工具（理念文档里推荐过 qmd 这类方案），再大才需要向量检索基础设施。

工程上很轻。 wiki 就是一个 Git 仓库的 Markdown 文件，版本历史、分支、协作全部免费。实践中常见的工作流是 Obsidian 开在一边、LLM Agent 开在另一边：LLM 根据对话改文件，你实时浏览链接和图谱。Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

适用面广。 个人目标与健康记录、长期主题研究、读书笔记、团队内部知识库、竞品分析、尽调、课程笔记，任何需要随时间累积知识的场景都能套用。

局限与坑

它不是一个装完就用的产品。 整个模式是抽象理念，目录结构、schema 约定、页面格式都要你和 LLM 一起定义并持续迭代。这既是灵活性，也是门槛——schema 写得敷衍，维护质量立刻下降。

质量依赖人的投入。 LLM 负责写和维护，你负责选资料、定方向、问好问题。如果资料是随手丢的、问题是不经思考的，wiki 只会变成一堆平庸摘要的集合。它放大的是你的判断，不是替代判断。

LLM 会犯错，需要复核。 交叉引用写错、结论归纳偏差、把矛盾标记反了，这些都会发生。至少在早期，人工阅读摘要和抽查页面的流程不能省。

规模有上限。 索引文件方案适合中等规模，资料上万份、页面数万时，还是得回到检索基础设施。它是 RAG 的补充，不是全场景替代。

图片处理麻烦。 带图文档需要把图片下载到本地，LLM 还无法在一次读取里同时理解文字和内联图片，要先读文本、再单独看图，流程有些笨拙。

适用场景

不适合：一次性的资料检索，或者语料规模已经远超中等量级的场景，RAG 依然是更务实的选择。

选型建议

先分清用途：RAG 解决"在大量语料里快速找到相关片段"，LLM Wiki 解决"让某个主题的知识随时间沉淀下来"。两者互补，不冲突。真正需要长期跟踪的领域用 LLM Wiki，海量杂项资料用 RAG。

如果决定尝试，建议从单一领域、小规模开始：选 20 到 30 份高质量资料，和 LLM 一起把 schema 写清楚，走完一轮摄入、提问、体检的完整循环。这个模式的成败不取决于模型，而取决于你有没有形成持续投喂和复核的习惯。

另外，这个理念已经有工程化实现可供参考，比如把代码库和文档库变成可交互知识图谱的开源项目。先理解模式、再评估工具，顺序会顺得多。