前言 #
前几天刷到 Karpathy 在 X 上发的一条帖子，核心意思是他最近把大量 Token 从写代码转移到了「操纵知识」上，用 LLM 来帮自己搭个人知识库。这条推文炸了之后，他干脆写了一份叫 llmwiki 的 idea file，把灵感升级成了可执行的设计文档。我看完之后觉得这套思路确实值得聊聊，它不只是换了一种 RAG 的姿势，而是在重新定义「第二大脑」该怎么搭。
RAG 的硬伤：知识不会累积 #
过去两年我们对大模型的主流用法是什么？当搜索框、当问答机、当 RAG 前端。你丢一批 PDF、一堆 Markdown，建个向量库，提问的时候检索几个 chunk，拼个答案出来。
这套做法单次看起来很聪明，但它有一个结构性问题：知识不会累积。每次提问题，模型都是从原始文档重新发现世界。同一个复杂问题，今天问一遍、下周问一遍，都是重新拼一遍碎片。你会觉得很熟悉的那种挫败感：明明这堆 PDF 已经问过十遍了，系统却像一个记忆力很差的助理，每次都从零开始翻箱倒柜1。
Karpathy 想换掉的，就是这种永远在「现场拼答案」、从不把知识做成资产的默认体验。
知识编译器：一个范式转换 #
Karpathy 给出的反转设计，其实就一句话：别再把问答当终点，而要把问答当中间产物，写回一个长期维护的知识体系。
在他的设计里，LLM 做的不是按需检索，而是增量编译。你往 raw 目录丢一篇新文章，它不会等你哪天来搜，而是立刻读完、抽取要点、更新相关概念页和实体页、补上交叉链接，甚至标记这条信息和旧说法冲突。
如果你要把这套脑洞讲给团队听，用 Karpathy 自己的类比就够了：
- Obsidian 是 IDE 前端，你在里面浏览 raw 资料、看 wiki 页、看 graph view，就像在 VS Code 里翻代码、看调用图
- LLM Agent 是 programmer，它根据 schema（Claude.md、agents.md）来决定怎么 ingest、怎么 query、怎么 link
- Wiki 本身就是 codebase，它是可读的、可 diff 的、可以用 Git 管版本的。它不是向量数组，而是一堆你随时可以打开、重构、review 的知识代码
当你用这个视角看 llmwiki，就会发现 Karpathy 其实是把工程文化那套东西挪到了知识管理上：有源代码、有中间产物、有测试 lint、有版本历史。只是这次编译的不是二进制，而是你自己的第二大脑2。
三层架构 #
Karpathy 的设计很工程思维，整体分三层：
最底下是 raw sources（原始资料）。论文、文章、代码仓库、截图、数据集，全都扔这里。模型只读不写，保证有一份不被 AI 润色过头的原版世界。
中间是 wiki 层。全部是 LLM 写出来的 Markdown，所有 summary、概念页、实体页、对比表都在这里增量生成、维护、加 backlinks。你作为人类，主要也是读这一层。
最上面压着一个 schema。它更像 Claude.md、agents.md 这种团队规范，约定目录结构、命名规则、ingest 和 lint 的流程，决定这套系统是混乱生长还是长期可维护。
三层拆开看很简单，但真正的魔法发生在那几个核心动作里。
四个核心动作 #
Ingest：增量编译 #
很多人一听 ingest 会下意识以为就是「塞到向量库里」。在 llmwiki 里不是这样，ingest 更像一次增量编译。
一个新来源进 raw，Agent 的流程大致是：先读完原文，对一下关键 takeaway，然后在 wiki 里新建 summary 页、更新 index，接着去相关的实体页和概念页把新信息融进去。一篇像样的文章，动辄会影响 10 到 15 个页面：人物关系会更新、时间线会更新、某个争议点的证据表也会多一行。
所以在这套范式里，ingest 不是上传文件，更像是 commit 了一次完整的知识变更。
Query：结构优先的检索 #
传统 RAG 的检索是很 flat 的：给一个 query，在整个语料空间里做相似度排名，抓 top-k chunk 扔给模型。它并不知道哪些是纲要、哪些是某一页的一角。
Karpathy 的做法是先花时间把结构铺好：有 index.md 这种内容导向的目录，每一页都有一行摘要，有实体页和概念页之间的 backlinks，有 log.md 记录最近 ingest 和 lint 的轨迹。在这种结构下，query 流程变成：先读 index，看有哪些页面命中这个问题，再顺着链接下钻到相关页面，最后才在小范围里综合答案。
对 Agent 来说，这有点像先看目录和索引，再查具体章节，而不是在一堆碎片上做 KNN。
File Back：好回答本身就是资产 #
传统用法里，问完一个好问题、模型给了一个很强的分析，结果停在聊天窗口里，过几天这条对话就沉底了。
在 llmwiki 的设计里，好回答本身就是资产。只要质量过关，就应该被写回 wiki：存成一个新的 concept 页面、一份决策记录、一张对比表，挂上 sources 和日期。这样你每次追问，其实都在让知识库升级一把。你的探索路径、你和模型一起踩过的坑，都会变成下一次 query 的可用上下文，而不是一堆失温的聊天记录。
Lint：知识版的测试套件 #
只长不体检，很快就会长成一团脂肪。Lint 在这里的含义和代码世界几乎一模一样：不是帮你写新东西，而是定期扫描 wiki 找问题。
它找的是：不同页面里互相打架的结论、被新资料推翻但还挂着的老说法、没有任何入链的孤儿页面、反复被提到却没有独立页面的关键概念。更高级一点，你可以让 Agent 在 lint 过程中顺手提建议，比如「这里有个反复出现但没独立页面的 pattern，可以拉出来单独建一个页面」。
有了 lint，这套系统才真的像一个长期维护的代码库，而不是自动生成的笔记堆3。
Fazapedia：把自己的人生编译成 Wiki #
Farza 看到 Karpathy 讲「把 LLM 当成 personal knowledge base 的编译器」这句话，直接共鸣了。他没有停留在转发和点赞，而是找一个周末，把几乎整个人生的数字痕迹全部丢给 Claude 处理。
不是几篇博客，而是 2500 多条本地素材：五年的 Apple Notes、私密原始日记、和朋友创始人的成千上万条 iMessage、一堆语音备忘录的转录。Agent 咀嚼了好几个小时，最后吐出来一个本地托管的 Markdown wiki，大概 400 篇互相链接的文章，起名叫 Fazapedia。
这个系统不光知道他的创业时间线，还知道他的朋友网络、他爱看的动漫，几乎把他整个人重建了一遍。Karpathy 看到之后直接盖章说这就是他心目中的 gold standard，是这套想法的教科书级落地。
对工作的实际收益 #
Faza 后面的用法更加实际。他不再每次从零给 Claude 写一个长 prompt 解释「我是谁、我喜欢怎样的设计、我做过哪些项目」，而是直接让 Agent 以 Fazapedia 为知识底座，去翻阅他过去的设计批评、项目总结和审美吐槽。然后只需要说「帮我为这个 side project 做一个 landing page」，Agent 就会自然带上他过去骂过的 UI 反模式、讨厌的配色、偏好的语气风格，一起写出页面和代码。
这就是从生成一次性答案，升级成基于自己的知识库做持续风格对齐和复用。
Karpathy 给出的四个 endorsement #
Karpathy 在后续讨论中给了四个非常工程化的 endorsement：
- Explicit（显式）：你可以清清楚楚读到模型知道什么，以纯文本形式存在，而不是一堆看不见的向量数组
- Yours（归你）：数据物理上在你控制的本地文件夹里，不被任何云端 SaaS 困住
- File over app（文件优先）：一切都是 Markdown，没有供应商锁定，任何编辑器、任何工具链都能接上
- BYOAI（自带 AI）：是你把模型插到这个文件夹上，而不是把自己的数据塞进某个模型提供方的黑盒
质疑与护栏 #
这不就是换皮的 RAG 吗？ #
反对的人会说，不管叫它 wiki 也好、compiler 也好，本质上还是要在一堆 Markdown 里检索，把相关内容塞进 context 再生成答案。
支持者强调三个差别：第一，知识是会写回去的；第二，模型是在一个已经被综合过、加过链接的中间层上工作；第三，多了一整套 lint 流程在主动维护结构。你可以这么理解：检索这一步确实还是 R，但 G 之前多了一层知识编译和健康检查。
AI Slop 的担心 #
你老让模型改模型自己写的东西，最后不会变成一锅 AI 废料吗？模型从人类原文里提炼出 wiki 已经有损耗了，下一轮再从 wiki 里读、再生成新的总结，损耗再叠一层。
这种担心是有道理的。这也是为什么 Karpathy 很强调 raw 目录的不可变性。raw 不能改，是随时可以回溯、校对、重新编译的那一份底稿。关键是在 schema 里明确规定什么场景必须回到 raw 对照，哪些结论不能只在 wiki 里闭环自转。
规模问题 #
不少人会问：现在玩的是一两百篇 wiki，lint 跑一跑还行，涨到几万篇、上千万字还能撑得住吗？
诚实地说，Karpathy 现在谈的确实偏个人研究和小型团队知识库。在这个量级上用 index 加下钻加适度 lint 是完全够用的。但如果你一上来就想拿它替代大型企业级 KM 系统，那确实需要更重的索引层。更合理的姿势是先承认它的 sweet spot 在个人和小团队，真把这块玩到上线了，再去谈规模化的分布式知识编译。
认知习惯的 tradeoff #
很多做 PKM 的人会说，写 wiki、整理笔记本来就不只是为了留一个 artifact，而是在这个过程中逼自己重新思考、重组认知。如果你把所有写作与整理都外包给 LLM，自己只看成品，确实有可能慢慢失去那种在整理中思考的肌肉。
我个人的建议是可以明确划分：命题型、需要严肃思考的内容，你自己写，AI 只做评论和补充；重复性高的结构化整理，比如把 50 篇访谈统一成一个对比表，让 Agent 去干。
生态与展望 #
如果这套思路只是 Karpathy 的一条推文或者 Farza 的一次人生实验，其实很容易被当成网红概念。但现在你能看到的是：llmwiki 已经有开源实现把三层架构跑通，QMD 这类本地 Markdown 搜索引擎在帮你解决 wiki 做大之后怎么搜的问题，Remember 则从另一个角度强调跨工具共享的结构化大脑，用的同样是 Obsidian 兼容的文件层。
这些都在印证一个方向：把知识堆在某个 SaaS 聊天窗里这条路线，正在被显式文件加本地工具加可插拔模型逐步蚕食。
结语 #
从 Karpathy 的那条推文出发，一路讲到了三层架构、Fazapedia、质疑和护栏。如果要用一句话收尾：在 AI 时代，我们真正的护城河不是多会写 Prompt，也不是多会堆 RAG 组件，而是有没有把自己的知识整理成一套可复利的知识代码库。
模型会变，框架会变，但这套 wiki 风格的文件层只要还在我们手里，就能持续接上下一代的 AI。如果你已经在用 Obsidian、Notion，可以试着问自己一个问题：从今天开始，你的 Token 要不要少花一点在写代码上，多花一点在编译知识上？