安德烈·卡帕西发布了LLM Wiki模式：文件夹结构获得1600万浏览量

每次你向AI助手询问你已经研究了几个月的事情时，它都会从零开始。它不记得你上周让它总结的论文。它不知道你现在问的问题与三个月前提出的另外三个问题有关。RAG管道（全称retrieval-augmented generation，是让AI模型访问外部文档的主流架构）将每个查询视为独立的。没有任何积累。没有任何复合。

2026年4月3日，OpenAI联合创始人、前特斯拉AI主管、现独立研究员的Andrej Karpathy在X上发布了一篇帖子，描述了他如何解决这个问题，以及his GitHub Gist中展示的完整架构。该模式是一个三文件夹Markdown设置，AI模型无需向量数据库即可编译、维护和查询结构化知识库，这篇帖子单条获得了1600万次浏览。对于关注Andrej Karpathy LLM工作的任何人来说，这篇帖子不仅仅是一个技术奇闻。Gist在几天内积累了5000星和485条评论。

这个数字值得停下来思考：1600万次浏览仅仅是为了描述一个文件夹结构。这不是一次病毒式产品发布，而是开发者们认识到他们长期以来一直在绕过的问题，并看到Karpathy在AI研究界的地位精准地指出了它。

发生了什么：一个获得1600万次浏览的GitHub Gist

Karpathy描述的概念在结构上很简单，即使其含义并非如此。三个文件夹：raw/、wiki/，以及一个index.md文件，它映射所有内容并设计为适合单个上下文窗口。

raw/保存源材料，包括研究论文、文章、GitHub README、文档和YouTube转录。没有任何组织，没有任何处理。它是所有可能相关内容的转储。wiki/是模型发挥作用的地方：定期，模型会遍历原始材料并将其编译成结构化的、百科全书式的Markdown文章。每篇文章综合原始来源对某个概念的描述，解决它们之间的冲突，并建立与相关文章的链接。index.md是目录，是wiki中每篇文章的结构化地图，简洁到可以放入单个上下文加载。

当你查询系统时，模型首先读取index.md，识别哪些文章相关，加载它们，并从编译后的知识而非原始源片段中回答。没有嵌入步骤，没有向量数据库，没有检索管道。该模式不检索信息。它已经合成了它。

Karpathy选择的发布格式本身就是一种声明。他published a Gist, not a repository，没有可安装的代码，没有包管理器集成，也没有带设置说明的README。他在后续报道中被广泛引用的理由是：“在LLM代理时代，分享想法比分享代码更有价值，因为其他人的代理会根据你的具体需求定制和构建它。”几天内，社区通过产生多个独立实现验证了这一框架：obsidian-wiki插件、一个完整的LLM-wiki GitHub仓库，以及一个v2 Gist，它通过代理内存架构扩展了原始模式。

VentureBeat's coverage准确捕捉了发布的实际吸引力：Andrej Karpathy LLM知识库架构“用AI维护的演进Markdown库绕过了RAG”。框架很重要：这不是一个新产品或训练模型，而是关于知识在到达模型之前应如何组织的架构模式。对于已经构建和维护RAG管道的开发者来说，用一文件夹Markdown文件替换向量数据库和嵌入基础设施的前景立即具有吸引力，这正是Gist收到的反应。

为什么这种模式很重要

RAG与这种方法之间的根本区别在于知识组装发生的时间。RAG在查询时组装上下文：你提出问题，系统从向量存储中检索相关块，模型从这些块生成响应。响应的质量完全取决于检索质量，包括是否识别了正确的块、它们是否包含足够上下文，以及它们是否相互矛盾。

Karpathy的方法在编译时组装上下文。在你提出任何问题之前，模型已经阅读了所有原始来源，理解了它们的关系，并编写了综合该理解的结构化文章。当你提出问题时，你不是在检索片段。你是在查询一个为理解而非检索而构建的知识结构。

由此产生的三个实际含义：

Token效率。对于小型知识库，将索引和两三篇wiki文章加载到上下文中使用的token比加载等效原始源材料大约少95%。更重要的效果是上下文质量：一篇结构良好的3000字文章对模型来说远比从不同文档中检索的十个300字块更可用。

透明度。文章中的每个事实都可以追溯到人类可以阅读、编辑或删除的Markdown文件。向量嵌入则不然。如果系统给出了错误答案，你可以找到并更正源文章。如果RAG管道给出了错误答案，错误可能在嵌入空间中，无法直接访问。

知识积累。这是Karpathy最强调的属性。一个在数月内维护wiki的模型会发展出关于该领域的机构记忆形式，不是作为权重变化，而是作为编码概念之间关系的结构化产物。询问新论文与先前工作关联的研究人员，从一个已经编译相关论文六个月的系统得到的答案，与在查询时独立遇到每篇论文的系统相比，在质量上截然不同。

实际用例反映了这些属性。跟踪数十篇论文文献空间的研究人员获得交叉引用的综合而非孤立摘要。维护架构决策记录的开发者获得一个可以追溯数月上下文中设计选择原因的系统。跟踪竞争情报的产品经理获得一个积累而非遗忘的仓库。

为什么大多数实现悄然失败

1600万次浏览针对的是想法。The 485 gist comments went to what breaks when you try to build it.

