LLM Wiki (大语言模型维基知识库)

什么是 LLM Wiki

LLM Wiki（大语言模型维基知识库）是 OpenAI 联合创始人 Andrej Karpathy 于 2026 年 4 月在 GitHub Gist 上提出的新型知识管理范式。核心思路是：把大模型看作知识编译器，将零散的原始资料预先编译成结构化、可互联、可迭代更新的 Markdown 维基知识库。

Karpathy 在帖子中写道："我最近消耗的 token，越来越少用来写代码，越来越多用来整理知识。"这条帖子获得了 170 万+浏览，Hacker News 上 284 分、90 条评论，VentureBeat 和 Analytics India Magazine 都做了专题报道 $TRAE_REF。

打个比方：传统笔记工具（如 Obsidian）是"开发环境"，大模型是"程序员"，Wiki 知识库就是双方共同维护的"代码库"。人类负责筛选信息、把控方向，LLM 承担摘要、关联、纠错、归档等重复性工作。

Karpathy 的人机协作三部曲

LLM Wiki 是 Karpathy 关于「人机协作」的第三块拼图：

为什么需要 LLM Wiki

传统 RAG 的四个痛点

传统 RAG（检索增强生成）虽然解决了大模型知识过时的问题，但本身有固有缺陷：

1. 分块损失 — 一篇结构化的论文切成 512 token 的碎片后，上下文关系全丢了
2. 检索不稳定 — Embedding 相似度不等于语义相关度，换个说法就可能检索不到
3. 无知识积累 — 每次提问都从零开始重新检索、理解，对话结束后知识不留存
4. 知识碎片化 — 原始文档之间没有显式关联，知识只是"堆"在数据库里

这些问题并非 RAG 的 Bug，而是其设计哲学决定的——RAG 本质上是"检索时理解"。Karpathy 提出了一个反直觉的思路：为什么不在入库时就让 LLM 理解好？

LLM Wiki 的核心理念

LLM Wiki 跳出"检索+拼接"的思维，借鉴编译原理：原始资料只编译一次，后续查询直接复用编译成果。这就像把散落的参考文献变成一本百科全书——查一次资料，整理成书，以后直接翻书即可。

关键洞察：如果你的知识库足够精炼，你根本不需要复杂的向量检索。100 个 Wiki 页面，每个平均 500 tokens，总共才 50,000 tokens——现在的 LLM 动辄 128K 甚至 200K 的上下文窗口，完全可以把整个 Wiki 塞进去。

LLM Wiki vs 传统 RAG

三代知识检索范式的演进

RAG 是第一代，GraphRAG 是第二代，LLM Wiki 是第三代 $TRAE_REF：

LLM Wiki vs GraphRAG 深度对比

GraphRAG（微软提出）和 LLM Wiki 经常被放在一起讨论，但它们的出发点完全不同 $TRAE_REF：

选型建议：如果你的问答场景高度依赖实体间关系推理（多跳查询），GraphRAG 更合适；如果你需要的是一个持续积累、可读可审、轻量运维的个人知识库，LLM Wiki 更合适。两者不是互斥的--社区已有人尝试在 LLM Wiki 的 Wiki 层基础上叠加知识图谱，兼顾结构化沉淀和图遍历能力。

从 Memex 到 LLM Wiki：80 年的知识管理梦

Karpathy 在原始 Gist 中提到了 Vannevar Bush 1945 年在《As We May Think》中提出的 Memex 概念 $TRAE_REF。这段历史值得了解：

Bush 当年设想的 Memex 比后来的万维网更接近 LLM Wiki--私有的、主动策划的、文档之间的连接和文档本身一样有价值。但 Bush 解决不了一个问题：谁来做维护？ 人类会厌倦、会偷懒、会放弃。80 年后，LLM 解决了这个问题。

"人类之所以会放弃维护 wiki，是因为维护负担的增速超过了价值增速。大模型消除了这个瓶颈。" -- Karpathy

三层架构

Karpathy 定义的 LLM Wiki 采用极简的三层目录结构：

LLM-Wiki/
├── raw/          # 第一层：原始资料目录（只读）
├── wiki/         # 第二层：LLM 生成的维基知识库
└── CLAUDE.md     # 第三层：全局规则配置文件

