# LLM Wiki

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

- Skill: `wangjs-jacky/llm-wiki` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add wangjs-jacky/llm-wiki`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wangjs-jacky/llm-wiki/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: wangjs-jacky (https://skillmd.com/u/wangjs-jacky)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wangjs-jacky/llm-wiki

---


# 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（向量检索） | 索引优先 |
|----------|----------------|----------|
| 检索方式 | 语义相似性匹配片段 | 像 human expert 一样查目录 |
| 理解结构 | 不理解知识库结构 | 理解概念之间的层级和关联 |
| 可解释性 | 黑盒，不知道为什么检索这些片段 | 透明，能看到 LLM 选了哪些文章及为什么 |
| 维护成本 | 需要嵌入计算基础设施 | 维护一个 Markdown 文件 |
| 适用规模 | 任意规模 | ~200 篇文章以内最佳，超过则需要搜索引擎辅助 |

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

### index.md 的设计规范

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

```markdown
# 知识库索引

## 概念
- [[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 元数据：

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

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

### 四种输入类型

| 类型 | 处理方式 |
|------|----------|
| **URL** | WebFetch 抓取，提取正文，去除导航/广告 |
| **PDF** | LLM 文档理解，提取文本到附属 `.md` |
| **图片** | LLM 视觉理解，写描述性附属文件 |
| **笔记** | 直接写入自由格式文本 |

## 第三层：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]]` 链接延伸即可。文章之间靠链接串联，而非把所有内容塞进一篇。

**每篇文章包含**：

```markdown
---
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，实现知识复利：

| 输出类型 | 格式 | 归档位置 |
|----------|------|----------|
| 问答回答 | Markdown | `outputs/YYYY-MM-DD-topic.md` → 索引 |
| 健康报告 | Markdown | `outputs/lint-YYYY-MM-DD.md` |
| 幻灯片 | Marp | `outputs/slides-topic.md` |
| 图表 | matplotlib PNG | `outputs/chart-topic.png` + `.md` |

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

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

### 为什么需要评估器？

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

### 评估维度

| 维度 | 检查项 | 通过标准 |
|------|--------|----------|
| **文章粒度** | 文章长度分布 | 80% 文章核心内容在 200-500 字之间 |
| **索引完整性** | index.md 覆盖率 | 每篇 wiki 文章在索引中有对应条目 |
| **链接密度** | 每篇文章的 wikilink 数量 | 平均 ≥ 3 个双向链接 |
| **结构一致性** | frontmatter 规范性 | 所有文章含 tags/type/updated_at |
| **概念去重** | 近重复文章检测 | 无语义重复的概念页 |
| **孤立检测** | 无入链文章比例 | 孤立文章 < 10% |
| **摘要质量** | 索引条目信息量 | 每条索引包含足够的判断信息 |
| **时效性** | 文章更新时间 | 无明显过时内容（可配置阈值） |

### 评估流程

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

### 评估报告示例

```markdown
# 知识库健康报告

## 总览
- 文章总数：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）

```bash
/kb-evaluate
```

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

### 2. 摄入（Ingest）

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

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

### 3. 编译（Compile）

```bash
/kb-compile
```

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

### 4. 查询（Ask）

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

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

### 5. 检查（Lint）

```bash
/kb-lint
```

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

### 6. 合并（Merge）

```bash
/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 如何管理此知识库）
```

## 工具生态

| 工具 | 用途 |
|------|------|
| **Obsidian** | 知识库的 IDE —— 图谱视图可视化知识网络、实时浏览更新 |
| **Obsidian Web Clipper** | 浏览器扩展，快速将网页文章转为 Markdown |
| **Dataview** | Obsidian 插件，对 frontmatter 运行查询生成动态表格 |
| **Marp** | Markdown 幻灯片，直接从 wiki 内容生成演示文稿 |
| **qmd** | 本地 Markdown 搜索引擎（大型 wiki 时使用） |

## 参考资料

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