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是数据库,这是文件系统;一个卖协作,一个卖可迁移性。当你的笔记要跟着你走十年,这个区别会越来越大。
你现在的笔记系统,五年后还能无痛迁移吗?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.