卡帕西最近在干一件特别狠的事：用大模型给自己造一个私人知识wiki。整个过程就是先收集原始资料，再用LLM把这些资料自动编译成一个结构化知识库，然后在这个知识库上直接问问题、做研究、写报告。你不再手动整理笔记，你变成了一个知识系统的管理者。
第一步：搞一个raw文件夹把所有东西扔进去
咱们先聊聊最开头那步。你猜卡帕西第一件事干了啥？他建了一个文件夹，名字就叫 raw/。就这么简单粗暴。这个文件夹是干嘛的？就是用来装所有原始资料的垃圾场，不对，应该叫宝库。他把论文、文章、代码仓库、截图、PDF，反正跟某个主题相关的东西，全往这个 raw/ 里塞。
这里有个关键动作你得看明白：他不挑食。不管资料质量高低、格式是啥，先存进去再说。这就像你准备考试的时候，把老师发的所有课件、网上搜的笔记、学长给的真题，一股脑全放一个文件夹里。区别在哪？区别在于你不是自己去看，你是准备把这些东西喂给LLM。
他还用了一个叫 Obsidian Web Clipper 的插件。这玩意儿干啥的？你正在浏览器里看一篇网页文章，点一下这个插件，它就能自动把网页转成 .md 格式的markdown文件，然后存到你指定的地方。更骚的是，它还会把网页里的所有图片也下载到本地。为啥要下载图片？因为现在的大模型是多模态的，也就是说它能看懂图片。你喂给它带图的资料，它理解得更透彻。
这一步做完之后，你的 raw/ 文件夹里就有了几十上百个markdown文件，每个文件都是一篇原始资料，图片也都在旁边整整齐齐地放着。你这时候还啥都没干呢，就是点了几下鼠标。但你的知识库已经打好地基了。
第二步：让LLM把原始资料编译成wiki
好，原始资料堆在那儿了，现在该干正事了。卡帕西的做法是：让LLM把这些乱七八糟的markdown文件，一个一个地“编译”成一个wiki。
你得理解“编译”这个词在这儿的意思。你写代码的时候，源代码是人类写的，但电脑看不懂，你得编译成机器码才能运行。现在的情况是：你的原始资料是人类写的文章，乱七八糟不成体系，你得让LLM把它“编译”成一个结构清晰、相互链接的wiki页面。
具体怎么干？他写了一些脚本，或者说用了一些自动化流程，让LLM读取 raw/ 里的每一个markdown文件，然后做这几件事：总结这篇文章的核心内容、提取关键概念、找出这篇文章跟其他文章的关系、自动生成双向链接。最后LLM会输出一个新的markdown文件，这个文件就是编译好的wiki条目。
你发现没有，你几乎没动手。你就是定了个规则：“LLM啊，你帮我把这个文件夹里的所有东西整理成一个wiki”。然后LLM就开始吭哧吭哧干活了。它一篇一篇地读，一篇一篇地总结，一篇一篇地建立链接。过了一段时间，你再打开Obsidian，你看到的不是一堆散乱的原始资料，而是一个已经初具规模的个人维基百科。
这里面还有一个细节值得你记住：卡帕西说他很少手动编辑这些wiki条目。也就是说，他充分信任LLM的输出质量。就算LLM总结得有点偏差，他也选择接受，或者只是轻微调整一下规则让下一次输出更好。他不是在做一个完美的wiki，他是在做一个够用的、能不断进化的wiki。
第三步：把Obsidian当成知识IDE来用
这时候你的wiki已经有模有样了，你怎么操作它？卡帕西的选择是：用Obsidian。但他用Obsidian的方式跟你用记事本完全不是一回事。他说他把Obsidian当成IDE来用。
IDE是啥你知道吧？就是程序员写代码的那个环境，像VS Code或者PyCharm。你在IDE里能干的事不只是写代码，你还能看代码结构、调试程序、运行测试、管理依赖包。卡帕西在Obsidian里干的事也差不多：他看原始资料、看LLM编译后的wiki条目、看概念之间的链接关系、看自动生成的图表和可视化。
他还用了Marp这个插件。Marp是干啥的？它能让你用markdown语法直接写幻灯片。你在Obsidian里写一篇笔记，用 --- 分页，用 # 表示标题，然后Marp就能把这篇笔记变成一套完整的PPT。这意味着什么？意味着你的知识输出流程被大大简化了。你问LLM一个问题，LLM给你写了一篇带图表的报告，你直接在这篇报告上加几个分页符，一套PPT就做好了。
你再看Obsidian在这整个流程里的角色：它不只是一个编辑器，它是一个知识操作系统。你在这个系统里完成所有跟知识相关的事：收集、整理、查询、输出。而你不需要切换软件，不需要复制粘贴，不需要手动同步。所有东西都在一个地方，所有操作都在一个界面里。
第四步：在你的wiki上直接问问题让LLM自动找答案
当你的wiki规模变大之后，比如有了一百篇文章、四十万字的内容，好玩的事就来了。你可以在Obsidian里直接打字问问题，LLM会基于你的整个wiki来回答。
这个功能是怎么实现的？卡帕西没有用复杂的RAG系统。RAG是啥你知道吧，就是检索增强生成，听起来很高大上。但卡帕西说：不用，LLM自己就能搞定。因为你的wiki结构足够清晰，LLM可以直接读取整个wiki或者相关部分，然后基于这些内容生成答案。
具体流程是这样的：你问一个问题，你的脚本或者插件把这个问题和你的wiki内容一起发给LLM。LLM先阅读所有相关的wiki条目，理解它们之间的关系，然后整合信息，最后给你一个完整的答案。这个答案不是从网上随便搜的，不是LLM自己瞎编的，而是完全基于你自己收集和整理的那些资料。
这就厉害了。你问“我家猫的神经信号传输速度是多少”，LLM会去找你wiki里关于猫神经系统的论文。你问“反向传播算法怎么推导”，LLM会去找你wiki里关于深度学习的笔记。这些资料都是你自己挑的、你自己信的，所以答案的可靠度比随便问一个通用大模型要高得多。
而且你不需要手动去翻那四十万字。你只需要打字提问，LLM帮你翻。你从“资料查找员”变成了“问题提出者”。你花在找资料上的时间变成零，花在思考和提问上的时间大大增加。
第五步：让LLM给你的wiki做质量检查和自动补全
光能回答问题还不够，卡帕西还让LLM干了一件事：主动维护你的wiki。LLM会定期扫描你的整个知识库，找出不一致的地方、缺失的信息、潜在的新主题。
不一致是啥意思？比如你wiki里有一篇文章说“地球半径是6371公里”，另一篇文章说“地球半径是3959英里”。这两条信息本质是一样的，但单位不同。如果LLM不够聪明，它可能当成两个不同的数字。但卡帕西的LLM会发现这个不一致，然后主动问你要不要统一单位，或者自动把两条信息关联起来。
缺失信息就更常见了。你wiki里有一篇关于“Transformer模型”的文章，里面提到了“注意力机制”，但你wiki里没有关于注意力机制的专门条目。LLM会发现这个缺口，然后主动去你的原始资料文件夹里找，或者直接问你要不要生成一篇关于注意力机制的总结文章。
潜在新主题是最好玩的部分。LLM分析了你的所有笔记之后，可能会发现你对“猫”和“量子物理”都很感兴趣，但它找不到任何把这两者联系起来的资料。于是它会建议你：“老板，你的wiki里没有关于‘薛定谔的猫’的内容，要不要补一篇？” 你看，LLM不只是在帮你整理现有的知识，它还在帮你发现你应该知道但还不知道的东西。
所有这些维护工作，LLM都是自动完成的。你不用每天打开wiki去检查哪里有问题，LLM会主动告诉你。你只需要在它提出问题的时候点一下确认，或者直接让它自己决定。你越来越像一个管理者，而不是一个操作工。
第六步：自己写工具来扩展这个系统的能力
现成的工具用了一段时间之后，你可能会发现有些功能没有、有些操作不方便。这时候卡帕西的选择是：自己写工具。他写了一个简单的搜索引擎，专门用来搜他的wiki。他还写了一个Web界面，让他在手机或者平板上也能访问这个wiki。他还写了一个CLI工具，也就是命令行工具，让他在终端里也能直接问LLM问题。
你注意这个转变有多关键。刚开始你只是用别人的工具：Obsidian是别人写的，LLM是别人训练的，插件是别人开发的。但现在你开始写自己的工具了。你不是在“使用”这个系统，你是在“构建”这个系统。
而且这些工具不是给你自己用的，至少不完全是。那个搜索引擎，看起来是给你搜资料用的，但更重要的用途是让LLM能更快地找到相关文档。那个Web界面，看起来是给你远程访问用的，但更重要的用途是让LLM能通过API来读取和写入wiki。你在给自己的AI小弟配装备。
这一步走完之后，你从“工具使用者”变成了“工具创造者”。你不再受限于现有软件的功能，你可以根据自己的需要任意扩展这个知识系统的能力。你今天觉得LLM回答问题太慢，明天就可以写一个缓存机制。你今天觉得LLM总结文章不够详细，后天就可以写一个提示词优化器。这个系统变得完全听你的话，因为有一部分代码是你亲手写的。
第七步：用wiki数据做微调让LLM把知识写进权重
前面几步做完之后，你的wiki已经是个很牛的东西了。但卡帕西觉得还不够，他想要更快的速度、更低的成本、更深的融合。他的方案是：用wiki里的数据去微调一个LLM。
微调是啥意思你知道吧？就是在一个已经训练好的大模型基础上，用你自己的小规模数据集再训练一下，让这个模型更适应你的特定任务。卡帕西的做法是：把他wiki里的所有文章整理成一个训练集，然后用这个训练集去微调一个开源的大模型，比如Llama或者Mistral。
微调之后会发生什么？LLM不再需要每次回答问题都去读取你的wiki文件了。那些知识已经被写进了模型的权重里。权重你可以理解成模型大脑里神经元之间的连接强度。知识被写进权重之后，模型对它的反应速度就跟对它自己的训练数据一样快。
这个转变太本质了。之前你的LLM回答问题时，流程是：读你的问题、读你的wiki文档、理解文档内容、生成答案。这是开卷考试，每次都要翻书。微调之后，流程变成：读你的问题、直接从权重里提取相关知识、生成答案。这是闭卷考试，但书已经被它背下来了。速度更快，成本更低，而且因为不需要在prompt里塞一大堆文档，上下文窗口的压力也小了。
卡帕西说这一步是未来的方向。你现在用wiki来辅助LLM回答问题，但最终你会让LLM直接把wiki里的所有知识吸收掉，变成它自身的一部分。你的知识库不再是挂在LLM外面的一个附件，而是长在LLM里面的一个器官。
第八步：设想一个终极形态一问问题就启动一整个AI团队
最后这个设想真的有点科幻，但卡帕西认真提出来了，咱们也得认真听。他说未来的理想形态是这样的：你问一个问题，不是调用一个LLM来回答，而是自动启动一整个AI团队。
这个团队怎么运作？首先有一个项目经理AI，它负责理解你的问题，然后拆解成子任务。接着有一个研究员AI，它去你的wiki里搜索相关资料。还有一个分析师AI，它负责整理这些资料，找出关键信息。还有一个写手AI，它负责把分析结果写成一篇结构完整的报告。还有一个质检AI，它负责检查报告有没有错误或者遗漏。最后还有一个汇报AI，它负责把最终报告用你指定的格式呈现出来，比如markdown、PPT、PDF。
所有这些AI同时工作，互不干扰。项目经理AI协调它们之间的配合。整个流程可能是几分钟或者几十分钟，取决于问题的复杂程度。你只需要在开始时问出那个问题，然后在结束时收到一份完整的报告。中间的过程你完全不需要参与。
卡帕西说这个设想远远超过了 .decode()。.decode() 只是一个格式转换，从字节变成字符串。但他设想的这个流程是一个多智能体协作系统，从一个问题变成一份研究报告。这不是在生成文字，这是在执行一个复杂项目。
你再看这个终极形态跟第一步的关系。第一步你只是在 raw/ 文件夹里堆资料。到了这一步，那些资料已经变成了一个AI团队的工作基础。你的角色从头到尾都没变过：你不是在执行任务，你是在定义任务。你不是工人，你是老板。你不是在回答问题，你是在让一个团队帮你研究问题。
这事儿为啥能让你背后一凉？
如果你现在，也就是此时此刻，还在坚持手动做笔记，用 Ctrl+C 和 Ctrl+V 来整理资料，像个勤劳的小蜜蜂一样自己慢慢查资料、慢慢归纳总结。那你就得接受一个现实：你在这个知识的赛场上，已经落后了一个版本。新的游戏规则已经变了，玩家们都不再亲自下场搬砖了。他们不再做知识的搬运工，而是成为了知识系统的管理者、设计师和指挥官。他们手里的牌，不是一本本的笔记，而是一个个由AI驱动的、会自我进化的知识帝国。
所以，未来衡量一个人学习能力的标准，可能不再是“我脑子里记住了多少东西”，而是“我构建了一个多强的、能为我自动学习和思考的知识系统”。这听起来很酷，但也真的很吓人，因为这意味着我们过去十几年学到的那些“勤奋学习”的方法论，可能马上就要过时了。
不过换个角度想，也挺好，毕竟谁不想当个每天喝喝咖啡、给AI小弟们开开会、就能让知识蹭蹭往上涨的“超级老板”呢？
总结一句人话
未来的学习方式，再也不是你吭哧吭哧学了多少，而是你大手一挥，指挥你的AI小弟们，帮你建了一个多牛的、会自己长大的“知识宇宙”。
作者背景
Andrej Karpathy：斯坦福博士，OpenAI创始成员，前Tesla AI高级总监，深度学习与大型语言模型领域的顶级工程与研究权威。
卡帕西追评
我想分享一个可能稍微优化过的版本，把它放在一个“点子文件”里。这个“点子文件”的核心想法是：在现在这个有大语言模型智能体的时代，分享具体的代码或应用已经没那么重要/没必要了，你只需要分享想法，对方手里的智能体就会根据他的具体需求，帮你定制和搭建出来。
所以，我把这个想法放在了这个代码片段里：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
你可以把这个链接交给你的智能体，它就能帮你建一个属于自己的 LLM 维基，并指导你怎么使用等等。我是故意写得有点抽象和模糊的，因为这个方向可以玩出太多花样了。当然，大家也可以在这个讨论区里修改这个想法，或者贡献自己的点子，这样也挺酷的。