第一层：raw/ — 原始资料仓库

永久只读，所有原始资料（PDF、论文、文章、笔记、截图、录音转文字稿等）放入后不做任何修改。这是知识溯源底座，所有 Wiki 页面内容均可追溯至此。LLM 只读不写，确保你永远能回头验证原始信息。

第二层：wiki/ — 核心知识库

由 LLM 全权维护，按概念、实体、摘要、综合分析等维度组织成 Markdown 文件。所有页面包含标准 YAML 元数据、正文、双链引用（[[页面名称]]）、来源标注和更新时间。典型规模为 100 篇左右的文章，约 40 万词——整个 Wiki 可以一次性塞进当前主流模型的上下文窗口。

内置 index.md（全局索引）和 log.md（更新日志），记录知识库迭代全过程。

第三层：CLAUDE.md — 规则配置文件

这是 Karpathy 所说的**"廉价本体论"**（Cheap Ontology）$TRAE_REF。传统知识本体（OWL、SPARQL）需要专业本体工程师来定义，年薪十几万美金。Karpathy 说用自然语言写一份 CLAUDE.md 就行了——定义好 Wiki 的结构和规则，LLM 就能按规矩办事。

CLAUDE.md 解决了三个核心问题：

更强大的设计是——修改 Schema 就能修改 LLM 行为，不需要改一行代码。想让摘要更详细？改 CLAUDE.md 里的字数限制就行。想新增一种页面类型？在模板里加一个定义即可。

五大页面类型

在完整的实现中，Wiki 可以根据需要分为五类页面，各司其职：

每种页面都有严格的模板：YAML frontmatter 元数据 + 标准化的 Markdown 结构 + [[双向链接]] 交叉引用。

标准 Wiki 页面示例

---
title: Transformer 架构原理
type: concept
sources:
  - raw/papers/attention-is-all-you-need.pdf
related:
  - [[Self-Attention 机制]]
  - [[BERT vs GPT]]
created: 2026-04-10
updated: 2026-06-01
confidence: high
---

# Transformer 架构原理

核心思想：摒弃循环和卷积，完全依赖注意力机制建立序列中任意位置的依赖关系。

## 关键贡献
- 多头注意力机制（Multi-Head Attention）
- 位置编码（Positional Encoding）
- 并行化训练

## 相关概念
#深度学习 #NLP #注意力机制

四大核心原理

1. 知识编译（Ingest）

这是 LLM Wiki 与 RAG 最本质的区别。当新资料放入 raw/ 目录后，LLM 一次性完整阅读全文（而非分块截取），然后完成：

原始文档 → 内容提取 → LLM 生成摘要 → 创建 Summary 页面
  → LLM 提取实体 → 创建/更新 Entity 页面
    → LLM 提取概念 → 创建/更新 Concept 页面
      → 更新双向链接 → 更新 index.md → 记录 log.md

一次编译，多次复用，彻底解决传统 RAG 反复解析原始文档的冗余开销。

2. 知识查询（Query）

用户提问时，系统直接读取 wiki/ 目录下的结构化 Markdown 页面，通过页面索引和双链关系快速定位相关内容。查询的设计哲学是：先查已编译的知识（Wiki），再查原始资料（Raw Sources），最后综合生成答案。

有价值的问答会被自动归档成新的 Wiki 页面（Query 类型），意味着 Wiki 会通过使用不断"自我增长"——你问得越多，知识库越丰富。

3. 知识自检（Lint）

借鉴代码静态分析的理念，定期触发巡检任务，让 LLM 遍历整个知识库自动执行三类维护：

• 修正矛盾 — 对比新旧资料，统一冲突观点
• 补全链接 — 为孤立页面补充关联，完善知识网络
• 清理过期 — 识别过时信息并标注更新

Lint 操作会输出健康报告：

🔍 知识库健康检查报告
健康评分: 85.0%
| 问题类型     | 数量 |
|--------------|------|
| 孤立页面     | 2    |
| 断链         | 1    |
| 过期内容     | 3    |
| 内容矛盾     | 0    |

4. 知识溯源（Traceability）

