当 Obsidian 像 IDE，LLM 像程序员，知识第一次开始像代码一样被持续维护
4 月初，Andrej Karpathy 在公开分享里提到，自己最近觉得特别有用的一件事，是用大语言模型为不同研究主题构建个人知识库；更值得玩味的是，他说自己最近大量的 token 消耗，已经不是花在“操纵代码”上，而是花在“操纵知识”上。对于一个长期被外界视为“最懂代码的人之一”的 AI 研究者来说，这句话的分量，远比一条普通的效率技巧帖要重得多。
这件事之所以会迅速引爆技术圈，不是因为 Karpathy 又推荐了一个新工具，也不是因为他发明了某种神秘架构，而是因为他点破了一个很多知识工作者都隐约感到、却一直没有被说透的问题：我们今天的大多数 AI 知识工具，其实擅长的是“回答”，却不擅长“积累”；擅长的是“把问题临时做对”，却不擅长“把知识长期留下来”。在他随后公开的 llm-wiki 说明文档中，这一点被说得非常明确：多数人今天把 LLM 和文档结合起来的方式，本质上仍然是 RAG，系统在每次提问时重新检索、重新拼接，知识并不会随着使用而复利增长。
很多高热度解读都把这种差异总结得很直白：RAG 的逻辑是“每问一次，就重新去文档里翻一次”；而 LLM Wiki 的逻辑是“每加入一个新来源，系统就把关键信息抽取出来，更新到已有知识结构里，后面的问题都建立在这个不断变厚的底座之上”。换句话说，前者是在一次次“重新发现知识”，后者是在一点点“编译知识”。这正是它最吸引人的地方。
一、真正击中人的，不是工具，而是那个所有人都经历过的知识困境
几乎每个知识工作者都熟悉这种场景：你读过很多文章，存过很多链接，做过很多笔记，开过很多会，也和 AI 聊过很多轮深度问题；但几周之后再回头看，真正能被稳定调用的，往往少得可怜。信息并不少，甚至可以说是爆炸式过剩，真正稀缺的，是一种能够把阅读、思考、比较、修订、串联与追问持续保存下来的机制。Karpathy 的这套思路会火，本质上是因为它抓住的不是“信息获取”的问题，而是“知识维护”的问题。
过去几年，RAG 当然已经非常有用。你把 PDF、网页、报告、会议纪要丢进去，系统按 chunk 切分、做索引、召回相关片段，再把结果交给模型生成答案。这套机制能够显著提升问答质量，也让“对文档提问”成为很多人接触 AI 的第一个高频场景。但 Karpathy 指出的关键问题也非常尖锐：只要系统的主要工作仍然发生在“提问时”，那么每一次问答，本质上就还是一次临时施工。你今天问一次，模型就从头检索、从头综合；你明天换个角度再问，它仍然要从头来过。系统可能会给你答案，却不一定会因此变得更懂这个主题。
这也是为什么很多人会觉得，现有 AI 工具“很好用，但总差一口气”。它们适合快速处理单次任务，却不天然适合支撑一个月、三个月、半年以上的深度研究。它们能把眼前这道题答出来，却很难像一个真正的研究助手那样，在长期合作中越来越理解你在追什么问题、哪些概念重要、哪些判断已经过时、哪些材料之间存在冲突。Karpathy 的 LLM Wiki，恰恰是在试图补上这一层。
二、RAG 不是错了，而是它解决的是“找到”，不是“留下”
很多讨论一上来就把 LLM Wiki 说成“替代 RAG”，这其实有点过于简单。更准确地说，RAG 解决的是“如何从大量原始材料中找到当前问题相关的片段”，而 LLM Wiki 解决的是“如何把已经读过、问过、比较过的内容，沉淀成一个越来越有结构的知识资产”。前者更像即时检索，后者更像持续编译。前者擅长把仓库翻出来，后者擅长把仓库整理好。
如果借用软件工程的比喻来理解，这两者的差别会非常清楚。传统 RAG 很像解释执行：每次运行时，系统都要从原始文本里重新找上下文、重新拼装答案。LLM Wiki 更像编译流程：原始材料先被处理成结构化的中间层，实体页、概念页、摘要页、索引页、日志页彼此连通，新资料进来时不是简单地“加一个文件”，而是让整套知识系统一起更新。查询阶段只是调用这个已经维护过的知识面，而不是每次从废墟里重新挖。这个比喻虽然不是原始说明里的技术术语，但非常准确地表达了它的核心思想。
真正让人眼前一亮的，不是“AI 会自动做摘要”，而是“摘要、交叉引用、概念页、冲突标注、索引更新、回答回写”第一次被放进了同一个长期工作流里。你不是在用 AI 临时消费文档，而是在让 AI 参与构建一套会越来越能用的知识底盘。
三、LLM Wiki 的本质，是在原始材料和最终答案之间，插入一个可维护的中间层
这套体系可以拆成三层：第一层是原始材料，也就是你亲自收集的文章、论文、图片、数据文件等，这一层是不可变的，LLM 只读不写，它是你的“事实源”。第二层是 Wiki，也就是由 LLM 生成和维护的一组 Markdown 文件，包括摘要页、实体页、概念页、比较页、总览页和综合页。第三层是 schema，也就是告诉 LLM 应该如何组织知识、如何命名、如何引用、如何在摄入、回答、维护时遵循统一规则的那份说明文档。
这三层设计看起来并不复杂，但真正高明的地方在于职责分离。原始材料负责可追溯，Wiki 负责可阅读、可导航、可复用，schema 负责让 LLM 不再像一个随意发挥的聊天机器人，而更像一个有工作规范的知识管理员。很多人第一次接触这一思路时，容易把注意力放在 Obsidian、Markdown、插件、索引工具这些“表层实现”上，但它真正提供的，其实是一种组织 AI 劳动的方式。不是“让模型答得更像人”，而是“让模型持续承担整理、归档、补链、修订、检查这些重复性维护工作”。
这一步看似只是多插入了一个 Wiki 中间层，实际上却改变了整个知识系统的时间结构。以前，原始材料和最终答案之间几乎是直连的，所以每次提问都要重新建桥；现在，中间多了一个持续生长的结构层，于是每一次阅读、每一次提问、每一次比较，理论上都可以留下痕迹，成为后续工作的起点。知识不再只在聊天窗口里闪现一下，而是开始拥有“版本”“链接”“历史”“上下文”和“延续性”。
四、三种动作：摄入、查询、体检，才是这套系统真正跑起来的关键
这套系统可以被理解为三个核心操作：ingest、query 和 lint。Ingest 不是把材料“放进去”那么简单，而是把新来源真正吸收进知识库：模型读取原文，和你讨论重点，写出摘要页，更新索引，再同步修改相关实体页和概念页，最后把这次动作记录进日志。一个来源可能同时触及 10 到 15 个 Wiki 页面。这意味着新资料不是孤零零地躺进仓库，而是会立刻引发一轮系统级更新。
Query 也不是传统意义上的“问答”。在这套模式里，你是在向 Wiki 提问。模型会先看索引，再钻进相关页面做综合，并且根据问题形式输出不同结果：可以是新的 Markdown 页面，可以是比较表，可以是 Marp 幻灯片，也可以是 matplotlib 图表。更重要的是，这些高质量回答不是一次性消费品，而可以被重新写回 Wiki，成为后续知识结构的一部分。很多真正有价值的探索，不应该消失在聊天记录里。
Lint 则是这套系统最容易被低估、却最体现“知识工程”味道的环节。它不是让模型再生成一篇漂亮总结，而是让模型像维护代码库那样，对整个 Wiki 做健康检查：看有没有互相矛盾的页面，有没有被新材料推翻的旧判断，有没有没人链接到的孤儿页，有没有已经频繁出现却还没有独立页面的重要概念，还有哪些知识缺口值得继续补齐。对一个知识库来说，这一步就像 CI、测试和重构。没有它，系统只会越来越胖；有了它，系统才有机会越来越清晰。
五、为什么这套思路会让人兴奋？因为它第一次把“知识维护”做成了低边际成本的工作
维护知识库最讨厌的部分，不是阅读，也不是思考，而是记账式的维护工作——更新交叉引用、保持摘要同步、标注新旧结论的冲突、确保几十个页面之间口径一致。正是这些看起来不“高智商”、却极其繁琐的琐碎劳动，让绝大多数个人 Wiki 和团队知识库最后都变成了半废墟。人不是不想维护，而是维护成本很快超过了收益。
而 LLM 恰恰擅长做这种“无聊但必要”的劳动。它不会嫌麻烦，不会忘记补一个反向链接，不会因为要同时修改十几份 Markdown 就情绪低落。只要规则写清楚、上下文给得足够、校验机制跟得上，它确实可以把大量原本不值得人类亲自做的机械性维护成本压到很低。于是，知识库第一次有可能不是因为“用户够勤奋”而活着，而是因为“维护这件事终于足够便宜”。这才是 LLM Wiki 最有潜力的地方。
还有一个很现实、却经常被忽略的优点：它是可检查的。本质上，这套 Wiki 就是一组 Markdown 文件，甚至可以直接作为 git repo 来管理，天然拥有版本历史、分支和协作能力。相比把知识锁在某个黑箱 SaaS 里，这种文件化、结构化、可追踪的方式，对严肃研究、长期主题积累、团队知识协作，都更友好。你不只是获得了一个更会回答问题的模型，而是获得了一个可以被人类审阅、修改、回滚和继承的知识工程产物。
六、它最适合的，从来不是“所有人所有问题”，而是那些需要持续积累的问题
这套思路非常适合以下场景：个人层面可以追踪目标、健康、心理、自我改进；研究层面可以围绕一个主题持续读论文、看报道、做综合；读书时可以为人物、主题、线索建立互相连接的页面；团队场景里可以把 Slack 讨论、会议纪要、项目文档、客户沟通等源源不断喂进去，让内部 Wiki 保持常新；除此之外，竞品分析、尽调、旅行规划、课程笔记、爱好深挖，都是适用场景。
把这些场景放在一起看，会发现它们有一个共同点：它们都不是“一次问完就结束”的问题，而是“越研究越复杂、越积累越值钱”的问题。LLM Wiki 不是为了帮你更快搞定一份临时报告，而是为了让你在一个主题上越走越深时，不至于每次都重新开荒。它最适合的用户，也往往不是只想“快速看个总结”的人，而是那些需要持续构建自己判断框架的人：研究者、投资人、记者、分析师、产品经理、长期创作者，甚至是任何把“理解”当成工作的人。
从这个角度看，它其实也不只是“个人第二大脑”的升级版，而更像是一种“AI 参与知识生产”的新分工：你负责选题、判断、取舍、方向和最后的责任；模型负责搬运、归档、连线、更新、整理、体检和初步综合。人类不再把精力浪费在维护目录和修反向链接上，而把脑力放在更少数、但更关键的问题上：什么值得进入系统？什么值得怀疑？什么值得被反复追问？
七、真正值得警惕的，不是它不够酷，而是很多人会把它想得太轻松
当然，LLM Wiki 绝不是“把资料丢进去，真理自动长出来”的魔法。即使 LLM 可以自动维护 Wiki，人类依旧不是可以彻底退场的。至少在高质量知识场景里，人的策展、校对和提问能力，仍然是系统上限的一部分。
其次，这套模式并不意味着规模问题已经被彻底解决。靠 index.md 先导航、再深入页面，在中等规模时效果往往已经很好，因此可以先不依赖复杂的 embedding-based RAG 基础设施。但随着 Wiki 继续长大，还是可能需要更正规的搜索工具。这说明 LLM Wiki 不是没有扩展性问题，而是把问题推迟到了一个更可控的阶段：先在文件系统和知识结构层面把事情做对，再决定何时上更复杂的检索。
更深一层的风险在于“综合幻觉”。一旦模型长期参与生成摘要、概念页、结论页，它确实有可能把某种未经充分核验的综合判断，逐渐写成系统里看起来很像常识的东西。越是结构清晰、链接完备的知识库，越容易让人产生“既然都写成这样了，应该已经很可靠”的错觉。所以 LLM Wiki 的真正挑战，不只是搭建，而是建立一套持续验证的伦理：哪些页面必须引用原始来源，哪些判断必须保留争议，哪些结论只能作为工作假设，而不能升级成系统共识。这个问题，不会被任何插件自动解决。
八、它真正预告的，不是一个爆款笔记法，而是 AI 角色的变化
为什么这次的分享会让人觉得“味道不一样”？因为它背后其实藏着一个更大的信号：我们对 LLM 的期待，正在从“即时回答器”转向“长期知识工人”。过去两年，大家最着迷的还是让 AI 写代码、写文案、写周报、写 SQL，或者在一个巨大上下文窗口里一次性塞进尽可能多的资料，希望它现场给出漂亮答案。但 LLM Wiki 提醒我们，也许真正更有复利价值的，不是一次塞更多，而是让系统拥有可维护的长期记忆层。
从更长的视角看，这甚至可能改变我们理解“知识库”的方式。过去，知识库常常被视为存储系统；现在，它越来越像一种持续运行的认知基础设施。它不是死的仓库，而是活的中间层；不是你写完就封存的文档集合，而是你和 AI 一起不断加工、不断澄清、不断纠错的工作表面。真正重要的，不再只是你保存了多少材料，而是这些材料有没有被组织成一张可继续思考的网。
值得一提的是，围绕这类方法论的进一步整理，也越来越多地出现在面向协作和知识沉淀的平台之中，例如一些团队会把相关框架、实践模板和研究记录统一收进长期维护的知识页中，例如：lcn4efxan5r4.feishu.cn/wiki/Vg5xwv… 。这类做法本身，也从侧面说明了“知识需要持续维护”正在成为越来越多人的共识。
九、结语：RAG 回答眼前的问题，LLM Wiki 经营的是时间
如果一定要用一句话概括这次引爆的话题，我会说：它不是提出了一个新的笔记法，而是重新定义了“AI 该如何参与知识工作”。在这套模式里，AI 的价值不再只是更快生成答案，而是更低成本地维护结构，让知识从一次次回答里沉淀出来，形成可复用、可追踪、可修订、可继承的长期资产。
RAG 当然不会消失，搜索也不会过时，向量数据库更不会因为一波讨论热度就被判死刑。但这套 LLM Wiki 思路至少提醒了我们一件事：下一代知识系统的竞争，未必发生在“谁搜得更快”，而更可能发生在“谁能把已经搜到、问过、想过、比过的内容，真正留下来”。当知识第一次像代码一样可以被持续维护，我们面对的就不只是一个更好用的工具，而是一种新的生产方式。
