# Karpathy 的 LLM Wiki 火了，我改造了一下，比原版更好用
**作者**: 范凯说 AI | Kai on AI
**日期**: 2026-04-06T15:11:37.000Z
**来源**: [https://x.com/fankaishuoai/status/2041171980494479679](https://x.com/fankaishuoai/status/2041171980494479679)
---
> 参考：Karpathy's LLM Wiki Gist
AI 界的全球顶流 Andrej Karpathy 发了一个 Gist，讲怎么用 LLM 来管理个人知识库，现在超级无敌火爆。我仔细看了一遍他的方案，从建立个人 Wiki 的角度来说，方案很优雅，但直接照搬不现实 ， 因为 AI 研究者和 我这种 AI 内容创作者的需求差太远了。
其实我用 OpenClaw + Obsidian 来做个人知识库管理的实践，已经有 2 个多月了，有很多自己的心得。这次结合他的方法论，升级了我的方案，打造了一套既优雅、又实用的 AI 知识库管理，分享给大家。
## Karpathy 想解决什么问题
一句话：别让 AI 每次都从零开始帮你想，让它帮你把知识攒起来。
你肯定有过这种体验 — 同一个问题，换个 session 问 AI，它又从头推导一遍。之前聊过的上下文全丢了。Karpathy 的解法是：让 LLM 把每次对话中产生的知识，沉淀成 Markdown 文件。下次再问，AI 先翻已有的笔记，在这个基础上往前推。
知识像滚雪球一样越攒越多，交叉引用越来越密，AI 对你的领域理解越来越深。
他的原话：
> "维护知识库最累的不是阅读和思考，而是记账。"
读文章、判断价值、决定方向 — 这些是人该干的事。但整理格式、更新链接、维护索引、检查哪篇过时了 — 这些 bookkeeping 的活，交给 AI 干最合适。
## Karpathy 方案的核心设计
三层架构
思路很清晰：原始输入、加工产物、操作规则，三件事分开管。
三个核心动作
Ingest（入库） — 新资料进来时，AI 读一遍，写摘要，判断该放哪，更新相关页面的链接，追加到索引。一条龙。
Query（查询） — 问 AI 一个问题，它在 Wiki 里搜相关内容，综合回答。关键是：如果查的过程中发现了新关联（比如两篇笔记其实在讲同一件事但没互相链接），AI 会把这个发现写回 Wiki。查询本身也在改进知识库。
Lint（健康检查） — 定期让 AI 扫一遍，找出问题：哪些页面成了孤岛没人引用？哪些内容太久没更新该过时了？哪些概念出现了矛盾？
两个特殊文件：index.md 按主题做全局目录，log.md 记录时间线。
## 我的方案：同样的思路，不同的落地
我的工具栈是 Obsidian + OpenClaw + Claude Code，通过 AGENTS.md 定义操作规则，不绑定特定 AI 工具。
从三层变成五层
Karpathy 的 Wiki 是个终点 — 知识沉淀下来就完了。但我做内容创作，知识存着不用等于没有。所以我的系统多了两层。
行动层意味着知识要落地。投资笔记不是写完就完，要指导真实的交易决策。健康计划要变成每周的训练安排。
产出层意味着知识要变成产品。视频、文章、课程 — 知识库是弹药库，写作才是开枪。
输入只留一个口子
不管是网页剪藏、Apple Notes 导出、还是脑子里冒出来的想法，全部先进 Notes/，然后走同一条流水线分发到各个目录。
一个入口，一套流程，多个终点。
我有个设计是 Karpathy 没提到的 — Notes/Conversation，专门存跟 AI 的对话。你跟 AI 认真讨论一个问题的时候，对话过程本身就在生产知识。比如这篇文章的雏形，就是我跟 Claude 讨论 Karpathy 方案时聊出来的。把它丢掉太可惜了。
确认机制：AI 先报计划，我再拍板
这是我跟 Karpathy 最大的分歧。
他让 LLM 全权操作 Wiki — 想建页面就建，想删就删，想改链接就改。我试过，发现 AI 对"这篇文章应该放哪"的判断经常不靠谱。
比如一篇内容创作方法论，AI 放到了 Knowledge/ 而不是 Writing/Knowledge/。一篇 Chrome DevTools 的教程，AI 新建了一个文件，其实应该合并到已有的 Claude Code 文档里。
所以我的规则是：AI 先列出分发方案，我看一眼确认了再动手。 这一步成本很低（看个表格而已），但能避免很多返工。
分类这件事，本质上反映的是你自己的思维结构。AI 可以建议，但最终得你来定。
## 三个操作怎么跑
Ingest：新内容进来怎么处理
用户说"处理一下 Notes/"，Agent 就开始干活。
第一步：列方案。 扫描 Notes/ 下所有没处理的内容，列出一个表：
等我确认后才执行。
第二步：分发。 按内容性质判断目标：
- 软件工具、代码技巧 → Software/
- 投资、保险、健康、生活事务 → LifeOS/
- 方法论、读书笔记、概念解析 → Knowledge/
- 内容创作方法论 → Writing/Knowledge/
- 选题素材 → Writing/
- 判断不了的 → 留在 Notes/，等我定
第三步：加工。 读原文写摘要，在目标目录创建或更新页面，给相关文件补上交叉引用。
第四步：清理。 原始文件从 Notes/ 删掉。
Query：问知识库问题
用户提问，Agent 在相关目录里搜内容，综合多篇文件给答案。
关键在第三步 — 反哺。如果搜索过程中发现两篇文件内容互补但没互相链接，Agent 会说出来，我确认了就补上。
举个例子：我问"创业怎么找前 1000 个用户"，Agent 找到了《头 1000 名用户》和《做产品的经验和感悟》。前者讲获客，后者讲产品打磨，互相补充但从来没链接过。发现这个关联后我让它补上了。
Query 的价值不只是回答问题，还在于暴露知识库的结构缺陷。
Lint：健康检查
四项检查：
跑完出报告，不自动改。
一个实践经验：按目录分别跑，不要一次全跑。 Software/ 这种工具备忘目录，每篇本来就是独立的操作手册，报一堆"孤立页面"没意义。Knowledge/ 才是 Lint 真正能发挥价值的地方 — 50 篇管理笔记之间居然零链接，这就是问题。
## 两套方案放一起看
架构
操作流程
特殊文件
设计哲学
他有我没做的
## 全局索引怎么组织
index.md 放在 Workspace 根目录，8 大分类覆盖所有内容：
只索引到目录。文件级索引是维护噩梦 — 每加一篇文章就得更新，目录结构稳定后基本不用动。
## 交叉引用：少即是多
Karpathy 鼓励密集的链接网络。我的做法相反 — 只建最强关联，不追求覆盖率。
什么时候值得建链接：
- 两篇文章内容互补（获客方法论 + 产品打磨哲学）
- 理论和实践配对（同理心理论 + 同理心实践）
- 读书笔记和应用思考配对（《深度工作》+ 时间管理）
- 人物和方法论配对（乔布斯的管理课 + 领导力）
格式很简单：文件末尾加个 ## 相关页面，放 2-3 条链接就够了。
链接太多反而是负担。改个目录结构就一堆断链要修，第 10 条链接的价值基本趋近于零。
## 几条原则
从这次折腾中攒出来的经验：
一个入口，多个终点。 所有输入走 Notes/，统一流程分发。
结构够用就行。 目录分到能找到东西就够了，不用追求图书馆级别的分类学。
AI 建议，你拍板。 分类反映你的思维结构，只有你自己最清楚一篇文章该放哪。确认一下成本很低，但省了很多返工。
链接宜少不宜多。 两三条强关联比十条弱关联有用得多，维护成本也低得多。
对话也是知识。 跟 AI 的深度讨论本身就在生产知识，别聊完就丢了。
存着不用等于没有。 知识库的终极检验标准是：它有没有帮你产出过东西？读过不等于会了，写出来才算数。
索引到目录，不到文件。 目录结构一旦稳定，索引几乎零维护。
不绑定工具。 AGENTS.md 兼容多种 Agent，今天用 Claude，明天换别的也能跑。
以上是原理和操作方法。如果你想进一步交流，欢迎加入「范凯说AI」公开社区参与讨论：
💬 公开社群： https://t.me/fankaishuoai
具体的实践细节 — 包括完整的 AGENTS.md 配置、Ingest/Lint/Query 的实操演示、以及我踩过的坑 — 我会在本周日的「范凯说AI」会员直播中详细讲解。想要拿到可以直接用的方案，加入会员社群：
⭐ 会员社群： https://im.page/fankaishuoai
## 相关链接
- [范凯说 AI | Kai on AI](https://x.com/fankaishuoai)
- [@fankaishuoai](https://x.com/fankaishuoai)
- [2.5K](https://x.com/fankaishuoai/status/2041171980494479679/analytics)
- [Karpathy's LLM Wiki Gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
- [https://t.me/fankaishuoai](https://t.me/fankaishuoai)
- [https://im.page/fankaishuoai](https://im.page/fankaishuoai)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:11 PM · Apr 6, 2026](https://x.com/fankaishuoai/status/2041171980494479679)
- [2,543 Views](https://x.com/fankaishuoai/status/2041171980494479679/analytics)
---
*导出时间: 2026/4/7 00:52:30*