借鉴 Karpathy 的 LLM Wiki 思路，我把自己的 AI 知识库重做了一遍
这不是"推荐几个笔记软件"的文章。这是一个个人开发者，受到 Karpathy "LLM 维护 Wiki" 思路启发后，把 Obsidian、AI Agent、项目文档和本地索引重新组织成个人记忆系统的过程记录。
一、原来的问题：资料很多，但没有形成系统
Obsidian 是人能读的，但 AI 不一定能稳定检索。项目文档贴近代码，但分散在各仓库里。Hermes 能采集信息，但如果保存链路不稳定，最后就会变成"我好像让它存了，但不知道存哪了"。AI 对话里有很多开发经验、踩坑记录，但没有进入长期系统。
这就是典型的"资料堆"问题：资料在增加，知识没有沉淀，AI 不能稳定调用，人也很难回溯。
二、我最后采用的核心思路
我把系统拆成四层：
Raw / Inbox / Project Docs
-> 本地索引
-> LLM 维护的 Wiki 编译层
-> 人工审阅后的长期记忆1. Raw：原始证据层
原始资料不轻易改写。论文原文、网页解析结果、项目原始文档，都应该先进入 raw 或 inbox。这一层的价值是保留证据。AI 可以总结错，但 raw source 不应该丢。
2. Index：本地索引层
我用 SQLite FTS 做本地全文检索。它不花哨，但非常可靠：本地运行、可备份、可调试。第一版我没有急着上向量库，因为很多个人知识库失败，不是因为没有 embedding，而是因为源头混乱、写入规则混乱、长期记忆污染。
3. Wiki Compile：LLM 维护的编译层
这是整个系统里最关键的变化。RAG 解决"找得到"，但 Wiki Compile 解决"积累得起来"。如果每次查询都只是临时从一堆 raw sources 里召回片段，那么 AI 永远在做一次性阅读。更好的方式是让 LLM 维护一个持久 wiki：新资料进来后创建 source page、重要概念更新 concept page、项目经验进入 project page、多个资料之间的综合判断进入 synthesis page。
这就像把知识从"运行时检索"变成"持续编译"。不是每次问问题时临时翻资料，而是让 AI 持续维护一个越来越清晰的知识结构。
4. Reviewed Memory：长期记忆层
我没有让 AI 直接写长期记忆。长期记忆只放少量经过确认的内容：个人偏好、长期决策、项目关键约束、反复验证过的工作流程。AI 生成的内容先进入候选区，再由人审阅。这是防止知识库变脏的关键。
三、为什么不是直接上向量数据库？
很多人一想到 AI 知识库，第一反应就是"上向量库。"但我的感受是，个人知识系统里，向量库不是第一优先级。真正优先的是：哪些目录应该被索引？哪些目录绝对不该被索引？自动采集内容写到哪里？AI 生成内容是否允许进入长期记忆？检索结果是否能追溯到原路径？如果这些问题没解决，向量库只会让混乱变得更快。
四、我的目录设计
10_Wiki
index.md # AI 和人类进入 wiki 的总入口
log.md # 记录每次 ingest、维护、综合、lint
Sources # 原始资料对应的 source page
Concepts # 概念页
Entities # 实体页
Projects # 项目知识
Synthesis # 跨资料、跨项目的综合判断
Questions # 待回答问题这个结构让我第一次感觉到：Obsidian 不再只是笔记软件，而更像一个由 AI 协助维护的知识代码库。
五、一个真实例子：项目上下文
以前我让 AI 修一个项目，通常要先解释一大段：项目在哪、后端端口是多少、前端怎么启动、用什么数据库。现在可以直接做项目上下文查询，系统会返回相关项目文档：基线文档、端口约束、部署要求、测试报告、历史说明。
AI 编程最怕的不是模型不聪明，而是它每次都没有上下文。
六、为什么一定要有人工审阅？
因为 AI 记忆系统最危险的问题是污染。如果让 AI 自动把所有总结、猜测、判断都写进长期记忆，几周之后知识库就会变成一堆看似正确但来源不明的结论。越靠近长期偏好和重要决策，越需要人工确认。AI 可以帮我整理，但不应该替我决定什么是长期记忆。
七、这套系统的意义
个人 AI 知识库的关键，不是"存更多东西"。而是让知识进入一个可持续循环：采集 → 检索 → 编译 → 使用 → 反馈 → 沉淀。
我不再把知识库看成资料仓库，而是把它看成一个可被 AI 持续编译的个人 wiki。AI 不只是回答问题，它还可以参与维护知识结构。但前提是：我们要给它 raw sources、schema、index、log 和审阅机制。
