LLM Wiki个人知识库构建深度评测与对比分析

2026-06-11阅读 0热度 0

分析报告

不妨想一个场景：你手头有15份关于某个项目的文档。产品规格说明在一处，会议记录在另一处，竞争对手分析报告则被遗忘在下载文件夹的某个角落。几个月后，有人问了你一个很简单的问题，结果你花了一个多小时，翻遍所有文件夹，就为了找到那个你曾经读过一次的关键段落。

文档就在那里，知识也在里面。但它们彼此割裂、不成体系——除非你把所有内容重新读一遍，否则根本没法找到想要的答案。

我找到了一个解决方法。它源自Andrej Karpathy的那个一页纸的“想法文档”，加上一个名为Cursor的AI代码编辑器，以及一个叫Obsidian的免费笔记应用。整个过程大概花了30分钟：我从那页手写的想法出发，最终得到了一个功能完整的个人知识库——它能够接受我丢进去的任何文档，并把它们结构化地转换为相互链接的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 是人工智能领域最受关注的代表人物之一。他是OpenAI的创始成员，曾领导特斯拉的AI与自动驾驶视觉团队，也以能用任何人都能明白的方式，解释深奥技术思想而闻名。所以每次他分享点什么，AI社区基本都要仔细听。

就在几天前，他公开了一份叫 llm-wiki.md 的简短文档。这不是一个产品或一个应用。它只是一个想法——用普通 Markdown 编写，描述了一种如何借助 AI 来构建和维护个人知识库的模式。

这份文档被设计成可以复制粘贴到任何AI模型（Claude、ChatGPT、Codex等）的上下文中，然后模型会阅读它、理解这个模式，并最终根据你的需求，搭建一个能真正工作的版本。

这一页纸的想法，就是这个代码仓库所有内容的基础。

3、什么是 LLM Wiki，它是如何工作的？

核心理念其实很简单。

看看大多数AI工具是怎么做的：你上传文档，提出问题，AI去你的文件里搜索一遍然后给出答案。效果不错，但有一个硬伤——AI在每次回答问题之后，会把之前的一切都忘掉。下次你再问，它又从零开始。重新读、重新搜、重新推导答案。什么都没保存，什么都没在之前的基础上积累。

LLM Wiki 把这个逻辑彻底反转了。AI不会再每次查询时都要重新检索原始文档，而是先完整地读一遍你的所有文档，然后从中构建出一个结构化的Wiki。这个Wiki是一堆Markdown文件的集合，包括摘要页面、产品页面、概念页面、人物页面和对比表格——全部通过维基风格的链接互相连接。当你添加新文档时，AI不会重新开始。它会读取新源文件，然后更新现有的Wiki页面、在需要的地方创建新页面、标记出前后矛盾的信息，并保证所有内容的一致性。

Wiki是一份持久的产出物。随着时间推移，它会逐步复合增长。你丢进去的源文件越多，它就越丰富、越互联。

3.1 三层结构

LLM Wiki由三个部分组成：

原始源文件——一个叫 raw/ 的文件夹。所有文档都放在这里：PDF、Markdown文件、剪藏的文章、记录。AI从这个文件夹读取内容，但绝不修改任何东西。你的原件始终会保持原样。
Wiki——一个叫 wiki/ 的文件夹。这个文件夹里的所有内容都由AI来创建和维护。它负责构建页面、维护交叉引用、更新术语表和索引。你负责浏览它；AI负责书写它。
规范——一个叫 CLAUDE.md 的文件。这是AI的操作手册。它定义了当前知识库里有哪些页面类型、处理新源文件时要遵循什么样的工作流程、页面如何格式化、以及何时需要对整个Wiki做一次健康检查。把它想象成一本规则手册，把通用的大模型，变成一个纪律严明的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

Cursor 通读了整份文档，把这个想法映射到了我的具体角色上：

痛点：产品更新分散在文档、Slack、邮件里——如何解决：全部摄取，AI将它们合并到一个Wiki中。
痛点：没有人维护的术语表——如何解决：AI自动构建并持续更新一份活的术语表。
痛点：新团队入职产品或代码库——如何解决：提供规格和文档，获得一份综合性的Wiki。
痛点：竞争对手研究只做一次就丢失——如何解决：AI维护一份结构化的对比，随时间持续增长。
痛点：从会议录音编写发布说明——如何解决：摄取记录，AI把关键决策归档到现有页面中。

