Karpathy 的 LLM Wiki 模式拥有 1600 万次浏览。以下是它实际运行时的样子。

每次开始新的 AI 会话时，你都从零开始。上周做的研究、上个月得出的结论、六个月前注意到的两篇论文之间的联系：这些都不会延续。你正在与之对话的 AI 对这一切没有任何记忆。RAG，作为让 AI 模型访问外部文档的主导架构，按需检索片段，但将每个查询视为独立的。没有任何积累。没有任何复合。

2026 年 4 月 3 日，OpenAI 联合创始人、前特斯拉 AI 负责人 Andrej Karpathy 发布了a GitHub Gist描述了一种不同的方法：一个三文件夹的 markdown 设置，其中 LLM 编译、维护和查询一个结构化知识库，而无需向量数据库。该帖子获得了 1600 万次浏览。这个数字代表了具体的东西：研究人员、开发人员、产品经理和分析师认识到他们多年来一直在解决的问题，终于被精确命名。

Karpathy 描述的架构是正确的。问题在于实际运行它需要什么。对于大多数不直接使用 LLM API 的人来说，从“这是个好主意”到“它在我的机器上运行”之间的差距是一个多天的工程项目，并成为持续的维护承诺。本文解释了该模式需要什么，一个可行的实现是什么样子，以及当基础设施由你处理时会发生什么变化。

Karpathy 的 LLM Wiki 模式究竟是什么

Karpathy 发布的 llm wiki 架构的核心是一种结构洞见：知识应该在查询之前组装，而不是在查询时。

传统 RAG 的工作方式如下。你提出一个问题，系统在向量存储中搜索相关块，模型根据出现的任何内容构建答案。质量完全取决于检索：正确的块是否出现，它们是否包含足够上下文，它们是否相互矛盾。每个查询都是全新的。系统不了解你的领域，只访问你的文档。

Karpathy 的模式颠倒了这一点。三个文件夹完成工作。raw/保存源材料：研究论文、文章、笔记、YouTube 转录、GitHub README。wiki/是 LLM 定期读取所有原始材料并将其编译成结构化、百科全书式文章的地方，每篇文章综合来源对概念的描述，解决它们之间的冲突，并链接到相关条目。index.md是一个目录，紧凑到可以放入单个上下文窗口。

当你查询系统时，模型首先读取索引，识别哪些文章相关，加载它们，并从编译的知识而不是原始片段中回答。LLM wiki 不会检索信息。它已经合成了它。

实际影响是具体的。与加载等效原始源材料相比，token 使用量下降约 95%。每个事实都可以追溯到可读、可编辑的 Markdown 文件。由于 wiki 随时间构建，第六个月提出的问题会利用比第一个月更丰富、更连接的知识结构。

Gist 没有描述的是设置。该架构假设熟悉 LLM API，习惯编写或运行脚本以触发编译和 lint 操作，以及在数周和数月内定期保持这些过程运行的纪律。对于最需要复合知识的研究人员、分析师和产品经理来说，这种假设是一个重大障碍。一个可行的实现不是文件夹结构。它是一个维护系统，而构建该系统是 Karpathy 留给读者的部分。

该Gist's 485 comments很大程度上记录了人们尝试自己构建时出现的问题：raw/ 文件夹在前两周后停止增长，编译步骤从未自动化，lint 过程被跳过，直到 wiki 变得不一致到不可靠。

AK Wiki 如何实现三层

remio 是一个本地优先的 AI 知识库，可自动从网页浏览、文件和会议中捕获内容。AK Wiki 是 remio 内的一个 aApp，直接构建在 Karpathy 的架构上。三层中的每一层都映射到具体实现，模式描述与大多数 DIY 尝试能够维持的内容之间的差距在每一层都缩小。

第 1 层：raw/ 问题，由自动捕获解决

在 DIY 设置中填充raw/需要刻意策展：决定包含什么，将内容转换为一致格式，并保持组织纪律以保持文件夹最新。随着时间的推移，这成为它自己的工作。大多数失败的实现都失败在这里。raw/ 文件夹在最初的热情消退后停止增长，从那时起停止接收新材料的知识库开始退化。

