Karpathy 的 LLM Wiki：让 AI 把知识编译成会生长的第二大脑

你把 20 份 PDF 扔进 NotebookLM，问了几个问题，答案看起来不错。第二天再问一个更细的问题，AI 又从零开始检索、拼接、猜测。没有积累。没有共识。没有记忆。

Karpathy 的 LLM Wiki 想解决的就是这个问题：不要让 LLM 每次都临时回答。让它把知识编译成一个持续更新的 Markdown wiki。

RAG 是运行时检索。LLM Wiki 是把知识提前编译成可读、可改、可追踪的中间层。

它到底是什么

LLM Wiki 不是一个固定产品。Karpathy 的 gist 更像一份工作流说明，可以贴给 Claude Code、Codex、Cursor 或 ChatGPT，让它帮你搭一个适合当前项目的知识系统。

核心结构只有三层：

• raw sources：原始资料。PDF、文章、会议记录、截图、表格都放这里。LLM 只能读，不能改。
• wiki：LLM 维护的 Markdown 页面。里面有摘要、人物、概念、决策、冲突、索引和交叉引用。
• schema：规则文件。Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md，Cursor 用 .cursorrules。它告诉 LLM 文件怎么放、页面怎么写、什么时候更新索引。

你负责丢资料、提问题、判断方向。LLM 负责整理、链接、更新、记账。

Karpathy 的比喻很准：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

它比普通 RAG 强在哪里

普通 RAG 的问题不是不能用，而是每次都在现场拼答案。

LLM Wiki 的优势在于它会积累：

• 新资料进来后，LLM 不只写摘要，还会更新旧页面
• 新资料推翻旧结论时，wiki 会记录冲突，而不是把两种说法混在一起
• 常用概念会变成独立页面，被其它页面链接
• 你问出来的高价值分析，可以反写回 wiki
• index.md 先承担导航职责，小规模时不需要向量数据库

这不是“更聪明的搜索”。这是把搜索结果沉淀成下一次可复用的结构。

适用场景

长期研究一个主题

你在几周或几个月里读论文、报告、访谈和竞品材料。普通聊天会把上下文打散。LLM Wiki 会把每次阅读变成 wiki 的一次增量更新。

产品和项目知识库

需求、会议纪要、客户反馈、技术决策经常散落在 Slack、文档和脑子里。LLM Wiki 可以把它们编译成当前状态、决策记录、开放问题和风险列表。

读书和课程笔记

每读一章，LLM 更新人物、概念、主题和争议。最后得到的不是一堆摘要，而是一个能追踪关系的伴读 wiki。

AI Agent 的长期上下文

多次会话做同一个项目时，最痛苦的是重复解释。LLM Wiki 把“上次做了什么、为什么这么做、现在卡在哪里”写进可读文件，下一次会话直接从 wiki 接上。

什么时候别用

资料很少，只是临时问答，别搭 wiki。直接把文档塞进上下文就够了。

资料质量很差，也别急着自动整理。LLM 会把脏资料整理得更像真的。先清理来源，再让它编译。

强事实、强合规场景要保留人工复核。LLM Wiki 可以记录来源和冲突，但不能替你承担事实责任。

还有一个现实边界：wiki 会膨胀。几百页 Markdown 之后，单个 index.md 不再够用，你需要本地搜索、分层索引，或者类似 qmd 这样的 Markdown 搜索工具。

最小目录结构

先别上复杂系统。新建一个 docs/wiki 目录就能跑。

docs/
  raw/
    sources/
    assets/
  wiki/
    index.md
    log.md
    current-status.md
    concepts/
    entities/
    decisions/
  AGENTS.md

如果你用 Claude Code，把 AGENTS.md 换成 CLAUDE.md。规则文件的内容比文件名更重要。

给 AI 的初始化提示

把 Karpathy 的 gist 链接发给你的 Agent，然后让它把模式实例化到当前项目。

Read https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
and set up an LLM Wiki for this project.

Use this structure:
- docs/raw for immutable source files
- docs/wiki for generated Markdown pages
- AGENTS.md for the maintenance rules

