LLM Wiki 是什么#

2026 年 4 月，Andrej Karpathy 发布了一篇 GitHub Gist，提出了一种全新的个人知识管理范式：让 LLM 做”知识编译器”，提前把原始资料编译成结构化 Wiki，查询时直接读取已编译好的知识，而不是每次从文档碎片中检索。

核心理念：LLM 不只是写代码的工具，更擅长组织知识。你丢原始素材进去，LLM 自动帮你生成结构化、双向链接的 Wiki 页面，知识越攒越聪明。

Karpathy 原话：“This is the end of the forgotten bookmark. For the individual, it’s a compounding research assistant.” —— 这是收藏夹吃灰的终结。对个人而言，它是一个产生复利的研究助手。

核心架构#

1
my-knowledge-base/
2
├── raw/                    # 第一层：原始素材（只读，不可变）
3
│   ├── articles/           # 网页文章
4
│   ├── papers/             # 论文 PDF 转 Markdown
5
│   ├── repos/              # 代码仓库文档
6
│   └── data/               # 截图、表格等
7
├── wiki/                   # 第二层：LLM 编译的结构化知识
8
│   ├── index.md            # 总索引，每次操作必须更新
9
│   ├── log.md              # 仅追加的操作日志
10
│   ├── concepts/           # 概念词条
11
│   ├── entities/           # 人物、组织、项目
12
│   ├── sources/            # 每篇素材的摘要页
13
│   └── comparisons/        # 对比分析页
14
├── outputs/                # 输出产物（报告、幻灯片、lint 结果）
15
└── CLAUDE.md               # 第三层：Schema 规则文件（最关键）

分工明确：

• 你：筛选素材、提问引导方向、审核 Wiki 质量、维护 raw/
• LLM：读取素材、生成摘要和概念页、维护交叉引用、更新索引、标记矛盾

Karpathy 用编译器类比来描述这个过程：

环境准备#

本质上只需要一个文件夹 + Claude Code。Obsidian 和 Git 是锦上添花，但不装也能跑通完整流程。

社区项目一览#

Karpathy 的 Gist 发布后一周内，社区涌现了大量实现。如果你不想从零手写 CLAUDE.md，这些现成项目能帮你一键初始化，直接开始用：

推荐：追求功能完整选 karpathy-llm-wiki，中文用户偏好本地化体验选 llm-wiki-skill，数据隐私要求极高的选 git-wiki（纯本地搜索，不依赖云端 LLM）。

快速上手#

1
mkdir -p ~/my-wiki/{raw/{articles,papers,repos,data},wiki/{concepts,entities,sources,comparisons},outputs}
2
touch ~/my-wiki/wiki/index.md
3
touch ~/my-wiki/wiki/log.md
4
cd ~/my-wiki
5
git init
6
echo "outputs/" >> .gitignore

1
# My Personal Wiki
2

3
## 项目结构
4
- `raw/` — 原始素材，只读。永远不要修改这里的文件。
5
- `wiki/` — LLM 生成和维护的 Markdown 页面。
6
- `wiki/index.md` — 总目录。每次操作后必须更新。
7
- `wiki/log.md` — 仅追加的操作日志。
8
- `outputs/` — 生成的报告、lint 结果等。
9

10
## 页面规范
11

12
每个 Wiki 页面必须包含 YAML frontmatter：
13

14
---
15
title: "页面标题"
16
type: concept | entity | source-summary | comparison
17
sources:
18
  - raw/articles/某篇文章.md
19
related:
20
  - "[[相关概念]]"
21
created: YYYY-MM-DD
22
updated: YYYY-MM-DD
23
confidence: high | medium | low
24
---
25

26
命名规则：
27
- 文件名用 kebab-case，与概念名一致（如 `attention-mechanism.md`）
28
- 内部引用统一用 `[[wikilinks]]`
29
- 引用来源时始终链接回 `raw/` 文件路径
30

31
## 工作流
32

33
### Ingest（摄入）
34
1. 读取 raw/ 中的新素材
35
2. 和用户讨论关键发现
36
3. 在 wiki/sources/ 中创建素材摘要页
37
4. 更新或新建 concept/entity 页面
38
5. 更新 wiki/index.md
39
6. 在 wiki/log.md 末尾追加：## [YYYY-MM-DD] ingest | 素材标题
40

41
### Query（查询）
42
1. 先读 wiki/index.md 定位相关页面
43
2. 读这些页面，综合回答
44
3. 用 [[wikilinks]] 标注引用来源
45
4. 如果回答有留存价值，主动询问是否保存为新 Wiki 页面
46

47
### Lint（健康检查）
48
1. 扫描所有 Wiki 页面，检查矛盾
49
2. 找出孤页（无入链的页面）
50
3. 标记被引用但未创建的概念
51
4. 找出被新素材取代的过时声明
52
5. 结果保存到 outputs/lint-YYYY-MM-DD.md

