490万浏览量的方案：用 LLM 构建持续更新积累的个人知识库

Karpathy 发了一条推文分享了他近期重点在用 AI 构建个人知识库用 LLM 构建和维护个人知识库让它成为一个持续更新积累的 wiki。博主 Nick Spisak 这个思路打造了一套保姆级实现教程获得 44k 人的收藏。我仔细看了一遍发现它解决了一个我一直没解决好的问题知识库的知识组织和维护成本。一、核心思路1. RAG 的缺陷大多数人用 LLM 处理文档的方式是这样的上传一堆文件 → 检索相关片段 → 生成答案。它有个问题每次提问LLM 都要从零开始重新发现知识。如果你问一个需要综合五份文档的复杂问题LLM 每次都要找到这些片段重新拼接重新理解。没有任何积累。NotebookLM、ChatGPT 文件上传、大多数 RAG 系统都是这个模式。2. 编译式知识库Karpathy 的思路不同。不是在查询时检索原始文档而是让 LLM持续构建和维护一个 wiki。一个结构化的、相互链接的 markdown 文件集合基于你的原始素材。当你添加一个新来源时LLM 不会只是索引它以便后续检索而是读取它提取关键信息整合到现有 wiki 中——更新实体页面、修改主题摘要、标记新旧数据矛盾、强化或挑战正在演进的综合观点知识被编译一次然后保持更新而不是每次查询都重新推导。Wiki 是一个持久的、可复利的人工制品。建立交叉引用综合已经反映了你读过的所有内容。每添加一个来源每问一个问题wiki 都会变得更丰富。3. 三层架构层级名称作用谁负责第一层Raw sources原始素材你策划的源文档集合文章、论文、图片、数据文件。不可变——LLM 只读不改你第二层Wiki维基LLM 生成的 markdown 文件目录摘要、实体页、概念页、对比页、概览、综合。LLM 完全拥有这一层LLM第三层Schema说明书一个文档如 CLAUDE.md告诉 LLM wiki 如何组织、遵循什么约定、摄入来源/回答问题/维护 wiki 时遵循什么工作流。你和 LLM 共同演进你 LLMLLM 写并维护所有内容做所有琐碎工作总结、交叉引用、归档、记账。你负责获取来源、探索、提出正确的问题。二、三个核心操作操作一摄入Ingest你把一个新来源丢进 raw collection告诉 LLM 处理它。流程LLM 读取来源 → 与你讨论关键收获 → 在 wiki 中写一个摘要页 → 更新索引 → 更新相关实体和概念页 → 在日志中追加一条记录。一个来源可能触及 10-15 个 wiki 页面。操作二查询Query你向 wiki 提问。LLM 搜索相关页面阅读它们综合出一个带引用的答案。答案可以有多种形式markdown 页面、对比表格、幻灯片Marp、图表matplotlib、canvas。关键洞察好的答案可以回存到 wiki 中成为新页面。操作三健康检查Lint定期让 LLM 检查 wiki 的健康状况。查找页面之间的矛盾被新来源取代的过时声明没有入链的孤儿页面被提及但缺少独立页面的重要概念缺失的交叉引用可以通过网页搜索填补的数据空白LLM 擅长建议新的研究问题和新的来源。这保持 wiki 在成长过程中健康。三、两个辅助文件索引和日志index.md内容导向wiki 中所有内容的目录——每个页面带链接、一句话摘要、可选元数据日期、来源数。按类别组织实体、概念、来源等。LLM 在每次摄入时更新它。回答查询时LLM 先读索引找到相关页面再钻进去。在中等规模下约 100 个来源几百个页面工作得很好不需要基于嵌入的 RAG 基础设施。log.md时间导向追加式记录发生了什么、何时发生的——摄入、查询、健康检查。一个技巧每条记录用一致的前缀开头例如## [2026-04-02] ingest | Article Title这样 log 就可以用简单的 unix 工具解析grep ^## \[ log.md | tail -5 # 最近5条记录日志给你 wiki 演进的时间线帮助 LLM 理解最近做了什么。四、六个实用技巧Obsidian Web Clipper浏览器扩展把网页文章转成 markdown。快速把来源加入 raw collection。图片本地化在 Obsidian 设置中把附件文件夹路径固定到一个目录如raw/assets/然后绑定快捷键下载当前文件的所有图片。这样 LLM 可以直接查看和引用图片不依赖可能失效的 URL。图谱视图Obsidian 的 graph view 是查看 wiki 形状的最好方式——什么连接到什么、哪些页面是枢纽、哪些是孤儿。Marp基于 markdown 的幻灯片格式。Obsidian 有插件。可以直接从 wiki 内容生成演示文稿。DataviewObsidian 插件对页面 frontmatter 运行查询。如果你的 LLM 给 wiki 页面添加 YAML frontmatter标签、日期、来源数Dataview 可以生成动态表格和列表。Git 版本控制wiki 只是一个 markdown 文件的 git 仓库。你免费获得版本历史、分支、协作。五、七步搭建同款知识库了解了思路和架构实际搭建只需要七步。第一步三个文件夹两分钟搭好创建一个项目目录里面放三个文件夹my-wiki/ ├── raw/ # 原始素材 ├── wiki/ # LLM 生成的维基页面 └── CLAUDE.md # 说明书告诉 LLM 怎么组织维基raw/是你收集的原始文件wiki/是 LLM 写的维基页面CLAUDE.md是关键配置文件。第二步不用整理什么都往里扔raw/文件夹不需要整理。文章、论文、图片、数据文件……丢进去就行。Karpathy 的原话是These are immutable — the LLM reads from them but never modifies them.这些是不可变的——LLM 只读不改。你的工作是策划来源不是组织它们。第三步让 AI 自动把网页存进来如果你用的是 Obsidian安装Web Clipper扩展。浏览网页时一键把文章转成 markdown保存到raw/文件夹。如果你用的是 Claude Code 或类似的 AI 编程助手可以用agent-browser工具自动抓取网页内容。第四步给 AI 一份说明书CLAUDE.md是整个方案的核心。它告诉 LLMwiki 如何组织目录结构、命名约定摄入来源时遵循什么工作流回答问题时如何查找和引用如何维护一致性# 知识库 Schema ## 这是什么 一个关于 [你的主题] 的个人知识库。 ## 如何组织 - raw/ 包含未处理的源材料。永远不要修改这些文件。 - wiki/ 包含整理后的维基。完全由 AI 维护。 - outputs/ 包含生成的报告、答案和分析。 ## 维基规则 - 每个主题在 wiki/ 中有自己的 .md 文件 - 每个维基文件以一段摘要开头 - 使用 [[topic-name]] 格式链接相关主题 - 在 wiki/ 中维护一个 INDEX.md列出每个主题及一行描述 - 当添加新的原始源时更新相关的维基文章 ## 我的兴趣点 [列出 3-5 个你希望这个知识库关注的方向]第五步一条指令AI 把笔记编成维基打开你的 AI 编程助手Claude Code、OpenAI Codex 等进入项目目录说请阅读raw/文件夹里的所有文件按照CLAUDE.md的约定在wiki/文件夹里生成维基页面。AI 会读取每个来源提取关键信息创建摘要页、实体页、概念页更新索引维护交叉引用你打开 Obsidian看着wiki/文件夹里自动生成的一个个页面链接已经建好矛盾已经标记。第六步开始提问打造活的知识库当知识库运行一段时间存够了一些你放进去的日常素材你可以开始提问“基于知识库中的所有内容我对 【某概念】 理解中最大的三个缺失是什么”“比较知识库里对 【某概念】 的信息。有何相同和不同之处”“用这个知识库中的关于【主题】的内容写一份综述。”AI 会搜索知识库根据素材回答你的问题。然后把输出的回答放到 outputs/ 或让 AI 用新见解更新相关的维基文章。每个问题都让下一个答案更好正循环就转起来了搜索相关页面综合答案把好的答案回存到 wiki你探索得越多wiki 就会越丰富。第七步定期检查不让错误复利每隔一段时间说请检查wiki/文件夹的健康状况找出矛盾、孤儿页面、缺失的交叉引用。AI 会给你一份报告你可以决定修复哪些问题。六、我使用知识库的过往看到 Karpathy 这个思路读到使用 Wiki 作为 LLM 产出知识的组织形式时我有一种醍醐灌顶的感觉觉得有必要更新我的知识库构建方式。下面聊聊我自己使用个人知识库的经历。阶段一传统笔记软件最开始用的是有道笔记。用了一段时间后发现一个问题导出很困难。后来迁移到开源工具 Joplin。支持三端同步手机、电脑、云端但慢慢发现另一个问题灵活性还是不够。笔记格式是 Joplin 自己的数据库迁移仍然有成本。阶段二Obsidian后来接触到了 Obsidian非常认同它的理念笔记应该用 markdown 格式本地存储方便迁移不应受软件、平台约束。用它同时管理日常笔记和和 ArkClaw 龙虾所有对话形成的记忆和输出文件。阶段三ima Obsidian 双轨制但在中国还有一个问题要解决公众号文章怎么收藏网页文章可以用 Obsidian Web Clipper但微信公众号是个特殊的存在。后来我发现腾讯家的 ima 平台可以直接收藏公众号文章顺带网页文章也能存进去。于是形成了现在的双轨制场景工具日常记录笔记Obsidian公众号/网页文章收藏ima 知识库两套知识库各自存放各自管理没有联系起来。核心问题存储≠知识我这套模式最大的问题是开头提到的RAG方案的缺点只有存储和检索没有整理和组织。信息只是存起来了没有形成知识。看到 Karpathy 的 wiki 思路时我意识到LLM 可以做那个记账的人帮我整理、交叉引用、发现矛盾。存储是静态的wiki 是持续更新的。七、这套方案的瓶颈写到这里我产生了一个疑问知识库越来越大如何检索于是我继续翻下面的评论果然有人提到两个问题。问题一查询瓶颈当你的wiki页面超过几百页后grep 会变慢。你想要查询一些信息比如我上周添加了关于 X 的哪些内容显示所有标记为未验证的内容。简单的读取文件无法实现这一点。索引在初期很有帮助但它无法扩展。问题二结构瓶颈无论你是否计划结构都会悄然形成。前言、命名规范、文件夹规则……wiki会自行构建起一套结构模式。在某个时刻你会意识到你是在与工具对抗而不是与它们协同工作。解决方案一BinderBinder 的作者遇到了同样的问题他的解决思路是与其让文件慢慢演变成数据库不如从结构化数据入手直接渲染成 Markdown 格式。数据进入事务日志在 SQLite 中建立索引每个实体以 Markdown 文件的形式显示。你可以用任何编辑器编辑编辑后的数据会返回。代理通过 API 写入数据。双向通信。GitHub: https://github.com/mpazik/binder解决方案二Knowledge Engine双层检索另一个开源实现用 Memvid 桥接器做了双层检索层级作用性能维基层兼容 Obsidian 的 Markdown 格式供人阅读正常Memvid 层.mv2 单文件内存机器查询搜索速度 5 毫秒桥接器以原子方式保持两者同步——内容哈希、漂移检测、矛盾和孤立页面的 lint 检查。当文档数量超过 500 篇grep 速度变慢时Memvid 层搜索速度 5毫秒的优势就体现出来了。GitHub: https://github.com/tashisleepy/knowledge-engine八、我的下一步打算Karpathy 的方案给了我一个清晰的方向用三个文件夹raw / wiki / CLAUDE.md搭建骨架raw/文件夹设定为 Obsidian 里现有的笔记仓库目录让 LLM 按照 CLAUDE.md 的约定开始生成维基页面每周做一次健康检查如果 wiki 增长到 500 页考虑引入 Binder 或 Knowledge Engine 的双层架构我们维护知识库失败不是因为懒是因为维护成本增长快于价值增长。LLM 不知疲倦不会忘记更新交叉引用因此能保持维护一个成长为复杂的wiki因为维护的时间成本接近于零。这可能是个人知识库的下一个形态。你是怎么构建自己的知识库呢欢迎评论区留言。参考资料Karpathy X: https://x.com/karpathy/status/2040470801506541998Binder: https://github.com/mpazik/binderKnowledge Engine: https://github.com/tashisleepy/knowledge-engine-END-推荐阅读我的 OpenClaw 可以开口说话NoizAI 技能安装使用教程谷歌开源Gemma 4256K原生多模态免费商用创建使用费曼学习技能让 AI 帮你快速学习新领域知识实战教程Claude Code 源码泄露解读背后的技术细节谷歌提示工程白皮书Google Prompt Engineering White-paper给 OpenClaw 接入10000工具和数据为你盯盘给出独家策略让你的OpenClaw替你打工从0到1跑通小红书运营全流程实战教程