30 分钟搭好 Karpathy 同款知识大脑，让 LLM 替你维护笔记库

4 月 2 日，Karpathy 发了一条推，讲他最近怎么用 LLM 建个人知识库。没有发布会，没有新模型，就一条 600 多字的纯文字推文。结果是 2100 万浏览，10.8 万人收藏。

Lex Fridman 在评论区说自己这套方案已经跑了一年，跑步的时候还拿它当交互式播客用；Obsidian 的 CEO 下场聊怎么防止 AI 污染个人笔记库；HubSpot 创始人 dharmesh 直接说要买下 secondbrain.com 做云端版。

两天后他把方法整理成一个 gist，取名 llm-wiki。5000 多个 star，5000 多次 fork。之后一个月里，HN 吵了两轮，开源实现冒出来七八个，Obsidian 出了配套插件，中文圈的“第二大脑”教程铺天盖地，卖课的、做产品的全来蹭。到 6 月底，36 氪还在发解读。

我把这波刷屏里能找到的东西读了一遍：他的原推和 gist、几百条回复、HN 的两场争论、gist 评论区里的生产环境实测报告，还有中英文的十几篇教程。读完的感受是，值得照做的部分被讲得太玄，真正的坑几乎没人提。这篇把两边都讲清楚：它到底是什么、怎么一步步搭、什么时候会变成陷阱。

一、刷屏的到底是个什么东西

先把定义钉死，因为全网教程里几乎一半在瞎解释，甚至有人把它和 Karpathy 另一个项目 llm.c 混为一谈，煞有介事地教你编译 C 代码。

llm-wiki 说的是一件很简单的事：你负责收集原始资料，LLM 负责把资料“编译”成一个持续维护的维基，你只读不写。

他的原话拆开是六个环节：

• 收料。文章、论文、代码库、图片，全部丢进一个 raw/ 目录。网页用 Obsidian Web Clipper 一键转成 Markdown，图片用快捷键下载到本地。

• 编译。让 LLM 增量地把 raw/ 里的东西加工成一堆互相链接的 .md 文件：每篇资料一个摘要页，概念单独立页，页面之间用双向链接串起来，索引自动维护。

• 看。Obsidian 只当浏览器用，看图谱、点链接、读页面。他的说法是：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。

• 问。库到了一定规模（他自己是 100 篇资料、40 万字），直接对着 wiki 问复杂问题，LLM 先读索引再钻进具体页面，把答案合成出来。

• 归档。答案可以是 Markdown、Marp 幻灯片、matplotlib 图表，好答案存回 wiki 变成新页面。你的每一次提问也在给知识库添砖。

• 体检。定期让 LLM 扫一遍全库：哪些页面互相矛盾、哪些结论被新资料推翻了、哪些概念被提到却没有自己的页面。

这里有一句话，很多转述都漏了：“You rarely ever write or edit the wiki manually, it’s the domain of the LLM.” wiki 归 LLM 管，人不插手。人的工作只剩两件：决定读什么，以及问出好问题。

还有一个背景，能帮你理解他为什么这么设计。早在 2025 年 3 月，Karpathy 写过一篇讲自己笔记法的博客，叫 append-and-review：一个 Apple Notes 文本笔记用了很多年，任何想法都往顶部追加，不打标签不分文件夹，隔段时间往下翻，值得留的复制回顶部，剩下的自然下沉。他管多笔记多文件夹叫“认知负担”，一个笔记 Ctrl+F 就够了。

把两篇放一起看，他的知识系统其实是两层。捕捉层烂到令人发指：一个破文本文件。编译层重到超出常人：LLM 全托管的维基。这个组合本身就是判断：捕捉环节的任何仪式感都是浪费，结构化的活一件都不要自己干。市面上大部分笔记课恰好反着来，教你在捕捉时打标签、建模板、走流程，然后结构化靠自己手动维护。方向全错。

二、他为什么敢说不用 RAG

