在之前的《知识沉淀的第一步——统一语言与 ADR》里，我讲了项目级的知识沉淀——统一语言（CONTEXT.md）和不可逆决策（ADR），两样东西就够。但沉淀的起点是「有知识」，项目里可以靠代码和讨论沉淀，可那些还没变成项目的知识呢？那些攒在收藏夹里、散落在微信文件传输助手和随手截图里的东西？
很长一段时间里，我对个人知识库的态度是「不折腾」。Notion 数据库建过，三个月后不再打开；Obsidian 仓库建过，里面躺着几篇孤零零的笔记；RAG 系统试过——上传一堆文档，然后呢？每次提问它都重新检索、重新拼装，好像我从来没读过它们一样——没有积累。
后来我发现了 karpathy 的 llm-wiki。它不是工具、不是框架、甚至不是教程，就是一个 markdown 文件——但它描述的模式，正是我需要的：
知识库不该由人维护，也不该由 RAG 现查现拼——应该让 LLM 增量维护一份持续编译、互相引用的 wiki。
这篇文章记录我照这个思路落地一个知识库的过程，包括全部结构和关键文件，以及三天里总结出的四条实战经验。如果你也想构建一个自己的知识库，这篇文章会给你一条已经跑通的路。
先看一组数字
在展开之前，先给结论。我的知识库是 2026 年 8 月 2 日搭起来的，到 8 月 4 日，三天：
| 项目 | 数量 |
|---|---|
| 摄入的原始文章（raw/） | 48 篇 |
| Wiki 页面总数 | 119 页 |
| 概念页（concepts/） | 54 页 |
| 实体页（entities/，人/组织/产品） | 14 页 |
| 来源页（sources/） | 48 页 |
| 综合页（syntheses/） | 1 页 |
| 沉淀问答（answers/） | 1 页 |
| 主题 hub（topics/） | 1 页 |
主题是 AI Agents。这 119 个页面里，没有一页是我手写的。我做的事只有三件：把文章丢进 raw/、偶尔提问、跑体检。剩下全是 AI 干的——包括页与页之间的交叉引用、跨文章的相互印证、矛盾的标注、以及那些我根本没意识到存在的关联。
这不是收藏夹里的 48 个死链接。这是一张网，而它还在持续生长。
为什么我放弃了 RAG
先说我为什么不用 RAG。RAG（检索增强生成）是目前几乎所有「AI 文档问答」产品的实现方式：你上传文档，系统切成小块做向量索引，提问时检索相关片段拼进上下文，LLM 生成答案。
它有一个被很多人忽略的问题：每次提问都是重新发现。
有一个比喻说得很好：RAG 像一个天才研究助理，你喂它什么它读什么，给你即时的答案——然后第二天醒来，什么都不记得了。它不记得上周它发现的两篇论文之间的矛盾，不记得上个月它帮你搭的框架。每次你都得把资料重新喂一遍，它每次都从零开始。
一份需要综合五篇文档才能回答的问题，RAG 每次都要找出这五篇的相关片段、再拼起来——它永远不会因为「上次已经做过这个分析」而变快。没有积累。
但更根本的问题在别处。回想一下你建过的知识库为什么荒废：收集（collect）很容易，整理（organize）很难，而维护（maintain）——在规模上几乎不可能。每加一篇新文章，理论上你要：读它、写摘要、链接到已有概念、更新相关页面、检查与旧知识的矛盾。第一周你会做，第二周你会忘，第三周你放弃了。知识库不是死于收集不足，而是死于维护成本。
karpathy 的洞察就是冲着这一点来的：
维护知识库最繁琐的部分不是阅读、不是思考，而是记账（bookkeeping）——更新交叉引用、保持摘要同步、标注新旧矛盾。人放弃 wiki 是因为维护负担的增长快过价值。而 LLM 不会厌倦，不会忘记更新某个交叉引用，一次能触碰 15 个文件。（译自 karpathy 的 gist）
于是他的方案是：你在 wiki 里几乎从来不自己写东西。你负责策展（找资料）、探索、提问；LLM 负责摘要、交叉引用、归档、记账这些苦力活。Obsidian 是 IDE，LLM 是程序员，wiki 是代码库——他原话就是这么说的。
LLM Wiki：三层架构，三个操作
karpathy 的模式拆开就三句话，我落地后变成下面这套结构：
1 | llm-wiki/ |
三层架构。raw/ 是源码——你策展、不可变，LLM 永远只读；wiki/ 是编译产物——LLM 生成的互相引用的 markdown；AGENTS.md（karpathy 用 CLAUDE.md，原理一样）是编译器——它规定目录怎么组织、页面什么格式、摄入/查询/体检怎么走，把 LLM 从「通用聊天机器人」变成「守纪律的图书管理员」。
三个操作。
- Ingest（摄入）：把新资料丢进
raw/，对 agent 说「摄入它」。它读全文 → 跟你讨论要点 → 建来源页 → 创建/更新涉及的实体和概念页（一篇资料通常触碰 10~15 个页面）→ 更新主题 hub → 更新 index → 追加 log。 - Query（查询）：你提问，它先读 index 定位候选页，再深入阅读，给出带引用的综合答案。关键约定是：好的答案回填进 wiki——一次对比、一个分析、一个发现的关联，别让它消失在聊天记录里。
- Lint（体检）：定期让它全库自查——页间矛盾、被新来源推翻的旧说法、没有入链的孤儿页、该有却没建的页面、以及资料缺口。
两个导航文件。index.md 是内容目录，每次操作后更新，查询时先读它；log.md 是只追加的时间线，每条以 ## [2026-08-02] ingest | 标题 开头——格式统一到可以用 grep "^## \[" log.md | tail -5 直接解析出最近动态。
这个模式的精神祖先，是 Vannevar Bush 1945 年提出的 Memex——一个私人的、主动策展的、文档之间的关联与文档本身同等重要的知识存储。Bush 没能解决「谁来维护」；八十年后，LLM 解决了。
落地：一个能直接照抄的脚手架
动手只有四步：git init、建目录、写 AGENTS.md、放第一篇资料。骨架可以全部照抄我上面的结构。
但有三个约定，是我用下来觉得整个系统的命脉，值得展开说：
1. 三条纪律，写死在 AGENTS.md 里。
raw/不可变——LLM 永远不碰它；log.md只追加——历史不改写；- 摄入时同步更新所有相关页面与 index——靠 lint 兜底防漂移。
2. 页面有统一 frontmatter。 这是让页面关联「可追踪」的骨架：
1 |
|
正文里首次提到的概念一律用 wikilink [[slug]] 标注。这两个机制合在一起，等于让 AI 每次摄入时都重新审视「这篇资料和已有知识有什么关系」——refs 是关系本身，sources 是关系可追溯到原始证据。
3. 矛盾不静默改写。 新资料推翻旧说法时，AGENTS.md 要求：旧页标 status: superseded，注明被谁在何时推翻，链到新页。知识库最怕的就是「最新一版覆盖一切」——历史被改写的库是没有记忆的。
最后加一层机器兜底：一个 scripts/lint.sh，检查六类问题——缺 frontmatter、断掉的 wikilink、无入链的孤儿页、index 漂移（页面存在但目录没列）、log 日期格式、topic 字段没有对应 hub 页。跑一次全库体检，几十页也就几秒钟。这个脚本的意义在于：AI 的「记得」是不可靠的，机器的检查是可靠的——约定层 + 兜底层，漂移才真正可控。
工具链上，前端我用 Obsidian 打开 wiki/ 目录——wiki 就是一堆 markdown，双击即见，graph view 直接可视化页面间的关联网络；版本历史是免费的，整个目录就是 git 仓库，每次摄入一个 commit，随时能回看知识库是怎么长出来的。
实战：三天，48 篇文章，119 个页面
数据在前面，这里讲它怎么长出来的。
第一天（8 月 2 日）我从收藏夹里翻出 30 多篇攒了大半年的 AI Agents 相关文章——从 Addy Osmani 的 spec 写作指南到 Anthropic 的官方最佳实践——一股脑丢进 raw/。注意，丢进去不等于摄入——但跨过这一步，资料才从「收藏」变成「输入」。这些攒了大半年的文章，三天内全部变成了知识库里的页面，而我只做了「把它们放进 raw/」这一件事。
然后就是机械地重复：摄入 raw/<文件>，读它和 agent 讨论出的摘要，偶尔纠正它的强调重点，看它更新完页面说「摄入完成」。一篇典型文章的摄入产出是这样（取自 log.md）：
- 新建 16 页：1 source、4 entities（addy-osmani、simon-willison、github、anthropic）、10 concepts（ai-agent-spec、spec-driven-development、curse-of-instructions…）、1 synthesis（ai-feature-implementation-loop）
一次摄入，16 个新页面，每个概念页都不是孤立笔记，而是带着 refs（它依赖谁）和 sources（证据来自哪）挂进已有的网络。比如 agentic-memory 这一页，把 Anthropic 官方文档、多代理研究系统、Claude plays Pokémon、情景记忆、生成式代理记忆五个来源的论述交叉引用在了一起。
最让我惊讶的是 AI 会自动发现跨源呼应。摄入 Anthropic 的《Effective context engineering》时，它在「与现有 wiki 的关系」一节里主动写道：
值得注意的跨源呼应：Willison 的代理定义（2025-09-18）被 Anthropic 官方采用
——它记得之前摄入过 Simon Willison 的文章，并在新资料里发现他下的定义被官方引用。这种关联，靠我自己读 48 篇文章是发现不了的，至少不会在摄入当天就发现。
Obsidian Graph View 全库关系图谱：节点越大、连线越多，说明该概念与全库的关联越紧密。
第二天（8 月 3 日），我第一次在 wiki 上做了真正的「咨询」：问它「AI coding 相比传统开发，到底解决什么、新增什么」。它读了几十个页面，回了一张十几行的对比表。然后按约定，这张表被回填成了 wiki/answers/ 里的一页，带着 14 份来源引用——我的探索也开始复利了。
四个超出预期的收获
如果说前几节是「复述模式」，这节是真正用出来的经验——karpathy 的 gist 里没有，但三天实操里反复出现的四件事：
1. 收集先行：收藏夹不是终点，入库才是。
过去我的收集方式就是收藏——它的代价是永远停在「待读」状态。现在不一样了：收藏夹里的东西被丢进 raw/，AI 把它变成知识库里的一页，知识在收藏之后就算入库了——之后任何一次咨询，它都在被引用。收藏夹的终局不是「读完」，而是「入库」。
2. AI 会反向推荐资料：摄入是滚雪球的过程。
摄入每篇文章时，AI 会在总结里列出「文内引用但尚未摄入的资料来源」。我在 log.md 里看到过这样一条：
新增待核：文内两篇未摄入（ai-makes-weak-engineers-less-harmful、you-cant-design-software-you-dont-work-on）
顺着这个线索，我把 Goedecke 的一个系列文章一篇篇找出来摄入——每摄入一篇，它又告诉我下一篇在哪。到第三天，一天之内连续摄入了 5 篇，形成一个「Goedecke ×10」的完整研究链条。我不需要知道要读什么，AI 在替我筛文献——这个过程中它还持续在主题页更新「开放问题」和「待核资料」清单，等于它自己给自己布置作业。
3. 专题驱动：一个主题一个 hub，关联自己长出来。
每个研究主题一个 topics/ hub 页：核心页面、当前状态、开放问题。摄入时 AI 自动同步它。我的 ai-agents 主题页现在挂着 42 个引用、44 份来源、一长串开放问题。翻它的时候像在看一个研究项目的 roadmap——哪块结论扎实、哪块缺实证、下一步该补什么，一目了然。主题是纲，摄入是目，纲举目张，关联关系在一次次摄入里自然生长，不需要刻意「建关系」。
4. 答案沉淀：咨询本身就是一种摄入。
这个模式里最反直觉的一点：提问也是知识来源。一次高质量咨询产出的综合结论（对比表、跨源分析），回填成 answers/ 页面后，下一次相关问题直接引用它，而不是重新综合一遍。聊天记录会消失，wiki 不会。karpathy 的原意是：探索和摄入一样复利——「explorations compound like ingested sources do」。
这个模式适合什么场景
karpathy 在 gist 里列过一串适用场景，我挑几个最典型的：
- 长期研究的专题。几周甚至几个月深挖一个主题——读论文、文章、报告，wiki 随摄入增量生长，最终形成一份带演化论点的综合资料。karpathy 自己就用这个模式跟踪研究主题（他公开分享过规模：单主题约 100 篇文章、40 万词）；我的 AI Agents 库走的也是这条路。
- 读书。边读边归档每一章，为人物、主题、情节线建页，读完一本就得到一本「伴读 wiki」——像 Tolkien Gateway 那样数千页互链的 wiki，一个人也能建出来。
- 个人成长。日记、播客笔记、文章按主题归档，逐步构建关于自己的结构化图景——目标、健康、心理，时间越长价值越高。
- 团队内部 wiki。喂 Slack 线程、会议记录、项目文档、客户通话，LLM 做没人愿意做的维护，wiki 永远保持最新。
- 其他一切「随时间积累」的事。竞品分析、尽职调查、旅行规划、课程笔记、爱好深挖——判断标准只有一条：你是不是在长期积累一类知识，并且希望它被组织起来，而不是散落各处。
边界：什么时候不要用这套东西
说实话的部分：这套模式不是万能的。
- 一次性问题不需要它。 判断标准很简单：你需要的是「一次查询」还是「长期积累」？前者 RAG 足够，后者才值得编译进 wiki。
- 几百页内 index.md 够用，更大要上搜索。 karpathy 的建议是 qmd——本地 markdown 混合检索（BM25 + 向量 + LLM 重排），有 CLI 和 MCP 两种用法。在那之前，index 加 lint 完全够。
- 漂移是真实风险。 gist 评论区有一个开源实现（MindBase）分享的教训：最好的约定是用工具边界物理强制——它的 builder 子代理干脆没有写文件的权限，raw 层想改都改不了。我的三条纪律是约定层，lint.sh 是兜底层，够用，但如果你要长期跑，考虑把「不可变」做成权限而不是约定。
- AI 会犯错，但可标注。 AGENTS.md 里有一条：不确定的论断在页面里标注为不确定，而不是断言。摄入时的讨论环节（「先和我讨论要点，再写」）也是纠错窗口。
- 成本是真实的。 一次摄入要读全文、触碰 10~15 个页面；48 篇全量入库是一次不小的 token 投入。好处是一次编译、持续复用——最费的是建库那一天，之后就便宜了。
30 分钟，从零开始
最后给行动清单，全部来自上面讲过的内容：
1 | # 1. 初始化（二选一：clone 我的仓库，或照上文目录树从零建） |
然后打开 Obsidian，指向 wiki/，看第一个节点挂进图谱。
直到动手之前，我还觉得「个人知识库」是个伪需求，收藏夹足够。现在回头看，区别不在工具，在于我把知识库的维护成本从 O(n) 降到了趋近于零——人只负责策展、提问、思考「这一切意味着什么」，LLM 负责其余一切。成本趋近于零，积累才有意义，复利才成立。
三天不算长，所以我尽量把能核对的都摆了出来：数字、日志、页面，都在公开仓库里，谁都可以复查。这个库还会继续长，后续我会接着记录它长成什么样。
karpathy 的 gist 没说教「知识管理很重要」——它只是证明了，这件事现在变得足够便宜了。