AI 知识库搭建：我用 Markdown 和 Git 做了一套长期 Brain OS

type

status

date

slug

summary

AI 知识库搭建，真正难的是什么

常见做法是把 PDF、网页和笔记上传到一个支持 RAG 的工具里。提问时，系统检索相关片段，再让模型生成答案。这种方式适合一次性查询，但答案本身通常不会自动变成经过维护的长期资产。

2026 年 4 月，Andrej Karpathy 在 LLM Wiki 提案中给出了另一种思路：让 LLM 在原始资料与提问之间，持续维护一层相互链接的 Markdown Wiki。新来源进入时，模型不只建立索引，还会更新已有概念、补充交叉引用、标记矛盾，并维护索引与日志。

这里要注意边界：这是 Karpathy 对个人知识库的设计提案，不是证明 LLM Wiki 在所有规模上都优于 RAG 的基准结论。我的判断是，两者并不冲突：

持久 Wiki 负责保存已经形成的综合结论、关系和分歧。

检索负责在材料变多后，帮助 Agent 快速找到应该读取的页面。

原始证据始终保留，必要时可以回到来源重新判断。

换句话说，搜索是导航层，不应该自动成为唯一的真相层。

我从 LLM Wiki 借了什么，又为什么没有照抄

LLM Wiki 原始提案有三个核心层次：

这套结构足够解释“资料如何被编译成知识”，但 Mufeng Brain OS 还要承载项目执行、研究问题、写作和投资决策。它们的变更规则并不相同。

最初的素材草案也采用了类似的通用目录：

问题很快出现了：一条未经核验的聊天记录应该放进 wiki 还是 memory？一份研究结论和一项已经执行的项目决定，是否应该用同一套状态字段？如果半年后发现来源错误，能不能直接修改原始记录？

这些问题无法靠继续增加模糊目录解决。因此，实际实现没有照抄草案，而是把“内容类型”升级为“变更契约”：

这次调整带来的核心变化，不是目录更多了，而是每一层都明确了“什么可以改、什么不能改”。

例如，20-sources/ 中的来源记录在首次摄取并写入日志后，不允许为了让结论更顺畅而偷偷修正；30-knowledge/ 中的综合页面则必须允许更新，因为新证据可能推翻旧判断。证据不可静默改写，结论可以被修订，这两件事必须同时成立。

为什么选择 Markdown 和 Git

这里没有“Markdown 天生能保存二十年”的事实保证。选择它，是一个有边界的工程决策。

CommonMark 规范把 Markdown 定义为用于编写结构化文档的纯文本格式，并强调源文本本身的可读性。纯文本的优势是，人和不同厂商的 Agent 都能直接读取，不依赖某个笔记产品的私有数据模型。

Git 则补上了变更历史。Pro Git 对版本控制的定义很直接：记录一个或一组文件随时间发生的变化，以便之后找回特定版本。它还能比较修改、定位引入问题的时间，并在分布式模式下让 clone 保留完整历史。

这两个工具组合起来，提供了四个我真正需要的属性：

可检查。 不打开专用应用，也能阅读正文、来源和规则。

可比较。 Agent 改了什么，可以通过 diff 审查。

可迁移。 更换编辑器、模型或搜索系统，不必先导出核心知识。

可重建。 向量索引、图缓存和可视化界面都可以从 Markdown 重新生成。

但 Git 不是自动备份，Markdown 也不会自动保证事实正确。仓库仍然需要私有远程副本、权限审查、来源协议和定期校验。工具只提供能力，不能替代治理。

给 AI Agent 的不是提示词，而是仓库协议

如果只告诉 Agent“帮我整理一下”，每次会话都会重新猜目录、命名、证据标准和完成条件。短期看很灵活，长期看一定会漂移。

Mufeng Brain OS 把这些规则写进根目录的 AGENTS.md。任何 Agent 在实质修改前，都要先读取当前重点、相关索引、目录规则和 Schema，再搜索是否已经存在同主题页面。

一条知识记录至少有稳定 ID、类型、状态、可见性和时间字段：

Schema 不是为了把 Markdown 伪装成数据库，而是让不同 Agent 对同一个页面的身份和生命周期形成最低限度的共识。

这里还有一个容易被忽略的约束：重要主张要区分事实、推断、假设、意见和决定。AI 最危险的错误之一，不是完全编造一段话，而是在压缩材料时把“来源作者的判断”悄悄写成“已经验证的事实”。

一次真实开发过程：从素材草案到可验证仓库

