Karpathy LLM Wiki评测：用AI自动维护个人知识库
最近 Andrej Karpathy 发布了一份 Gist，标题名为 LLM Wiki。
这份 Gist 探讨的是一种知识管理策略：由 LLM 长期维护一套 Wiki，然后在这套 Wiki 基础上持续提问、梳理和更新内容。
目前用户使用 LLM 处理资料的主流流程大致如下：上传一批 PDF、网页、笔记，提出一个问题，让模型临时检索相关片段，并在当前对话中拼凑答案。这种方式可行，但存在几个明显短板：每次都需要重新翻阅原始资料，模型每轮都要重新构建上下文，历史问题无法沉淀为结构化知识，文档之间的关联也无法自动生成。
LLM Wiki 正好补上了中间缺失的这一层。
先将知识沉淀为 Wiki，再在 Wiki 上开展后续工作
该 Gist 的核心思想是：不要每次提问都从零开始在原始资料中挖掘知识，而是先将知识整理到一套持续维护的 Wiki 中。
这样一来，系统会增加一个中间层：
raw sources：原始资料（文章、论文、图片、数据文件）保持不变。wiki：由 LLM 维护的一套 Markdown 页面，负责摘要、交叉引用、主题页、人物页、概念页。schema：一份规则文件（例如CLAUDE.md或AGENTS.md），告诉 LLM 如何正确维护这套 Wiki。
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 页面、对比表、幻灯片、图表、画布。这一步的作用是让“提问结果”也开始沉淀为结构化内容。
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 讲的是“结构会积累”，但结构一旦积累错误，错误内容也会一并沉淀。因此这类系统如果要落地到团队知识库，后续大概率需要补充：事实核查层、可信度标记、引文约束、高风险页面的审核机制。
2. 这套方法还会朝训练数据方向延伸
还有评论提到一种更激进的延伸：不只拿 Markdown Wiki 做检索和综合，而是继续把这些页面整理成结构化训练数据，然后用于本地微调模型。这个方向很激进，但它引出了另一个问题：LLM 到底该如何参与长期知识积累？是只在查询时临时调取，还是逐步将知识压缩进一种长期结构里？
这份 Gist 的深层意图
如果只用一句话概括：Karpathy 正在试图将“知识检索”转变为“知识编译”。
这件事会直接改变你组织资料的方式、你与 LLM 的协作模式，以及一个知识库是否会越用越有价值。
如果你最近也在使用 Obsidian、Notion、Roam、Logseq 这类工具积累长期材料，这份 Gist 值得认真阅读。它讨论的是一套不同的知识工作流：你负责选资料、提问题、做判断，LLM 负责整理、链接、维护和持续更新。这套分工一旦成立，知识库将从“存放资料的地方”逐渐演变为一个可持续生长的系统。