双向链接、知识图谱、数据库、AI 搜索……知识管理软件越来越复杂。Karpathy 却让 AI 持续维护一个 Markdown 知识库。问题随之而来：我们究竟是在管理知识，还是在管理知识管理软件？
如果要为近些年的知识管理软件写一部发展史，大概也是一部功能不断膨胀的历史。从最初的笔记本、标签、文件夹，到双向链接、块引用、关系型数据库、知识图谱，再到今天几乎每个产品都要加上的 AI 搜索、AI 总结和 AI 助手，人们仿佛已经默认一件事：管理知识是一件极其复杂的事情，复杂到必须有一套越来越精密的软件，才配得上“第二大脑”这个名字。
但事情有了一个颇具戏剧性的转折。2026 年 4 月 2 日，Andrej Karpathy 分享了自己的 LLM Knowledge Bases 工作流。他把论文、文章、代码仓库等原始材料放进目录，交给大语言模型持续整理，最终产出一个由 Markdown 文件组成的 Wiki。查看时用 Obsidian，分析时让智能体直接读写文件，需要搜索就调用命令行工具，生成的文章、图表和幻灯片还会继续归档回知识库。没有让人眼花缭乱的“下一代知识操作系统”界面，也没有把向量数据库作为启动项目的必选项。这个工作流最醒目的东西，竟然就是一个文件夹。
Karpathy 的 Wiki 仍有反向链接、概念分类和关联文章，他也照样使用 Obsidian 和插件。值得关注的是日常维护工作的分配。他改变的是知识管理中最费力的那部分工作的承担者：过去是人去维护知识结构，现在开始由 AI 去维护；过去软件让人适应复杂的功能，今天越来越多的功能可以退到后台，成为智能体随用随取的能力。
一、我们是怎么把记笔记变成一门重工业的
十几年前，写一份笔记大概只需要打开编辑器，输入标题和正文，保存。后来有人觉得分类不够灵活，于是有了标签；标签解决不了跨主题的关联，于是有了双向链接；链接太多又需要全局视图，于是有了知识图谱；笔记不够结构化，就加入数据库、属性、模板和公式。再往后，软件要支持任务、项目、日历、白板、自动化、协作和权限，原本很朴素的个人知识管理，被一步步建造成了一个小型信息系统。
这些创新大多有真实价值。问题出在另一头：功能的增长，悄悄把管理成本转嫁给了使用者。你收藏了一篇论文，却先要考虑它该进入哪个数据库、贴什么标签、关联哪几条旧笔记、要不要拆成原子卡片。你开完一场会，会议纪要还没有消化，就得给它补充属性、调整页面层级。一个知识库是否精美，越来越取决于主人是否愿意长期充当它的录入员、管理员和维护工程师。
于是出现了一种熟悉的荒诞：人们花大量时间研究怎样搭建更好的知识管理系统，真正用这些知识解决问题的时间反而被挤压了。很多人拥有几百篇收藏、上千条笔记和一张漂亮的关系网络，却仍然会在需要做判断时重新打开搜索引擎，从头找资料。知识库看起来越来越丰富，知识却未必真正进入了工作流程。某种程度上，我们把“整理知识”这件事做得过于精致，直到它本身成了需要被管理的负担。
二、Karpathy 用“编译”组织原始材料
Karpathy 的方案之所以有意思，是因为他并没有停留在“把资料转换成 Markdown”这一步。他描述的路径大致是：先把论文、网页、代码和图片等原始资料收入 raw/ 目录，再让 LLM 持续阅读和整理这些资料，增量生成一套 Markdown Wiki，包括来源摘要、概念条目、专题文章、相互引用和索引文件。人可以在 Obsidian 里阅读，但 Wiki 的主要编写和维护工作由模型承担。
这里有一个很重要的词：编译。它比“上传文档到知识库”更准确。上传解决的是保存，搜索解决的是查找，编译则试图把一批原始、异构、彼此松散的信息，重新组织成适合进一步理解和调用的知识表达。好比软件开发中，源代码经过处理形成可执行的程序；在这个工作流中，原始材料经过智能体处理，形成可持续更新的知识结构。这个比喻有边界，但它揭示了两种工作方式的根本差异：一个静态地存放资料，一个不断地加工资料。
更有意思的是，整理工作并非一次性完成。新加入一篇论文，智能体可以更新相关概念的解释，补充旧条目的参考来源，指出新旧研究的冲突；进行一次专题问答，产生的分析报告、Marp 幻灯片或图表又能回到库中，成为下一次研究的输入。Karpathy 还提到过让 LLM 对知识库做“健康检查”，发现前后不一致、资料缺口和潜在的新关联。这样一来，知识库不再只是记录过去的仓库，而逐渐成为研究过程的一部分。
在他的公开描述中，某个研究主题的 Wiki 已有大约 100 篇文章、40 万词。这个规模下，模型借助自动维护的索引和简短摘要，就能够找到和阅读相关材料，以至于他暂时没有必要搭建一套复杂的 RAG 系统。这是一个个人研究实践的观察，而不是对所有数据规模和任务类型的性能结论。它提供了一种很有价值的提问方式：在引入一整套复杂技术栈之前，为什么不先验证文件、索引和智能体能完成多少工作？
三、这场变化最激进的地方，是人终于不用再亲手整理每一条知识
回看过去的笔记方法论，无论是卡片盒笔记法、PARA，还是某种高度定制的数据库模板，背后都有一个共同前提：知识库的结构主要靠人维护。人负责决定放哪里、叫什么名字、跟谁关联、什么时候更新。软件提供更便利的操作界面，但执行动作的仍然是使用者。AI 出现以后，很多产品只是给原来的工作流加了一个聊天框，用户仍然要先把自己的知识整理成软件喜欢的样子，然后再让 AI 来回答。
Karpathy 的实践把这个顺序反过来了。研究者负责提出问题、选择材料、形成判断，智能体负责把资料拆解、合并、链接、索引与维护。知识结构不再要求在输入之前就设计得十分完美，它可以在使用过程中逐渐生长。今天为了研究一个问题而建立的概念关系，明天可以被另一项研究复用；一个新问题也可能促使系统重新组织已有条目。分类从先验的硬约束，变成可以迭代的中间结果。
这里还藏着一个容易被低估的变化：**知识库的写入成本正在急剧下降，但判断成本并没有同步消失。**AI 可以在几分钟内整理几十篇材料，生成一批条理清楚的 Markdown 文件，也能一本正经地把两条不相关的事实编织成一个看似精妙的结论。因此，人从整理员的位置上退下来，并不意味着从知识系统中退出。人的精力应该转向更重要的环节：哪些来源值得信任，哪些概念的边界需要明确，哪些矛盾反映了真正的研究问题，哪些结论能够指导实际决策。
这也解释了为什么 Karpathy 把原始材料与整理后的 Wiki 分开，是一个非常值得借鉴的选择。原始资料保留了回溯的可能，AI 生成的摘要和分析则允许被修改、重建甚至删除。当一篇衍生条目出现错误时，至少还有机会回到证据，而不必在一层又一层自动生成的文字中寻找事实的起点。未来衡量一个知识管理系统是否可靠，漂亮的图谱和流畅的问答体验恐怕都要排在证据链、版本记录和纠错能力之后。
四、为什么偏偏是 Markdown？因为文件正在重新成为最重要的接口
Markdown 有一种不讨巧的朴素。它没有复杂的页面对象模型，不要求专用服务端才能打开，一份文件既可以给人阅读，也可以直接给程序解析。一个普通文件夹，任何编辑器都能打开，命令行可以搜索，脚本可以批处理，Git 可以记录差异，智能体可以读取、修改、比较和生成。它的生命力并非来自界面先进，而是来自依赖足够少、可组合的方式足够多。
在传统软件时代，界面是大多数用户操作数据的主要入口。为了让人方便地建立联系，产品需要设计按钮、菜单、弹窗、拖拽交互和各种可视化组件。智能体成为参与者之后，操作入口发生了变化。一个能够读取目录、执行检索、修改文件并检查结果的模型，并不需要像人一样不断点击界面。许多过去必须在产品中精心设计的操作，如今可以被组合成一系列文件操作与命令行调用。过去最亮眼的功能，可能会逐渐退化为后台的一项普通能力。
这对软件行业的冲击其实比“大家开始用 Markdown”更大。用户真正需要的，是知识能够长期保存、可靠访问、反复加工、随时迁移。如果这些能力以普通文件为基础提供，那么某个软件就不再天然拥有对知识的解释权和控制权。今天你用 Obsidian，明天可以换成 VS Code 或其他工具；今天由一个模型完成分析，明天可以让另一个模型接手。界面可以更新，模型可以替换，脚本可以重写，只要知识资产本身保持开放和可读，迁移成本就可以显著降低。
当然，Markdown 并非一切数据的理想格式。复杂表格、实时事务、音视频、三维模型、时间序列和强约束的业务数据，各有更适合的存储方式。它真正重要的地方，是提供了一种足够简单的、可供人和 AI 共同使用的知识表达层。原始数据仍然可以留在原有系统中，Markdown 负责记录解释、上下文、索引、结论及其来源。这里强调的是为知识建立尽量独立于具体应用的可读接口，原始业务数据仍保留在适合它的系统中。
五、RAG 没有死，但“先把全部文件向量化”这条惯性路线该重新审视了
过去几年，企业建设 AI 知识库时，常见方案几乎形成了标准动作：先把文档解析成文本，切成段落，生成 Embedding，写入向量数据库，检索时召回若干片段，再交给大模型生成回答。这个流程解决过真实的问题，特别是面对大量非结构化内容、需要模糊语义匹配或者检索规模很大时，向量索引仍然有其价值。但行业也逐渐习惯了把它当作项目的起点，而不是经过比较之后选择的技术手段。
问题在于，向量相似度和知识理解之间存在距离。用户要查一份明确名称的设备说明书时，文件名和目录索引可能比向量检索更可靠；要比较同一工艺规范的两个版本时，版本号和章节定位比语义上“最像”的段落更重要；要追查某项质量问题的原因时，时间、设备编号、批次和因果链条，往往是比文本相似度更有用的检索条件。把文档过早切成彼此独立的片段，也可能削弱原有的章节关系、适用范围和版本上下文。
Karpathy 的启发，是让智能体先利用人能看懂的目录、标题、索引和摘要来定位资料，再按需打开相关文件，必要时继续执行全文搜索、结构化查询或语义检索。先检索、再阅读、再决定是否需要更复杂的索引，完全可以成为许多中小规模知识库的初始路线。对于大型语料、多语言模糊查询和严格时延要求，向量检索依然可能是关键组件；对于精确定位和已知文件关系，传统索引及命令行工具反而更有优势。真正成熟的系统应该能按任务组合这些能力，而不是要求每一个问题都绕一遍同样的 RAG 管线。
换句话说，技术没有被推翻，默认架构却值得被重新讨论。当模型越来越善于规划检索步骤、阅读长文档、使用工具和维护中间索引，很多以前需要通过复杂外部系统弥补的能力，正在回到模型与文件的协作之中。软件工程里有一句朴素的经验：能通过简单方案验证的事情，最好不要从最复杂的架构开始。知识管理正在重新发现这句话。
六、把这套思路放进企业，尤其是工业现场，才会看到更大的价值
个人知识库可以有些随性，企业知识却常常散落在更难处理的地方。研发设计文档在 PLM，工艺规程在受控文档系统，生产记录在 MES，设备数据在 SCADA 或时序库，故障分析在售后报告里，许多关键经验甚至留在工程师的电脑文件夹和邮件附件中。这些系统各自解决了业务问题，却很少形成一套能持续吸收经验、横向解释问题的知识结构。企业购买了不少系统，仍然会遇到一个令人无奈的局面：数据并不缺，真正遇到问题时却找不到可以直接使用的知识。
设想一名工艺工程师正在调查某种焊接缺陷。传统知识库可能给他检索出几份操作规程、几篇历史报告和一批相似的故障记录，然后把筛选与比对的工作交还给他。而一个更主动的工业智能体，可以先定位相关产线和工艺版本，读取适用的作业指导书，关联历史缺陷案例，查询必要的生产参数与质量记录，整理出一份带来源的分析草稿，再标明尚未证实的原因和需要现场复核的数据。随着工程师完成复核，这次分析还可以转化为新的案例条目，反过来修订相关知识索引。下一次遇到类似问题，系统便不必从零开始。
在这里，Markdown 文件夹并不会取代 PLM、MES、ERP，更不可能凭几份文本替代 CAD 模型、工艺执行记录或实时控制系统。真正有价值的架构，是以原有业务系统保持权威数据，以受控的文件和知识目录承载可解释的经验，再由具备权限的智能体跨系统完成检索、分析和协同。知识文档可以在企业内网或本地环境中维护，访问原始数据时继承原系统的权限，形成报告时保留引用与操作日志。工艺参数是否允许修改、质量结论是否允许发布、生产指令是否可以执行，仍应由确定的权限和审批机制约束。
这也给企业软件开发者提了个醒：不要急于在旧平台外面堆砌一个更加复杂的“AI 知识中台”。有时候更有价值的工作，是梳理现有目录和业务接口，明确哪些文件是权威来源、哪些只是 AI 的推导结果，让智能体有办法稳定地阅读、操作、验证和回写。把这一层做好，知识才可能从静态资料变成可复用的生产能力。门槛在于能否把一次正确的工程实践，沉淀为下一次可追溯、可执行、可改进的工作依据。
七、简单不等于粗糙，文件夹背后仍然需要严肃的工程纪律
看到 Karpathy 的分享，很容易走向另一个极端：既然一个文件夹就够了，数据库、版本管理、知识治理和企业软件是不是都该扔掉？这显然误解了事情的本质。个人研究场景里可行的做法，一旦进入多用户协作、百万级文档或高风险业务场景，就会面临权限隔离、并发修改、版本冲突、审计留痕、敏感信息泄露和错误传播等问题。纯文本便于 AI 读写，也同样便于 AI 批量写错；自动生成的关联越多，一处未经核实的错误越可能沿着链接扩散。
因此，我更赞成一种朴素但严格的做法：原始材料与衍生知识分开保存，重要结论必须能指向来源；AI 可以提出修改，但关键内容的发布要经过验证；每次改动留下版本差异和操作记录；索引、摘要和衍生条目可以重新生成，原始证据却不能被悄悄覆盖；敏感资料按权限访问，不能因为放进同一个文件夹就默认对所有智能体开放。对于企业而言，Markdown 是很好的协作格式，但权限、审计、数据血缘和事务一致性仍需要相应的系统能力支撑。
还有一个常被忽视的技术细节：知识库本身不能只有文章，最好也有关于它自身的说明。目录的用途、命名规则、资料可信度、更新时间、引用规范、哪些文件可改、哪些文件禁止改，这些约束都可以写成明确的文本规则，交给智能体遵守和检查。让模型知道如何工作，往往比塞给它更多零散资料更重要。越是希望系统长期自治，越需要一个可以反复检查的边界；越是追求架构简单，越不能把可靠性寄托在模型每一次都“刚好做对”上。
八、下一代知识管理产品，还能卖什么？
这是 Karpathy 的方案带来的商业问题，也是我认为最值得软件行业认真回答的问题。如果用户的数据是一组开放文件，模型可以直接维护条目，搜索可以调用系统工具，链接和索引也能由智能体自动生成，那么原本作为收费亮点的许多功能，就可能失去独立定价的基础。软件厂商继续比拼谁的双链更顺滑、谁的图谱更炫酷、谁又多了几个 AI 按钮，恐怕很难形成长期优势。
但这不代表知识管理产品没有未来。恰恰相反，Karpathy 在原帖最后明确表示，这一套由脚本拼装的工作流仍有机会发展成出色的新产品。只是新产品的价值中心需要改变：从让人更方便地手动整理知识，转向让知识能够被智能体安全、持续、低成本地维护；从提供一个封闭的内容容器，转向提供跨工具、跨模型的知识工作环境；从展示已有多少条笔记，转向回答知识经过多少次验证、帮助解决过哪些实际问题、还存在哪些未被解释的冲突。
未来值得付费的，可能是可靠的数据接入和本地部署能力，是稳定的权限控制与审计，是可回溯的知识编译流程，是复杂任务的执行、复核和交付，也可能是更自然的人机协作体验。软件依然重要，只是它应该隐藏更多不必要的复杂性，让人把注意力放回问题本身。一个优秀的知识工具，未必需要天天提醒用户自己有多强大；最好的状态，是它始终在工作，而用户几乎感觉不到自己还在“管理知识”。
结语：把时间还给问题本身
Markdown 文件夹折射出这轮 AI 浪潮里的一个反差。我们曾经为了管理知识，发明越来越多的操作界面、索引机制、数据库模型和可视化组件；当模型终于能够读懂文件、调用工具、主动维护结构时，很多额外的复杂性忽然失去了存在的理由。让一个简单的目录重新站到舞台中央，并非技术倒退，而是技术进步到一定阶段之后，对既有设计的一次重新清算。
**回归文件，让知识可以长期读写与迁移。**回归的是知识作为长期资产的独立性，是人和机器都能理解的开放表达，是从原始证据到最终结论的清晰路径。知识管理软件当然还会继续进化，但它真正需要回答的问题也许已经变了：过去是“怎样让人更高效地管理知识”，以后则是“怎样让知识在人的判断和 AI 的持续工作之间，自然而可靠地生长”。
知识管理工具值得追求的结果很具体：少花时间维护目录，多花时间思考和解决问题。
参考资料
- Andrej Karpathy, LLM Knowledge Bases, 2026 年 4 月 2 日，原帖：https://x.com/karpathy/status/2039805659525644595
- VentureBeat, Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG with an evolving markdown library maintained by AI, 2026 年 4 月 3 日：https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an
- CommonMark, CommonMark Spec, Markdown 纯文本结构化文档规范：https://spec.commonmark.org/current/