每个 Wiki 页面的元数据中都绑定 raw/ 目录下的原始文件，人工审核时一键追溯源头，兼顾 AI 自动化与人工可控性，降低大模型幻觉带来的风险。

完整工作流

原始资料入库 (raw/)
  → LLM 编译生成 Wiki 页面 (wiki/)
    → 用户查询（读取 Wiki 而非 raw）
      → 定期 Lint 巡检修复
        → 新增资料继续编译迭代
          → 循环增长

如何搭建 LLM Wiki

前置准备

• 本地文件管理：系统文件夹即可，推荐搭配 Obsidian（天然支持双链和 Markdown）
• 大模型服务：Claude、GPT-4、通义千问等在线 API，或本地部署 Llama 3、Qwen 等开源模型
• 文本编辑器：VS Code、Typora 等

搭建步骤

步骤 1：创建目录结构

LLM-Wiki/
├── raw/
├── wiki/
└── CLAUDE.md

步骤 2：编写 CLAUDE.md 规则文件

写入页面格式要求、链接规则、元数据规范、Lint 巡检标准。以下是一个完整的模板参考：

# LLM Wiki 全局运维规则

你当前角色为 LLM Wiki 专属维护者，仅负责处理知识库相关工作。

## 一、页面格式要求
1. 所有 wiki 目录下的 Markdown 文件必须包含标准 YAML 头部：
   title、type、sources、related、created、updated、confidence
2. type 仅可选：concept(概念)、entity(实体)、source-summary(摘要)、
   comparison(对比分析)、synthesis(综合分析)
3. confidence 分为 high/medium/low 三档

## 二、链接与引用规则
1. 页面之间使用双链 [[页面名称]] 关联，禁止无效链接
2. 所有内容必须标注来源，溯源至 raw/ 目录下的原始文件
3. 新增页面必须关联至少 1 个已有相关页面

## 三、内容撰写规则
1. 基于 raw 目录原始资料提炼，禁止编造内容
2. 正文逻辑清晰，分层使用标题，添加相关标签
3. 多篇资料内容冲突时，同时保留多方观点并标注矛盾点

## 四、Lint 巡检规则
1. 检测孤立页面并补充关联链接
2. 核查内容矛盾、过时信息并标注更新
3. 补全缺失的元数据与来源标注

步骤 3：导入原始资料

将论文、笔记、文档放入 raw/ 目录，保持原始文件只读。

步骤 4：执行知识编译

两种方式：

• 手动交互：将 CLAUDE.md + raw 资料上传至大模型，输入编译指令，将返回的 Markdown 文件保存到 wiki/ 目录
• 命令行自动化：使用 Claude Code 等工具，执行 claude --ingest ./raw --wiki ./wiki --rule ./CLAUDE.md

步骤 5：查询使用

用 Obsidian 打开 wiki/ 目录直接浏览，或通过 AI 问答方式查询整个知识库。

步骤 6：定期巡检

每周或每新增 5 份以上资料后执行 Lint 巡检，保持知识库质量。

社区开源实现

Karpathy 发布 Gist 后，社区很快涌现出多个开源实现，以下是三个最具代表性的项目 $TRAE_REF：

sage-wiki（Go）— 编译器范式

用 Go 编写，与 Karpathy 构想对齐度最高的实现。把知识库当编译目标，编译管道分 5 个 Pass：diff 检测、并行 LLM 摘要、概念提取去重、Wiki 文章生成、图片处理，支持断点续传。

搜索系统采用四维混合搜索：BM25 全文搜索 + 向量余弦相似度 + RRF 融合 + 标签加权和时间衰减。知识图谱支持 8 种语义关系（implements、extends、contradicts 等），支持 BFS 遍历和环检测。还做了 MCP 服务器，提供 14 个工具可被 Claude Code 调用。单一二进制，零依赖，go install 即可运行。

llm-wiki（Python）— CLI 与 LLM 完全分离

Python CLI 处理所有确定性操作（解析文档、建索引、搜索、校验），CLI 中一行 LLM 调用代码都没有。所有智能操作通过一份 SKILL.md 文件委托给外部 Agent，你可以接任何 LLM Agent 来驱动。

