如果你最近在折腾 AI 知识管理，大概率已经发现一个尴尬现实：大多数“AI 知识库”看起来很聪明，用久了却并不真正沉淀知识。 你每次提问都像在重新开工，系统临时检索、临时拼接、临时作答，回答结束后，知识也跟着蒸发了。
Karpathy 最近分享的一个思路，之所以让很多人眼前一亮，就在于他不再把 LLM 当“问答机器”，而是把它当成一个持续维护 Markdown Wiki 的知识工程师。这不只是换了个工作流，而是在重新定义“个人知识库”到底应该怎么长大。
为什么 Karpathy 这个思路会让人兴奋？
Andrej Karpathy 提出的，不是一个花哨的新应用，也不是某个封闭平台的商业功能，而是一种非常“工程化”的知识管理思维：
不要每次都让 LLM 从一堆原始资料里重新找答案，
而是让它持续把你的知识整理成一个结构化、可链接、可维护、可长期进化的 Wiki。
这个思路听起来朴素，但它击中了很多 AI 工具的痛点。
今天大多数人使用 AI 管理信息的方式，通常是这样的：
这套流程当然有用，但它更像一个“即时问答层”，而不是“长期记忆层”。
你今天问“某技术路线和另一路线的区别是什么”，模型会临时拼一个答案；明天你又问一次，它可能还要从头找材料、重新推理、重新组织。回答虽然聪明，但它并没有真正把理解留在系统里。
Karpathy 的想法，正好反过来：
这也是为什么很多人看完之后会觉得“被点醒了”——因为它不是在优化 Chat，而是在优化知识的复利机制。
02 传统 RAG 为什么不够？问题不是不会答，而是不会积累
很多人把 NotebookLM、文件上传问答、企业知识库助手都归为一类，这类系统背后的默认思路通常就是 RAG（检索增强生成）。
RAG 的优势很明显：
但它有一个常被忽略的结构性问题：它擅长“取回”，不擅长“沉淀”。
比如你读了 20 篇关于 AI Agent、工作流编排、Obsidian PKM、向量数据库的文章。你真正想得到的，不只是“我问的时候帮我找几段原文”，而是：
传统 RAG 的麻烦在于：这些“综合理解”常常不会被自动保存下来。
于是每次复杂提问都像一次性脑暴：
系统没有真正变聪明，只是这次调用表现得聪明。
而 Karpathy 的做法是把“临时理解”变成“长期结构”。
每次 ingest 一个新资料源，Agent 不是简单把它索引进去，而是：
这种思路更像“知识编译”，而不是“即时检索”。
03 Karpathy 的三层架构：Source、Wiki、Schema
Karpathy 把整个系统拆成了三层，这个设计非常值得借鉴。
3.1 Raw Sources：原始资料层
这层放的是你收集到的原始内容，比如：
这一层最重要的原则是：尽量保持原始性和可追溯性。
也就是说，它像素材仓库，而不是整理结果仓库。Agent 可以读取它、引用它、总结它，但通常不应该随便改写它。因为一旦原始层被污染，你后续所有知识演化都可能失去依据。
3.2 The Wiki：知识库层
这是整套系统的核心。
Wiki 不是“原始资料的备份”，而是 LLM 帮你产出的结构化中间层。它可以包含：
与其说这是笔记，不如说它更像一个不断演化的知识地图。
这层的价值在于：它是可读、可查、可复用、可追踪变化的。 你以后所有更复杂的问题，都可以在它上面继续生长，而不是每次回到原始资料堆里重新翻。
3.3 The Schema：规则层
这一层经常被低估，但它其实非常关键。
Schema 决定了：
对 Claude Code 来说可能是 CLAUDE.md，对 Codex 来说可能是 AGENTS.md，对其他 Agent 也可能是你自己的约定文件。
没有这一层，知识库很容易变成一堆漂亮但混乱的 Markdown。Schema 的作用，就是让系统越长越有秩序，而不是越长越臃肿。
04 三个核心操作：Ingest、Query、Lint
Karpathy 把整个工作流收束成三个动作，我觉得这比很多“功能一大堆”的 AI 产品更高级，因为它抓住了最关键的闭环。
4.1 Ingest：录入
当你加入一个新来源时，Agent 不是只做摘要，而是做一轮“知识整合”。
一个优秀的 ingest 流程至少应该包含：
读取原始内容提炼关键结论判断它关联哪些现有主题/实体更新已有页面而不是只新增新页面补充来源引用记录新旧观点的差异
这意味着录入一个新来源，可能会改动 10 个以上页面。
这正是 AI 特别适合干的“脏活累活”：跨页面更新、一致性维护、补链、改摘要、补引用——人做这些容易烦，模型做这些反而稳定。
4.2 Query：提问
你当然仍然可以问问题，但不同的是，你不再只是在问原始资料，而是在问一个已经经过组织的 Wiki。
这会带来两个直接好处：
这一步特别像“研究过程中产出中间成果”。
例如你问：
这些问题的回答，如果被沉淀成页面，以后就不必重复从零构建。
4.3 Lint：体检
这是很多知识管理系统最缺的一环，也是 Karpathy 这套方案非常妙的地方。
知识库不是写完就算，它会老化、断链、冲突、失衡。
Lint 可以理解成“知识库健康检查”，让 Agent 定期帮你发现：
这一步的意义很大，因为真正拖垮个人知识库的，往往不是缺少内容，而是结构开始腐坏之后，人就不想维护了。
05 为什么 Obsidian 会成为这套系统的理想前端？
Karpathy 的一个比喻很经典：
Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。
这个比喻几乎一下就把问题讲明白了。
Obsidian 之所以适合，并不是因为它“比别的笔记工具更酷”，而是因为它天然具备几种重要特性：
5.1 Markdown 天然适合 Agent 操作
Markdown 结构简单、可 diff、可版本控制、可局部编辑，对 Agent 来说非常友好。
相比富文本系统，Markdown 的优势是：
5.2 双向链接很适合做知识图谱
知识增长不是线性的，而是网络状的。
你今天读一篇文章，可能影响：
Obsidian 的链接、反链和图谱视图，让这种“知识之间的关系”变得可见。这对人类理解系统状态非常有帮助。
5.3 人和 Agent 的协作边界清晰
你不需要让 Agent 替你思考一切。
更合理的分工是：
这比“全自动第二大脑”更现实，也更可持续。
06 这套方法为什么现在才开始成熟？
很多人会问：类似 Wiki、PKM、第二大脑、Zettelkasten 这些概念，明明早就有了，为什么偏偏今天大家突然觉得“能用了”？
我觉得核心原因不是 Obsidian，也不是 Markdown，而是 Agent 能力终于开始够用 了。
过去的问题不是大家不理解“知识要沉淀”，而是维护成本太高：
结果就是：
现在 LLM 的真正价值，不只是回答你一个问题，而是把这些“维护性劳动”接过去。
这也是为什么这套方法的本质不是“更聪明的问答”，而是“更低成本的长期维护”。
当维护成本下降到足够低，知识库才有机会从爱好品变成生产系统。
07 它适合哪些人？并不是所有人都需要上来就建大系统
我很喜欢这个思路，但也不建议每个人一上来就照着搭一个巨大的知识工程体系。
更现实的判断标准是：如果你有以下特征，这套方法会特别值钱。
适合的人暂时不一定适合的人
因为这套系统真正的收益，来自“复利”。如果没有持续输入和持续查询，它的优势发挥不出来。
08 给普通人的一个务实上手方案
如果你被这个思路打动了，不一定要一步做到 Karpathy 那种理想形态。更好的做法是先搭最小可用闭环。
第一步：先定一个单一主题
不要一开始就想管理“我的全部人生知识”。
更好的做法是只做一个主题，比如：
主题越清晰，结构越容易长出来。
第二步：把原始来源和 Wiki 分开
至少建两个目录：
不要把原文摘录、临时记录、整理后的知识页混在一起。
第三步：定义几个基础页面类型
比如：
第四步：让 Agent 只做三件事
一开始别贪多，只让它做：
总结新来源更新相关页面做周期性体检
这已经足够带来很大价值了。
第五步：把好的回答回存
如果某次问答特别有价值，不要让它留在聊天记录里。让 Agent 把它整理成一页正式文档放回 Wiki。
这一步是“把聊天变资产”的关键。
09 常见误区：把系统搭复杂，比把知识沉淀下来更容易上瘾
围绕这类系统，最容易踩的坑通常不是模型不够强，而是人太容易被“系统设计感”迷住。
误区 1：一上来就做很复杂的 Schema
规则太多，维护反而会变重。Schema 应该是逐步长出来的，不是一次设计完美。
误区 2：把工具链堆得过多
向量数据库、搜索引擎、自动标签、图谱、自动摘要、数据面板全上，最后系统维护成本比知识本身还高。
误区 3：以为 Agent 会自动判断真伪
Agent 可以帮你整理，但不能代替你做最终判断。来源质量、结论可信度、偏见问题，仍然需要人把关。
误区 4：只录入，不回看
如果你只不断 ingest，不去 query、不去 lint，知识库也会越来越像信息坟场。
误区 5：把聊天记录当知识库
聊天记录是过程，不是结构。真正可复用的知识，需要整理成页面、命名、链接、可追溯。
10 5 条真正有用的避坑建议先让知识库可维护，再追求自动化。 如果结构本身已经很乱，自动化只会把混乱加速放大。每周至少做一次 Lint。 不做体检，知识库迟早会出现失链、重复、过时和孤岛。所有重要结论尽量带来源。 没有来源支撑的“洞察”，时间一长最容易失真。页面命名尽量稳定。 命名频繁变来变去，会把链接系统和认知稳定性一起拖垮。把高价值问答整理成正式页面。 这是从“会聊天的 AI”走向“会积累的系统”的分水岭。11 未来 7 天你可以怎么亲手试起来Day 1：选主题，建目录
确定一个单一研究主题，建立 sources/、wiki/、index.md。
Day 2：录入 3 个高质量来源
不要贪多，先录入少量但高质量内容，观察 Agent 如何整理页面。
Day 3：建立基础 Schema
定义命名方式、来源引用格式、页面结构。
Day 4：第一次 Query
围绕一个真实问题提问，并把高质量回答整理成新页面。
Day 5：第一次 Lint
检查重复、孤儿页、缺少链接和过时内容。
Day 6：加一个辅助工具
比如 Web Clipper、Dataview、Marp 或更好的搜索组件。
Day 7：复盘
回看这一周，判断：哪些页面真正有用？哪些结构多余？哪些流程还需要简化？
12 我的看法：这不是更高级的笔记术，而是更像“个人知识操作系统”
我觉得 Karpathy 这次带来的最大启发，不在于某个具体命令、某个插件或某个仓库，而在于一种思维转变：
你不再把 LLM 当作“替你答题的工具”，而是当作“替你维护知识结构的协作者”。
这背后其实是两个时代的分界线。
过去我们用搜索引擎，是“需要时查一下”；
现在我们开始用 Agent，是“持续把知识系统建起来”。
如果说传统 RAG 更像“临时外脑”，那么 Agent + Obsidian 这套组合，更接近一种个人知识操作系统：
对真正长期做事的人来说，这比“再多一个能上传 PDF 的聊天机器人”有价值得多。
结尾
如果你也在做 AI、内容创作、研究、投资或者开发，我很建议你认真试一次这种工作流。它最迷人的地方，不是看起来多酷，而是它有机会让你的知识越用越值钱。
等你真的把“好回答能回存、旧页面会更新、知识会体检、结构会演化”这套闭环跑起来，你会很难再回到只会临时检索的知识工具时代。
