LLM 驱动的 Obsidian 个人知识库管理。当需要评估、优化、索引 Obsidian vault，或讨论知识管理、wiki 构建、LLM 辅助笔记、索引优先检索时触发。
LLM 驱动的 Obsidian 个人知识库管理。当需要评估、优化、索引 Obsidian vault，或讨论知识管理、wiki 构建、LLM 辅助笔记、索引优先检索时触发。
npx skills add https://github.com/wangjs-jacky/jacky-skills --skill llm-wiki复制此命令并粘贴到 Claude Code 中以安装该技能
Obsidian 万物采集器。委托 web-search 路由层获取内容（100+ 站点 + Layer 1-4 全栈），采集到 raw/ 并编译为结构化 wiki 笔记。支持批量并行、断点续传。触发词：采集、导入知识库、ob-collect、视频转笔记、采集书签、批量采集。
从动效视频/截图反推出可直接喂给 LLM 还原动效的 Prompt 描述词。重点在「看懂运动」和「对齐你的意图」，不是搬运帧。触发词：分析动效、animate prompt、生成动效描述、动效 Prompt、animation analysis、帮我写这个动效的描述、还原这个动画
网络信息获取唯一决策入口。三层能力： ① Layer 1 — OpenCLI 100+ 站点直采（含 External CLI 桥接 + 本机扩展 CLI） ② Layer 2 — 通用搜索降级链（WebSearch → Tavily → DuckDuckGo） ③ Layer 3/4 — 已知 URL 读取 + 浏览器 CDP 兜底 触发场景：搜索、查询、调研、读取网页、抓 SPA、登录后内容、采集前置「先搜后采」 不触发场景：URL 已明确且已确认走 OpenCLI（如 ob-collect 拿到具体视频 URL 后直接执行） 特殊指令：/web-search setup（注册 Tavily + 扫描本机 CLI） 沉淀机制：搜索完成后按规则更新 experience.local.md
项目知识沉淀到 Obsidian。四种模式：自动沉淀（Hook）、手动沉淀、浏览追问、架构回顾（生成档案+批注+resolve 改代码）。触发词：ob-project-log、项目沉淀、追问文章、架构回顾、review init/resolve。
对话中快速收藏通用知识点到 Obsidian 知识库。触发词：/save、/collect、收藏、记录一下、ob-topic。
专属项目学习导师 - 当用户希望学习项目、特定代码文件或底层技术时，以交互式问答驱动教学，并将每次讲解持久化为结构化学习日志（overview + 主题笔记）
| name | llm-wiki |
| description | LLM 驱动的 Obsidian 个人知识库管理。当需要评估、优化、索引 Obsidian vault，或讨论知识管理、wiki 构建、LLM 辅助笔记、索引优先检索时触发。 |
把 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（向量检索） | 索引优先 |
|---|---|---|
| 检索方式 | 语义相似性匹配片段 | 像 human expert 一样查目录 |
| 理解结构 | 不理解知识库结构 | 理解概念之间的层级和关联 |
| 可解释性 | 黑盒，不知道为什么检索这些片段 | 透明，能看到 LLM 选了哪些文章及为什么 |
| 维护成本 | 需要嵌入计算基础设施 | 维护一个 Markdown 文件 |
| 适用规模 | 任意规模 | ~200 篇文章以内最佳，超过则需要搜索引擎辅助 |
本质区别：RAG 检索的是"看起来像"查询的文本片段。索引优先让 LLM 像 human expert 一样工作 —— 先查目录，再翻到相关章节。
索引文件是整个系统的心脏。它必须满足三个条件：紧凑、一致、可导航。
# 知识库索引
## 概念
- [[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 和注意力机制本质上解决同一个问题：如何为相关性/质量分配标量分数
关键约束：
当 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 抓取，提取正文，去除导航/广告 |
LLM 文档理解，提取文本到附属 .md | |
| 图片 | LLM 视觉理解，写描述性附属文件 |
| 笔记 | 直接写入自由格式文本 |
每篇未编译的 raw 文件经过编译流程：
wiki/sources/<slug>.mdwiki/concepts/<concept>.md[[wikilinks]] 链接index.md 索引log.md关键约束：建议每篇文章核心内容 ≤ 500 字。
为什么？因为 LLM 的上下文空间是有限的。500 字的文章意味着：
超出 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。 每个答案、每次分析都让知识库为未来查询变得更丰富。
大多数人的 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 最初是纯人写的。需要一个从"人写人读"到"人机协作"的过渡路径。
运行评估器，了解当前 vault 的 LLM 友好度。识别需要重构的文章（过长、缺少结构、缺少链接）。
为现有文章创建 index.md。这一步让 LLM 能够导航已有内容。LLM 扫描所有文章，提取摘要，建立分类索引。
不是一次性重写所有文章，而是 渐进式重构：
当知识库达到一定规范度后，LLM 可以自主运行：
/kb-lint：健康检查，发现并修复问题/kb-reflect：发现隐含关联，生成综合文章/kb-merge：合并重复概念/kb-evaluate
检查知识库是否 LLM 友好，生成健康报告和修复建议。
/kb-ingest https://example.com/article
/kb-ingest ~/papers/attention.pdf
/kb-ingest "我的笔记：RLHF 和 CoT 之间可能有深层联系"
将任何来源暂存到 raw/，不触发处理。
/kb-compile
处理所有未编译内容，生成/更新 wiki 文章和索引，自动触发反思引擎。
/kb-ask RLHF 和 chain-of-thought 有什么关系？
索引优先的问答：读索引 → 选文章 → 读全文 → 综合回答 → 归档回 wiki。
/kb-lint
健康检查：矛盾、孤立页面、缺失概念、断裂链接、重复文章。
/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 时使用） |