格式支持非常广，用 MarkItDown 库支持 PDF、DOCX、PPTX、HTML、图片、音频、ZIP 等 20 多种格式。中文支持完善，用 jieba 做分词，有 CJK 停用词过滤。架构上采用 Clean Architecture，Domain 层零外部依赖，测试覆盖 162 个用例。

Thinking-Space（Electron）— 全功能工作站

跨平台桌面应用（Mac、Windows、iOS），有完整的 UI、多标签编辑器、内嵌终端。支持 55 种以上的 Agent 能力操作，多个 AI 提供商，内置 Excalidraw 绘图、思维导图、PDF 转换、RSS 阅读器。但它与 Karpathy 的"编译式知识库"思路关系较松，更像一个 AI 增强的笔记工具。

选型建议

• 研究者：有大量论文和文章要处理，想要自动编译，选 sage-wiki
• 文档格式杂、含中文、想自由切换 Agent：选 llm-wiki
• 不习惯命令行、想要图形界面：选 Thinking-Space

社区反响与争议

支持的声音

• Tech podcaster Charly Wargnier 称其为"能自我修复的活知识库"
• Lex Fridman 确认自己在用类似的设置
• 企业家 Vamshi Reddy 说："每个企业都有一个 raw/ 目录，没有人编译过它，这就是产品。"Karpathy 本人点赞了这条评论

反对与质疑

1. 知识可信度问题（Epistemic Integrity）

最尖锐的批评来自 Hacker News：真正的问题不在于怎么组织知识，而在于知识可不可信。如果 LLM 把错误信息写进了 Wiki，后面所有查询都会被污染，而且你很难发现。raw/ 层不可变的设计提供了一个验证锚点，Lint 操作的存在也说明 Karpathy 意识到了这个问题，但目前没有完美解法。

2. 认知外包风险

HN 用户 qaadika 维护着一个 4100 条笔记的 Obsidian 库，他说："整理知识的苦活本身就是洞察产生的过程，把这事交给 AI，你得到的知识库跟你这个人没什么关系。"写文档的价值在于更新你自己的心智模型。

3. 规模限制

Karpathy 自己说的甜蜜点是 100 篇文章、40 万词。超过这个量级，系统可能撑不住。有人警告说，到了某个临界点，Agent 自己都理不清里面的内容了。

常见误解与正确理解

LLM Wiki 发布后，社区出现了大量解读，其中不乏误解。澄清几个最普遍的误区 $TRAE_REF：

误解一：LLM Wiki 就是另一种 RAG

这是最普遍的误读。RAG 的工作方式是"检索时理解"——每次查询都重新去原始文档里捞碎片、即时拼凑，答完即忘。而 LLM Wiki 是"入库时理解"——资料进入的那一刻就完成编译，知识被结构化地沉淀下来。

一个形象的比喻：RAG 是仓库管理员，LLM Wiki 是图书管理员。前者你来问一个问题，它跑进仓库捞几个箱子，拼一段答案给你；后者一次性读完所有书，建好分类目录和索引，下次有人问问题，直接走到对应的那一页。

误解二：LLM Wiki 需要复杂的向量检索基础设施

恰恰相反。LLM Wiki 的设计哲学是"简单优于复杂"。Karpathy 自己称 index.md 为"穷人的向量库"——在 100 篇文章的规模下，一个纯文本的索引文件就够用了。不需要向量数据库、不需要 Embedding 模型、不需要重排序模型，只需要大模型 + 本地文件夹。

误解三：LLM Wiki 交给 AI 后人类就不用管了

这也是危险的误读。LLM Wiki 的人机分工是：LLM 做苦力活（归档、交叉引用、更新、保持一致性），人类做决策活（筛选材料、定义 Schema、验证质量）。Karpathy 挑的是"人类最不擅长的事"——人类做归档会烦、会忘、会偷懒、会前后不一致，LLM 不会。但最终的质量把控、方向判断，始终需要人类参与。

误解四：LLM Wiki 是通用的知识管理方案