Before editing, propose the page conventions, log format, and ingest workflow.
After approval, create the initial files.

这里的关键不是“生成文件”。关键是让 Agent 先写规则。没有 schema，LLM 只是热心整理。写了 schema，它才会变成稳定的 wiki 维护者。

日常怎么用

LLM Wiki 的使用只有三个动作：ingest、query、lint。

Ingest：加入新资料

你把新资料放进 docs/raw/sources，然后告诉 Agent：

Ingest docs/raw/sources/customer-interview-2026-05-17.md.

Do not overwrite raw files.
Update the relevant wiki pages, index.md, current-status.md, and log.md.
Flag contradictions instead of silently resolving them.

一次 ingest 可能会改 5 到 15 个 wiki 页面。这是正常的。价值就在这里：新资料不是孤立摘要，而是进入已有知识网络。

Query：基于 wiki 提问

不要让 AI 直接读 raw 资料回答。先让它读 index.md，再进入相关页面。

Using docs/wiki/index.md as the entry point, answer:
What changed in our pricing assumptions after the latest customer interviews?

Cite the wiki pages you used.
If the answer reveals a new decision or unresolved question, add it to the wiki.

好答案不应该死在聊天记录里。比较、判断、决策、开放问题，都应该反写回 wiki。

Lint：体检 wiki

每隔几次会话跑一次健康检查。

Lint docs/wiki.

Find:
- stale claims
- contradictions between pages
- orphan pages
- concepts mentioned often but missing their own page
- pages that need source citations

Propose fixes before editing.

这一步决定 wiki 会不会变成垃圾堆。长期知识库失败，通常不是因为没人写，而是没人维护连接和一致性。这个活适合交给 LLM。

一个实战例子：竞品研究

假设你在研究三个 AI 编程工具。你可以这样组织：

docs/raw/sources/
  tool-a-pricing.md
  tool-b-docs.md
  tool-c-review-notes.md

docs/wiki/
  index.md
  current-status.md
  concepts/context-management.md
  concepts/agent-permissions.md
  entities/tool-a.md
  entities/tool-b.md
  entities/tool-c.md
  decisions/positioning-gap.md

第一次 ingest 后，LLM 生成三个工具页和两个概念页。

第二次你问：

Which competitor is weakest for enterprise onboarding, and why?

Agent 先读 index.md，再读三个 entity 页面和相关 concept 页面。它给出结论后，把“enterprise onboarding gap”写入 decisions/positioning-gap.md。下次你再研究新工具，这个判断会被复用，而不是重新发现。

可选工具

小规模时，文件系统加 Markdown 就够了。

变大之后再加工具：

• Obsidian：浏览图谱、反向链接、Dataview 查询
• Obsidian Web Clipper：把网页保存成 Markdown
• Git：查看 wiki 演化历史，回滚错误更新
• qmd：本地 Markdown 搜索，适合 index.md 开始变大的时候
• Marp：从 wiki 直接生成演示文稿

不要一开始就堆工具。先让三层结构跑起来。

你需要守住的规则

第一，raw 永远不可变。LLM 不能“顺手修正”原始资料。

第二，每次更新必须写 log.md。没有日志，wiki 很快会失去时间线。

第三，冲突要显式记录。不要让 LLM 替你把矛盾抹平。

第四，wiki 页面要短。一个页面只承担一个概念、一个实体或一个决策。页面太长，就拆。

第五，先直接读，再考虑 RAG。Karpathy 的判断很实用：中等规模之前，index.md 加 Markdown 页面往往已经够用。复杂检索应该是增长后的补救，不是第一步。

---

LLM Wiki 的核心不是“让 AI 记住更多”。它是把 AI 的每次阅读和每次回答，变成下一次可以继承的知识结构。

下次你想把一堆资料丢进聊天窗口时，先停一下。你要的是一次答案，还是一个会生长的知识库？

Karpathy gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 实践实现: https://github.com/Ss1024sS/LLM-wiki