我用 Karpathy 的思路搭了一个给 LLM 读的知识库
目录 ▼
我用 Karpathy 的思路搭了一个给 LLM 读的知识库
知识编译一次，持续维护，而非每次查询重新派生。
一、场景：你的知识库是不是也在”每次重新派生”？
我有一个 2700+ 笔记的 Obsidian vault。
按 PARA 分类法建的——Projects、Areas、Resources、Archives。建得很整齐，查的时候很痛苦。
每次问 AI 一个问题，它从头扫一遍所有笔记，生成一个”看起来很对但其实很泛”的答案。下次再问同一个领域的问题，它又从头来一遍。
这就好比你每次写代码都要重新编译整个项目，而不是增量编译。编译一次，用多次，这是工程常识。但知识管理领域，大部分人在做的就是”每次查询重新派生”。
2026 年 4 月，Karpathy 在他的博客上提了一个观点：与其让 LLM 每次从原始文本中提取信息，不如先把知识”编译”成结构化的 wiki 页面，让 LLM 直接读编译好的结果。
我照着这个思路搭了一个。
二、转折：Karpathy 的核心观点
Karpathy 说的核心就一句话：
知识应该像代码一样被编译，而不是像数据库一样被查询。
传统知识库是”数据库模式”——你存了一堆笔记，每次查询时 LLM 从头扫描、理解、提取、综合。这个过程每次都在重新”派生”同样的知识。
Karpathy 的方式是”编译模式”——你先把原始文本处理成结构化的 wiki 页面（带 frontmatter、交叉引用、一句话概述），LLM 读的是编译好的结果，而不是原始文本。
区别在哪？
原始笔记是散装的。一篇微信读书笔记 500 行，LLM 需要自己判断哪些是核心观点、哪些是批注、哪些是引用。
编译后的 wiki 页面是封装好的。每个页面 50-100 行，frontmatter 标注了类型/状态/置信度，正文有核心观点、关键概念（带 wikilink）、实际案例、适用边界。LLM 读一个页面就能拿到完整的知识节点。
三、工程师视角：怎么搭的
我用工程师的思路把这个系统拆成了四层。
3.1 输入层：raw/ 符号链接
所有原始数据通过符号链接引入 Wiki，只读不修改。
raw/3_Resources → 3_Resources/（微信读书/开卷有益/知识管理等）
raw/Working → 66_Working/（工作笔记 558 篇）
raw/Myself → 99_Myself/（个人成长 438 篇）
raw/AI素材 → 5_Express/02_Material/AI/这一步的关键是”只读”。原始数据不动，所有编译输出写在 Wiki 内部。出问题了删掉 Wiki 重来就行，原始数据零损伤。
3.2 编译层：6 种页面类型
我把知识拆成 6 种类型，每种有固定的 frontmatter 和正文模板：
| 类型 | 文件数 | 模板 |
|---|---|---|
| books/ | 60 | 核心观点 + 关键概念 + 实用方法 + 与我的关联 |
| concepts/ | 235 | 一句话解释 + 详细说明 + 实际案例 + 适用边界 |
| entities/ | 11 | 人/公司/产品/工具的独立档案 |
| areas/ | 12 | 领域知识 + 项目聚合 |
| synthesis/ | 8 | 跨主题综合分析 |
| maps/ | 5 | 导航地图（知识路径） |
每种类型的 frontmatter 必须包含 status（stable/needs_review）、置信度（high/medium/low）、最后验证日期。这不是形式主义，是让 LLM 知道这个页面有多可靠。
3.3 交叉引用层：知识网络
这是整个系统最关键的设计——每篇文章必须有至少 3 个 [[wikilink]]，链接到其他 wiki 页面。
没有链接的知识是孤岛。有链接的知识是网络。
比如我编译了《福格行为模型》这本书，它会链接到 [[微习惯]]、[[元认知]]、[[个人复盘]]、[[习惯]]。这些页面又会反过来链接到它。形成一个知识图谱。
LLM 查询时，可以从一个页面跳转到相关页面，像人在知识库里”散步”一样。这比每次从头扫描所有笔记高效得多。
3.4 健康检查层：lint.py
写了一个 190 行的 Python 脚本，检查 6 件事：
- 断链：指向不存在页面的 wikilink
- 孤岛页面：没有入站链接的页面
- 缺失 frontmatter：没有结构化元数据的文件
- 缺字段：缺少 status/confidence 的页面
- 链接不足：少于 3 个出站链接的页面
- 页面偏薄：少于 30 行的页面
跑一次 0 ERROR、0 WARN，说明知识库是健康的。有报错就修，逻辑和代码 review 一样。
四、踩坑经验
搭这个系统的过程中，踩了几个坑。
坑 1：编译 ≠ 摘要
一开始我把”编译”理解成了”摘要”——把 500 行笔记压缩成 50 行。
不对。
摘要是”这本书讲了什么”。编译是”这个知识我怎么用”。
区别在于：编译后的页面必须有”与我的关联”和”适用边界”。前者回答”跟我有什么关系”，后者回答”什么时候不该用”。
纯摘要是信息压缩。编译是知识封装。
坑 2：交叉引用比内容更重要
前 100 个页面，我花了 80% 的时间写内容，20% 的时间建链接。
后来发现反了。
内容写得再好，没有链接就找不到。链接建得好，即使内容薄一点，LLM 也能通过相关页面找到足够的上下文。
后来的策略是：先建骨架（标题 + 一句话 + 链接），再充实内容。链接先行，内容后补。
坑 3：index.md 不能太长
索引文件 457 行，列出所有 322 个页面。LLM 每次读这个文件就要花不少 token。
后来精简成了”目录 + 统计 + 导航”模式——150 行就够，Agent 扫一遍就能定位到相关目录，再按需读具体页面。
坑 4：CLAUDE.md 太长其他平台用不了
一开始只有 CLAUDE.md 一个配置文件，389 行。只有 Claude 能读，Codex 和 WorkBuddy 都不认。
后来拆成了 AGENTS.md（140 行通用参考）+ CLAUDE.md（220 行 Claude 专用），所有平台都能用。
五、适用边界
这套系统适合什么人？
适合：
- 有大量笔记/文档需要被 LLM 引用的人
- 需要跨多个 AI 平台使用知识库的人（Claude/Codex/WorkBuddy）
- 工程师思维的人（喜欢结构化、模板化、可检查）
不适合：
- 笔记少于 200 篇的人——直接让 LLM 读原始笔记就够了，不值得编译
- 纯文科思维的人——frontmatter、lint.py、符号链接这些概念可能门槛偏高
- 不愿意持续维护的人——编译一次不够，需要定期更新和 lint
代价：
- 初期投入大。300+ 页面的编译花了几周时间。
- 维护成本存在。每次新增知识都要走”inbox → 编译 → 交叉引用 → 更新索引”的流程。
- 需要基本的 Markdown 和 Git 能力。
六、下一步
现在这个系统已经在跑了，322 个页面，lint 全部通过。
接下来想做的事：
- 概念关系网络图：把 235 个概念之间的引用关系可视化，看哪些是核心节点
- Skill 归档：把本机的 WorkBuddy Skill 镜像到 Wiki 内，通过 Git 版本控制
- 选题→发布管道：从 Wiki 的知识节点直接长出文章，而不是每次从零写
最后一个问题留给你：你的知识库，是”数据库模式”还是”编译模式”？
—— 易浅