LLM Wiki 最适合领域内聚的场景——研究一个课题、读一本书、做一个竞争分析。如果你的知识库是"什么都往里堆"——编程笔记、游戏攻略、设计素材、项目模板混在一起——跨领域的交叉引用只会制造噪音。有开发者拿自己积累了五六年的 Obsidian 知识库去试（几千个文件、十几个领域），结果"啥也不是"。这不是 LLM Wiki 的问题，而是领域不内聚的资料本身就不适合编译成单一 Wiki。

实际使用中的五大痛点

LLM Wiki 的理念优雅，但实际落地时有一些需要正视的挑战 $TRAE_REF：

痛点一：规模天花板比想象中来得早

原始方案的索引机制是一个 index.md 文件，里面存着所有页面的摘要和链接。每次查询 LLM 都要从头读到尾。大约 200-300 篇中等长度的技术文章，就能把它撑满。之后 index.md 越来越长，上下文窗口越来越拥挤，响应越来越慢。Karpathy 自己也提到了这一点，建议规模变大后接入本地搜索引擎（如 qmd）来替代纯文本索引。

痛点二：超长文档缺乏处理方案

默认流程是一次性读完整篇文档。但如果你丢进去一份 200 页的技术报告或一本书，LLM 的上下文窗口直接撑不住。截断意味着后半段信息全丢，硬塞则成本暴涨、幻觉频发。这个问题在原始方案里没有明确解法，需要自己设计分块策略。

痛点三：真实成本不低

每次 Ingest 一篇新文章，LLM 要读新资料、扫描现有 Wiki 页面、更新 10-15 个关联页面、写日志。一次完整的 Ingest 实际消耗约 7.5 万到 25 万 token。按 Claude 的 API 价格计算，每篇文章的摄入成本在 $1.5-3 美元之间。如果每月摄入 50 篇，仅 Ingest 一项就要花 $75-150 美元。换便宜模型能省钱，但可能导致摘要质量下降、交叉引用混乱。

痛点四：冷启动门槛高

前 5-10 篇资料基本是调校期。你需要反复迭代 CLAUDE.md，告诉 LLM 该怎么分类、怎么命名、怎么建立关联。这需要你对 LLM 的行为模式有足够深的理解。Karpathy 能上手就用，因为他本人就是 AI 领域最顶尖的专家之一。对大多数人来说，写 Schema 就像做卷子最后一道大题——只会写个"解"字。

痛点五：Lint 机制本身也会幻觉

Lint 让 LLM 检查 LLM 生成的内容，这个环节同样存在幻觉风险。最终的质量兜底，绕了一大圈，还是回到人工审阅。和你自己写笔记然后偶尔回头检查，底层逻辑上并没有本质区别，只是中间多了一层自动化。

这些痛点不是 LLM Wiki 的"致命缺陷"，而是它的"已知边界"。Karpathy 的原始 Gist 本身就是一份"想法文件"（idea file），有意设计得抽象，目的是让你和 LLM 一起把它实例化成适合自己领域的版本。

突破规模天花板：qmd 本地搜索引擎

Karpathy 在原文中点名推荐了 qmd 作为规模扩展的解决方案 $TRAE_REF。qmd 是一个专门为 LLM 工作流设计的本地 Markdown 搜索引擎，全程在设备端运行，不依赖任何云端 API。

三层检索架构：

三层结果通过 RRF（Reciprocal Rank Fusion）算法融合，最终返回最相关的内容块。

智能分块机制：按 Markdown 标题边界切割，每块约 900 token，15% 重叠。这意味着 200 页的超长文档不需要一次性塞进上下文--用不同主题词多次检索，每次只取 3-5 个块（约 3000-4500 token），精准定位到需要的段落。

如何解决五大痛点：

• 规模天花板 - qmd 替代 index.md，有真正的混合检索索引，几千篇文章照样跑，响应速度不随规模退化
• 超长文档 - 块级检索让 200 页文档变成可分批消化的知识单元，不再"一锅端或截断"二选一
• 成本 - 每次查询不再需要把整个知识库塞进上下文，token 消耗压缩一个数量级
• MCP 集成 - qmd 提供 CLI 接口和 MCP 服务器，LLM 可以直接调用它作为原生工具

安装方式：bun install -g qmd，然后在 CLAUDE.md 中配置让 LLM 优先使用 qmd 搜索而非全量加载 index.md。

成本优化策略

