手搓脚本产品化成 CLI：Karpathy 的 LLM Wiki 想法值 2100 万浏览，有人 40 小时把它变成了流水线

Karpathy LLM Wiki gist：github.com/karpathy/442a6bf · ⭐ 5,000+ · 2026-04-04
llmwiki-cli：github.com/doum1004/llmwiki-cli · npm install -g llmwiki-cli

---

那条值 2100 万浏览的推

4 月 4 日，Karpathy 发布了一个 gist：llm-wiki.md。

标题是「A pattern for building personal knowledge bases using LLMs」，正文 2000 字。这篇 gist 在 24 小时内获得了 5000+ stars 和 5000+ forks。随之而来的讨论，换算成曝光量，是 2100 万。

它描述的想法并不复杂——但非常精准地戳中了一个所有人都有但说不清楚的痛点：

我们在用 AI 积累的知识，每次对话结束就消失了。

---

RAG 的问题：每次都在重新发现

大多数人的 AI + 文档体验是这样的：你上传一堆文件，AI 在你提问时检索相关片段，生成回答。

Karpathy 说，这叫 RAG（检索增强生成），而它有一个根本性的缺陷：没有积累。

“Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up.”

每次提问，AI 都在从头发现知识。五份文档之间的关联，AI 要一次次重新推断。矛盾的地方从未被主动标记。重要的综合见解只存在于某次对话里，下次问就没了。

NotebookLM、ChatGPT 文件上传、大多数 RAG 系统——都是这样工作的。

---

LLM Wiki 的答案：持久编译的知识库

Karpathy 的方案是：不要在查询时检索，而是让 LLM 增量构建并维护一个 wiki——一组结构化、互相链接的 markdown 文件。

每加一份新文档，LLM 不只是把它扔进检索索引：

新文档加入
    ↓
LLM 读取文档，提取关键信息
    ↓
生成摘要页（wiki/sources/文章名.md）
    ↓
读取现有概念页和实体页
    ↓
做跨文档综合，更新概念页（wiki/concepts/...）
    ↓
更新人物/组织/产品实体页（wiki/entities/...）
    ↓
更新索引（wiki/index.md）+ 追加日志（wiki/log.md）

一份文档平均要触及 10~15 个 wiki 页面。

知识不是往角落里堆灰，是往已有的墙上砌砖。

---

三层架构

Karpathy 定义了三层：

第一层：原始文档（raw/）

你的文章、论文、笔记、截图。不可修改，是 source of truth。LLM 只读，永远不改。

第二层：wiki（wiki/）

LLM 生成和维护的 markdown 文件。

wiki/
├── index.md          ← 主索引，每次 ingest 更新
├── log.md            ← 时间线日志（append-only）
├── sources/          ← 每份原始文档对应一个摘要页
├── concepts/         ← 概念页（思想、框架、理论）
├── entities/         ← 实体页（人、组织、产品）
└── synthesis/        ← 跨文档综合分析

这个层完全由 LLM 维护，你只读。

第三层：Schema（SCHEMA.md 或 CLAUDE.md）

告诉 LLM 这个 wiki 的结构、约定、ingest 流程。这是配置文件，让 LLM 成为一个有纪律的 wiki 维护者，而不是乱输出的聊天机器。

---

两个特殊文件：index.md 和 log.md

这两个文件是 wiki 的导航骨架，设计思路很精妙：

index.md（内容导向）

所有页面的目录，每条一行摘要。LLM 每次 ingest 后更新它。提问时 LLM 先读 index.md 找到相关页面，再深入读取。这在中等规模（~100 份文档，~几百个页面）效果很好，不需要 embedding RAG 基础设施。

log.md（时间线导向）

append-only 的操作记录：什么时候 ingest 了什么、做了什么查询、lint 了什么。每条记录的格式建议统一前缀：

## [2026-07-19] ingest | Karpathy LLM Wiki gist
## [2026-07-19] query | "graph database vs vector DB"
## [2026-07-19] lint | 发现 3 个 orphan 页面