这次实现没有从空白提示词直接生成最终文章，而是沿着仓库自己的规则做了一次完整检查。

第一步，我从根目录的 README.md 和 NOW.md 开始，再沿索引读取架构、原则、工作流、Schema、Karpathy 来源记录、综合知识页和 Markdown/Git 决策记录。这样可以避免把最初素材里的设想与已经落地的实现混为一谈。

第二步，我用全文搜索定位 Brain OS、Markdown、Git、证据 和 LLM Wiki 的实际出现位置。文章里的分层结构、变更规则和适用边界都来自这些文件，而不是写作时临时补出的概念。

第三步，我检查了仓库的确定性工具。当前的 tools/brain.py 只依赖 Python 标准库，负责检查必需文件、Schema、ID 唯一性、类型位置、相对链接和索引覆盖；9 项单元测试覆盖了解析、页面校验、链接检查和文档创建。

最后，我实际运行：

基线结果是 9 项测试通过，仓库健康检查也通过。下面的图片来自这次真实命令输出，不是生成的终端界面。

这个过程也解释了为什么“让 Agent 维护知识库”不能只靠自然语言约定：语义审查负责判断内容是否可信，确定性程序负责阻止缺字段、断链和漏索引。两种检查各自解决不同的问题。

一个真实的失败：引用看起来有了，其实无法审计

最初素材提到了 Karpathy 的 Gist，但链接只指向作者的 Gist 列表页。读者知道“可能有这个来源”，却无法直接确认是哪一篇、何时发布、具体说了什么。

正式实现时，我把它改成了精确的 LLM Wiki Gist 地址，并单独建立来源记录，写明作者、创建时间、访问时间、捕获方式和记录限制。文章写作前又重新打开原始页面，确认其创建日期为 2026 年 4 月 4 日。

这个错误很小，却暴露了知识库最常见的问题：有“参考资料”不等于有可审计的证据。一个主页链接、搜索结果摘要或模型转述，都不能替代精确来源。

另一个主动避开的错误，是在第一天就接入向量数据库、知识图谱和复杂自动化。当前仓库规模下，索引文件加 rg 已经能完成导航；只有当已知内容反复找不到、索引过大或重复页面持续出现时，额外基础设施才有明确收益。

这是工程判断，不是通用结论。随着材料规模、查询类型和团队人数变化，检索层可能变得必要，但它仍应当是可重建的加速层。

最小可落地版本，只需要五步

如果你想搭自己的 AI 知识库，不必复制 Mufeng Brain OS 的全部目录。先做下面五件事：

1. 选定权威底座

把 Markdown 文件和本地资源设为权威数据。笔记应用、向量库和图形界面先作为视图，不要让它们成为唯一副本。

2. 至少分开来源与综合

最小结构可以只有：

来源记录保留原始出处，知识页面允许随证据修订。不要把 AI 生成的摘要当作原始来源。

3. 写清 Agent 的修改规则

在 AGENTS.md 中回答：

修改前必须读取什么？

新页面如何命名和去重？

事实如何引用，推断如何标记？

完成后必须跑什么检查？

4. 给页面最小 Schema

从 id、type、status、created、updated 和 tags 开始即可。字段越多，维护成本越高；没有真实检索或协作问题时，不要提前设计复杂本体。

5. 把规则变成测试

先检查机械问题：缺字段、重复 ID、断链、错误目录和漏索引。再做语义审查：来源是否可靠、结论是否过期、矛盾是否被抹平、推测是否被写成事实。

结论

这套系统当前已经证明的是：一组清晰的层级、协议和标准库测试，可以让多个 AI Agent 围绕同一套 Markdown 资产协作，并让每次修改留下可审查的文件痕迹。

它还没有证明的是：这套结构在数千页面、多人并发和多年使用后仍然足够。向量检索是否需要加入、目录是否需要分片、Schema 是否会变重，都应该由真实失败触发，而不是靠想象预装。

对长期 AI 知识库来说，最重要的不是第一次生成了多少页面，而是系统能否在发现错误后保留证据、修正结论，并让下一次对话从可验证的成果继续。

参考资料

Andrej Karpathy：LLM Wiki，创建于 2026-04-04，访问于 2026-07-24。

CommonMark Spec 0.31.2，发布于 2024-01-28，访问于 2026-07-24。

Pro Git：About Version Control，访问于 2026-07-24。

2026.07.24 21:28 沪 · 赵巷

📌 声明：本文由 AI 辅助完成