用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 中经常按 Cmd+G。视觉地图显示哪些页面是枢纽，哪些是孤立的，以及一切如何连接。这是看到你的 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 无法解决的部分是谁来做维护。现在我们有了答案。

原文链接: I used Karpathy’s LLM Wiki to build a knowledge base that maintains itself with AI

汇智网翻译整理，转载请标明出处