LLM Wiki 的真实成本不容忽视，但可以通过以下策略大幅压缩 $TRAE_REF：

经验法则：编译阶段省的钱，会在查询阶段十倍还回来。Ingest 用强模型是值得的投资，因为一次编译的成果会被查询成百上千次复用。

适用场景

个人场景

• 个人研究者 - 追踪论文、建立知识体系
• 技术学习者 - 整理学习笔记、关联概念
• 内容创作者 - 管理写作素材、积累领域知识
• 独立开发者 - 个人技术文档、项目知识沉淀
• 读书笔记 - 类比托尔金粉丝 Wiki，把多本书的读书笔记编译成主题知识库

团队与企业场景

LLM Wiki 不只是个人工具，在企业场景中同样有价值 $TRAE_REF：

• 团队知识库 - LLM 读取 Slack 对话、会议记录、项目文档，维护一份不断更新的团队知识库。新人入职不用翻遍半年的聊天历史，直接问 Wiki
• 竞品分析 - 追踪一个行业或公司的方方面面：新闻、财务数据、监管文件、研究报告。新信息进入时，LLM 自动更新相关分析页面，标注与旧数据的矛盾
• 尽职调查 - 投资尽调过程中，将法律文件、财务报表、行业报告编译成结构化 Wiki，支持跨文档综合查询
• 项目文档沉淀 - 将项目过程中的设计文档、技术决策记录、Postmortem 报告编译成 Wiki，项目结束后知识不流失
• 课程笔记 - 整理一个学期的课程材料，自动关联概念，期末复习时直接查询 Wiki

企业家 Vamshi Reddy 说："每个企业都有一个 raw/ 目录，没有人编译过它，这就是产品。"Karpathy 本人点赞了这条评论。

冷启动策略：已有大量文章怎么办

如果你已经积累了数百甚至上千篇 Markdown 文章，不要试图一次性全部编译。推荐三阶段分批策略 $TRAE_REF：

阶段一：元数据扫描（快速、低成本）

用脚本批量读取每篇文章的标题 + 前 200 字，生成一个 raw/index.csv，包含文件路径、大致主题、写作时间。这一步花费很少，但给 AI 一张全局地图。

# 示例：批量提取元数据
for f in raw/**/*.md; do
  title=$(head -1 "$f")
  preview=$(head -20 "$f" | tail -19)
  echo "$f|$title|$preview" >> raw/index.csv
done

阶段二：按主题分批摄入

不要按时间顺序，而是按主题聚类摄入。例如先处理所有技术类文章，让同一主题的知识在 Wiki 里先成体系。每批 10-20 篇，编译后检查质量，调整 Schema。

阶段三：增量维护

冷启动完成后，之后每新增一篇文章就做一次小 Ingest 操作。知识库进入"日常运营"模式。

关键原则：先选 50 篇你最熟悉的文章做试验，跑通整个流程，再扩展到全部。不要追求一步到位。

局限性

• 不适合海量动态实时数据（实时新闻、动态业务数据）
• 大规模知识库（数百篇以上长文档）编译阶段算力消耗较高
• 依赖大模型文本理解能力，存在少量内容幻觉风险，需人工抽检
• 不适合多人实时协作场景（并发编辑 Markdown 文件会有冲突）

LLM Wiki vs 传统知识管理工具

LLM Wiki 不是 Obsidian、Notion 或 Roam Research 的替代品，而是对这些工具的范式升级 $TRAE_REF：

Karpathy 自己也用 Obsidian——但他把 Obsidian 定位为"IDE"，LLM 是"程序员"，Wiki 是"代码库"。你在 Obsidian 里浏览和审阅像看代码，LLM 负责编写和维护像写代码。这不是替代关系，是分工关系。

与 AI 生态的深度集成

LLM Wiki 不是一个孤立的方案，它能与现有的 AI 工具链形成强大的协同效应 $TRAE_REF：

与 Obsidian 搭配

Obsidian 天然支持 Markdown 和 [[双链]]，是 LLM Wiki 的完美前端。你可以在 Obsidian 中打开 wiki/ 目录，实时查看 LLM 创建的页面、跟随链接跳转、在图谱视图中可视化知识网络。Karpathy 推荐的实操方式是：一边打开 AI Agent 对话窗口，一边打开 Obsidian，LLM 做出编辑后你实时浏览结果。

