Karpathy 的 LLM Wiki：让 LLM 帮你维护一套个人 Wiki

最近 Karpathy 发了一份 gist，标题就叫 LLM Wiki。

它讨论的是一种知识管理方式：

让 LLM 持续维护一套 wiki，再在这套 wiki 上继续提问、整理和更新。

现在很多人用 LLM 处理资料，常见路径差不多是这样：

• 上传一堆 PDF、网页、笔记

• 问一个问题

• 让模型临时检索相关片段

• 再在当前会话里拼答案

这条路能用，但也有几个明显问题：

• 每次都要从头翻资料

• 模型每次都要重新拼接上下文

• 上次问过的问题不会沉淀下来

• 文档之间的关系也不会自己长出来

LLM Wiki 补的，就是中间这层。

先把知识整理成 wiki，再在 wiki 上工作

gist 的核心意思是：

不要每次提问时都重新从原始资料里发现知识，先把知识整理进一套持续维护的 wiki。

这样一来，系统会多出一层中间层：

1. raw sources 原始资料，文章、论文、图片、数据文件，保持不变

2. wiki 一整套由 LLM 维护的 markdown 页面，负责总结、交叉引用、主题页、人物页、概念页

3. schema 一份告诉 LLM 这套 wiki 该怎么维护的规则文件，例如 CLAUDE.md 或 AGENTS.md

Karpathy 在这里强调了一点：

原始资料是 source of truth，wiki 是中间产物。 平时读的是 wiki，但 wiki 本身要持续回看、持续修、持续吸收新资料。

这跟传统 RAG 的差别也就出来了：

• RAG 每次问问题都重新找片段

• LLM Wiki 先把知识整理成稳定页面，再在这些页面上继续问

换句话说，它把“当场拼答案”改成了“先把知识库存起来，再在库上工作”。

这样做以后，体验会变在哪里

因为 wiki 已经先整理过一轮，很多东西就不需要每次再从零开始：

• 交叉引用已经建好

• 冲突信息已经标出来

• 主题总结已经积累下来

• 之前问过的问题，也可以继续沉淀回 wiki

所以后面的工作不再是反复“重新理解原始资料”，而是在已有结构上继续往下长。

Karpathy 还给了一个很形象的比喻：

• Obsidian 像 IDE

• LLM 像程序员

• wiki 像代码库

这个比喻很容易把它的工作方式讲清楚。

它适合什么场景

Karpathy 在 gist 里列了不少例子：

• 个人知识管理

• 长期研究某个主题

• 边读一本书边建角色、主题、线索页

• 团队内部 wiki

• 竞品分析、尽调、旅行规划、课程笔记

这些场景有个共同点：

• 资料会不断累积

• 问题不会只问一次

• 人想要的通常不只是“找到片段”，而是“把结构慢慢整理出来”

如果只是临时查一个问题，RAG 已经够用。 但如果一个主题会反复碰、反复问、反复补材料，wiki 这层就开始有意义了。

实际跑起来，核心就是 ingest / query / lint

这份 gist 没有把流程写得很复杂，核心就是三步。

1. Ingest

把一份新资料放进 raw sources，让 LLM 去处理。

常见动作包括：

• 读资料

• 跟你讨论重点

• 生成摘要页

• 更新 index

• 更新相关实体页和概念页

• 记进 log

Karpathy 还提到，他个人更喜欢一次 ingest 一份资料，并且自己在旁边看着，让 LLM 在这个过程中决定该强调什么。

2. Query

后面再问问题时，不是直接从 raw sources 临时翻，而是先去 wiki 里找相关页，再综合回答。

而且回答本身也不一定只是一段聊天回复，它还可以继续回写成：

• markdown 页面

• 比较表

• slide deck

• chart

• canvas

这一步的作用，是让“提问结果”也开始沉淀。

3. Lint

第三步是定期健康检查 wiki。

Karpathy 列出来的检查项包括：

• 页面之间有没有冲突

• 有没有旧结论被新资料推翻

• 有没有孤立页

• 有没有该有但还没建的概念页

• 有没有缺交叉引用

• 哪些地方可能需要补新资料

wiki 不是建完就结束，它也需要持续 lint。

index.md 和 log.md 为什么重要

gist 里专门把 index.md 和 log.md 单独拿出来讲。

它们解决的是两类完全不同的问题。

index.md

这是内容导向的目录。

里面放的是：

• 页面链接

• 一行摘要

• 分类

• 可选元数据

模型回答问题时，可以先读 index，再决定要深入哪些页面。

Karpathy 提到，这套方式在大约 100 个 source、几百个页面的规模下，已经能跑得比较顺，甚至不一定非得上 embedding 检索系统。

log.md

这是时间导向的记录。

里面记的是：

• 什么时候 ingest 了什么

• 什么时候做了 query

• 什么时候跑了 lint

如果每条记录的前缀格式统一，它甚至可以直接交给 unix 工具处理。

这个点很小，但会直接影响整套方法能不能长期跑顺。

为什么这套方法会成立

很多人最后放弃维护 wiki，通常是因为：

• 维护太麻烦

• 更新交叉引用太烦

• 新资料来了还得改很多旧页

• 一旦规模变大，维护成本涨得比价值还快

而 LLM 在这里的优势恰好落在另一侧：

• 不会嫌烦

• 不会漏掉交叉引用

• 可以一次改十几个文件

• 维护成本接近于零

于是分工就变得很清楚：

• 人负责找资料、决定看什么、问对问题、判断材料意味着什么

• LLM 负责整理、归档、链接、更新、维护一致性

评论区提到的两个现实问题

评论区里还有两个补充，和正文放在一起看会更完整。

1. 知识整理会放大事实错误

有位评论者提了一个很现实的问题：

如果这套 wiki 是给工程团队内部用的，而里面写的是：

• API 参数定义

• 版本依赖约束

• 时间线记录

这种对精度要求很高的内容，那么 LLM 在中间产物里的小错误，会被放大成整个团队的知识污染。

他提到，现在最笨但最稳的办法还是人工逐条核对。 一旦人工核对成本太高，整套“让 LLM 帮你维护 wiki”的收益就会被抵消掉。

这个问题提得很准。 gist 里讲的是“结构会积累”，但结构一旦积累错了，错的内容也会一起沉淀。

所以这类系统如果真要落到团队知识库，后面大概率还得补：

• 事实核查层

• 可信度标记

• 引文约束

• 高风险页面人工 review

2. 这套方法还会继续往训练数据方向走

还有评论提到一种更激进的延伸：

不是只拿 markdown wiki 做检索和综合，而是继续把这些页面整理成结构化训练数据，再去本地微调模型。

这个方向很激进，但它把另一个问题带了出来：LLM 到底该怎样参与长期知识积累。

是只在查询时临时取用，还是逐步把知识压缩进一种长期结构里？

这份 gist 后面那层意思

如果只用一句话概括，我会这么说：

Karpathy 在试图把“知识检索”改成“知识编译”。

这件事会直接影响：

• 你怎么组织资料

• 你怎么和 LLM 协作

• 一个知识库会不会越用越值钱

如果你最近也在用 Obsidian、Notion、Roam、Logseq 这类工具记长期材料，这份 gist 值得读一遍。

它讨论的是一种不同的知识工作流：

• 你负责选资料、提问题、做判断

• LLM 负责整理、链接、维护和持续更新

这套分工一旦成立，知识库会从“存资料的地方”慢慢变成一个可持续生长的系统。