这条推里最挑衅的一句是：我以为得上 RAG，结果发现根本不用。

过去两年，“个人知识库 + AI”的标准答案就是 RAG：文档切块，做向量索引，提问时检索相似片段塞给模型。NotebookLM、ChatGPT 传文件、各种“和你的文档聊天”产品，全是这个架构。

RAG 的问题用一个类比就能说清。你写好一段代码，不会每次运行都让机器重新读一遍源码，你会编译一次，之后每次运行都用编译产物。RAG 相当于每次提问都重新“解释执行”一遍你的全部笔记：检索、拼凑、作答，答完全忘，下次再来一遍。问了一百个问题，你的知识库还是那堆原始文件，一点没变厚。

编译模式反过来。每加一篇新资料，LLM 就把它融进已有的结构里：更新相关页面，修订综述，把新数据和旧结论冲突的地方标出来。等你提问时，交叉引用早就建好了，矛盾早就标过了。gist 里那句核心的话值得背下来：the wiki is a persistent, compounding artifact。维基是一个持久的、会复利的东西。

落到日常使用上，RAG 有三个治不了的病，编译模式全解掉了：

• RAG 只见局部。它能告诉你第 5 篇笔记提到了 A，讲不出这 500 篇笔记共同指向什么，因为“共同指向”这种东西不存在于任何一个文本块里，它存在于块与块的关系里。wiki 的概念页就是专门存这个的。

• RAG 会精神分裂。你半年前的笔记说 A 对，上个月的笔记推翻了 A，检索会把两段都捞出来拼在一起，逻辑打架。编译模式在新资料进来那一刻就把矛盾标出来了。

• RAG 没有维护概念。向量索引不会告诉你哪些知识过期了。wiki 有 lint，过期是会被查出来的。

不过这里我得把话说全，这也是全网吹爆文里集体缺席的部分：“不用 RAG”是个有适用范围的结论，范围就是 Karpathy 自己报的那个数，40 万字。HN 上有人算过账，这个量级下 LLM 靠索引文件导航完全够用；到 400 万字，同一套办法就会垮，你绕了一圈还是得回去搞检索。

gist 评论区一个跑了 6 个月生产环境、4000 多个互链概念的团队证实了这条线：扁平索引撑到几百页，之后他们加了本地混合搜索。更准确的说法是：个人规模不用 RAG，这个规模能覆盖 90% 的人，但它有边界，不可以拿着个人方案去接企业活。

三、三层三操作，架构十分钟讲完

gist 把系统抽象成三层。

raw/ 层，原料，不可变。所有原始资料住在这里，LLM 只读不改。这是整个系统的地基：wiki 里的每一条结论都要能追溯回 raw/ 里的某个文件。后面讲到幻觉问题时你会发现，这条“不可变”规则是唯一的安全带。

wiki/ 层，编译产物，LLM 全权负责。摘要页、概念页、实体页、对比页，加两个特殊文件：index.md 是内容目录，每页一行链接加一句话摘要，LLM 答题前先读它找路；log.md 是只追加的操作日志，每次摄入、每次体检都记一笔，让下一次会话知道上一次干了什么。

schema 层，一个 CLAUDE.md（或 AGENTS.md），整个系统的灵魂。它写清楚目录结构、页面格式、命名规则、三种操作各自的步骤。Karpathy 的原话是，这个文件决定了 LLM 是一个“有纪律的维基管理员”还是一个泛泛的聊天机器人。那个 6 个月生产环境的团队说得更直接：schema 文件是整个仓库里最重要的文件。我完全同意，而且要加一句：新手搭这套系统，八成的失败发生在没写 schema，或者 schema 写得太糊。没有 schema，LLM 每次编译的格式都不一样，页面该合并的不合并、该拆的不拆，一个月后你得到的是一堆 AI 味浓重的碎片，然后弃坑，再得出结论“这方法不行”。方法没问题，是你跳过了最重要的一步。

日常就三个动作，对应三个 prompt：

