跳到主要内容

教程

Karpathy LLM Wiki 是什么?用 Claude Code 自己搭一个

用图解说明 Andrej Karpathy 的 LLM Wiki、大家实际在用的现成实现,以及可直接复制的 Claude Code 配置。

Qi-Xuan Lu更新 7 分钟阅读
查看实际操作画面

关于这篇指南

01

概念

02

读过 Karpathy 的 LLM Wiki,想用 Claude Code、Codex 或 Obsidian 真正搭出一个的人

03

7 分钟阅读

01

LLM Wiki 是一个由 AI 根据你的来源持续更新的 Markdown 页面文件夹,答案会积累,不必每次从头整理。

02

它有三层(来源、wiki、schema)和三个任务(ingest、query、lint)。

03

多数人从现成项目开始;你也可以用 Claude Code 加一个空文件夹自己搭。

01

Karpathy 的 LLM Wiki 是什么

2026 年 4 月,Andrej Karpathy 在 GitHub gist 发表了《LLM Wiki》。这个做法是把来源整理成互相链接的 Markdown 页面,让后续问题可以先从维护中的综合页面开始,不必每次都从头搜索整批资料。来源变更时仍要重新读取并检查受影响的页面;重要结论也可能需要回到引用来源核对。

本文引用 Karpathy 的公开说明作为这个模式的来源,不代表 Karpathy 为 Wenlan 背书。

Schema

CLAUDE.md 或 AGENTS.md:wiki 怎么组织

AI 每个任务都按这份规则做

原始来源

文章、论文、笔记、文件

只读不改

ingest

Wiki

每个主题一页 Markdown,互相链接

index.md · log.md

query

回答

附上用到的页面与来源链接

lint:找出矛盾、过时说法、没有被链接的页面

LLM Wiki 的三层结构与三个任务。
先看完整示例,不必安装

02

三个任务:ingest、query、lint

对 wiki 的每一次修改,都属于这三个任务之一。分开做,提问就不会偷偷改写页面。

  • Ingest(加入来源):读新来源、写一页摘要、更新受影响的页面,再更新 index.md 和 log.md。
  • Query(提问):先读 index.md,只打开需要的页面,回答时附上链接。好的答案可以存成新页面。
  • Lint(健康检查):找出互相矛盾的页面、被新来源取代的说法、没有被链接的页面,以及还没有页面的主题。

03

LLM Wiki 和 RAG 的区别

RAG 会针对每个问题检索相关来源片段;来源集合与索引仍可继续使用,同一份资料也可能在不同问题中再次被检索。LLM Wiki 则把持续维护的综合内容留在可打开检查的页面里,让后续查询可以从页面开始。新增或变更的来源仍要重新整理,重要结论也可能需要回到引用核对。大型 wiki 仍可用搜索找到合适页面。

RAG

  1. 提问
  2. 检索来源片段
  3. 回答

来源仍可查询;片段可能再次出现。

LLM Wiki

  1. 来源
  2. 整理并维护页面
  3. 提问
  4. 先看相关页面

来源变化时要更新页面。

RAG 会按问题检索来源片段,同一内容可能再次出现;Wiki 保留维护中的页面,来源变化时仍要更新。

04

现成的 LLM Wiki 实现

多数人是从现成项目开始。GitHub 上名称或描述含“llm-wiki”的仓库超过 6,400 个,大多在 2026 年 4 月之后创建;星数最多的 nashsu/llm_wiki 和 claude-obsidian,都超过 15,000 颗星(2026 年 10 月)。

项目是什么适合你,如果你
Karpathy 的 gist原始说明,不是软件想自己动手配置(见下方)
nashsu/llm_wiki跨平台桌面 app想要一个独立 app 整理文档
AgriciDaniel/claude-obsidianClaude Code + Obsidian 的配置笔记本来就放在 Obsidian
Astro-Han/karpathy-llm-wiki给 Claude Code、Cursor、Codex 的 Agent Skills 套件想把这个模式装成 AI 技能
Wenlan桌面 app,附 MCP server同时用好几个 AI 工具,希望页面保持最新、又不会覆盖你的修改

05

用 Claude Code 15 分钟搭一个

你需要 Claude Code(或 Codex、Cursor 等能改文件的 AI 工具)和一个空文件夹。建好下面的结构并执行 git init,AI 改了什么都看得到、也能恢复。想阅读页面,用 Obsidian 或任何 Markdown 编辑器打开文件夹即可。

文件夹结构

my-wiki/
  CLAUDE.md        # schema:AI 要遵守的规则
  raw/             # 你的来源;AI 不会修改
  wiki/
    index.md       # 每页一行
    log.md         # 每次 ingest、query、lint 一行
    sources/       # 每份来源一页摘要
    topics/        # 每个主题、人物或概念一页
已经有 Obsidian vault?把它变成 LLM Wiki

06

可直接复制的 CLAUDE.md