1
# 假设你有一篇想收藏的博客文章
2
cp ~/Downloads/some-article.md raw/articles/

1
cd ~/my-wiki
2
claude

1
# 用 Obsidian 打开 wiki/ 目录作为 Vault
2
# 点击左侧 Graph View 按钮，即可看到知识节点和双向链接图谱

进阶玩法#

1
#!/bin/bash
2
# 每次提交后自动做一次轻量 lint
3
claude --print "对 wiki/ 做一次快速健康检查，只标记严重问题，结果追加到 outputs/lint-$(date +%Y-%m-%d).md"

1
# 每天凌晨 3 点执行 lint
2
0 3 * * * cd ~/my-wiki && claude --print "执行完整 lint，结果保存到 outputs/" && git add -A && git commit -m "auto lint $(date +%Y-%m-%d)"

1
~/wikis/
2
├── ai-research/
3
│   ├── raw/  wiki/  CLAUDE.md
4
├── investment-notes/
5
│   ├── raw/  wiki/  CLAUDE.md
6
└── course-notes/
7
    ├── raw/  wiki/  CLAUDE.md

LLM Wiki vs RAG：什么时候用哪个#

选 RAG 的场景： 百万级文档、内容频繁变动、多团队规模。

选 LLM Wiki 的场景： < 500 篇源文档、希望知识产生复利、零基础设施偏好、个人或小团队使用。

常见问题#

Q：我用 ChatGPT / Cursor / Codex 行不行？

都可以。Karpathy 的方法论是工具无关的——核心是 raw/ → wiki/ → CLAUDE.md 三层架构。Claude Code 的原生 Agent 能力最强，但任何能读文件、写文件的 LLM 工具都能胜任。社区已有 Cursor 和 Codex 的适配实现。

Q：原始素材放什么格式？PDF 行不行？

建议尽量转成 Markdown。LLM 读取 Markdown 最可靠，PDF 解析依赖具体工具，可能丢失格式。Obsidian Web Clipper 能一键把网页转 Markdown。如果只有 PDF，可以先用 pdftotext 或 LLM 自带的 PDF 阅读能力转成文本。

Q：Wiki 太大会不会让 LLM 上下文不够用？

Karpathy 原版 Wiki 约 100 篇文章、400K 词，在 Claude 200K 上下文中完全放得下。如果 Wiki 超过上下文窗口，社区已经有方案：git-wiki 内置本地混合搜索（BM25 + 向量 + LLM 重排），llmwiki（Rust crate）用 Tantivy + fastembed 实现无需 LLM 索引也能扩展。

这两个方案都能让 Wiki 规模突破上下文限制：

• git-wiki：用 qmd 做本地搜索，搜索后只把相关页面送进上下文
• llmwiki：替换 index.md 为真实搜索引擎（BM25 + 语义搜索 + 混合 RRF）

Q：和 Obsidian 自带的关系图谱有什么区别？

Obsidian 图谱只展示 [[链接]] 关系，不会自动发现缺失的概念、标记矛盾、或跨文章提炼主题。LLM Wiki 的 Lint 操作能做 Obsidian 本身做不到的语义分析。

Q：隐私怎么办？数据都在本地？

所有数据都在本地 Markdown 文件中。用 Claude Code 时数据会发送到 Anthropic API，但你也可以切换到本地模型（Ollama + 开源模型）。纯 Markdown 格式意味着数据不受厂商锁定。

总结#

Karpathy 的 LLM Wiki 不是要革 RAG 的命，而是提供另一种哲学：编译优于检索、质量优于数量、显式关联优于隐式 Embedding。

对于个人知识管理，它是最轻量的方案——你只需要文件夹 + Claude Code，就能让 AI 帮你把收藏夹里吃灰的文章变成活的、会生长的知识网络。

参考资源#

• Karpathy 原始 Gist — llm-wiki.md
• karpathy-llm-wiki — 多平台支持（Claude Code / Cursor / Codex / OpenCode），783⭐
• llm-wiki-skill — 中文优化版，支持 Claude Code / Codex / OpenClaw，知识图谱可视化
• git-wiki — 本地混合搜索版
• llm-wiki-manager — 8 模式多 Wiki 管理
• llmwiki — Rust 原生搜索引擎（Tantivy BM25 + fastembed 语义搜索 + 混合 RRF），突破上下文窗口限制
• Karpathy 的 LLM Wiki：不用 RAG 也能构建个人知识库 — Toolin AI
• 告别收藏夹吃灰：Karpathy 的 LLM 知识库方法，我复现了一遍
• How to Build Karpathy’s LLM Wiki — Dev.to