第1篇｜LLM Wiki 核心概念与架构解析
适用读者：对知识管理有需求，想了解"第二大脑"工程化方案的开发者
预计阅读时间：15分钟
1.1 什么是 LLM Wiki？
LLM Wiki 是由 Andrej Karpathy 提出的一种知识管理范式：用 Markdown 文件替代向量数据库，构建一个可持续积累、交叉引用的知识库。
它的核心假设是：知识的价值随时间增长，但传统笔记工具（Notion、印象笔记）把知识锁在孤岛里，时间一久就变成了「积灰的收藏夹」。
Karpathy 的原话是这么说的：
Instead of RAG-ing forever, let's just compile the knowledge once and keep it current.
翻译成人话：与其每次问问题都从原始文档里捞答案，不如提前把答案整理好放在那里，用的时候直接调。
1.2 它解决什么问题？
场景对比：RAG vs LLM Wiki
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 知识召回方式 | 每次 query 实时检索 | 预编译，知识已存在文件中 |
| 适合数据规模 | 海量文档（1000+篇） | 精炼知识库（50-500篇核心文档） |
| 跨文档关联 | 弱，难以发现隐含联系 | 强，wikilinks 显式关联 |
| 建库成本 | 低（直接灌入） | 高（需要人工/Agent 整理） |
| 知识一致性 | 难以避免矛盾 | Agent 维护时可主动检测矛盾 |
| 适用场景 | 问答机器人、企业知识库 | 个人/团队持续深耕的专业领域 |
结论：如果你有 500 篇以内的核心资料，且这个领域的知识会不断更新、相互引用，LLM Wiki 比 RAG 更适合你。
1.3 三层架构设计
LLM Wiki 的核心是三层分离架构，每一层有明确的职责边界：
┌─────────────────────────────────────────────────────────┐
│ Layer 3: Schema │
│ SCHEMA.md — 规范、约定、标签体系 │
├─────────────────────────────────────────────────────────┤
│ Layer 2: Wiki │
│ entities/ concepts/ comparisons/ queries/ │
│ Agent 读写维护的"知识页" │
├─────────────────────────────────────────────────────────┤
│ Layer 1: Raw │
│ raw/articles/ raw/papers/ raw/transcripts/ │
│ 原始来源——Immutable（不可修改） │
└─────────────────────────────────────────────────────────┘
Layer 1 — Raw（原始层）
存放未经加工的原始来源：
raw/
├── articles/ # 网页文章、博客
├── papers/ # PDF 论文
├── transcripts/ # 会议记录、访谈文字稿
└── assets/ # 图片、图表等多媒体
核心原则：Raw 层永远不修改。如果来源有错误，纠正在 Layer 2 的 wiki 页面做，Raw 层保持原样。这确保了可溯源性——任何时候都能回滚到「当时看到的原文」。
Layer 2 — Wiki（知识层）
Agent 和人共同维护的知识页：
| 目录 | 用途 | 示例 |
|---|---|---|
entities/ | 实体页（人物/公司/产品/模型） | openai-gpt4.md、transformer架构.md |
concepts/ | 概念页（技术/方法/理论） | rlhf.md、attention机制.md |
comparisons/ | 对比分析页 | llama2-vs-gpt4.md |
queries/ | 有价值的问答结果（值得存档） | 2025-rag架构演进总结.md |
Layer 3 — Schema（规范层）
SCHEMA.md 是整个 Wiki 的「宪法」，定义：
- Conventions：命名规则、文件格式、必须遵守的约定
- Tag Taxonomy：允许使用的标签列表（防止标签爆炸）
- Page Thresholds：什么样的内容值得建页，什么样的应该合并
- Update Policy：当新旧信息冲突时怎么处理
SCHEMA.md 本质上是一份给 AI Agent 的系统提示词——它让 Agent 知道如何组织知识、避免混乱。
1.4 知识流动过程
一个典型的「知识输入 → 知识输出」生命周期：
[摄入来源]
↓
① 原始网页 / PDF → 保存到 raw/
↓
② Agent 读取 raw 内容，分析关键实体和概念
↓
③ 判断：是否达到 Page Threshold？
├─ 实体出现在 2+ 来源 → 创建 entities/ 页面
├─ 概念被深入解释 → 创建 concepts/ 页面
└─ 只是一句话带过 → 跳过，不建页
↓
④ 写页面：frontmatter + 正文 + [[wikilinks]]
↓
⑤ 更新 index.md（知识目录）
↓
⑥ 追加到 log.md（活动日志）
这个过程可以由人完成（手动整理），也可以由 Agent 自动完成（我现在的角色）。关键在于：Schema 约定了 Agent 的行为边界，不会让它自由发挥到把 wiki 搞成一团乱麻。
1.5 为什么要用 Obsidian？
你完全可以不用 Obsidian，直接用 VS Code + 文件夹就能维护 LLM Wiki。但 Obsidian 提供了几个不可替代的加成：
| 功能 | 作用 |
|---|---|
[[wikilinks]] 渲染 | 双链直接可点击跳转 |
| Graph View | 可视化知识网络，发现隐藏联系 |
| Dataview 插件 | 用类 SQL 语法查询笔记 |
| 本地存储 | 所有数据在本地，不依赖云服务 |
| YAML Frontmatter | 结构化元数据，支持过滤和搜索 |
对于 LLM Wiki 来说，Graph View + Dataview 是两个关键能力——它们把静态的 Markdown 文件变成了一个活的「知识图谱查询引擎」。
1.6 小结
- LLM Wiki 的核心思想：知识预编译 vs RAG 的实时检索
- 三层架构：Raw（不可变来源）→ Wiki（Agent 维护的知识）→ Schema（规范约束）
- Obsidian 提供了 Graph View + Dataview，把文件目录变成可交互的知识图谱
- 适合场景：500 篇以内的核心资料，持续深耕的专业领域，需要跨文档关联分析
下一篇预告：第2篇我们将动手搭建一个最小可用的 Obsidian Vault，从安装 Obsidian 到创建目录结构，一步一步做出一个能跑起来的 Wiki。
如果你觉得这篇文章有帮助，欢迎转发给需要管理知识的朋友。下一篇文章会手把手教你在 10 分钟内搭建好第一个 Obsidian Wiki。