| 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（向量检索） | 索引优先 |
|---|
| 检索方式 | 语义相似性匹配片段 | 像 human expert 一样查目录 |
| 理解结构 | 不理解知识库结构 | 理解概念之间的层级和关联 |
| 可解释性 | 黑盒，不知道为什么检索这些片段 | 透明，能看到 LLM 选了哪些文章及为什么 |
| 维护成本 | 需要嵌入计算基础设施 | 维护一个 Markdown 文件 |
| 适用规模 | 任意规模 | ~200 篇文章以内最佳，超过则需要搜索引擎辅助 |
本质区别：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 和注意力机制本质上解决同一个问题：如何为相关性/质量分配标量分数
关键约束：
- 每个条目一行 —— 一句话描述，不超过 80 字
- 总量可控 —— 索引本身必须能完整放入 LLM 上下文（~200 篇文章 ≈ ~200 行索引）
- 分类清晰 —— 按概念/实体/来源/综合分层组织
- 增量更新 —— 每次摄入新内容后 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 篇再统一编译，也可以每篇即编译。
四种输入类型
| 类型 | 处理方式 |
|---|
| URL | WebFetch 抓取，提取正文，去除导航/广告 |
| PDF | LLM 文档理解，提取文本到附属 .md |
| 图片 | LLM 视觉理解，写描述性附属文件 |
| 笔记 | 直接写入自由格式文本 |
第三层：Wiki 编译
编译流程
每篇未编译的 raw 文件经过编译流程：
- LLM 阅读原始内容
- 写入结构化摘要（建议 ≤ 500 字，超出部分用 [[reference]] 链接延伸）到
wiki/sources/<slug>.md
- 提取关键概念，创建或更新
wiki/concepts/<concept>.md
- 概念去重：如果概念页已存在，读取并更新而非创建重复
- 建立双向
[[wikilinks]] 链接
- 更新
index.md 索引
- 追加条目到
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，实现知识复利：
| 输出类型 | 格式 | 归档位置 |
|---|
| 问答回答 | 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
→ 给出优先修复建议
评估报告示例
# 知识库健康报告
## 总览
- 文章总数：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 如何管理此知识库）
工具生态
| 工具 | 用途 |
|---|
| Obsidian | 知识库的 IDE —— 图谱视图可视化知识网络、实时浏览更新 |
| Obsidian Web Clipper | 浏览器扩展，快速将网页文章转为 Markdown |
| Dataview | Obsidian 插件，对 frontmatter 运行查询生成动态表格 |
| Marp | Markdown 幻灯片，直接从 wiki 内容生成演示文稿 |
| qmd | 本地 Markdown 搜索引擎（大型 wiki 时使用） |
参考资料
