第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。