llm-wiki

name: llm-wiki description: LLM 驱动的 Obsidian 个人知识库管理。当需要评估、优化、索引 Obsidian vault，或讨论知识管理、wiki 构建、LLM 辅助笔记、索引优先检索时触发。

LLM Wiki - LLM 驱动的 Obsidian 知识库

把 Obsidian 当 IDE，LLM 当程序员，知识库当代码库。LLM 不只回答问题 —— 它持续编译、索引和优化你的知识网络。

核心原则

传统 RAG 的致命缺陷：没有积累。 每次提问都从头检索原始文档，答案用完即弃。知识从未沉淀。

本模式的核心差异：知识复利。 LLM 增量编译原始资料为结构化 wiki，知识被编译一次并持续保持更新。每一次探索、每一次提问都在让知识库变得更好。当索引足够优化时，表现超越 RAG。

知识库的四个层次

从底到顶，知识库由四个层次构成：

┌──────────────────────────────────────────────────┐
│  4. 输出层 (Outputs)                              │
│  问答回答、综合报告、幻灯片、图表 → 归档回 wiki    │
├──────────────────────────────────────────────────┤
│  3. Wiki 层 (LLM 编译/维护)                       │
│  index.md · concepts/ · entities/ · synthesis/    │
│  每篇文章建议 ≤ 500 字，超出部分用 [[ref]] 链接延伸  │
├──────────────────────────────────────────────────┤
│  2. 原始资料层 (Raw)                              │
│  raw/ · articles/ · papers/ · images/ · notes/    │
│  不可变，LLM 只读不写                              │
├──────────────────────────────────────────────────┤
│  1. 索引地图层 (Index Map)                        │
│  全局 index.md + 各目录子索引                      │
│  LLM 的导航入口，查询时始终在上下文中              │
└──────────────────────────────────────────────────┘

为什么分四层而不是三层？

传统三层架构（Raw → Wiki → Outputs）忽略了最关键的一层：索引地图。

索引地图不是 wiki 的一个文件 —— 它是独立的基础设施层。它决定了 LLM 能否高效地找到、理解和关联知识。好的索引地图让 LLM 在几百篇文章中精准定位 3-5 篇相关文章，无需加载整个 wiki。索引的质量决定了整个系统的上限。

第一层：索引地图

为什么索引比 RAG 更好？

本质区别：RAG 检索的是"看起来像"查询的文本片段。索引优先让 LLM 像 human expert 一样工作 —— 先查目录，再翻到相关章节。

index.md 的设计规范

索引文件是整个系统的心脏。它必须满足三个条件：紧凑、一致、可导航。

# 知识库索引

## 概念
- [[concepts/attention]] — 让模型动态权衡 token 相关性的机制
- [[concepts/transformer]] — 基于自注意力的序列建模架构
- [[concepts/rlhf]] — 用人类反馈强化学习对齐语言模型的方法

## 实体
- [[entities/vaswani]] — Ashish Vaswani，Google Brain 研究员

## 来源
- [[sources/attention-is-all-you-need]] — Vaswani 2017，原始 Transformer 论文

## 综合（LLM 生成）
- [[synthesis/scoring-mechanisms]] — RLHF 和注意力机制本质上解决同一个问题：如何为相关性/质量分配标量分数

关键约束：

1. 每个条目一行 —— 一句话描述，不超过 80 字
2. 总量可控 —— 索引本身必须能完整放入 LLM 上下文（~200 篇文章 ≈ ~200 行索引）
3. 分类清晰 —— 按概念/实体/来源/综合分层组织
4. 增量更新 —— 每次摄入新内容后 LLM 自动追加

渐进式索引加载

当 wiki 规模超过 200 篇文章，单一索引文件过长时，采用 渐进式索引加载：

index.md（全局索引，始终在上下文中）
  ├── concepts/index.md（概念子索引）
  │   ├── concepts/ml/index.md（机器学习子索引）
  │   └── concepts/web/index.md（Web 开发子索引）
  ├── entities/index.md（实体子索引）
  └── sources/index.md（来源子索引）

查询流程：

