52447个Markdown文件，没有向量数据库，没有RAG管道，没有MCP服务器。这就是作者用了十年的个人知识库。
Andrej Karpathy最近发推，讲用LLM（大语言模型）搭建个人知识库：把原始资料丢进文件夹，让AI"编译"成互相关联的Markdown wiki，再用Obsidian查看。他还附了一份"idea file"，直接扔给AI代理就能搭好整套系统。
作者看到这条推，被同事追问细节。他的回应很直接：这套玩法我玩了十几年，根本不用搞什么特殊基建。文件系统本身就是图数据库，LLM就是查询引擎。
5万条笔记的底层结构
作者的结构借自Tiago Forte的"Building a Second Brain"，PARA分类法打底，再按实际工作习惯扩展：
/projects/{项目名}
/areas/{主题领域}
/people/{Slack用户名}
/daily/{年}/{月}/{日}/
/meetings/{年}/{月}/{日}/
每个会议结束后，AI代理自动在daily目录下创建笔记，下载附件里的Google Doc，再链接到对应的人物笔记。和老板JP的1:1，会挂上[[/people/jp|jp]]的链接，以及讨论过的项目链接。
几个月后，每个人的笔记变成时间线：每次对话、每个决策、每个待跟进事项。每个项目文件夹攒下所有相关产物。你不用记东西在哪，图结构替你记。
为什么文件夹+链接就够了
作者的核心观点很锋利：Wiki链接（[[target]]）就是语义边，文件就是节点，文件夹分类就是schema（模式定义）。LLM读得懂自然语言，也读得懂这套结构。
他举了个场景。写设计文档、性能评审包、项目交接、新人 onboarding——这些任务 traditionally 要花几小时翻Slack、翻邮件、翻记忆，还漏东西。知识库把这变成系统行为，而非临时 scramble（ scramble 这里指手忙脚乱地拼凑）。
更关键的是，这套系统没有供应商锁定。纯文本文件，任何工具都能打开。Obsidian只是查看器，换成VS Code、换成终端、换成任何未来的笔记软件，底层数据完全可迁移。
对比现在流行的RAG方案：向量数据库、embedding模型、检索管道、重排序算法……作者的态度近乎嘲讽——你们把简单问题复杂化了。
AI代理的实际工作流
作者没讲具体用哪个模型，但描述了代理的行为模式。会议结束后，代理执行固定动作：创建日期笔记、下载附件、提取关键决策、更新人物时间线、标记待办。
这些动作不需要精密编排。LLM理解"JP上周提到的那个性能瓶颈"这类模糊查询，因为它能在/people/jp的笔记里找到时间线，再顺着链接跳到对应的项目文档。
图结构的威力在这里：一次遍历，上下文自然展开。不需要预定义的SQL join，不需要向量相似度计算，不需要人工打标签。
作者提到一个细节：他会在人物笔记里记录"open thread"（悬而未决的事项）。下次开会前，代理自动汇总这些未闭环的讨论。这种"渐进式积累"替代了"会前临时回忆"。
这套玩法的边界在哪
作者没回避限制。文件系统查询的延迟，随笔记数量线性增长。5万条还能秒开，50万条呢？他没测过。
多人协作也是盲区。这套系统是个人知识库，不是团队知识库。Slack里的集体决策被摘录进来，但实时同步、冲突解决、权限管理——文件系统不解决这些。
还有，LLM的幻觉问题没消失。代理可能链错链接，可能误解会议内容，可能把"JP说的"和"你说的"搞混。作者的对策是人工复核关键决策的链接准确性，但没说具体频率。
最诚实的坦白在最后：他承认自己"收集了可能太多的Markdown文件"。5万条里，有多少是僵尸笔记？多少链接已经失效？多少项目文件夹里的内容再也不会被打开？
图数据库解决了"找到"的问题，但没解决"值得保存"的判断。这个筛选工作，目前还得人来干。
Karpathy的推火了之后，评论区有人问：这和Notion/Confluence有什么区别？作者的答案藏在结构里——Notion是数据库，这是文件系统；一个卖协作，一个卖可迁移性。当你的笔记要跟着你走十年，这个区别会越来越大。
你现在的笔记系统，五年后还能无痛迁移吗？
热门跟贴