摘要：很多人的个人知识库，问题不在输入，而在维护：资料越攒越多，结构越用越散；AI 能临时回答，却留不下长期积累。Karpathy 开源的
LLM Wiki，把“知识库维护者”这个角色交给了 LLM，让它按规则持续摘要、互链、回写、查错，把知识库从静态存档变成会自我更新的feedback loop。我们一起看看如何搭建一套会持续自我维护的知识工程框架
很多人的个人知识库，难的不是搭起来，而是持续维护。
如果你也用过 Obsidian、Notion、收藏夹、剪藏工具，大概率都熟悉这种失控感：资料越攒越多，回头却找不到，也说不清彼此的关系，更不知道某个旧结论有没有过时。
后来很多人干脆换了一条路：不整理了，直接把文件丢给 AI。
这当然比手工翻快得多，但新的问题也很快出现了：它能答，却不会沉淀；它能综合，却不会持续更新；你今天问过的结论，明天大概率还得再问一遍。
Karpathy 这次真正击中的，不是又一套 Obsidian 工作流，而是个人知识库里最贵、也最容易被忽略的那一环：
你缺的不是更强的搜索，而是一个愿意持续做整理、链接、更新、查错的维护者。
如果只记住一句话：
RAG 更像临时检索，LLM Wiki 更像持续编译。
一、知识库为什么会“腐烂”
补资料不难，难的是维护。
有个很典型的例子：Obsidian 里攒了几百篇笔记，明知道里面有好东西，回头却找不到；试过补标签、补链接、重分目录，两周后还是放弃。这几乎就是大多数个人知识库失败的缩影。
你不断剪藏新文章，存新截图，记新会议纪要，但没有人持续做下面这些动作：
-
给旧资料写可靠摘要
-
把同一主题的内容连起来
-
发现两个页面里已经出现矛盾
-
把零散结论沉淀成专题页
-
把旧判断用新资料校正
这些事不是做不了，而是很难长期做。它们太像“知识后勤”：不刺激，不显眼，却很耗时，有点像软件工程里的回归测试、文档补全、依赖升级，理论上都重要，实际上最容易被拖到以后。
这也是为什么传统的个人知识管理工具，往往都有同一个结构性问题：采集越来越快，维护越来越慢。
后来 AI 文件上传又补上了另一半能力：你不需要真的整理好，也能直接问。可这条路解决的是“回答速度”，不是“知识积累”。模型能临时综合，却不会自动记住你上次的结论、修正旧判断，更不会顺手把这次的新结果写回一个长期可用的结构里。
所以很多人现在其实夹在两个低效之间：
-
手工知识库，维护太重，
-
依赖人，容易过时
-
AI 问答知识库，沉淀太弱
Karpathy 这套方法的价值，就在于它试图把这两个问题一次接上。
二、Karpathy 真正开源了什么
这次最容易被误读的一点，是把它看成“Obsidian 使用技巧”。
Obsidian 在这套方法里更像前端，而不是本体。
Karpathy 在 昨天 4.04 日开源的 llm-wiki.md 里，真正给出来的是一张非常清楚的系统蓝图。我们来一起拆解下，核心点是：
-
三层架构
-
三个核心动作
-
两个关键文件
1. 三层架构：raw / wiki / schema
第一层是 raw/。
这是原始资料层。网页文章、论文、PDF、图片、数据文件、播客转录，都先放进这里。原则只有一个：它是事实层，只读，不改。
第二层是 wiki/。
这是 LLM 维护的知识层。摘要页、概念页、实体页、专题页、对比页，都在这里。你可以读，可以检查，但尽量不要自己去当主要维护者。LLM 的职责，就是持续维护这一层。
第三层是 schema。
也就是 AGENTS.md、CLAUDE.md 这一类规则文件。它定义目录结构、命名规范、引用方式、导入流程、问答回写方式和 lint 规则。没有这一层，LLM 很容易退化成一个临时聊天工具；有了这一层，它才更像一个有纪律的知识库维护者。
如果换成软件工程语言，其实非常好理解：
-
•
raw/像src/ -
•
wiki/像编译产物 -
•
schema像构建规则和工程约束 -
LLM 像编译器加维护者
-
Obsidian 更像 IDE
“编译器”这个类比，是这套方法里最有启发性的地方。
一旦你接受这个类比，你对知识库的期待就会变：它不再只是一个装资料的仓库，而更像一个会持续重构、持续修正、持续增量编译的系统。
2. 三个核心动作：ingest / query / lint
第一步是 ingest。
新资料进来，不是只存好就结束，而是触发一次知识编译：读原文、写摘要、补概念、更新索引、修改相关页面、记录日志。Karpathy 在 gist 里提到，一份资料可能会影响 10 到 15 个页面。这个量级本身就说明了，它不是“写个摘要”，而是在维护整个知识结构。
第二步是 query。
当你提问时，LLM 不是直接从原始资料里临时找块拼答案，而是先读 wiki 和 index，再综合生成结果。更关键的是，这次结果如果足够有价值，不应该只停在聊天记录里，而应该写回系统，变成新的一页 markdown、新的一张对比表、甚至一份 slide。
第三步是 lint。
这一步是很多知识库系统最缺的，也是我最认同 Karpathy 的地方。定期让 LLM 去查整个 wiki：
-
有没有互相冲突的定义
-
有没有已经过期但没被修正的结论
-
有没有只有标题没有内容的空洞页
-
有没有经常被提到、却还没有独立页面的概念
-
有没有孤立页和断掉的链接
这一步一加进来，知识库就从“会存东西”变成了“会自我维护的系统”。
3. 两个关键文件：index.md 和 log.md
一个是 index.md。
它不是普通目录，而是 LLM 和人共同使用的“总索引”。每个页面一行，带摘要、链接，必要时再补日期、来源数、主题归类。Karpathy 的判断很有意思：在中等规模下，一个维护得足够好的 index.md，已经能替代不少复杂 RAG 基建。
另一个是 log.md。
它记录时间线：什么时候导入了什么、问过什么、做过什么 lint、最近系统改了哪些判断。它一方面方便人回看，另一方面也让 LLM 在新会话里更容易找回上下文。
这就是为什么 Karpathy 会说：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。
这个比喻不是修辞，而是这整套方法的骨架。
三、为什么偏偏是现在
如果把时间拨回两年，这套方法大概率还只能停在概念层。它偏偏在现在成立，我觉得有三个现实原因。
1. 模型终于开始擅长“跨文件维护”
过去的模型更适合回答单个问题，不太适合维护几十上百个相互关联的 markdown 页面。
现在的模型，至少已经开始能做这类动作：
-
读多份资料后抽共识
-
把长文压成稳定摘要
-
从多篇摘要里抽概念
-
维护页面之间的交叉引用
-
顺手更新索引和日志
-
用新资料修正旧页面的说法
一旦这类能力开始稳定，知识库的重心就不再是“怎么搜得更准”，而是“怎么让系统自己越来越完整”。
2. 配套基础设施已经足够轻
Markdown、Git、Web Clipper、Obsidian、本地搜索、Agent CLI，这些基础设施今天都已经相对成熟，而且成本很低。
Karpathy 这套蓝图没有要求你先上向量数据库，也没有要求你先搭一套复杂服务。它更像是工作流创新，而不是重型工程改造。
这点很重要。
因为很多人一谈“AI + 知识库”，第一反应就是先搭 RAG。Embedding、切片、向量库、召回策略，整套基础设施先铺半个月，知识库本体反而还没开始长。
Karpathy 的顺序正好相反：
先让知识结构活起来，再考虑检索基础设施要不要升级。
3. 个人知识库最大的瓶颈，本来就不是入口，而是维护成本
这也是我最认同的部分。
个人知识管理这个领域，这么多年其实不缺工具。缺的是一个愿意长期做整理、更新、链接、对照、查错的人。
人类会疲惫，会遗忘，会拖延，会对“补结构”这类工作天然缺耐心。
LLM 的优势恰好不在“更懂你”，而在“它不嫌烦”。
这也是为什么 Karpathy 会在原帖里暗示：这里面可能藏着一个非常大的产品机会。
我理解他真正看到的，不是“第二大脑市场又多了一个玩法”，而是一个更底层的位置：
未来真正值钱的，可能不是帮你记更多内容的软件，而是帮你持续维护上下文的系统。
四、谁最该重视这件事
它真正值钱的，不是“更聪明的笔记库”，而是能把很多高频知识工作的主线重新整理一遍。
1. 对内容创作者：从“临时拼稿”变成“先养专题 wiki，再写文章”
这是我觉得最有代入感的场景。过去写一篇深度稿，常见路径是：
-
收藏一堆链接
-
临时看资料
-
临时问 AI
-
临时拼结构
-
写完就散
而按照 Karpathy 这套方法，更合理的路径其实是：
-
先持续把资料喂进
raw/ -
让 LLM 把它们编译进专题 wiki
-
每次提问都把好答案回写进去
-
最后文章从一个已经长过几轮的问题空间里长出来
这样一来，你写的就不再是一篇“临时拼出来的稿”，而是一个持续积累过判断的专题产物。对高频写作者来说，真正贵的不是那几千字，而是每次都要从头理解一次主题。
2. 对研究型读者：从“资料收藏”变成“论点进化”
研究的关键，从来不是看过多少，而是你的判断有没有随着输入一起演进。
这套方法最好的地方，是它天然支持“旧结论被新资料修正”。
你不是把所有资料扔进一个大仓库里，等需要时再问；你是在维护一个会变化的知识结构。新资料来了，LLM 会去改旧摘要、补新证据、发现矛盾、重写概念页。
这使知识库不再只是“资料柜”，而更像“观点的工作区”。
3. 对开发者：从“项目经验散落在仓库和聊天记录里”变成“可复用的长期上下文”
这条线对开发者也很重要。很多项目里的有效知识，其实并不在正式文档里，而是散落在这些地方：
-
仓库 README 和 issue
-
旧 PR 讨论
-
调试记录
-
架构取舍说明
-
某次事故复盘
这些内容平时都在，但真正需要时，往往还得靠人临时回忆、临时搜、临时问。如果用 Karpathy 这套方法，你其实可以把项目知识也做成一套长期上下文：
-
•
raw/放仓库文档、PR、issue、设计稿、复盘材料 -
•
wiki/放模块摘要、关键约束、架构权衡、常见坑 -
•
output/放具体问题的调试报告、对比分析和决策记录
这样一来，项目知识就不再只是“谁脑子里知道”，而会变成持续维护的工程知识层。对 AI Coding 来说，这尤其关键，因为 Agent 真正缺的往往不是写代码能力，而是长期、稳定、可修正的项目上下文。
4. 对团队：从“没人愿意维护 wiki”变成“维护成本接近于零”
团队知识库最常见的问题，不是不会建，而是没人维护。
会议纪要写了，项目文档也有，Slack 里讨论也很多，但这些内容一旦没人持续整理，几个月后就会重新碎掉。
Karpathy 这套方法对团队最有价值的一点，就是把最没人愿意做的维护工作交给 LLM：
-
摘要更新
-
交叉引用
-
概念统一
-
缺口发现
-
旧结论校正
一旦这部分成本被压低，团队 wiki 才有机会从“倡议”变成“真的能活下来”。
五、四个最容易踩的坑
这套方法很值得学，但也很容易一上来走偏。
1. 一上来先搭 RAG
这是最常见的误区。
在资料规模还不大时，优先级不是向量库，而是结构化维护。先把 raw -> wiki -> query -> file back -> lint 跑通，通常比先搭一套复杂检索架构更有收益。
先跑通流程，再优化基础设施。这一点对知识库和对软件工程一样成立。
2. 一上来想管理所有东西
健康、写作、工作、阅读、消费、关系、项目，一次全上，听起来很完整，实际上很容易做成一个巨大杂货铺。
更务实的起点，不是全量覆盖，而是选一个你已经在持续深入的主题，先跑通一个最小闭环。
3. 还停留在手工维护
这也是很多人容易口头接受、实际上没放手的一点。
如果你已经决定用这套方法，就不要再把主要精力耗在手工补链接、手工整理目录、手工维护概念页上。你的职责应该是：
-
筛选原料
-
提问题
-
做最后的判断和验收
维护工作要尽量明确交给 LLM。
4. 只有 ingest，没有 query 和 lint
这会让系统重新退化成一个更整齐的收藏夹。
真正的复利，不是你存了多少，而是你有没有把新问题、新回答、新冲突、新修正继续写回系统。
六、如果今天就想开始，我建议先跑这条最小闭环
不要一上来就想把所有知识都管理起来
更务实的起点，是拿一个你已经在持续深入的主题先试跑。比如：
-
一条公众号系列
-
一组 AI Coding 工具研究
-
一条行业赛道跟踪
-
一套团队项目经验沉淀
-
一个项目或业务的知识文档
先跑通下面这条链。
第一步：建 4 个目录
your-vault/
├── raw/
│ └── assets/
├── wiki/
├── output/
│ ├── qa/
│ └── health/
├── index.md
└── log.md
先把原始资料、知识页、运行时输出和图片资产分开。index.md 先当总索引，log.md 先当时间线。不要一上来做很重的分类，先把分层建立起来。
第二步：写一个足够短的 AGENTS.md
它至少要讲清楚 4 件事：
-
新资料来了以后，LLM 要更新哪些页面
-
摘要页、概念页、专题页怎么命名
-
query 结果什么时候必须回写
-
lint 时要重点查哪些问题
这一步不是形式主义，它是整套系统能不能长期稳定的关键。
第三步：一次只 ingest 一份资料
先拿 5 到 10 篇资料做第一轮，别一上来灌满。
更稳定的做法是一次一篇：
-
读原文
-
写摘要
-
抽概念
-
更新索引
-
写日志
你自己检查输出稳不稳，再继续第二篇。
第四步：复杂问题一律“引用 + 回写”
不要只问：“这几篇文章讲了什么？”
更好的问法是：“请基于 wiki 对比 A 和 B 的差异，所有结论都要引用原文页面，并把最终结果存成一页新的 markdown。”
这一步决定了知识库是只会回答，还是会增长。
第五步：每周做一次 lint
让 LLM 固定检查：
-
定义有没有冲突
-
哪些说法已经过期
-
哪些页面是孤立页
-
哪些概念反复出现却还没独立成页
-
下一步最值得补的资料是什么
这一步一做，知识库才会慢慢有“工程感”。
如果要再往前走一步，我建议直接把这三类提示词写进 AGENTS.md 或常用模板里：
Ingest 模板
读取
raw/最近新增的文件。为每份资料生成结构化摘要，提取概念，补充或更新相关 wiki 页面，更新index.md，并在log.md记录本次导入。
Query 模板
基于现有 wiki 回答问题。所有结论都要引用来源页面。若本次输出具备长期价值，请把结果存成一页新的 markdown 到
output/qa/，并在需要时回写 wiki。
Lint 模板
通读 wiki，找出定义冲突、过期说法、孤立页面、缺失概念页和断裂链接，并输出一份健康检查报告，按影响优先级排序。
这三段一旦稳定下来，你的知识库就不再只是“放资料的地方”，而会慢慢变成一个会积累判断的系统。
收尾一下
很多时候，底层思路是相通的：先构建 feedback loop，再让系统逐步演化为 self-improving agent。LLM Wiki 也是这套逻辑在个人知识库里的一个落地。
把“知识库维护者”这个角色，明确交给了 LLM。
过去这个角色默认是你自己：手工整理、手工补链接、手工更新、手工查错。现在这部分脏活累活，第一次有可能被系统性地外包给模型。
这不是一个小优化，而是一种更接近知识工程的工作流变化。
真正会复利的，不是你存了多少资料，而是你有没有把判断持续编译进一个会更新、会回写、会查错的 wiki。
我们可以先拿一个你已经在持续深入的主题，跑通一条 raw -> wiki -> query -> file back -> lint 的最小闭环。
参考来源
-
Andrej Karpathy，2026-04-02, 1321万阅读：x.com/karpathy/st…
-
Andrej Karpathy，2026-04-04, 300万阅读：x.com/karpathy/st…
-
llm-wiki.md：gist.github.com/karpathy/44…
AI趣实验 出品 （全平台同名）