用户提问 → LLM 读全局 index.md（始终在上下文中）
         → 定位到 1-2 个最相关的子索引
         → 读取子索引，选择 3-5 篇具体文章
         → 读取完整文章，综合回答

这样，无论 wiki 多大，LLM 每次只需要加载 索引 + 子索引 + 3-5 篇文章，远少于加载整个 wiki。

第二层：原始资料

摄入规范

所有原始资料存入 raw/，添加 frontmatter 元数据：

---
source: https://example.com/article
ingested_at: 2026-04-06T10:00:00Z
type: web | pdf | image | note
status: uncompiled
---

核心原则：摄入与编译分离。 先捕获，后处理。可以一次性摄入 20 篇再统一编译，也可以每篇即编译。

四种输入类型

第三层：Wiki 编译

编译流程

每篇未编译的 raw 文件经过编译流程：

1. LLM 阅读原始内容
2. 写入结构化摘要（建议 ≤ 500 字，超出部分用 [[reference]] 链接延伸）到 wiki/sources/<slug>.md
3. 提取关键概念，创建或更新 wiki/concepts/<concept>.md
4. 概念去重：如果概念页已存在，读取并更新而非创建重复
5. 建立双向 [[wikilinks]] 链接
6. 更新 index.md 索引
7. 追加条目到 log.md

每篇文章的设计规范

关键约束：建议每篇文章核心内容 ≤ 500 字。

为什么？因为 LLM 的上下文空间是有限的。500 字的文章意味着：

• 索引中的一行描述（~80 字）让 LLM 快速判断相关性
• 完整文章（~500 字）提供足够细节用于回答问题
• 3-5 篇文章 × 500 字 = 1500-2500 字的精确上下文，远优于 RAG 返回的碎片化片段

超出 500 字怎么办？ 没关系。将核心要点控制在 500 字以内，详细展开的内容拆分到子概念文章，通过 [[reference]] 链接延伸即可。文章之间靠链接串联，而非把所有内容塞进一篇。

每篇文章包含：

---
tags: [tag1, tag2]
type: concept | source | entity | synthesis
updated_at: 2026-04-06
---

# 概念标题

一句话定义。

## 核心要点
- 要点 1
- 要点 2
- 要点 3

## 关联
- [[related-concept-1]] — 关联原因
- [[related-concept-2]] — 关联原因

## 来源
- [[sources/source-1]]

自我改进：反思引擎

编译后自动运行两阶段反思：

阶段 1 —— 发现（仅读索引）：从索引的一行摘要中识别：

• 跨领域主题（一个概念出现在多个不相关来源中）
• 隐含关系（两个概念看似相关但无链接）
• 矛盾（来源持对立立场）
• 空白（多来源暗示但无专门文章的主题）

阶段 2 —— 综合（定向深度阅读）：对每个候选，读相关文章，证据充分则生成新的 synthesis 类型文章。

综合文章是 二阶知识 —— 从知识中生成的知识。它们捕获没有任何单一来源会表述的关联。

第四层：输出与归档

所有输出归档回 wiki，实现知识复利：

核心原则：好的输出归档回 wiki。 每个答案、每次分析都让知识库为未来查询变得更丰富。

评估器：检查知识库是否 LLM 友好

为什么需要评估器？

大多数人的 Obsidian vault 是给人看的，不是给 LLM 看的。文章长短不一、结构混乱、缺少链接、信息密度低。评估器检查当前知识库是否适合 LLM 理解和高效检索。

评估维度

评估流程

/kb-evaluate
  → 扫描 wiki/ 所有 .md 文件
  → 统计文章长度分布、链接密度、frontmatter 完整性
  → 检查 index.md 覆盖率
  → 检测孤立文章和断裂链接
  → 生成评估报告：score.md
  → 给出优先修复建议

评估报告示例

# 知识库健康报告

## 总览
- 文章总数：87
- 平均长度：420 字 ✅
- 索引覆盖率：92% ⚠️（7 篇文章未在索引中）
- 平均链接数：2.8 ⚠️（建议 ≥ 3）

## 问题清单（按优先级）
1. 🔴 3 篇文章 > 2000 字 → 需拆分
2. 🟡 7 篇文章缺少索引条目 → 需补充
3. 🟡 12 篇文章链接数 < 2 → 需补充链接
4. 🟢 4 篇孤立文章 → 可选补充入链

