本文来自微信公众号： 曼谈AI ，作者：曼谈AI，原文标题：《我用 Andrej Karpathy 的方法重建了 Obsidian 知识库，太香了！》
Andrej Karpathy昨天发了条推文，说他现在大部分token消耗不是在写代码，而是在用LLM管理知识。他把原始素材（论文、文章、数据集）扔进一个目录，然后让LLM "编译"成一个wiki——一堆.md文件，有摘要、有分类、有反向链接，全部由LLM维护，人基本不碰。
我看完第一反应：这不就是我想要的吗？我的Obsidian一直是个"高级收藏夹"——文件扔进去就不管了，偶尔打开翻翻，找东西全靠记忆和搜索。30个markdown文件，7个PDF报告，散落在"新闻""报告""洞察""笔记"几个目录里，互相之间没有任何关联。
于是我花了一个小时，用Claude Code把整个vault按Karpathy的思路重建了。过程中有几个认知上的转变，比方法本身更值得聊。
改造：从"收藏夹"到"编译型知识库"
Before:高级收藏夹vault/新闻/(8篇日报)报告/(PDF+md混放)洞察/(2篇笔记)笔记/(3篇)录音/(1篇转写)论文/(空的)30个文件，零关联，6份PDF沉睡After:编译型知识库vault/INDEX.md+MOC.mdraw/(PDF,录音,剪藏)inbox/(待处理日报)wiki/(LLM编译产物)concepts/insights/projects/output/(生成的输出)35篇互链，6份PDF全部激活
改造前后的vault结构对比
原来的vault结构很典型——按内容类型分文件夹：新闻、报告、洞察、笔记、论文。看起来整齐，但有个致命问题：原始素材和提炼后的知识混在一起。一篇SemiAnalysis的40页PDF和我写的3段洞察笔记放在同一层级，信息密度差了一个量级，却享受同等待遇。
Karpathy的核心设计是raw/和wiki/的分离。原始素材是原始素材，编译产物是编译产物，中间有一个LLM做"编译器"。这个隐喻很精确——不是在"整理"知识，而是在"编译"知识。就像源码和可执行文件的关系。
改完之后的结构：
迁移文件只花了十分钟。重头戏在下一步。
编译：让LLM把PDF "读"成知识
raw/PDF报告网页剪藏录音转写LLM编译器提炼/分类/关联/链接wiki/concepts/概念文章insights/报告洞察projects/项目知识INDEX.md全局索引MOC.md知识地图原始素材Claude Code结构化知识
核心流程：原始素材经过LLM编译，变成结构化的wiki
raw/reports/里躺着6份PDF——Gartner、SemiAnalysis、Omdia的行业报告。之前只有2份被我手动写了读书笔记，其他4份下载后就没打开过。
我让Claude Code逐个读取PDF，提炼成中文洞察文章。不是翻译，不是摘要，而是提取3-5个核心判断，每个判断附上论据和我的评注。比如SemiAnalysis那篇GPU租赁报告，40页内容编译成一篇800字的文章，核心判断是：H100租赁价格6个月涨了40%，需求驱动，On-Demand全部售罄。
4份PDF同时编译，几分钟后wiki/insights/多了4篇文章，每篇都有frontmatter（标题、标签、日期、来源链接）和Obsidian反向链接。
然后是更有价值的一步：我发现这几篇报告有一个共同的交叉节点——推理成本。Gartner在讲中美推理成本差异，SemiAnalysis在讲GPU租赁价格，Omdia在讲OpenClaw带来的token消耗爆发。于是LLM自动生成了一篇概念文章《推理成本》，把散落在不同报告里的数据串成了一条逻辑链。
这就是"编译"和"摘要"的区别。摘要是把每篇文章缩短，编译是把多篇文章里的知识重新组织成概念网络。
交互：Wiki不是终点，是起点
知识库建好之后，我试了一件事：直接问Claude Code一个跨报告的问题——"GPU租赁价格还在涨吗？对AI漫剧生产成本有什么影响？"
Claude Code先读了wiki里SemiAnalysis的两篇编译文章（截至4月初的数据），然后联网搜了最新的市场价格做交叉验证，最后把wiki里的AI漫剧行业数据拉过来做关联分析。
结论是反直觉的：GPU租赁涨了40%，但漫剧生产成本反而从2000-5000元/分钟降到了400元/分钟。因为头部团队在自建算力池+用开源模型，工具链自动化降了人力成本，模型效率也在提升。GPU涨价对依赖API的小团队是灾难，对自建算力的头部团队几乎无感。
这个分析质量让我意外。不是因为LLM有多聪明，而是因为它有足够的上下文。wiki里有行业数据、有报告洞察、有成本结构，LLM只需要把它们连起来，再用外部搜索验证时效性。
Karpathy说"我以为要上RAG，但LLM自己维护INDEX文件和摘要就够了"。实测确实如此。我的wiki只有35篇文章、几万字，LLM通过INDEX.md（每篇文章一句话摘要）就能快速定位相关内容，根本不需要向量数据库。
Wiki35篇/持续增长提问联网验证综合回答写回Wiki读取相关文章搜最新数据更新过时信息生成分析有价值的结果知识增值
知识复利循环：每次提问都在给知识库增值
更关键的是最后一步：这个分析本身被写回了wiki。一篇新的概念文章《漫剧工具推理经济学》被创建，链接回了推理成本、行业全景、GPU租赁报告。我的每一次提问都在给知识库增值。Karpathy说的"explorations always add up"，用起来确实是这个感觉——知识在滚雪球。
几个改变认知的点
知识管理的主体变了
传统流程是：人读素材→人写笔记→人建链接→人维护索引。Karpathy的模式里，这四步全是LLM做的。人只做两件事：往raw/扔素材，对wiki提问题。
这意味着知识管理的瓶颈不再是"我有没有时间整理笔记"，而是"我有没有在持续喂入新素材"和"我有没有问出好问题"。投入的性质变了。
"编译"和"存储"是两回事
Notion、语雀、Obsidian，大部分人的用法是"存储"——把信息放进去，需要时搜出来。问题在于存进去的原始信息和你需要的知识之间有一个巨大的gap，这个gap以前靠人肉填（写读书笔记、做思维导图），现在可以让LLM填。
一份40页的SemiAnalysis PDF在raw/里躺着，对我的价值接近零。经过LLM编译成800字的洞察文章，提炼出4个核心判断、标注了和其他文章的关联，它的价值瞬间变成了可查询、可关联、可复用的知识节点。
小规模下不需要RAG
我一开始以为要搞向量数据库、embedding、相似度检索这一套。实际跑下来，在几十篇文章、几万字的规模下，一个INDEX.md（每篇一句话摘要）加上MOC.md（按主题分组的知识地图）就完全够了。LLM读一遍INDEX就知道该去读哪些文章。
当然，如果wiki膨胀到几百篇文章、上百万字，可能确实需要更高级的检索。但绝大多数人的个人知识库到不了那个规模。先跑起来再优化，是比架构完美但从不开始更好的策略。
Wiki是起点，不是牢笼
刚建好的时候我担心一个问题：LLM会不会只在wiki里打转，变成一个封闭系统？实际使用发现不会。问"GPU租赁价格还在涨吗"，它会先读wiki里的已有判断，然后主动联网搜最新数据做验证。如果外部信息和wiki有冲突，它会提示并更新。
wiki提供的是积累的上下文，外部搜索提供的是实时的事实。两者组合比任何一个单独使用都强。这跟人的知识结构其实一样——你的认知框架帮你快速理解新信息，新信息反过来修正你的认知框架。
实操建议
如果你也想试，不需要从零搭建。拿你现有的Obsidian vault改就行：
第一步：建raw/和wiki/两个目录，把原始素材和你写的笔记分开。
第二步：建一个INDEX.md，把wiki里每篇文章用一句话概括。这是LLM的查询入口。
第三步：拿一份你一直没读完的PDF或长文，让LLM编译成一篇wiki文章。感受一下"编译"和"摘要"的区别。
第四步：对wiki问一个需要跨文章回答的问题。看看LLM能综合到什么程度。
第五步：把有价值的问答结果写回wiki。开始积累复利。
工具方面，我用的是Claude Code直接操作本地文件。Obsidian只是"前端"——浏览wiki、看Graph View的知识关联图。所有的读写、编译、索引维护都交给LLM。
一个小时，30个散乱文件变成了35篇互相链接的知识网络，6份沉睡的PDF全部激活，还多了2篇从提问中长出来的概念文章。这个投入产出比，确实太香了。