用LLM Wiki构建个人知识库

你有 15 份关于某个项目的文档。产品规格说明在这里。会议记录在那里。竞争对手分析报告保存在下载文件夹的某个地方。三个月后有人问你一个简单的问题你花了一个小时翻遍各个文件夹试图找到你曾经读过一次的那段话。文档是存在的。知识也在里面。但它们是分散的、不连贯的不重新阅读所有内容就无法搜索。我找到了一个解决方案。它涉及 Andrej Karpathy 的一页纸想法文档一个叫做 Cursor 的 AI 代码编辑器以及一个叫做 Obsidian 的免费笔记应用。在大约 30 分钟内我从那一页纸的想法变成了一个完全可用的个人知识库可以接受我扔给它的任何文档并将其转换为结构化的、相互链接的 wiki 页面。而我自己一个 wiki 页面都没有写。这篇文章讲述了这一切是如何发生的并为你提供了一个可以克隆并立即开始使用的代码仓库。1、开始使用代码仓库链接https://github.com/balukosuri/llm-wiki-karpathy包含内容Karpathy 的原始llm-wiki.md想法文档为技术写作者定制的CLAUDE.md规范可根据你的领域进行编辑预配置的 Obsidian 仓库设置图谱视图、快捷键、侧边栏一个空的raw/文件夹准备存放你的第一个源文件一个wiki/文件夹包含四个起始页面索引、日志、概览、术语表放入你的第一个文档。说 “ingest”。看着 wiki 自己写自己。2、Andrej Karpathy 是谁Andrej Karpathy 是 AI 领域最知名的人物之一。他是 OpenAI 的创始成员领导过特斯拉的 AI 和自动驾驶视觉团队并以其能够用任何人都能理解的方式解释深层技术思想而闻名。当 Karpathy 分享某些东西时AI 社区会倾听。几天前他分享了一份名为llm-wiki.md的简短文档。它不是一个产品或应用程序。它只是一个想法 — 用普通 markdown 编写描述了一种如何使用 AI 代理来构建和维护个人知识库的模式。该文档被设计为可以复制粘贴到任何 AI 代理Claude、ChatGPT、Codex 或其他中。代理会阅读它理解这个模式然后构建一个适合你需求的工作版本。原文链接Karpathy’s llm-wiki.md这一页纸的想法是这个仓库中所有内容的基础。3、什么是 LLM Wiki它是如何工作的核心理念很简单。**大多数 AI 工具是这样工作的**你上传文档提出问题AI 搜索你的文件以生成答案。这工作得很好但 AI 在每次问题后都会忘记所有内容。下次你问什么时它会从头开始。它重新阅读、重新搜索、重新推导答案。什么都没有保存。什么都没有在之前的基础上建立。LLM Wiki将此翻转过来。AI 不是每次都搜索你的原始文档而是阅读你的文档一次并从中构建一个结构化的 wiki。这个 wiki 是 markdown 文件的集合包括摘要页面、产品页面、概念页面、人物页面和比较表格所有这些都通过 wiki 风格的链接相互连接。当你添加新文档时AI 不会从头开始。它阅读新源文件并更新现有 wiki添加到已存在的页面在需要的地方创建新页面标记矛盾并保持一切一致。wiki 是持久的工件。它随时间复合。你给它提供的源文件越多它就越丰富、越互联。3.1 三层结构LLM Wiki 有三个部分原始源文件— 一个名为raw/的文件夹。这是你放置文档的地方 — PDF、markdown 文件、剪藏的文章、记录。AI 从这个文件夹读取但从不改变其中的任何内容。你的原件保持原样。wiki— 一个名为wiki/的文件夹。AI 创建并拥有这个文件夹中的所有内容。它构建页面、维护交叉引用、保留术语表并更新索引。你浏览它AI 编写它。规范— 一个名为CLAUDE.md的文件。这是 AI 的操作手册。它定义了存在哪些类型的页面、处理新源文件时遵循什么工作流程、如何格式化页面以及何时检查 wiki 是否有问题。把它想象成将通用 AI 转变为有纪律的 wiki 维护者的规则手册。3.2 三种操作**摄取Ingest**你将文档放入raw/并告诉 AI 处理它。AI 阅读它、创建摘要页面、更新整个 wiki 中的实体页面、将新术语添加到术语表、更新索引并记录它所做的事情。单个源文件可以触及 10-15 个 wiki 页面。**查询Query**你提出问题。AI 阅读 wiki而不是原始文件来组合答案。好的答案可以保存回 wiki 作为分析页面所以你的问题会随着时间推移使知识库变得更丰富。**检查Lint**你要求 AI 对 wiki 进行健康检查。它发现矛盾、过时信息、没有链接的孤立页面以及缺失的交叉引用。把它想象成你的知识库的拼写检查。4、我如何用 Cursor 在三个提示中构建它这就是发生的事情。我打开 Cursor一个 AI 驱动的代码编辑器将 Karpathy 的llm-wiki.md文件放入一个空项目文件夹中然后开始与 AI 对话。提示 1“What is this and how can I make use of this as a technical writer?”Cursor 阅读了整个文档并将这个想法映射到我的角色痛点LLM Wiki 如何解决它产品更新分散在文档、Slack 和邮件中全部摄取AI 将它们合并到一个 wiki 中没有人维护的术语表AI 自动构建和更新一个活的术语表新入职产品或代码库提供规格和文档获得一个综合的 wiki竞争对手研究只做一次就丢失了AI 维护一个随时间增长的结构化比较从会议录音编写发布说明摄取记录AI 将关键决策归档到现有页面提示 2“Can you make a plan and create?”五个字。Cursor 一次性规划并构建了整个项目创建了raw/和wiki/文件夹编写了包含实体类型、页面格式、9 步摄取工作流程、查询工作流程、检查工作流程和会话启动检查清单的CLAUDE.md创建了四个起始 wiki 页面index.md、log.md、overview.md和glossary.md提示 3“Can you set up Obsidian?”Cursor 通过 Homebrew 安装了 Obsidian 并预配置了仓库新文件默认放在wiki/中图谱视图按页面类型着色* 图谱视图、搜索和快速切换的键盘快捷键启动时打开概览页面两个窗口并排左侧是 Cursor 用于与 AI 对话右侧是 Obsidian 用于实时浏览 wiki。5、克隆此仓库时你会得到什么这是确切的文件结构project-root/ │ ├── llm-wiki.md # Karpathy 的原始想法文档 ├── CLAUDE.md # 规范 — 告诉 AI wiki 如何工作 │ ├── raw/ # 你的源文档AI 读取从不写入 │ └── .gitkeep │ ├── wiki/ # AI 生成的知识库 │ ├── index.md # 所有页面的主目录空的准备填充 │ ├── log.md # 发生了什么以及何时发生 │ ├── overview.md # 宏观综合随时间演变 │ ├── glossary.md # 术语、定义、风格规则 │ └── sources/ # 每个原始文档一个摘要 │ └── .obsidian/ # 预配置的 Obsidian 仓库 ├── app.json # 文件路径、链接行为 ├── appearance.json # 主题、字体大小 ├── core-plugins.json # 哪些插件处于活动状态 ├── graph.json # 图谱视图颜色和布局 ├── hotkeys.json # 键盘快捷键 └── workspace.json # 默认标签页和侧边栏布局为什么这个结构有效清晰的分离。raw/是你的。wiki/是 AI 的。你从不在wiki/中编写。AI 从不更改raw/。规范是大脑。CLAUDE.md定义实体类型、页面格式和工作流程。AI 首先读取此文件并遵循其规则。编辑此文件以更改 AI 在你的特定领域的行为方式。索引是地图。当你提问时AI 首先读取index.md以找到相关页面然后深入研究它们。不需要向量数据库或嵌入 — 索引在数百页之前都工作得出奇地好。日志是时间线。每次摄取、查询和检查过程都会记录时间戳。你总是知道发生了什么以及何时发生的。Obsidian 是预配置的。任何克隆仓库的人都会得到一个即用型 Obsidian 仓库其中图谱视图、快捷键和侧边栏布局已经设置好。无需手动配置。6、如何使用此仓库步骤 1克隆它git clone [YOUR-REPO-URL] cd llm-wiki步骤 2在 Cursor 中打开在 Cursor 中打开项目文件夹。AI 自动读取CLAUDE.md并理解 wiki 结构及其所有规则。如果你使用不同的 AI 代理Claude Code、Codex 或其他请将CLAUDE.md的内容粘贴到你的代理上下文中。步骤 3在 Obsidian 中打开将同一文件夹作为 Obsidian 仓库打开。如果你没有 Obsidian只需让 Cursor“Set up Obsidian for me.” 它会安装并打开仓库。一切都是预配置的 — 快捷键、图谱视图颜色、侧边栏布局。步骤 4将源文件放入 raw/任何文档都可以产品规格或设计文档会议记录剪藏的网页文章使用 Obsidian Web Clipper 浏览器扩展风格指南PDF 报告保存为文本的邮件线程步骤 5说 “ingest”在 Cursor 中输入“Ingest raw/my-document.pdf”AI 会阅读文档与你讨论关键要点在wiki/sources/中创建源摘要页面为它找到的任何产品、功能、人物或概念创建新页面用新术语更新术语表用所有新页面更新索引如果大局发生变化更新概览在wiki/log.md中记录所有内容并加上时间戳你看着页面在 Obsidian 中实时出现。步骤 6提问“What are the main risks identified across all my sources?”AI 阅读 wiki组合答案并询问“Should I save this as a wiki page?” 如果你说 yes答案将成为 wiki 中的永久分析页面。你的问题使知识库更丰富。步骤 7继续提供内容每个新源文件都建立在之前的基础上。概览页面演变。术语表增长。交叉引用倍增。在 10-15 个源文件之后wiki 开始向你展示你未曾注意到的联系。步骤 8偶尔检查大约每 10 次摄取“Lint the wiki”AI 检查页面之间的矛盾被较新源文件替换的过时声明没有链接指向它们的孤立页面被提及但缺少自己页面的重要概念页面间不一致的术语它报告发现的问题并询问要应用哪些修复。7、这适合谁技术写作者— 每个规格都更新术语表。每个客户电话都添加到人物页面。每个竞争对手分析都建立在上一个之上。研究人员— 论文、文章和报告被归档、总结和交叉引用。到项目结束时你有一个带有演变论点和所有已建立联系的 wiki。产品经理— 提供 PRD、客户访谈、竞争分析和冲刺回顾。wiki 维护大局。学生— 每个教科书章节都成为一个源文件。AI 构建概念页面并链接它们。到考试时你有一个连接的学习指南。任何随时间构建知识的人— 旅行计划、爱好研究、健康跟踪、课程笔记。任何信息来自多个来源的事情。8、示例技术写作者的第一周第 1 天将三份入职文档放入raw/PRD、内部 FAQ、发布说明。逐一摄取。AI 创建产品页面、人物页面、术语表并标记文档之间的矛盾。一天结束时8 到 10 个 wiki 页面一个都没有写。第 2 天记录工程师访谈转录它放入raw/。AI 提取技术决策、更新功能页面、添加术语表术语并标记与 PRD 的两个冲突。你现在有一个具体的澄清事项清单。第 3 天用 Obsidian Web Clipper 剪藏三份竞争对手文档。摄取所有三份。AI 创建比较分析。要求它基于 wiki 起草文档大纲。将大纲保存为分析页面。第 4 天在编写之前打开wiki/glossary.md。每个术语、拼写和已弃用的名称都在那里。检查人物页面以了解受众。检查产品页面以确保准确性。从 wiki 编写而不是翻阅原始文件。第 5 天获得审查反馈。将其保存为 markdown 文件放入raw/摄取。AI 在各处重命名功能将旧名称移至已弃用列表并更新引用它的每个页面。一次摄取每个页面都更新。**一周后**15 到 20 个 wiki 页面、一个活的术语表、一个带有未解决问题的概览、完整的活动日志以及一个显示一切如何连接的图谱视图。9、使其更好工作的技巧一次摄取一个源文件。你可以批量摄取许多文档但你会失去引导 AI 的机会。保持参与 — 阅读摘要告诉 AI 要强调什么在摄取过程中提出后续问题。当你参与时wiki 会变得更好。保存你最好的问题。当你提出问题并获得有用的答案时告诉 AI 将其保存为分析页面。你的探索应该在 wiki 中复合而不是消失在聊天历史中。使用图谱视图。在 Obsidian 中经常按CmdG。视觉地图显示哪些页面是枢纽哪些是孤立的以及一切如何连接。这是看到你的 wiki 增长的最令人满意的方式。编辑规范。CLAUDE.md不是一成不变的。如果你发现你的领域需要一种新的页面类型如API 端点或客户细分或食谱变体将其添加到规范中并告诉 AI。wiki 适应你的需求。在编写之前检查术语表。每次你坐下来写东西时首先打开wiki/glossary.md。它有正确的术语、错误的术语以及每个选择背后的原因。这使你的写作保持一致而不必记住所有内容。不要自己编写 wiki 页面。抵制诱惑。你的工作是找到好的源文件并提出好的问题。AI 的工作是总结、交叉引用、归档和簿记。让它做它的工作。10、结束语人们放弃 wiki 的原因不是他们不再关心知识。而是维护变得太多了。想一想。更新交叉引用。保持摘要最新。确保第 7 页不与第 23 页矛盾。将新术语添加到术语表。将新页面链接到旧页面。这项工作无聊、重复且永无止境。所以 wiki 会过时。人们不再信任它。最终没有人打开它。AI 完全改变了这个等式。AI 永远不会厌倦维护。它可以一次性更新 15 个文件。它注意到新信息何时与旧声明矛盾。它保持术语表最新、索引完整和交叉引用最新。wiki 维护的成本几乎降至零。这就是 Karpathy 想法背后的洞察。知识库的难点从来不是阅读或思考。它一直是簿记。而簿记正是 AI 最擅长的。你的工作变成了有趣的部分找到好的源文件、提出正确的问题并决定什么重要。其他一切 — 让你试图维护的每个 wiki 失败的繁重工作 — 都被处理了。Karpathy 在他的原始文档中提到这个想法与 Vannevar Bush 1945 年的 Memex 有关 — 一个个人知识存储的愿景在文档之间有关联线索。Bush 想象一台可以在相关想法之间跟随链接的机器构建一个每次使用都会变得更丰富的连接知识网络。我们最终得到的网络与此完全不同。它是公共的、嘈杂的文档之间的连接大多是偶然的。Bush 的愿景是私人的、精心策划的和深度个人的。LLM Wiki 比我们在 80 年中构建的任何东西都更接近他的想象。Bush 无法解决的部分是谁来做维护。现在我们有了答案。原文链接用LLM Wiki构建个人知识库 - 汇智网