LLM 知识库

一份由 AI 持续读写的结构化知识库，通常就是一堆 markdown 文件。

与基础 RAG 用法的区别：那种做法里新文档进来只是被加进索引， 已经索引的内容不会被改写；而 LLM 知识库里新素材进来会触发一次编译—— 更新既有页面、建新页、加链接、标记矛盾。有人的说法是 「摄取是一次重构，不是一次追加」。

补一句分寸（2026-09-22）：这里原先写的是「RAG 里新文档只会被索引， 永不改变、永不连接」。「RAG 都这样」是错的——比如 GraphRAG 就会从资料里抽出实体与关系、 组织成图并预计算摘要。所以本项目的取舍应当表述为 「我们选择保存可编辑、可审阅的综合页面」，而不是「所有 RAG 都不积累知识」。 检索与知识整理可以共存，不是互斥的两条路。

关于「一份来源可能改动 10 到 15 个页面」这个数（勘误，2026-09-24）： 它是有出处的——Karpathy 的原始 gist 在 Ingest 段落里写着 A single source might touch 10-15 wiki pages. 本页此前写「没有出处」， 那是错的，现已逐字核对原文并补上链接。

该修的仍然要修：那句话是作者描述自己工作流时的经验性例子， 不是普遍规律，所以不能泛化、也不该当本项目的 KPI。 「有出处」与「可泛化」是两件事——前者这次补上了，后者仍然不成立。 把页面改动数当指标会催生为了改而改。

三层结构#

三个操作#

• 摄取（Ingest）：读入来源，写摘要页，更新索引与相关条目页
• 查询（Query）：从相关页面综合出答案，并给出处
• 体检（Lint）：检查矛盾、过时、孤儿页、断链

已实现 / 计划实现#

这张表是 2026-09-22 补的。此前本页通篇以「本项目怎么做」的口吻描述这套模式， 而其中大半尚未落地——读者无从分辨哪些是真的、哪些是打算做的。

勘误（2026-09-23）：这张表自己就出过这个毛病。上面三行原先写着 「计划中，尚未实现」，而它们在写下那句话的时候就已经落地了—— 来源登记（knowledge/sources/）、引用与复核字段（Doc.sources / Doc.review）、 影响分析脚本（scripts/wiki-impact.mjs）全都存在。 没有任何检查会发现这件事：lint 管的是断链、重复 slug、孤儿页， 那些都是页与页之间的问题；而这一条是页与仓库之间的问题。

现在这张表的每一行都带一条 verify: 声明（见本页 frontmatter）： 检查同时核对那句话还在不在页面上、以及它对应的文件在不在。 只查文件是不够的——正文改了、声明没改的话，声明还在验一句没人说过的话。

本项目的取舍：把 lint 做成确定性的#

Karpathy 那套的体检是「让 agent 定期看看」。这不是工程方案—— 它不可复现、不可回归、进不了 CI。

所以本项目只把机械可判定的那部分做成代码（src/lib/wiki/lint.ts）：

• 断链、重复 slug → 错误级，构建失败
• 孤儿页、缺摘要、空正文 → 警告级
• 摘要过长 → 提示级

语义级的检查仍然留给 agent（「这两页说法矛盾」「这条结论已被推翻」）， 但地基是机械的。没有地基的话，agent 每次检查的结论都不一样， 你没法判断「这次多了三条告警」是内容变了还是模型心情变了。

与「数字花园」的关系#

数字花园（digital garden）强调公开的、持续演化的笔记， 不按时间排列，靠链接组织。LLM 知识库是它的一个变体： 区别在于维护者从人换成了 agent。

两者面对同一个问题：怎么防止腐烂。花园派的做法是「定期打理」， LLM 知识库派的做法是「让 agent 定期重构」。本项目认为两者都不够， 机械检查必须先进 CI。

为什么博客适合这个模式#

博客天生是流——按时间排，读过就沉底。 但知识是网：你写过三篇关于排版的文章，它们之间的共性不会自动浮现。

加一层知识库，文章仍然是流（读者的入口），但知识层把散落各篇的东西 连起来。读者（和人以外的读者）不必读完所有文章才能拼出全貌。

参考#

• Andrej Karpathy 的 llm-wiki gist，2026-04 —— 本文的模式取自它；注意它是抽象模式，不是框架或 npm 包。 上面「10–15 个页面」那句即出自它的 Ingest 段落，原文为 A single source might touch 10-15 wiki pages.
• DeepWiki（2025-05）、LangChain OpenWiki（2026-07）、微软 deep-wiki 插件
• llmstxt.org 提案——注意其实际效果数据见 内容协商 末尾