LLM Wiki 方法论深度研究报告
LLM Wiki 方法论深度研究报告
基于方夏 AI 研究 Wiki 中 18 篇相关来源的综合分析
报告日期：2026-06-12
核心来源：《深度解析 LLM Wiki / Obsidian-Wiki / GBrain》《LLM 打造全自动个人知识库》《OpenHuman: Memory Tree + Obsidian Wiki》《Karpathy Software 3.0》等
一、执行摘要
LLM Wiki 是 Andrej Karpathy（OpenAI 联合创始人）提出的一种反 RAG 的知识管理范式：不是让大模型在查询时临时检索，而是让 LLM 充当"编译器"——在查询前将原始资料一次性编译成结构化的 Markdown Wiki。这一理念在 2026 年上半年引发了从理论到工程实践的完整生态演化，催生了 GBrain（Y Combinator CEO Garry Tan）、OpenHuman（GitHub 19k star）、以及 OpenClaw/Hermes Agent 内置的知识管理体系。
本报告从 AI 研究 Wiki 的 18 篇相关来源中提炼出 LLM Wiki 的完整方法论图谱，涵盖核心理念、技术架构、生态演化、与传统 RAG 的对比、以及实践建议。
二、核心理念："LLM-as-Compiler"
2.1 一句话定义
"The insight is that the LLM should compile a wiki incrementally, rather than be asked to retrieve at query time."
— Andrej Karpathy
LLM Wiki 的核心洞察是：把 LLM 从"检索器"升级为"编译器"。
传统的 RAG（检索增强生成）在每次查询时从头搜索原始文档，然后拼接上下文送给 LLM。LLM Wiki 反转了这个流程——昂贵的阅读、综合、交叉引用工作在查询前一次性完成，查询时面对的是已经预编译好的结构化知识。
2.2 为什么是"编译"而不是"检索"
| 维度 | 传统 RAG | LLM Wiki |
|---|---|---|
| 核心操作 | 查询时检索 + 拼接 | 提前编译 + 查询时直接读 |
| 成本分布 | 每次查询都消耗算力 | 一次性 ingest 成本高，之后查询极轻 |
| 知识质量 | 取决于检索算法和 chunk 策略 | LLM 阅读理解 + 交叉引用 + 矛盾标注 |
| 可审查性 | embedding 黑盒 | 纯 Markdown，100% 可读可编辑 |
| 知识累积 | 文档堆积，质量不增 | 持续增长、去重、结构化 |
| 错误修复 | 需改原始文档或调参数 | 直接编辑 .md 文件 |
2.3 与 Karpathy 更大叙事的关联
LLM Wiki 不是孤立项目，它嵌入 Karpathy 的 Software 3.0 框架：
- Software 1.0：程序员显式编写规则代码
- Software 2.0：神经网络从数据中学习权重
- Software 3.0：用自然语言（Prompt）编程，Context Window 是新的编程环境
LLM Wiki 本质上是 Software 3.0 在知识管理领域的应用：你通过 Schema 文件（如 CLAUDE.md）用自然语言定义知识组织规则，LLM 按照这些规则"编译"出结构化知识库。
三、三层架构
LLM Wiki 的技术架构简洁而有力，分三层：
vault/
├── raw/ ← 原始层：只追加，不改写
│ ├── articles/ ← 文章、论文、转录稿
│ ├── notes/ ← 快速笔记、想法片段
│ └── assets/ ← 图片、附件
├── wiki/ ← Wiki 层：LLM 生成和维护
│ ├── index.md ← 目录（每次 Ingest 后更新）
│ ├── log.md ← 操作日志（追加）
│ ├── concepts/ ← 概念页（每个核心概念一个文件）
│ ├── entities/ ← 实体页（人、组织、项目）
│ └── sources/ ← 来源页（每条原始资料一个摘要页）
└── CLAUDE.md ← Schema 层：规则和约定
3.1 原始层（raw/）
- 只追加原则：原始资料一旦放入不做修改
- 格式宽容：接受 .md、.pdf、.docx、网页剪藏
- 工具支持：Obsidian Web Clipper 一键网页转 Markdown
3.2 Wiki 层（wiki/）
LLM 是这层的唯一作者（人类可以编辑但通常不手动写）：
- sources/：每篇原始资料一个摘要页，提取核心论点和关键结论
- concepts/：每个核心概念一个页面，带有来源引用和交叉引用
- entities/：人物、组织、产品、项目的专属页面
- index.md：全局目录，Ingest 后自动更新
- log.md：每次操作的执行日志
3.3 Schema 层（CLAUDE.md）
这是人与 LLM 之间的"合约文件"——用自然语言定义：
- 命名约定（文件名格式、中英文处理）
- 页面模板（概念页/来源页/实体页的标准结构）
- 质量标准（引用完整性、断链检查）
- 工作流规则（Ingest 步骤、Lint 规则）
四、四大工作流
4.1 Ingest（摄入/编译）
这是 LLM Wiki 最核心的操作：
- 从
raw/articles/读取新文件 - 为每个文件创建
wiki/sources/下的来源页 - 提取核心概念，创建/更新概念页
- 提取人物/组织，创建/更新实体页
- 建立交叉引用（
[wiki/...](/wiki/wiki/...)wikilink） - 更新
wiki/index.md - 追加到
wiki/log.md
关键特征：
- 增量式——每次只处理新增文件
- 概念/实体页会被反复更新（随着新资料加入而增厚）
- 交叉引用自动建立（知识图谱的文本等价物）
4.2 Query（查询）
查询时 LLM 直接读取预编译好的 Wiki，而非翻原始文档：
- 读取
wiki/index.md了解目录 - 定位相关页面并读取
- 综合回答，标注来源引用
- 可选：将问答保存为新 wiki 页面
优势：比 RAG 更快、更准、更可解释。不需要 embedding 模型和向量数据库。
4.3 Lint（质量检查）
LLM 周期性巡检知识库质量：
- 检查
[wiki/...](/wiki/wiki/...)引用是否有效（断链检测） - 检查孤立页面（无入向引用）
- 检查跨页面矛盾
- 检查过时信息
- 报告结果并建议修复
4.4 Compile（编译/更新索引）
Ingest 后自动执行：更新 index.md、更新受影响的跨页面引用。
五、生态演化：从理念到产品
5.1 GBrain（Garry Tan，Y Combinator CEO）
GBrain 是 LLM Wiki 理念的更工程化版本：
- 思想与 LLM-Wiki 类似，但加入了更多自动化管道
- 强调知识的"自组织"与"自进化"
- 面向 YC 创业生态的高密度信息网络
5.2 OpenHuman（GitHub 19k star）
OpenHuman 把 Karpathy 的推文工程化成了可安装的桌面 Agent：
核心创新：Memory Tree + Obsidian Wiki
- 所有数据（邮件、文档、聊天、commit）被切成 ≤3k token 的 Markdown 块
- 打分后折叠成层级摘要树，存在本地 SQLite
- 同样的 chunk 以 .md 文件落入 Obsidian-compatible vault
- 20 分钟自动同步：agent 早晨打开就知道你今天的日程和昨天的 commit
三大差异化设计：
- 主动认识你：不等你教，118 个 OAuth 集成 + 每 20 分钟 auto-fetch
- Memory Tree 三层架构：来源树 / 主题树 / 全局树
- TokenJuice 压缩中间层：HTML→Markdown、URL缩短、去重 + 摘要，成本降 80%
创始人 @senamakel 的一句话概括："It becomes you, controlled by you."
5.3 OpenClaw/Hermes 生态
在 Agent 框架中，LLM Wiki 方法论落地为两个核心机制：
Skill 机制（经验性知识）：
- 本质是结构化的经验沉淀
- 告诉 Agent "在这个场景下，按什么步骤、用什么工具"
- 可自动沉淀（但触发时机可控性较低）
知识库机制（事实性知识）：
- OpenClaw 的 Workspace：MEMORY.md + SOUL.md + daily-notes/
- 与 Obsidian 双向同步
- "编译"而非"检索"——与 Karpathy 理念一致
5.4 三种知识库加载方式对比
针对 Agent 加载本地知识库，当前生态已形成三种主流方案：
| 方案 | 适用规模 | 优势 | 劣势 |
|---|---|---|---|
| QMD（WASM 轻量向量库） | 个人 / 百万字级 | 零配置、双重检索（BM25+语义）、端侧友好 | 千万级性能抖动 |
| 传统 VectorDB（Chroma/Milvus） | 企业 / 千万-亿级 | 多维过滤、稳定性 | 维护成本高 |
| Mem0g（Graph RAG 知识图谱） | 复杂推理 | 逻辑推理强、跨文档关联 | 构建极慢、门槛高 |
LLM Wiki 的定位：轻量级 + 高可读性 + 无黑盒，适合个人知识工作者和深度研究型场景。
六、知识工程 vs 提示工程
来源文章提出了一个关键的二元划分：
| Prompt Engineering | Knowledge Engineering | |
|---|---|---|
| 核心问题 | "完成什么任务" | "应该知道什么" && "如何运用已知" |
| 输出物 | Prompt / System Message | Schema 文件 + 结构化 Wiki |
| 知识类型 | 即时指令 | 经验性知识 + 事实性知识 |
| 可持续性 | 一次性使用 | 持续累积、增厚 |
核心洞察：Knowledge Engineering 是影响 Prompt、Context、Harness 的关键上游，但被行业讨论得最少。LLM Wiki 的 Schema 文件（CLAUDE.md）就是 Knowledge Engineering 的典型产出——它用自然语言定义知识的组织规则。
七、格式之争：Markdown / HTML / SVG 三层分工
LLM Wiki 引发的另一个讨论是：AI 输出的最佳格式是什么？
结论：三层框架
| 层 | 格式 | 场景 |
|---|---|---|
| 后台/内部 | Markdown | Agent 记忆文件、Skill 文档、Prompt、协议传递 |
| 文档输出 | HTML | 需求文档、研究报告、代码审查、交互原型 |
| 视觉输出 | SVG | 架构图、信息图、卡片图、知识图谱 |
Markdown 在 AI 知识管理中的地位稳固——"模型学到的关联是 Markdown = 认真、结构化、专业"。但 AI 的最终输出越来越不是文档形态，SVG 让 AI 第一次有能力"直接出图"。
八、人类角色转变
LLM Wiki 重新定义了知识管理中人与 AI 的分工：
| 人类负责 | LLM 负责 |
|---|---|
| 决定加什么资料 | 阅读和综合原始资料 |
| 提出好问题 | 创建和更新 Wiki 页面 |
| 在 Schema 中设定规则 | 建立交叉引用 |
| 审查 LLM 的输出 | 标记矛盾点 |
| 添加个人笔记 | 维持数十页之间的一致性 |
| 每次 Ingest 后更新索引 |
核心变化：人类从"知识的组织者"变成了"知识的策展人"。你只管"堆知识"和"提问题"，繁琐的梳理、去重、关联交给 LLM。
九、实践建议
9.1 上手路径
- 最小可用：创建一个 Obsidian vault + 一个 CLAUDE.md + raw/ 目录
- 首批 Ingest：选 10-20 篇核心文章，建立骨架概念页
- 安装 Obsidian Web Clipper：一键收集网页到 raw/
- 定期 Lint：每 10-15 篇新资料后跑一次质量检查
- Schema 共同演化：随 Wiki 增长调整 CLAUDE.md
9.2 避坑指南
- 不要追求完美：先建立骨架，逐步深化
- 源头质量决定一切：精挑细选 100 篇高质量文章 > 1000 篇垃圾
- 善用 Graph View：Obsidian 图谱不是装饰，它能发现连接断裂
- 概念页和实体页要分开：前者是"what"，后者是"who/where"
- log.md 必须维护：每次操作留痕，便于回溯
9.3 规模化路径
当 Wiki 超过 100 个来源页时，考虑：
- 按主题分子批次 Ingest（并行子代理处理）
- 定期 Compile 索引
- 考虑引入 embedding 辅助检索（混合 RAG 方案）
- 但核心仍保持 Markdown 可读性（不做纯黑盒向量化）
十、方夏实践案例
方夏的 AI 研究 Wiki 是 LLM Wiki 方法论的一个大规模实践样本：
| 指标 | 数值 |
|---|---|
| 原始文件（raw/） | 915 个 .md + 266 个 .docx + 其他 |
| 镜像文件（wiki/raw/mirror/） | 1,185 个 |
| 来源页（wiki/sources/） | 521 个 |
| 概念页（wiki/concepts/） | 29 个 |
| 实体页（wiki/entities/） | 73 个 |
| 总计 | 623 个 Wiki 页面 |
关键经验：
- 并行子代理 Ingest：915 个文件分 4 批并行处理，15 分钟内完成
- 月度/字母分组批量页：避免为 915 个文件逐一建页的爆炸问题
- 主题分类 13 个维度：AI 技术、开发工具、文学影视、新能源、历史文化、地缘政治、企业管理、经济金融、健康医疗、社会观察、人物方法论、供应链、平台经济
- 持续维护：index.md + log.md 每次 Ingest 后同步更新
- 与 Obsidian 协同：所有 Wikilink 在 Obsidian 中可视化
十一、结论与展望
LLM Wiki 方法论代表了一个范式转变：从"AI 帮你搜索"到"AI 帮你思考"。
短期（2026 下半年）可预见的演进方向：
- 自动 Schema 生成：LLM 根据 raw/ 内容自动推荐分类体系
- 多 Wiki 联邦：跨主题 Wiki 的交叉引用（方夏的 AI 研究 Wiki + 区块链 Wiki + 物流 Wiki 已初具雏形）
- "编译"即服务：云端的定时 Ingest 服务 + 本地 Obsidian 查看
- 混合检索：LLM Wiki + embedding 辅助召回，取长补短
长期来看，LLM Wiki 是 Software 3.0 时代知识管理的自然形态：Markdown 是新时代的知识汇编语言，Schema 文件是知识编译器，Wiki 是预编译的知识产物。
附录：核心来源页清单
| 来源页 | 标题 | 核心贡献 |
|---|---|---|
| wx-48xpgamheakyj26p | 深度解析 LLM Wiki / Obsidian-Wiki / GBrain | 方法论核心，知识工程 vs 提示工程 |
| wx-vktdum1wkr9j3svh | LLM 打造全自动个人知识库 | 五步搭建方法论 |
| wx-rtu4iywvej-hbwn1 | OpenHuman: Memory Tree + Obsidian Wiki | 工程化实现，19k star |
| wx-_c5qt0gvvitu6u-o | OpenHuman：第三个开源 AI Agent | 主动认识你的架构差异 |
| wx-ab_dbrinxk8wnswv | Karpathy: Vibe Coding 已死, Software 3.0 | Karpathy 思想大框架 |
| wx-lz6icry1ynnxqq9t | Markdown/HTML/SVG 格式之争 | AI 输出格式的三层分工 |
| wx-vev_hhi05-h1y7xv | OpenClaw 知识库加载攻略 | QMD / VectorDB / Mem0g 三种方案对比 |
| wx-hvizuucsy8rwfour | Spec-Driven Development | 与 LLM Wiki 的方法论呼应 |
| openclaw-notes-2026-06-batch | 6 月研读笔记 | Karpathy Software 3.0 + Skill 本质 |
| openclaw-notes-2026-04-batch | 4 月研读笔记 | Karpathy "10亿参数" 判断 |
| workspace-memory（概念页） | Workspace 与记忆系统 | "编译而非检索"理念 |
本报告基于 AI 研究 Wiki 的 yhf-llm-wiki 方法论（Karpathy LLM Wiki Skill）整理生成。
报告路径：~/文档/LLM-Wiki方法论深度研究报告-2026-06-12.md