• Ingest（摄入）：丢一篇新资料进 raw/，说一句“把它编进 wiki”。LLM 读原文、写摘要页、更新所有相关页面、更新索引、记日志。一篇资料动十几个页面是常态。

• Query（查询）：直接提问。LLM 先读 index.md 定位，再读两三个相关页面，合成答案并给出引用。好答案让它存回 wiki。

• Lint（体检）：定期跑一句“检查全库的矛盾、过期结论、孤儿页面、缺失概念”，输出一份体检报告。

一个容易被忽略的操作细节，来自 Karpathy 在回复区的自答。有人问增量编译怎么做、batch size 多少，他说：现在完全没有全自动，每个源我手动加，一次一篇，我全程在场，尤其是早期。等 LLM 摸清了套路，后面每篇的成本才会骤降，降到一句“file this new doc to our wiki”就行。这条比 gist 正文还重要。

全网教程都在教你“一条 prompt 批量编译 50 个文件”，而发明者本人是一篇一篇喂的。批量摄入省下的时间，会以页面质量失控的形式加倍还回来。前 10 篇一定要一篇篇来，边编译边纠正它的格式和详略，把纠正的结论写回 CLAUDE.md。这是在训练你的管理员，训练好了才能放量。

四、手把手搭一个最小可行版

讲完原理，直接动手。这一节照做下来 30 分钟，成本是原有订阅费（用你已有的 Claude 订阅）。前提只有一个：装好 Claude Code（Codex、OpenCode 之类的同类工具都行，或者 WorkBuddy 都可以，流程一样）。

第 1 步：建目录。

my-brain/ ├── raw/ # 原始资料，只进不改 ├── wiki/ # LLM 的地盘 │ ├── index.md # 空文件 │ └── log.md # 空文件 └── CLAUDE.md # 马上写

顺手 git init 一下。wiki 就是一堆文本文件，git 白送你版本历史，哪次编译搞砸了直接回滚，log.md 之外多一层审计。

第 2 步：写 CLAUDE.md。

下面这份模板综合了 gist 原文、几个生产实测者的版本和我自己的取舍，可以直接抄，抄完把主题改成你的：

markdown# 知识库：[你的主题]

结构

• raw/：原始资料，永远不要修改这里的任何文件
• wiki/：你生成和维护的 Markdown 页面
• wiki/index.md：总目录，每次操作后更新
• wiki/log.md：只追加的操作日志

页面规则

每个 wiki 页面必须带 frontmatter：

title: 页面标题 type: concept | entity | source-summary | comparison sources: [raw/下的来源文件路径] related: [“[[相关页面]]”] updated: YYYY-MM-DD confidence: high | medium | low

• 文件名用短横线小写（attention-mechanism.md）
• 内部引用一律用 [[wikilink]]
• 每个结论都要能追溯到 raw/ 里的来源，没有来源的结论不写

Ingest 流程

1. 读 raw/ 里指定的新文件
2. 先向我汇报要点，等我确认再动笔
3. 在 wiki/ 写摘要页，更新或新建相关概念页
4. 更新 index.md，追加 log.md

Query 流程

1. 先读 index.md 找相关页面，读 2-3 个页面后作答
2. 答案里引用 [[页面]]，追溯原文时给 raw/ 路径
3. 答案有长期价值时，问我要不要存成新页面

Lint 流程

检查：页面间矛盾 / 被新资料推翻的旧结论 / 没有入链的孤儿页 / 被提到但没有页面的概念。输出报告，未经我同意不做任何删除。

铁律

• NEVER 删除任何文件
• NEVER 修改 raw/
• 新页 vs 改页：这个东西会被其他页面链接，就新建； 只是已有页面的补充信息，就原地更新

最后那条“新页 vs 改页”的启发式来自生产实测：schema 里把页面类型列清楚之后，模型九成的场合能判对。铁律里的 NEVER 也别删，AI 工具最危险的地方从来都是它太积极。