与 Claude Code 搭配

Claude Code 可以作为 LLM Wiki 的执行引擎。通过 CLAUDE.md 配置文件，Claude Code 能自动完成 Ingest、Query、Lint 全套操作。社区已有实现将 Claude Code 与 Obsidian 对接，形成"Claude Code + Obsidian = 知识库王炸"的组合。

与 MCP 协议集成

LLM Wiki 可以与 MCP 协议深度结合。例如 sage-wiki 项目就提供了 MCP 服务器，暴露 14 个工具供 Claude Code 调用——搜索知识库、读取页面、提取概念、更新索引等，全部通过标准 MCP 协议完成。这意味着你的知识库可以成为一个"MCP 资源"，被任何支持 MCP 的 AI 工具访问。

与本地模型搭配

对于隐私敏感的场景，LLM Wiki 可以搭配本地部署的模型（如 Ollama、LM Studio）使用。虽然本地模型在编译质量上可能不如 GPT-4 或 Claude，但对于个人知识库的日常维护，完全够用。社区实现中，llm-wiki（Python）项目就通过 SKILL.md 将智能操作委托给外部 Agent，你可以自由切换任何 LLM。

最佳实践与经验建议

综合社区的真实使用经验，以下是几条值得采纳的建议 $TRAE_REF：

1. 从小处着手，先跑通闭环

不要一上来就想把整个知识库编译完。选一个单一领域（比如"学习 Transformer 架构"或"做竞品分析"），先扔 5-10 篇资料进去，跑通 Ingest → Query → Lint 的完整闭环。体验过"编译一次、多次复用"的感觉后，再扩展到更多领域。

2. Schema 是灵魂，值得反复迭代

CLAUDE.md 不是一次写好的。前 5-10 篇资料的冷启动期，你会不断发现"这个分类不对"、"那个模板不好用"。每发现一次就修改一次 Schema。最终你的 Schema 本身就是你知识管理哲学的体现——它比任何笔记都更能反映你的思维方式。

3. 先养 raw/，再建 wiki/

LLM Wiki 的起点不是 Schema，不是 wiki 结构，而是你持续往里扔东西的 raw/ 目录。没有足够的高质量原始素材，wiki 就是空的。建议先积累 50-100 篇核心资料，再让 LLM 开始大规模编译。顺序很重要。

4. 定期 Lint，别等知识腐烂

把 Lint 巡检纳入你的知识管理节奏。建议每新增 5 份以上资料，或每两周，执行一次 Lint。让 LLM 检查矛盾、补全缺失链接、标记孤立页面。长期跳过的 Lint，知识库会像没有维护的代码库一样慢慢腐烂。

5. 查询结果要回写，让知识复利

这是最容易忽略但最有复利价值的操作。每次你问了一个好问题，让 AI 把答案保存到 wiki 的某个分类下（如 synthesis/ 或 queries/）。下次同样的疑问，不需要重新推导。知识库会通过使用不断"自我增长"——你问得越多，它越丰富。

6. 注意领域隔离

如果你的知识涉及多个不相关的领域，不要试图塞进同一个 Wiki。建立多个独立的 LLM Wiki 仓库，每个仓库对应一个领域。跨领域的交叉引用只会制造噪音——行业研报和游戏攻略放在同一个 Wiki 里，对任何一个领域都没有帮助。

7. 不要为了省钱用弱模型做编译

Ingest 阶段使用弱模型，摘要质量会显著下降、交叉引用会混乱。建议 Ingest 和 Lint 用强模型（Claude、GPT-4），日常查询可以用弱模型或本地模型。编译阶段省的钱，会在查询阶段十倍还回来。

FAQ：常见问题

Q: LLM Wiki 会取代 RAG 吗？

不会。两者解决不同问题。RAG 适合大规模、实时性要求高的场景（企业知识库、客服 Bot），LLM Wiki 适合中小规模、深度积累的场景（个人研究、团队知识沉淀）。Karpathy 自己也说不排斥 RAG--当 Wiki 规模超过上下文窗口时，在 Wiki 层之上叠加 RAG 检索是自然的演进方向。