整个系统就是这份文件:Claude Code 读 CLAUDE.md,Codex 则存成 AGENTS.md。“My notes”这条规则,能防止下一次更新覆盖你手动修正过的段落。

接着在 Claude Code 里输入 ingest raw/<文件名>、query <问题> 或 lint。先放两三份同一主题的来源,每做完一个任务就看一次 git diff。

CLAUDE.md

# LLM Wiki

This folder is a wiki you maintain from my sources.

## Layout
- raw/: my sources. Read them. Never edit, move, or delete them.
- wiki/sources/: one summary page per source, named after the source.
- wiki/topics/: one page per topic, person, or idea.
- wiki/index.md: every page, one line each: [[page]] - summary.
- wiki/log.md: one line per job: ## [YYYY-MM-DD] ingest | <title>

## Page rules
- Start each page with a two- or three-sentence summary.
- Every claim links to the source page it came from.
- Link related pages with [[wiki links]].
- If a new source contradicts a page, say so on the page and cite both.
- Never rewrite text under a "## My notes" heading. I write that part.
- Write pages in Simplified Chinese.

## Jobs
- ingest <file>: summarize it, update affected topic pages,
  update index.md, and log it.
- query <question>: read index.md first, open only the pages you need,
  and answer with links. Offer to save a useful answer as a page.
- lint: list contradictions, outdated claims, orphan pages, and
  missing pages. Fix only what I approve.

07

先用完整示例试做,不必先安装

你的 wiki 能回答项目问题、指出依据,并在来源变化时提醒旧答案不能照用吗?先用这组虚构资料,在你现有的 AI 工具中试一次。以下是人工编写的教学输入与参考答案,不是 Wenlan 运行记录、客户成果或性能对比。

新建一个可随时删除的测试文件夹,按下方文件名分别保存三个 Markdown 文件,让 Agent 只读访问。生成的 wiki 答案另存,不要让 Agent 修改原始来源。API 名称与英文测试数据保持一致,便于三种语言的读者核对同一个问题。

提问:“只根据 api-v1.md、decision-07.md 和 runbook-v1.md,整理一页重试规则。每条规则标明来源文件名,区分重试次数与总尝试次数,列出尚未确定的信息。不要用常识补齐文档没写的内容。”

完整测试资料:分别保存这三个文件

# api-v1.md — fictional API specification, revision 1
GET /reports: after a failed first attempt, allow up to 3 retries.
POST /payments: do not retry automatically.

# decision-07.md — fictional client decision
Use the API's GET retry cap of 3 to limit repeated requests.
Automatic POST retries are disabled because duplicate payments are unsafe.

# runbook-v1.md — fictional operator note
Record the endpoint, attempt number, and final failure in the local test log.
The request timeout has not been decided.

08

核对答案,再改一份来源

对照下面的参考答案,不必逐字相同,但四项结论都要有正确依据;超时时间必须保留“尚未指定”。亲自打开被引用的文件:看似合理的引用,不代表真的支持那句话。

然后按下方内容新增 api-v2.md,让它替代 api-v1.md。第二次提问:“以 api-v2.md、decision-07.md 和 runbook-v1.md 作为当前来源,把 api-v1.md 仅作历史参考,对照之前的 wiki 答案与当前证据,找出过时结论,保留‘最多重试 1 次’与‘3 次’尚未解决的冲突;不要默默修改 decision-07.md,也不要替这项冲突下结论。”

如果普通文件加上你的 Agent 已经能清楚完成,就保留这个简单方法。当维护来源页面、让多个 AI 工具共享查询成为重复工作时,再评估 Wenlan。来源链接不等于语义已验证;另存替代来源也不等于更新已链接来源,仍要查看实际页面状态。这个练习不能证明 Wenlan 的准确率、节省时间、自动维护效果或今后复用。

参考答案、更新后的来源与应有的审核记录

# Request retry policy — reference answer, revision 1
GET: at most 3 retries after the first attempt (4 attempts total).
Source: api-v1.md; decision-07.md.
POST: no automatic retry.
Source: api-v1.md; decision-07.md.
Log: endpoint, attempt number, final failure.
Source: runbook-v1.md.
Timeout: not specified. Ask the owner; do not invent a value.
Source: runbook-v1.md.

# api-v2.md — fictional replacement for api-v1.md
GET /reports: after a failed first attempt, allow at most 1 retry.
POST /payments: do not retry automatically.

# Review note — before accepting a revised answer
The old GET answer is stale: api-v2.md now allows only 1 retry.
decision-07.md still says 3. Preserve and flag this conflict.
Do not report the old 3-retry policy as settled current guidance.
POST, logging, and the unknown timeout are unchanged.
Ask the decision owner to reconcile decision-07.md with api-v2.md.
查看 Wenlan 的来源与审核边界

09

自己搭的 LLM Wiki 会在哪里卡住