第 3 步：喂前三篇资料。

挑三篇同一主题、你真读过的文章丢进 raw/（Obsidian Web Clipper 剪网页最省事），然后在目录下开 Claude Code：

把 raw/ 里的三篇文章逐一 ingest 进 wiki，严格按 CLAUDE.md 的流程， 一篇处理完给我看结果，我确认了再做下一篇。

第一篇出来后重点检查三件事：页面粒度（一页只讲一个概念，混了就让它拆）、链接密度（概念页之间有没有互相引用）、详略（摘要页应该比原文短得多，概念页应该有跨来源的综合）。不满意就直接说，同时让它把改进规则写回 CLAUDE.md。

**第 4 步：**用 Obsidian 打开 wiki/ 看一眼。装 Obsidian，Open folder as vault 选中 wiki 目录，按 Cmd+G 开图谱。三篇文章大概会出 10 到 20 个节点。这一步的价值是心理上的：图谱会随着你喂料肉眼可见地长大，这个反馈是你坚持下去的燃料。

**第 5 步：**问一个你知道答案的问题。比如“这三篇文章在 X 概念上的说法有没有冲突”。检查它引用的页面对不对、结论有没有编造。这是你的验收测试。

到这里最小可行版就跑通了。有两个此刻不要做的事：一是不要装插件，Dataview、Templater 那些等库过百页再说，工具链的复杂度会在你还没建立习惯时先杀死你的动力；二是不要一次性把陈年积累的 500 篇收藏全倒进去，原因上一节讲了。

五、进阶：从玩具到系统

最小版跑顺一两周后（注意是跑顺，用不顺的系统加功能等于给漏船装帆），再上这几个部件。每一个都来自有人真实踩坑后的修正。

• Token 三级预算。库大了之后最先失控的是成本，而且钱大头烧在一个想不到的地方：重复读取。有个做课程知识库的人测下来，token 消耗主要花在模型一遍遍重读 AGENTS.md、index、原始文件上，推理本身反倒便宜。解法是在 CLAUDE.md 里写死一个三级预算：回答问题先读 index.md（几 KB，轻），再读 2-3 个相关 wiki 页（中），确实需要核对原文才碰 raw/（重）。禁止“把全库读一遍再回答”这种动作。

• 强制双输出，防知识蒸发。每次问答，要求模型同时给两样东西：答案本身，加上一条 wiki 更新（哪怕只是往某个概念页追加两行）。规则写进 CLAUDE.md，不能二选一。没有这条约束，你最有价值的思考会全部蒸发在聊天记录里，知识库退化成一个只进不出的文件堆。复利来自回流，回流靠强制。

• 模型分级省钱。Ingest 是重复性的体力活，对推理能力要求低，用便宜模型跑（Haiku、DeepSeek、本地 Ollama 都行）；Query 尤其是跨页面综合，才值得上强模型。另外给单文件设个规矩：超过 50KB 的资料只提摘要不全文编译。实测里一个中等项目全量初始化 1 美元以内，日常每次更新 5 到 15 美分，正经用一个月 10 到 20 美元封顶。花超了基本都是没做分级。

• 源文件粒度决定编译质量。有人拿三本商业书（15.5 万词）做过对照实验：整本书一个文件喂进去，出来的是典型 AI 烂泥；同样的书按章节拆成 68 个文件再编译，出来 210 个概念页、4600 条交叉引用，模型自发在三本书之间做综合，还发现了两本书之间一处谁都没明说的观点矛盾。模型和 prompt 完全没变，唯一的变量是拆分粒度。长资料入库前先拆：书按章，长报告按节，播客转录按话题段。这十分钟的体力活是全流程性价比最高的投入。

• Lint 定时跑，这条没有商量余地。那个 4000 概念的生产团队报告的最大失败模式叫 drift：摄入时漏更新了交叉引用，页面悄悄过期，错误开始被别的页面引用，你的库变成一座“有组织的错误信息库”。他们的结论是 lint 必须挂定时器。个人用法不用那么重，每积累 20 篇新页面跑一次，或者固定每月一次：

