LLM Wiki: AI时代下的个人Wiki整理方法

背景

Karpathy近日提出了一种整理个人wiki的方式：llm-wiki。俗话说，绝知此事要躬行，我按照该文章的描述内容，整理了一下我自己的个人wiki，并记录对应的结果。

什么是llm-wiki

我之间是如何使用obsidian记录wiki并且查询的？

1. 首先找到觉得有收益的文章/网页，随后人工提炼有收益的知识点。直接复制或者用自己的话整理一下。
2. 在自己的个人wiki中，先根据自己修订的目录，找到最适合存放这个页面的子页面，然后把第一步得到的内容摘抄到对应的子页面中去。
3. 在想要查找的时候，通过目录或者全局搜索关键字，找到对应的知识点并查询。

这么做有以下问题：

1. 步骤繁琐且耗费精力。识别到有价值的知识点不难，但是粘贴到自己的wiki中，并且保证格式一致需要花较多的时间。如果想用自己的话再复述一遍，则更加耗时。
2. 没有检查机制。我就出现过一个知识点，被记录了两遍的情形。一次是两年前，一次是现在。
3. 查询知识点困难。通过关键字查询/目录查询，很容易搜不到想要的内容。

Karpathy的方法是，他只做知识的摘录者，通过插件把网页一键转换成markdown，保存到本地。同时触发AI工作流，自动把新的markdown内容整合到自己的wiki中。后续的wiki知识卡片的提取/整理/双向链接都由AI来完成，将人工从工作中解放。

怎么做

为了落地这一构想，我搭建了一套基于 Cursor (作为 AI Agent) 和 Obsidian (作为可视化界面) 的工作流。其核心在于将知识库看作一个“代码仓库”，而 AI 就是这个仓库的专职维护者。

基础设施：三层架构

我将本地文件夹划分为三个逻辑层：

• raw（原始层）：存放由插件一键转化的原始 Markdown 网页、PDF 论文等。这些是“事实来源”，AI 只读不改。
• wiki（维基层）：这是真正的知识库。包含原子化的概念页面（Concepts）、实体页面（Entities）以及全局索引（Index）。
• schema（模式层）：即 .cursorrules 文件。这是给 AI 的指令集，定义了它必须遵守的“编织规范”，例如双向链接的格式、日志记录要求以及冲突处理机制。

2. 自动化摄取流水线 (Ingest Pipeline)

现在的操作流程变成了这样：

1. 一键采集：看到好文章，使用浏览器插件将其转为 .md 丢入 raw_sources。
2. AI 编织：在 Cursor 中输入简单的指令：“读取新文件，更新我的 Wiki”。
3. 多点更新：AI 会自动执行“缝合”操作——它会同时修改 10 多个相关的 Wiki 页面。它不再是简单地把文章贴进去，而是把文章中的新知识点，像拼图一样塞进现有的知识网中。

深度体验：LLM-Wiki 的收益在哪里？

在实际运行了一段时间后，我发现这套系统解决了传统笔记法无法跨越的鸿沟：

节省双向link

在 LLM-Wiki 中，分类是自动发生的。AI 不会觉得累，它能瞬间完成跨文件的引用更新和索引维护。对我来说，维护成本从“一小时”降到了“一句话”。

从“存档”转向“整合” (Synthesis)

这是最令我惊喜的一点。当我有两个互相冲突的知识点时（比如两年前的实验数据和现在的理论分析），AI 在整合时会主动标注 [Contradiction]。它不仅仅是帮我存起来，它是在帮我审计知识。

语义化的“外挂大脑”

现在的查询不再依赖于“关键词匹配”。由于 AI 已经预先建立好了复杂的双向链接，我可以直接问：“根据我之前的标定记录，这次数据抖动的可能原因是什么？”AI 会穿透数十个零散的实验记录，直接给出一个综合后的结论。

结语

Karpathy 提到，人类之所以放弃维护 Wiki，是因为维护的负担增长得比价值快。而 LLM 刚好相反，它最擅长的就是处理这些枯燥、重复、但逻辑极强的簿记工作。

但不仅仅是做记录这一件事。Karpathy实际上在教我们一个方法论：如果一件事情重复且枯燥，如何使用AI来优雅的代替人进行工作。