# LLM 知识库

> Karpathy 2026 年 4 月提出的模式——让 agent 主动读写并维护一层知识库，新素材进来时做的是「重构」而不是「追加」。

来源：https://xiaoxusop.github.io/letterpress/wiki/llm-wiki/
语言：zh-CN
类型：知识库条目

## 被引用

- [内容协商](https://xiaoxusop.github.io/letterpress/wiki/content-negotiation/)
- [这个博客是怎么搭的](https://xiaoxusop.github.io/letterpress/how-this-works/)
- [letterpress](https://xiaoxusop.github.io/letterpress/wiki/letterpress/)

## 正文

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

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

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

> **关于「一份来源可能改动 10 到 15 个页面」这个数**（勘误，2026-09-24）：
> **它是有出处的**——Karpathy 的原始 gist 在 Ingest 段落里写着
> `A single source might touch 10-15 wiki pages.` 本页此前写「没有出处」，
> **那是错的**，现已逐字核对原文并补上链接。
>
> 该修的仍然要修：那句话是**作者描述自己工作流时的经验性例子**，
> 不是普遍规律，所以**不能泛化、也不该当本项目的 KPI**。
> 「有出处」与「可泛化」是两件事——**前者这次补上了，后者仍然不成立。**
> 把页面改动数当指标会催生为了改而改。

## 三层结构

| 层 | 作用 | 本项目里对应 |
|---|---|---|
| 原始素材 | 原则上不可变的输入 | **尚无独立登记**。文章（`src/content/posts/`）可充当素材，但它们**会被修订**，引用时需钉具体版本 |
| 知识层 | agent 维护的结构化页面 | `src/content/wiki/` |
| schema | 告诉 agent 怎么维护 | `AGENTS.md` |

## 三个操作

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

## 已实现 / 计划实现

| 能力 | 状态 |
|---|---|
| 知识层页面（`src/content/wiki/`）与互链 | **已实现** |
| 机械检查（`src/lib/wiki/lint.ts`）进 CI | **已实现** |
| 文章 → 知识页的人工综合 | **已实现**（本页就是） |
| 来源登记与版本固定 | **已实现**（`knowledge/sources/`） |
| 页面级的引用与复核字段 | **已实现**（`Doc.sources` / `Doc.review`） |
| 摄取 / 影响分析的工作流脚本 | **已实现**（`scripts/wiki-impact.mjs`） |
| 面向 agent 的检索与问题金标 | **已实现**（`knowledge/questions.md`） |
| 语义级的矛盾检测（「这两页说法冲突」） | 计划中，尚未实现 |

> 这张表是 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](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)，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 提案——注意其实际效果数据见 [内容协商](https://xiaoxusop.github.io/letterpress/wiki/content-negotiation/) 末尾