AK Wiki 的源层是 remio 现有的捕获基础设施。你剪辑的每个网页、索引的每个本地文件、记录的每次会议都会自动流入。没有摄取决定，没有格式转换，没有要维护的文件夹。材料在你工作时积累，而不是作为单独的活动。对于不是开发人员的知识工作者来说，这是拥有这个系统与不拥有它的区别。杀死 DIY 实现的摄取纪律根本不存在作为约束。

第 2 层：按主题和概念组织的编译知识

编译操作产生两种类型的输出。主题集合是围绕你定义的主题组织的结构化知识条目：“AI Agents”、“竞争研究”、“Q2 产品决策”。你设置范围；AI 从你捕获的所有触及这些主题的材料中构建条目。

概念集合不同。这些是 AI 在编译过程中发现的连接和概念，而你没有明确定义。如果你在不同周和不同上下文中捕获的来源指向相同的底层想法，AK Wiki 会将这种关系作为自己的条目浮现。系统不仅在组织你的知识。它正在发现你没有放入其中的结构。

两种输出类型都是可读的结构化文章，而不是向量嵌入或检索分数。你可以阅读它们、编辑它们，并将每个声明追溯到它来自的源材料。这是VentureBeat noted在报道 Karpathy 方法时指出的透明度优势：一个“由 AI 维护的不断演进的 markdown 库”，对其人类所有者保持清晰易读，不像需要工具检查的向量索引。

在编译过程中，AK Wiki 还补充知识空白。当你捕获的材料缺乏来源中出现的概念覆盖时，系统会搜索网络以填充它。Karpathy 的原始架构对此没有等效；它仅适用于你明确放入raw/的内容。

第 3 层：自我维护的可查询主题地图

编译输出组织成可导航的主题视图：index.md的功能等效物，随每次编译运行更新。与手动维护的索引不同，当你停止策展时它不会过时。该结构反映了系统从捕获材料中合成的内容，而不是你记得上周二记录的内容。

编译和 Lint 实际做什么

两个操作定义了 AK Wiki 如何随时间保持知识质量。两者都解决了 Karpathy 模式 DIY 实现中记录良好的失败模式。

编译不是索引。当编译运行执行时，AI 读取你捕获的内容，并根据当前理解重写知识条目。新来源集成到现有文章中，而不是作为单独条目附加。来源之间的矛盾在文章内被识别和解决。结果是合成：你研究了三个月的主题上的一个良好编译条目，与三个星期后构建的条目不同，因为底层材料更丰富，连接更深。

这在计算上比构建向量索引更重，这就是它按需或按计划运行而不是连续运行的原因。这是预期的设计。输出质量与检索系统产生的内容有质的区别，处理成本反映了这种差异。对于技术角色之外的知识工作者来说，不必配置此管道本身就是一个有意义的优势：编译步骤是一个按钮，而不是你编写的脚本。

Lint 是防止知识退化的操作。Karpathy 在他的原始 Gist 中描述了 lint 过程：对整个 wiki 的定期扫描，以识别不一致、过时信息以及与更近期材料冲突的条目。他指出这是必要的。他没有指定如何自动化它、运行频率，或当 wiki 增长到运行它变得昂贵时该怎么做。

在实践中，lint 是 DIY 实现中首先被跳过的事情。运行它需要记住运行它，有可用的工作脚本，并分配时间和 API 成本。大多数开始强劲的实现逐渐停止运行 lint，wiki 在接下来的几个月内变得不太可靠，而没有任何明显的失败信号。条目看起来权威。它们越来越错误。

在 AK Wiki 中，Lint 是从主界面访问的内置操作。它可以立即触发或安排自动运行。AI 根据知识库的当前状态审查现有条目，标记已变得不一致的内容，并更新它。Karpathy 架构需要但未指定的维护循环，在 AK Wiki 中是一个按钮。

你的知识库随时间看起来的样子

这种架构的价值在设置时不可见。它会积累。

在第一个月，主题集合开始围绕你最活跃的研究领域形成。条目很有用：它们将几周捕获的材料合成为结构化文章，比搜索原始来源更快地回答问题。跨主题连接有限，因为没有太多可连接的内容。该系统已经比搜索原始文件文件夹更有用，但复合尚未开始。这是 DIY 实现感觉有前途但尚未产生感觉必不可少的结果的阶段。正如 Gist 评论中广泛记录的那样，这也是大多数实现停滞的阶段，因为维护循环在复合有时间展示其价值之前就崩溃了。