提示 2

五个字。Cursor 一次性规划并构建了整个项目：

创建了raw/和wiki/文件夹
编写了包含实体类型、页面格式、9步摄取工作流程、查询工作流程、检查工作流程以及会话启动检查清单的CLAUDE.md
创建了四个起始Wiki页面：index.md、log.md、overview.md和glossary.md

提示 3

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中输入：

AI会：

阅读文档
和你讨论关键要点
在wiki/sources/中创建源摘要页面
为找到的任何产品、功能、人物或概念创建新页面
用新术语更新术语表
用所有新页面更新索引
如果大局有变化，更新概览页面
在wiki/log.md中记录所有内容并加上时间戳

你会看着页面在Obsidian中实时出现。

步骤 6：提问

AI读取Wiki，组织答案，然后询问：“Should I sa ve this as a wiki page?” 如果你说 yes，答案就会成为Wiki里一个永久的分析页面。你的提问丰富了知识库的内容。

步骤 7：继续提供内容

每个新源文件都建立在之前所有内容的基础上。概览页面逐步演变，术语表越来越丰富，交叉引用数量成倍增加。大概在10到15个源文件后，Wiki开始呈现出许多你从未注意到的联系。

步骤 8：偶尔检查

大约每完成10次摄取后，执行一次检查：

AI会检查：

页面之间的矛盾
被较新源文件替换掉的过时声明
孤立页面——没有任何链接指向它们
被提及但缺少自己页面的重要概念
不同页面之间不一致的术语

它会报告发现的问题，并询问要对哪些修复进行操作。

7、这适合谁

技术写作者——每个规格都会更新术语表。每个客户电话都会添加到人物页面。每个竞争对手分析都会在前一个基础上持续构建。

研究人员——论文、文章和报告会被归档、总结和交叉引用。项目结束时，你会得到一份有着演变论点和所有已建立联系的Wiki。

产品经理——把PRD、客户访谈、竞争分析和冲刺回顾丢进去，Wiki会维护好全局视图。

学生——每个教科书章节都能作为一个源文件。AI会构建出概念页面，并将它们相互链接。考试到来时，你已经获得了一份连接性的学习指南。

任何随时间构建知识的人——旅行计划、爱好研究、健康记录、课程笔记。只要信息来自多个源头，这套模式都管用。

8、示例：技术写作者的第一周

第1天

把三份入职文档放入raw/（PRD、内部FAQ、发布说明）。逐一摄取。AI创建了产品页面、人物页面、术语表，并标记了文档之间的矛盾。一天结束时：8到10个Wiki页面——而你一个字都没写过。

第2天

你记录了一场工程师访谈，转录后放入raw/。AI提取了技术决策，更新了功能页面，添加了术语表术语，同时标记了与PRD的两个冲突。现在你手里有了一份具体的澄清事项清单。

第3天

用Obsidian Web Clipper剪藏了三份竞争对手文档。全部摄取。AI创建了一份对比分析。你直接要求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永远不会因为维护工作而感到疲倦。它可以一次性更新15个文件。它会在新信息与旧声明冲突时第一时间注意到。它会保持术语表最新、索引完整、交叉引用实时更新。几乎为零的维护成本，让Wiki重新变得值得维护。

这就是Karpathy那个想法背后真正的洞察。知识库的瓶颈从来不是阅读或思考的部分，它一直在——记录与管理的琐事上。而记录与管理，正好是AI最擅长的。

你的工作变成了其中真正有趣的部分：找到好的源文件、提出正确的问题、判断哪些内容重要。而其他所有——那些让你曾经试图维护的每一个Wiki最终走向失败的重担——都有人接手了。

Bush的愿景是私密的、精心策划的、深度个人化的。而LLM Wiki，比过去80年里我们构建的任何东西，都更接近他当初的想象。Bush无法解决的那部分问题——谁来承担所有维护工作？现在，我们有了答案。