上面的配置适合一个人、一个 AI 工具、几十份来源。规模变大后:

  • 来源变了,页面没变。要等下一次 lint 才知道哪些页面过时。
  • 除非每个 AI 工具每次都遵守“My notes”规则,否则你手动改过的内容会被覆盖。
  • 每个 AI 工具都要一份自己的规则文件,久了内容就不一致。
  • 超过几百页后,index.md 会长到塞不进上下文。
  • AI 对话里的决定,不手动复制就进不了 raw/。

10

在 Wenlan 中使用 LLM Wiki

Wenlan 是一个开源 app,替你执行同样的模式。它把文档、笔记和 AI 对话整理成附来源链接的页面,来源变了就更新页面,而且不会覆盖你的修改。Claude Code、Codex 和其他 AI 工具读的是同一组页面。

/capture 存下对话中的决定,/distill 创建或更新主题页面,/pages 打开页面,/brief 和 /recall 只加载下一次对话需要的内容。

Wenlan 工作流——需要已安装并连接的客户端

/brief <topic>
/recall <question>
/capture <decision + why>
/handoff
/distill <topic>
/pages <topic>
查看完整日常工作流

并排比较

用实际使用的维度比较。自建文件夹 + CLAUDE.md 更好的地方,我们直接写出来。

维度Wenlan自建文件夹 + CLAUDE.md
配置安装 app 并连上你的 AI 工具一个文件夹、一份 schema 文件和 git
来源改变时你要求时更新,或在后台自动更新下一次 lint 才发现(如果有跑)
你自己的修改保留;更新不会覆盖你改过的页面只有 AI 遵守 schema 规则时才保留
多个 AI 工具Claude Code、Codex 等共用同一个 wiki每个工具一份规则文件
AI 对话作为来源可以直接从对话存下决定手动复制到 raw/

让 wiki 自己保持最新

Wenlan 把你的文档、笔记和 AI 对话整理成附来源链接的页面,来源变了就更新,而且不会覆盖你的修改。

在实际画面中,核对引用与修订

以下来自 Wenlan App 的 Tally 发票项目演示录像。放大实际画面,查看一条引用如何回到来源,以及页面修订提出了哪些变化。

1. 从 SQLite 结论回到原始依据

Wiki 说明 Tally 为单人应用选择 SQLite。展开的引用显示「SQLite for Single-User App」来源、摘要和「Open memory」入口。再次使用这个决策前,先比较句子与来源是否一致。

Wenlan 实际录制的 Tally Wiki,SQLite 引用已展开,显示来源摘要和 Open memory 入口。

滑动图片,查看放大后的细节。

打开原图
Tally 演示录像:Wiki 页面与来源浮层。来源链接让结论可检查;是否真正支持该句,仍需亲自核对。

2. 先看增删内容,再决定是否接受

Project notes 修订删除「数据库尚未决定」的旧文字,提出使用 SQLite 的新表述。画面保留增删差异、先前版本,以及 Skip/Approve 操作。先检查新文字和引用,再决定保留哪些内容。

Wenlan 实际录制的 Project notes 修订,显示增删文字、先前版本,以及 Skip 和 Approve 操作。

滑动图片,查看放大后的细节。

打开原图
Tally 演示录像:一项待审核的页面修订。这张画面没有显示已批准的结果,也不能证明每句修改都正确。

常见问题

Karpathy 的 LLM Wiki 是什么?+
Andrej Karpathy 描述了一种由 AI 根据来源撰写并维护的个人 wiki:把来源整理成互相链接的 Markdown 页面,后续问题可以从这些页面开始。来源变更时仍要重新读取并检查受影响的页面。引用他的说明不代表他为 Wenlan 背书。
LLM Wiki 和 RAG 是同一种东西吗?+
两者做法不同。RAG 会针对每个问题检索相关来源片段,同一份资料可能再次被检索。LLM Wiki 把持续维护的综合内容留在可打开检查的页面里;来源变更时仍要重新整理,重要结论也可能需要回到引用核对。大型 wiki 也可以搜索页面。
怎么用 Claude Code 搭 LLM Wiki?+
建一个文件夹,raw/ 放来源、wiki/ 放页面,加一份 CLAUDE.md 说明结构、页面规则和 ingest、query、lint 三个任务,再执行 git init。在文件夹里启动 Claude Code,先加入两三份来源。
搭 LLM Wiki 一定要用 Obsidian 吗?+
不用。wiki 就是纯 Markdown,任何编辑器都能用。Obsidian 适合用来阅读:wiki 链接可以点,关系图谱能看出页面之间的关系。
Karpathy 的 LLM Wiki 在 GitHub 哪里?+
它是 karpathy 在 GitHub gist 上的一篇《LLM Wiki》,链接在下方参考资料。它是模式的说明,不是可以安装的仓库;nashsu/llm_wiki、claude-obsidian 等项目把它做成了软件。
LLM Wiki 能取代代码搜索或官方文档吗?+
不能。LLM Wiki 不能取代代码搜索、当前的源代码、测试结果或工具本身的文档,软件现在怎么运作仍以这些为准。同样的主题在很多次对话或多个工具之间反复出现时,它才值得。

分享这篇指南