社区反馈中最一致的模式是这种变化：文件夹结构正确构建，第一次编译产生令人印象深刻的结果，然后在接下来的几周内知识库慢慢变得不可靠、冗余或被放弃。这不是理解概念的失败，而是概念未能指定自身维护要求的失败。

知识有一个该模式未解决的生命周期。默认情况下，Markdown文件被假定为永久有效。但在实践中，你上周发现的bug比六个月前的更相关。你见过十二次的架构模式比见过一次的更可靠。原始模式没有提供表示时间相关性或衰减的机制。第一个月和第六个月编写的文章在wiki/中共存，没有指示哪一个反映当前理解。

矛盾在没有自动检测的情况下积累。随着仓库增长，新的编译过程引入与早期文章冲突的文章。Karpathy的架构描述了一个“lint pass”，即定期扫描整个wiki以识别不一致并解决它们。这有效。它也需要有人有意识地定期运行。大多数实现无法维持这种做法。

规模上限是硬性的，且意外到来。该方法在编译内容约50000到100000 token以下时可靠工作。超过该阈值，index.md本身不再适合单个上下文窗口，整个查询模型就会崩溃。对于跨专注领域的个人研究项目，这个上限可能永远不会达到。对于接近团队或部门规模的任何事情，它会很快遇到。

企业限制是结构性的，而不是通过迭代可解决的。通过一个人的文件系统管理的本地Markdown文件夹没有访问控制模型、没有多用户冲突解决，也没有审计跟踪。对于团队来说，这不是可以绕过的限制。这是使用不同架构的理由。

LLM Wiki v2，由扩展Karpathy原始的开发者发布在GitHub Gist上，通过添加代理内存研究的持久性模式、记录规模失败模式并提出知识生命周期管理机制，明确解决了其中一些差距。原始发布几周内v2的存在证实了所描述的模式对于生产使用是不完整的。

LLM Wiki vs RAG：何时使用哪种

Karpathy帖子后流传的“RAG已死”框架是不准确的，就像“email已死”框架一样。这两种方法不是针对相同工作负载的竞争者。它们适合不同的规模和不同的要求。

当知识库小到可以编译到100000 token以下、主要用户是构建它的人或具有共享上下文的小团队、以及知识积累比原始检索速度更重要时，Karpathy方法是正确选择。当知识库包含数十万到数百万文档、具有不同权限级别的多个用户需要访问、或内容变化频繁以至于维护精选编译不切实际时，RAG是正确选择。

对于大多数个人知识工作者和小团队来说，这种模式不仅可行；它比他们原本需要构建和维护的RAG基础设施更好。设置向量数据库、管理嵌入、调整检索参数和调试检索噪声的复杂性是真实的。对于只有几百个文档的个人研究系统，that complexity is genuinely unnecessary。

Karpathy工作流所代表的实用中间地带很好地映射到Obsidian等工具，其中Web Clipper处理源摄取，文件系统处理文件夹结构。原始Gist发布几天内出现的社区实现绝大多数基于Obsidian，这不是巧合。

这对我们构建知识系统意味着什么

Karpathy将其框架为“想法文件”而非代码发布，反映了AI开发规范正在转变的真实情况。在2026年，知识管理系统有趣的部分不是基础设施。而是上下文工程：信息如何在查询时被结构化、合成并提供给模型。

这所代表的更广泛趋势是开发者和知识工作者思考AI工具方式的重新定位。过去的问题是“我如何让模型更聪明？”2026年的问题越来越多地是“我如何构建模型可以访问的信息？”Karpathy的模式是第二个问题的一个答案。

Ward Cunningham在1995年发布了原始的WikiWikiWeb，作为一种模式，而不是产品，不是商业工具，而是描述如何组织协作知识。它花了数年时间才将这个想法推广到我们现在所说的wiki。Karpathy的Gist处于类似的位置：一种对其创建者有效的模式，通过社区实现传播，并产生解决其差距的变体。Analytics Vidhya说得好：意义不在于技术实现，而在于它所代表的从业者思考AI和持久知识的范式转变。

1600万次浏览所代表的问题实际上不是关于文件夹结构。而是你数月和数年积累的知识是否真的复合，或者每个新会话是否从头开始。这是一个关于架构的问题，但也是一个关于你想围绕自己构建什么样的知识基础设施的问题。

社区最诚实的答案是，Karpathy的模式对构建它的人、在他们关心的领域、并有纪律定期运行lint pass的人有效。对于其他人，它有效直到失效，然后需要大量工具投资或更主观的系统自动处理维护层。discussion thread on the original Gist本身是一个有用的产物：485条评论记录了模式在哪里失效、人们尝试了什么修复，以及哪些扩展实际上坚持下来。阅读它比构建一个失败的wiki花费的时间更少。

如果Karpathy模式所解决的问题——应该积累但没有积累的知识——听起来很熟悉，那是因为它是个人和团队知识管理的核心问题。将每个会话视为无状态的工具将有价值的上下文留在桌面上。remio's AI-native second brain围绕同一原则构建：知识系统的价值来自它随时间积累的内容，而不是按需检索的内容。无论你是构建自己的模式还是寻找一个为你完成复合的工具，值得问的问题是相同的：当你六个月后回到这些信息时，AI是否会记得任何东西？