审查整个 wiki/：找出互相矛盾的页面、被新资料推翻的结论、 没有任何入链的孤儿页、无来源的声明。 给出报告，并建议 3 个值得新建页面的空白概念。

最后那半句是彩蛋，lint 顺便帮你发现下一步该读什么。

• 两个库隔离，保护你自己的声音。这条来自 Obsidian CEO：AI 生成的内容和你亲手写的笔记，放两个 vault。他的理由值得逐字读：个人笔记库的价值在于高信噪比、来源可知，一旦和 AI 产物混在一起，搜索、反链、图谱就再也不代表“你的”思想了。AI 库里真正有用的东西，人工挑出来搬进主库。这个动作的摩擦是特意保留的。

• 搜索工具，大概率你不需要。Shopify CEO 写的 qmd 是这个生态的标配搜索引擎，本地跑，混合检索。但生产实测的共识是：百页以内，模型自己 grep 加读索引完全够；到几百页再上。一上来就配搜索、配 MCP、配自动化 hooks 的人，多半是在用搭系统的快感代替用系统的枯燥。

六、什么时候不该建：反方观点值得一整章

这波刷屏里最有营养的内容全在反对声里。HN 两场讨论加起来 130 条评论，gist 评论区还有人贴了控制变量的实验数据。我挑真正扎实的几条，附上我的立场。

第一刀：小体量下这就是无用功，有实验数据。有人给自己的小型代码库建了 28 页 wiki，然后做 A/B 测试：同样四个问题，一组直接让 agent grep 代码，一组查 wiki。结果 token 消耗几乎一样（27.3k 对 27.6k），正确率都是满分。原因扎心：在一个概念对应一个百行文件的库里，实体页比源文件本身还长，压缩比小于等于 1；更糟的是页面标了“派生内容，请对照源码核实”，agent 就 wiki 和源码各读一遍，成本翻倍。他的修复方案是把 28 页塌缩成一张密集的单页地图，查询成本立刻降到 grep 的一半。他总结的边界条件我认为是全部讨论里最值钱的一句话：这个模式只在“一个页面压缩了分散在多个来源里的事实”时赚钱，给本来就能一眼看完的东西建镜像，是负价值。另外他还有一句同样锋利的：要么查询时无条件信任 wiki，要么它就不该存在。

由此推出第一条判断：手头不到二三十篇会反复参考的资料，别建。单篇资料让 LLM 直接读原文就是最优解，知识库的全部价值都在跨文件关联上，文件不够多，关联无从谈起。

第二刀：外包了整理，会不会也外包理解。这是 HN 上最响的反对，来自一个有 4100 篇手写笔记的 Obsidian 老用户。他的论点：归档、连接、总结这些“杂活”恰恰是新想法冒出来的时刻，你在给两篇笔记建链接时被迫思考它们的关系，这个被迫就是学习本身。AI 建的知识库“没有任何 personal 可言，那是 AI 的数据库，你只是在旁边问问题”。同一楼还有人补了个类比：用 AI 生成记忆卡片很荒谬，因为做卡片的过程才是学习，刷卡片只是巩固。更有说服力的是一条真实使用者的自述：他因为精力耗尽开始重度依赖 wiki 工作流，几个月后发现自己积累了一种“持续的大脑亏空”，交付物越来越多，理解越来越薄，而这套工作流让人上瘾，停不下来。

我的立场：这一刀砍中了一半。它对研究型使用（读论文、做尽调、追一个领域）基本无效，因为那类场景下 Karpathy 的分工是成立的，人依然读原文、依然做判断，LLM 接手的只是你本来就做不到坚持的记账。但它对学习型使用是致命的。你想搞懂一个东西的时候，别用这套系统，老老实实自己写笔记。你想管理一堆你已经懂的东西的时候，再用它。分不清这两种场景的人，会拿着一座越来越漂亮的维基，和一颗越来越空的脑子。