从人写到人机协作：过渡策略

大多数人的 Obsidian vault 最初是纯人写的。需要一个从"人写人读"到"人机协作"的过渡路径。

阶段 1：评估现状

运行评估器，了解当前 vault 的 LLM 友好度。识别需要重构的文章（过长、缺少结构、缺少链接）。

阶段 2：建立索引

为现有文章创建 index.md。这一步让 LLM 能够导航已有内容。LLM 扫描所有文章，提取摘要，建立分类索引。

阶段 3：增量重构

不是一次性重写所有文章，而是 渐进式重构：

• 新摄入的内容按规范编译（建议 ≤ 500 字、结构化、链接丰富，超出用 [[reference]] 延伸）
• 旧文章在 LLM 查询时顺便优化（遇到长文章时拆分、遇到缺少链接时补充）
• 每次交互都可能触发对相关文章的小幅改进

阶段 4：LLM 自主迭代

当知识库达到一定规范度后，LLM 可以自主运行：

• /kb-lint：健康检查，发现并修复问题
• /kb-reflect：发现隐含关联，生成综合文章
• /kb-merge：合并重复概念
• 输出归档回 wiki，持续积累

六种核心操作

1. 评估（Evaluate）

/kb-evaluate

检查知识库是否 LLM 友好，生成健康报告和修复建议。

2. 摄入（Ingest）

/kb-ingest https://example.com/article
/kb-ingest ~/papers/attention.pdf
/kb-ingest "我的笔记：RLHF 和 CoT 之间可能有深层联系"

将任何来源暂存到 raw/，不触发处理。

3. 编译（Compile）

/kb-compile

处理所有未编译内容，生成/更新 wiki 文章和索引，自动触发反思引擎。

4. 查询（Ask）

/kb-ask RLHF 和 chain-of-thought 有什么关系？

索引优先的问答：读索引 → 选文章 → 读全文 → 综合回答 → 归档回 wiki。

5. 检查（Lint）

/kb-lint

健康检查：矛盾、孤立页面、缺失概念、断裂链接、重复文章。

6. 合并（Merge）

/kb-merge concepts/attention concepts/attention-mechanism

合并重复概念，保持概念空间紧凑。

维护循环

摄入 → 编译 → 查询 → 归档
                ↑              ↓
              反思 ← 检查 ← 合并

每个环节都在让知识库变得更好。知识复利的关键不在于摄入更多内容，而在于 让已有知识之间建立更多关联。

推荐目录结构

obsidian-vault/
├── raw/                        # 原始资料（不可变）
│   ├── web/                    # 网页裁剪
│   ├── pdf/                    # PDF 文档
│   ├── images/                 # 图片（本地化）
│   └── notes/                  # 个人笔记
├── wiki/                       # LLM 编译维护
│   ├── index.md                # 全局索引（核心）
│   ├── log.md                  # 变更日志
│   ├── concepts/               # 概念文章（建议 ≤ 500 字）
│   │   └── index.md            # 概念子索引
│   ├── entities/               # 实体页面
│   ├── sources/                # 来源摘要
│   ├── synthesis/              # 综合文章（LLM 生成）
│   └── archive/                # 归档（合并后的旧文章）
├── outputs/                    # 输出文件
│   ├── YYYY-MM-DD-*.md         # 问答回答
│   └── lint-YYYY-MM-DD.md      # 健康报告
└── CLAUDE.md                   # Schema（告诉 LLM 如何管理此知识库）

工具生态

参考资料

• Karpathy 原文 Gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• 方法论完整原文（中文翻译）：references/llm-wiki-pattern.md
• Karpathy 推文实践总结（中文翻译）：references/karpathy-tweet-translation.md
• 实战案例：构建自我改进型个人知识库（中文翻译）：references/self-improving-kb.md
• 开源实现：louiswang524/llm-knowledge-base（9 个 Claude Code skills）
• 灵感来源：Vannevar Bush 的 Memex（1945）—— 个人策划的知识存储，文档间的关联轨迹