Q: 我已经有 Obsidian / Notion 知识库了，要推倒重来吗？

不需要推倒重来。你的现有笔记就是天然的 raw/ 目录。新建一个平行的 wiki/ 目录，让 LLM 从你的已有笔记中编译出结构化 Wiki。raw/ 是输入，wiki/ 是输出，两者并行存在。

Q: LLM Wiki 适合多人协作吗？

原始设计是个人工具。Markdown 文件的并发编辑会产生冲突，就像两个人同时编辑同一个代码文件一样。但社区已有解决方案：将 wiki/ 目录放入 Git 版本控制，用分支和合并管理多人编辑。sage-wiki 等开源实现已支持 AI 辅助的冲突合并--LLM 自动检测冗余内容、合并不同视角的编辑。对于小型团队（3-5 人），这是可行的。

Q: 用什么模型做 LLM Wiki 最好？

Q: LLM 编译出来的内容有错误怎么办？

三个防线：

1. raw/ 层不可变 - 任何 Wiki 内容都可以追溯回原始文件验证
2. Lint 巡检 - 定期检查矛盾和过时信息
3. 人工抽检 - 对 confidence 为 low 的页面重点审核

LLM Wiki 的竞争对手不是"完美的知识管理"，而是"不做知识管理"。一个不完美但持续维护的知识系统，比一个完美但永远没人维护的系统好一万倍。

Q: 多久做一次 Lint？

建议两种触发方式：

• 定量触发：每新增 5 份资料后执行一次
• 定时触发：每两周执行一次

如果知识库更新不频繁，每月一次也可以。关键是不要跳过--长期不 Lint 的知识库会像没有测试的代码库一样，慢慢腐烂到不可信。

Q: 能用本地模型完全离线运行 LLM Wiki 吗？

可以。搭配 Ollama 或 LM Studio 部署本地模型（如 Qwen 2.5、Llama 3），配合 qmd 做本地检索，整个 LLM Wiki 完全在本地运行，零 API 成本、零数据外泄。代价是编译质量可能不如 Claude / GPT-4，需要更频繁的人工抽检。llm-wiki（Python）项目就通过 SKILL.md 将智能操作委托给外部 Agent，你可以接任何本地模型。

总结

LLM Wiki 是知识管理领域的一次范式创新。它跳出了传统 RAG"检索+拼接"的固有思维，用"编译器模式"实现了知识的前置加工与长期沉淀。它的核心价值不在于取代 RAG，而是弥补 RAG 在长期知识沉淀、体系化构建、轻量化运维上的短板。

Karpathy 的底层哲学可以概括为：

1. 编译优于检索 — 提前让 LLM 理解文档，而不是查询时临时理解
2. 质量优于数量 — 500 字精炼摘要 > 5000 字原文
3. 显式关联优于隐式 — [[双向链接]] > Embedding 空间相似度
4. 简单优于复杂 — 如果能全量加载，就不需要复杂的检索系统
5. Schema 驱动 — 修改文档即修改行为，非技术人员也能参与

对于科研人员、开发者、终身学习者而言，LLM Wiki 让零散资料逐步沉淀为结构化、可复用的个人知识资产。与传统的笔记整理不同，它的本质是人机协同的知识运营——人类负责筛选方向和校验质量，AI 负责编译、关联、维护等重复性工作，二者共同构建一个持续进化的知识体系。

如果你研究的领域需要深度理解，别把所有整理工作都扔给 AI。用它来打理交叉引用、更新索引、整理结构，但概念之间的关联和判断，还是自己来比较靠谱。

延伸阅读

• Andrej Karpathy 的原始 Gist
• RAG（检索增强生成） - 了解传统方案
• MCP（Model Context Protocol） - AI 工具连接协议
• Ollama - 本地部署大模型的工具
• Claude Code - 命令行 AI 编程助手
• LM Studio - 本地模型图形化管理工具
• Smithery - MCP 服务器一站式发现与安装平台
• Vibe Coding - Karpathy 提出的人机协作编程范式
• Embedding - 向量嵌入基础概念，理解 RAG 检索原理