第三刀：生产力色情。一个更冷的观察：知识库这个品类，完美模拟“收获”的快感，但不提供产出的结果。收藏不等于拥有，高亮不等于理解，同理，一座 AI 帮你整理得井井有条的维基也不等于你产出过任何东西。有人举了个终极例子，就用 Karpathy 本人：他那 40 万字的 wiki 只有他自己看，而他的推文有 2100 万人看。全世界引用的从来都是他输出的东西。

这条我全盘接受，并且认为它是整套方法的最后一块拼图：知识库是中间件，终点必须是输出。写进工作流就是，每次 lint 之后多问一句“基于现在的库，最值得写的三个选题是什么”，让库直接吐生产任务。库的健康度不用图谱衡量，用它这个月帮你产出了几篇东西衡量。

第四刀，附送一个讽刺当警示。gist 评论区后来变成了大型翻车现场，几百个人把这份文档直接喂给自己的 agent，“implement this gist, make no mistakes”，然后回来贴自己的实现打广告，评论区淹没在 AI 生成的营销文里，有人留言说这个评论区本身就是最好的反面教材。连 Karpathy 自己都在 HN 上贴了一段 Claude 代写的回怼，被踩到删帖。这个故事的教训和工具无关：这套系统里唯一不能外包的环节是判断，一旦你连“往库里放什么、信不信它的输出”都交给 AI，你就成了评论区里那几百个 slop 账号中的一个。

七、给不同的人的三条启动路线

最后按人群收拢一下，三条路线难度递增。

路线一，非技术背景，只想先尝到味道。不碰终端。Claude.ai 网页版直接传 5 个同主题的 PDF，一句 prompt：“为这些文档里的每个关键概念生成一个 Markdown 页面，带摘要、[[wikilink]] 交叉引用，标出文档之间的矛盾。”生成的页面手动存进本地文件夹，用 Obsidian 打开看图谱。半小时体验完编译模式的核心，再决定要不要上正装。

路线二，会用命令行，个人知识管理。就是第四、五节的完整流程：三层目录、CLAUDE.md、一篇篇 ingest、月度 lint。前两周只做摄入和查询，第三周开始加双输出和模型分级。判断这条路线走没走对的标志：某天你问了个复杂问题，它引用的三个页面来自你三个不同时期喂的资料，而那个关联你自己都没意识到。到这一步，复利开始了。

路线三，工程师，想接进工作流。在路线二之上加自动化：SessionStart hook 每次会话自动注入 index 前 60 行和 log 末 15 行；post-commit hook 在代码提交后台触发 wiki 增量更新，挂 –max-budget-usd 0.5 当保险丝；每周日定时 lint。六个项目这么跑，每月 API 成本 10 到 20 美元。但记住第六节那把刀：先确认你的项目知识真的分散在多个来源里（会议记录、老 PR 的讨论、部署的口头约定），如果一切尽在代码中，grep 就是你的知识库，别建。

写到这里，把 Karpathy 那两篇东西里我认为最被低估的一句话放在结尾。

他说维护知识库最累的部分从来都是记账，人类弃坑是因为维护成本永远涨得比价值快，八十年前 Memex 就死在这上面，现在 LLM 把维护成本压到了近乎零。

这句话反过来读才是重点：机器接管了记账，等于你再也没有借口把“整理”当成产出了。筛选值得读的东西，问出别人问不出的问题，把理解变成作品发出去，这三件事从来没有工具能代劳，今天也一样。

知识大脑搭得再漂亮，它也只是仓库，而仓库不产粮食。

关于作者

Kyrie — 前国内大厂 R&D 工程师，现居曼谷，做中国科技企业出海 BD。持续分享出海一线真实记录、AI 在业务里的实战用法，偶尔也聊聊美股投资和国外生活。

• X：.@KyrieCheungYep