这样 grep "^## \[" log.md | tail -10 就能看最近 10 条操作，LLM 也能快速了解上次做到哪里。

---

llmwiki-cli：40 小时把想法变成可安装的工具

Karpathy gist 发布的同天，就有人开始把它做成 CLI。doum1004/llmwiki-cli 是其中最完整的实现，已发布到 npm，可以直接安装：

npm install -g llmwiki-cli

这给你一个 wiki 命令（如果冲突则用 llmwiki）。

CLI 的设计哲学非常清晰：

「CLI 是手，LLM 是脑。」

CLI 只做文件 I/O：读、写、搜、管理。它不调用任何 LLM API。合成、关联、更新决策——全部由 Claude Code / Codex / Cursor 等 AI Agent 来做。

初始化

wiki init my-wiki --name "My Research Notes" --domain "machine learning"

生成结构：

my-wiki/
├── .llmwiki.yaml    ← wiki 配置
├── SCHEMA.md        ← Agent 行为规则（核心配置文件）
├── raw/             ← 放原始文档的地方
└── wiki/            ← LLM 维护的页面
    ├── index.md
    ├── entities/
    ├── concepts/
    ├── sources/
    └── synthesis/

核心命令

# 写页面（JSON 从 stdin 读，LLM 输出的就是这个格式）
wiki write wiki/sources/karpathy-llm-wiki.md <<'EOF'
{
  "title": "Karpathy LLM Wiki",
  "tags": ["knowledge-management", "LLM", "wiki"],
  "source": "https://gist.github.com/karpathy/442a6bf...",
  "content": "Karpathy 提出的 LLM 知识库范式...\n\n参见 [[RAG]] 和 [[知识图谱]]。"
}
EOF

# 搜索
wiki search "知识积累"

# 查反链（谁引用了这个页面）
wiki backlinks wiki/concepts/RAG.md

# 健康检查（孤儿页、断链、缺失交叉引用）
wiki lint

Agent 的工作流（Ingest）

# LLM Agent 拿到一份新文档后做什么
wiki read wiki/concepts/LLM.md      # 先读相关概念页
wiki read wiki/entities/OpenAI.md   # 再读相关实体页
# （综合后，LLM 生成/更新页面）
wiki write wiki/sources/new-paper.md <<JSON
{"title": "...", "tags": [...], "content": "摘要...\n\n更新了 [[LLM]] 的最新进展..."}
JSON
wiki write wiki/concepts/LLM.md <<JSON
{"title": "LLM", "content": "...(加入新文章的洞察，链接到 [[new-paper]])..."}
JSON
wiki lint    # 最后检查健康状态

高级功能

多 wiki 支持：每个项目/主题独立 wiki，全局注册表管理

wiki init ~/wikis/ml --name ml --domain "machine learning"
wiki init ~/wikis/personal --name personal --domain "personal notes"
wiki registry    # 列出所有 wiki
wiki search "neural networks" --all  # 跨所有 wiki 搜索

可视化图谱（可选）：基于 [[wikilinks]] 生成 d3-force 交互图，可部署到 GitHub Pages（demo 在 doum1004.github.io/llmwiki-cli）

---

和 RAG 的本质区别

维度	RAG（传统）	LLM Wiki
查询时做什么	实时检索 + 生成	读已编译的 wiki
新文档加入时	直接向量化入库	LLM 主动综合、更新 10~15 个页面
跨文档关系	每次查询重新发现	已编入 wiki，始终存在
矛盾检测	不处理	lint 周期性检查
知识积累	搜索结果	每次 ingest 后 wiki 变得更丰富
基础设施需求	embedding 模型 + 向量库	markdown 文件 + 任何 LLM

---

适合用的场景

Karpathy 列了几个：

• 个人研究：几周/几个月深入一个主题，读论文、文章，逐渐构建知识图谱
• 读书：每章 ingest，角色、主题、情节线逐渐成型，读完有一个同人 wiki
• 商业/团队：用 Slack 消息、会议记录、项目文档喂 wiki，AI 做维护工作
• 竞品分析、尽职调查、旅行规划、课程笔记

不适合的：