在第三个月，概念集合开始变得重要。AI 现在已经阅读了你在不同上下文中捕获的材料：三个月前剪辑的文章、上个月的会议记录、上周索引的文档。它浮现了你没有故意创建的它们之间的连接。第一个月构建的竞争分析条目已更新以纳入你在第三个月捕获的产品公告，无需你手动操作。知识库不再只是你放入内容的结构化版本。它开始包含你没有明确构建的理解。

在第六个月，系统开始回答你不知道要问的问题。当一个主题有足够的密度时，AI 会利用数月积累的上下文，而不是你最近碰巧捕获的任何内容。研究人员询问新论文与先前工作的关系时，会得到反映该领域六个月阅读的答案。产品经理询问反复出现的投诉模式时，会得到将当前反馈与 Q1 做出的产品决策连接起来的响应。开发人员询问为什么做出某种架构选择时，会找到一个条目，该条目追溯了在四次单独会议中发生的讨论线程的推理。

Analytics Vidhya直接指出：意义不在于技术实现，而在于它代表的范式转变：从作为你查询的工具的 AI，到随着时间积累对你特定领域理解的系统。Karpathy 描述的复合效应是真实的。大多数实现从未达到这种效应变得可见的时间范围，因为它们没有存活足够长的时间到达那里。

从这种知识系统受益最多的人并不总是最有能力构建和维护其背后基础设施的人。AK Wiki 将这两件事分开。

AK Wiki vs. DIY LLM Wiki vs. RAG

这三种方法适合不同的用户、规模和要求。它们之间的选择不是关于哪种架构更优越的技术判断。这是一个关于你是谁以及你 realistically 能维持什么的实际问题。

自己构建是正确的选择，当你需要完全的架构控制，在单一专注领域工作，并有技术背景来构建和维护基础设施时。Epsilla's analysis对该架构的企业限制正确地指出，它识别了 RAG 的根本问题，但需要自己的维护系统才能在实践中发挥作用。对于想要拥有该系统每一层的开发人员来说，自己构建是一条合理的路径。

AK Wiki in remio是正确的选择，当你想要复合知识效应而无需基础设施承诺时。自动捕获取代手动 raw/ 策展。内置编译和 lint 取代自定义脚本和 cron 作业。通过网络搜索进行的信息补充填补了本地系统无法解决的空白。结果是一个编译的知识 wiki，不需要其所有者也成为其工程师。

RAG仍然是具有严格访问控制、多用户要求和超过编译 wiki 所能处理的文档语料库的大规模企业知识库的正确架构。这种模式，无论是 DIY 实现还是通过产品实现，都是为个人和小团队知识管理设计的。在企业规模上，检索基础设施是正确的基础。

• 原始摄取：DIY 需要手动策展；AK Wiki 自动捕获；RAG 自动索引

• 编译：DIY 需要手动脚本；AK Wiki 按按钮或计划运行；RAG 持续索引

• Lint：DIY 维护是手动的且经常被放弃；AK Wiki 有内置的可安排 lint 操作；RAG 没有等效

• 透明度：DIY 和 AK Wiki 都产生可读、可编辑的条目；RAG 存储需要工具检查的向量嵌入

• 非技术用户：DIY 在设置时受阻；AK Wiki 开箱即用；RAG 需要管道配置

• 规模上限：DIY 和 AK Wiki 适合个人到小团队规模；RAG 实际上是无限的

Karpathy 命名的问题并不新鲜。自 AI 助手变得有用以来，知识工作者一直在会话边界丢失上下文。Gist 所做的是精确地描述解决它的架构，以至于 1600 万人认识到他们一直缺少的东西。

架构是正确的。它解决的问题是真实的。一致地运行它，几个月来，是困难的部分。如果你想要 Karpathy 描述的知识系统而无需构建支持它的基础设施，remio's AI-native second brain包括 AK Wiki 作为开箱即用的实现：自动捕获、内置编译和 lint、跨主题合成、信息补充，以及从第一天起就复合的知识。