Karpathy 想把 AI 聊天框，变成一座会自己长大的“个人维基”
从“问一次找一次”，到“越用越懂你”
这两年，很多人用大模型处理文档，走的基本都是同一条路：把 PDF、网页、会议记录一股脑扔进去，然后靠 RAG——也就是检索增强生成——在你提问时现查现答。这个方法当然有用，NotebookLM、ChatGPT 文件上传、企业知识库问答，背后都差不多是这个逻辑。可问题也很明显：模型每次都像在临考抱佛脚。
Karpathy 这次在 GitHub 上发的《LLM Wiki》，厉害的地方就在于，他没有再讨论“怎么让检索更准”，而是换了一个问题：为什么每次都要从头找？为什么不能让大模型像一个勤奋到有点过头的研究助理，读完材料后主动把知识整理进一套持续演化的 Wiki 里？下次再问，它不是去原始资料堆里翻箱倒柜，而是直接在这套已经组织好的知识地图上工作。
这听起来像是个小小的工作流调整，实际上很像把“聊天”升级成“知识编译”。传统 RAG 的知识像临时拼出来的乐高，每次回答都拆了重搭；Karpathy 想要的是一栋楼，资料进来后先被消化、归档、挂链接、标冲突，之后越建越高。这个差别，恰恰击中了很多重度用户对大模型最深的怨念：它聪明，但不长记性；它能说，但不太会经营长期知识。
这不是另一个笔记工具，而是给 AI 一个“长期职位”
Karpathy 的设计很朴素，甚至朴素得有点“极客”：原始资料放一层，Wiki 放一层，再加一个 schema 文件，告诉模型该怎么写、怎么归类、怎么更新。这三层结构里，最关键的不是某个炫酷的模型能力，而是角色分工被重新定义了。
原始资料是事实底座，不让模型碰，避免“写着写着把史料改了”；Wiki 是模型维护的 Markdown 文件集合，包括人物页、概念页、主题综述、比较页、摘要页；schema 则像编辑部风格手册，规定栏目怎么设、标题怎么起、引文怎么落。Karpathy 甚至给出一个很形象的比喻：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。这个比喻妙就妙在，它承认知识管理不是一次性产物，而是一套需要持续维护的工程系统。
如果你平时写过笔记，大概会秒懂这件事有多诱人。人类并不是不愿意记录，而是不愿意做那些繁琐又机械的维护工作：补双链、改索引、更新旧页面、标注新旧观点冲突、把散落在不同文档里的同一件事串起来。大多数个人 Wiki 半途而废，不是因为主人不爱学习，而是因为维护成本会悄悄吃掉热情。LLM 恰好适合接手这类“脑力不高级，但极耗耐心”的活。
这也是为什么我觉得《LLM Wiki》虽然只是一个 idea file，却比很多“AI 知识库新品发布”更值得看。它不是把大模型硬塞进现有文档系统里，而是在问：如果默认 AI 是一个持续在岗的知识管理员，工具链应该怎么重做？
真正的价值，不在于总结资料，而在于制造“知识复利”
Karpathy 文中有一句话很打动人：好的回答，也应该回写进 Wiki。这个想法很容易被低估，但它其实是整个方案的灵魂。
今天我们和大模型聊完一大段内容，往往以一种非常浪费的方式结束：答案停留在聊天记录里，三天后谁也找不到，或者找到了也懒得整理。于是每次新问题出现，系统又得重来一遍。LLM Wiki 想做的，是把“问答”本身也纳入知识资产的积累过程。一张比较表、一段分析、一页演讲提纲，甚至一次对冲突观点的梳理，都可以作为新页面进入 Wiki，成为未来问题的前置成果。
这会让知识系统产生一种难得的复利效应。你读一篇论文，不只是多了一条摘要；你问一次问题，不只是得到一次回答。所有这些都在慢慢加厚那本由 AI 代笔、你来掌舵的“个人百科全书”。它不必像维基百科那样追求公共中立，也不必像学术数据库那样绝对规范，它更像是一套围绕你当前任务和兴趣不断重组的“第二大脑”，只是这回，那个帮你打理神经元连接的人，不再是未来某个更自律的你，而是一个不会嫌烦的语言模型。
这件事放到当下行业背景里尤其微妙。过去一年，AI 产品竞争已经从“谁的模型分数更高”慢慢转向“谁能嵌进真实工作流”。搜索、写作、编程之后，知识管理正在成为下一块硬仗。NotebookLM 很强，Perplexity 也在往研究助理方向走，企业里则有一堆 AI 文档助手盯着 Confluence、Notion、Slack 这些入口。但多数产品仍停留在“让信息更容易被问到”，Karpathy 的方向更进一步：让信息先被系统性吸收，再被反复调用。
理想很美，难点也一点不少
当然，LLM Wiki 绝不是一个“装好就能飞”的万能方案。它最先撞上的难题，不是技术炫不炫，而是知识治理。
第一层问题是准确性。让模型维护 Wiki，意味着它不只是生成答案，而是在改写中间知识层。一旦摘要带偏、概念抽象过头、把未证实的推断写成事实，错误就会被“固化”下来，之后还可能不断传播。RAG 的问题是每次都重新找，容易漏；Wiki 模式的问题是如果第一次整合错了，后面可能一路错下去。所以 Karpathy 才强调原始资料不可修改，强调日志、索引、lint，也强调人要参与摄取流程。这其实是在提醒大家：别把“自动化整理”误解成“自动化真理”。
第二层问题是 schema 设计。一个差的 schema，会把 Wiki 变成漂亮但空心的文件夹树。页面命名、概念层级、引用规范、更新策略、冲突标注方式，这些看似琐碎，最后决定了整套系统是会越长越清晰，还是越长越混乱。说白了，这不是买个软件就能解决的事，它更像是在训练一个长期合作者。你和 AI 之间，要逐渐形成默契和工作规范。
还有一个更现实的争议点：这种系统到底更适合个人，还是更适合团队？个人场景里，它足够灵活，也更能容忍主观性；团队场景里，信息源更多、协作收益更大，但权限、审校、责任归属都会变复杂。把 Slack 讨论、会议录音、项目文档自动汇总成团队 Wiki，听上去像所有管理者的梦想；可谁来保证敏感信息不被误归档？谁来批准“AI 对公司共识的概括”？这类问题，恐怕会比搜索精度更早出现在真实落地中。
一个 Gist 背后，藏着 AI 产品形态的下一步
我喜欢这篇《LLM Wiki》，还有一个原因：它带着 Karpathy 一贯的风格——不急着卖产品，而是先把一种工作方式讲明白。它像一张设计草图，交给 OpenAI Codex、Claude Code 或其他代理型 AI 去落地；也像一个信号，提醒开发者别只盯着更大的上下文窗口和更花哨的 Agent demo，真正有粘性的应用，往往来自那些会日积月累的系统。
大模型正在经历一个从“回答机器”到“记账先生”的转变。这个比喻听上去不够性感，但可能更接近生产力本质。真正改变工作方式的工具，未必是最会表演的那个，而是那个每天默默把脏活累活都干了、还把档案整理得井井有条的家伙。
从这个角度看，LLM Wiki 的意义不只是个人知识管理升级，更像是对下一代 AI 软件的一个预测：未来最有价值的 AI，不会只存在于对话框里，而会长期存在于你的文件系统、项目脉络、阅读轨迹和思考历史中。它不是一次性回答你，而是和你一起，把混乱的信息堆慢慢养成一座可居住的知识建筑。
如果这条路走通，最大的变化可能不是“AI 更聪明了”，而是我们终于不用再扮演自己生活里最不擅长的那个角色——资料管理员、文档维护员、笔记馆馆长。把这些琐事交出去，人类也许才能把脑力留给真正值得费神的部分：判断、怀疑、联想，以及提出下一个好问题。