• 需要实时查询海量文档（还是 RAG 更合适）
• 非结构化、一次性的随手笔记（wiki 维护需要 LLM 成本）

---

一句话总结

Karpathy 的 LLM Wiki 把知识管理的问题说清楚了：RAG 是每次查询前重新发现，LLM Wiki 是一次编译、持续更新、永远可查。llmwiki-cli 把这个想法做成了可以 npm install -g 的 CLI：wiki 命令处理文件，Claude / Codex 做知识综合，两者分工明确。一份文档触及 10~15 个页面，知识在墙上砌砖，不在角落里堆灰。

© 2026 Author: Mycelium Protocol

LLM Wiki: From Hand-Written Script to CLI in 40 Hours

Karpathy’s gist: April 4, 2026 · 5,000+ stars · 5,000+ forks
llmwiki-cli: npm install -g llmwiki-cli · github.com/doum1004/llmwiki-cli

The Problem with RAG

Most AI + document workflows are RAG: upload files, retrieve relevant chunks at query time, generate an answer. Karpathy identified the fundamental flaw: “there’s no accumulation.” Ask something that requires synthesizing five documents, and the LLM pieces it together from scratch every time. No cross-references are built. No contradictions are flagged. No insights persist beyond the conversation.

The LLM Wiki Answer

Instead of querying raw documents, let the LLM incrementally build and maintain a persistent wiki — structured, interlinked markdown files between you and your raw sources.

Every time a new document is added, the LLM:

1. Reads the document, extracts key information
2. Writes a summary page (wiki/sources/...)
3. Reads existing concept and entity pages
4. Synthesizes across documents, updates concept pages
5. Updates entity pages (people / orgs / products)
6. Updates wiki/index.md and appends to wiki/log.md

One document touches 10–15 wiki pages on average. Knowledge compounds — bricks added to a wall, not dust piling in a corner.

Three Layers

Raw (raw/): Your source documents. Immutable. LLM reads but never modifies.

Wiki (wiki/): LLM-generated and maintained markdown pages.

• sources/ — one summary page per document
• concepts/ — ideas, frameworks, theories
• entities/ — people, organizations, products
• synthesis/ — cross-cutting analysis
• index.md — master catalog (updated on every ingest)
• log.md — append-only timeline (grep-friendly prefixes)

Schema (SCHEMA.md): Tells the LLM how the wiki is structured and what workflows to follow. What makes an LLM a disciplined wiki maintainer instead of a generic chatbot.

llmwiki-cli

npm install -g llmwiki-cli     # gives you `wiki` command
wiki init my-wiki --name "Research Notes" --domain "machine learning"

Design philosophy: “CLI is the hands, LLM is the brain.”

The CLI never calls any LLM API. It only does file I/O: read, write, search, health-check. Synthesis, cross-referencing, update decisions — all done by Claude Code / Codex / Cursor.

# Core workflow
wiki write wiki/sources/paper.md <<JSON
{"title":"Paper Title","tags":["ML"],"content":"Summary...\n\nSee also [[attention]] and [[transformers]]."}
JSON

wiki search "attention mechanism"
wiki backlinks wiki/concepts/attention.md
wiki lint                    # find orphans, broken links, stale pages
wiki search "..." --all      # search across multiple wikis

RAG vs LLM Wiki

Aspect	RAG	LLM Wiki
On query	Retrieve + generate	Read compiled wiki
On new document	Index for retrieval	LLM actively updates 10-15 pages
Cross-document relations	Rediscovered every query	Already embedded in wiki
Contradiction detection	None	wiki lint
Knowledge accumulation	Search results	Wiki gets richer on every ingest
Infrastructure	Embedding model + vector DB	Markdown files + any LLM

Summary

Karpathy’s LLM Wiki idea clarified the knowledge management problem: RAG is re-discovering on every query; LLM Wiki is compiled once and updated incrementally. llmwiki-cli productized it into an npm CLI where wiki handles files and Claude/Codex does the synthesis. One document, 10–15 pages updated, knowledge that compounds.

© 2026 Author: Mycelium Protocol