一、Karpathy 的 LLM Wiki 是什么
前 OpenAI 联合创始人 Andrej Karpathy 最近提出了一个想法：让 LLM 替你维护一个持久的个人知识库（Wiki） ，而不是每次提问都从原始文档重新检索。
原文链接：gist.github.com/karpathy/44…
核心观点：
Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis.
The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read.
简单翻译：知识不是每次都重新检索，而是一次性编译好，持续维护。每新增一份资料，整个知识库都会变得更强。
架构分三层：
- Raw sources — 原始文档，不可变
- Wiki — LLM 生成并维护的结构化 Markdown 页面
- Schema — 配置文件（如 CLAUDE.md），告诉 LLM 怎么维护这个 wiki
二、LLM Wiki 能干什么
Karpathy 列举了很多场景：
- 个人成长：记录目标、健康、心理状态，随时间构建自我画像
- 深度研究：读论文、文章、报告，逐步构建带有论证演化的知识体系
- 读书笔记：边读边建 Wiki，结束时你拥有一个像 Tolkien Gateway 那样的深度知识库
- 团队知识管理：Slack 线程、会议记录、项目文档自动维护成内部 Wiki
- 竞品分析、尽职调查、旅行规划、课程笔记、兴趣深挖 — 任何需要持续积累知识的场景
本质上，LLM Wiki 解决的是一个经典问题：人类放弃 Wiki 的原因不是不会写，而是维护成本随时间指数增长。LLM 不怕枯燥，不怕忘记更新交叉引用，一次操作能改 15 个文件。
三、LLM Wiki vs RAG
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 知识处理 | 查询时实时检索 chunk | 提前编译好，查询时直接读取 |
| 跨文档关联 | 每次重新发现 | 已经建好交叉引用 |
| 矛盾检测 | 不做 | 新资料入库时自动标记矛盾 |
| 累积效应 | 无，每次从零开始 | 每加一份资料，整个库更丰富 |
| 维护成本 | 需要向量数据库、Embedding | 只需要 Markdown + Git |
| 适用规模 | 海量文档（万级+） | 中小规模（百级 sources，数百 pages） |
| 基础设施 | 重（向量库、检索管线） | 轻（Markdown 文件 + index.md） |
LLM Wiki 的优势：简单、可累积、人可读、Git 天然版本控制。在个人知识管理这个场景下，它比 RAG 更自然。
LLM Wiki 的不足：不适合海量数据（Karpathy 自己说 ~100 sources 是舒适区）；依赖 LLM 的上下文窗口；当 Wiki 增长到数百页以上时，单靠 index.md 导航会吃力，需要引入搜索工具（如 qmd）。
一句话总结：RAG 是"搜索引擎"，LLM Wiki 是"知识库"。搜索每次从零开始，知识库是持续编译的。
四、我把它做成了一个 Claude Code Skill
Karpathy 的原文是一个想法文档，不是实现。他说：
This document is intentionally abstract. It describes the idea, not a specific implementation.
我基于这个想法，做了一个可直接使用的 Claude Code Skill — llm-wiki。
技能设计
5 个命令：
| 命令 | 用途 |
|---|---|
/init | 初始化知识库目录结构和配置文件 |
/ingest | 处理新资料：分类归档 → 生成摘要 → 提取实体 → 更新主题 |
/query | 从知识库回答问题，好的回答可回填为新页面 |
/lint | 健康检查：矛盾、孤立页、缺失引用 |
/status | 查看知识库概览 |
架构设计
我做了一个关键改进：两区 raw/ 模型。
raw/
buffer/ ← 缓冲区：用户随便丢文件进来，无需命名分类
archive/ ← 归档区：ingest 后 LLM 自动分类存放，不可变
assets/
<category>/ ← interview/、career/、research/ 等语义分类
wiki/ ← LLM 维护的知识库
sources/ ← 源文档摘要
entities/ ← 实体页（人物、组织、概念、技术）
topics/ ← 主题页（综合分析）
index.md ← 内容目录
log.md ← 变更日志
CLAUDE.md ← Schema 配置
用户只需要把文件丢进 raw/buffer/，LLM 在 ingest 时自动分类、命名、移动到 raw/archive/，然后生成所有 wiki 页面。
五、Skill 工作流
初始化
/init → 创建目录结构 → 生成 CLAUDE.md → 初始化 index.md 和 log.md
摄入资料（核心流程）
用户丢文件到 raw/buffer/（或直接对话中提供）
↓
LLM 读取内容，判断语义类型
↓
移动到 raw/archive/<category>/<name>.md（不可变）
↓
生成 wiki/sources/<name>.md（摘要页）
↓
提取实体 → 创建/更新 wiki/entities/*.md
↓
更新 wiki/topics/*.md（综合分析）
↓
更新 wiki/index.md + log.md
一个资料通常会影响 10-15 个 wiki 页面。这是关键 — 不是简单索引，而是真正的知识整合。
所有页面通过 [[wikilink]] 互相引用，在 Obsidian 的 Graph View 里能看到一张有机的知识网络图。
六、Skill 源码
目录结构
~/.claude/skills/llm-wiki/
├── SKILL.md ← 主文件：5 个命令 + 架构 + 约定
└── references/
└── schema-template.md ← CLAUDE.md 模板（/init 时使用）
总结
Karpathy 提出了一个优雅的想法：让 LLM 当你的知识库程序员。我做的 Skill 就是把这个想法落地成可复用的工具：
- 丢文件 →
raw/buffer/ - 说
/ingest→ LLM 自动分类、生成摘要、提取实体、更新主题 - 问问题 → LLM 从已编译的知识库综合回答
- 好答案自动回填 → 知识持续复利增长
本质上就是把"维护知识库"这件人类最讨厌做的事，交给不会偷懒的 LLM。
如果你也在用 Claude Code + Obsidian，可以直接把这个 Skill 放到 ~/.claude/skills/llm-wiki/ 目录下开始使用。有任何想法欢迎评论区交流 🙌
