LLM Wiki：把上下文编译成会生长的知识库

4506 字

23 分钟

LLM Wiki：把上下文编译成会生长的知识库

2026-04-27

AI工程

LLM

/

Wiki

/

AI工程

/

知识管理

TL;DR#

Karpathy 这个 LLM Wiki 想法，我觉得最重要的地方不是“用 AI 总结文档”，而是它换了一个知识库的维护方式：

不要每次提问时才从原始资料里重新检索、重新拼答案，而是让 LLM 持续把资料编译成一个结构化、可链接、会更新的 Markdown Wiki。

说白了，传统 RAG 更像是“临时翻资料回答问题”，LLM Wiki 更像是“先把资料整理成一本不断修订的内部手册”。

这两件事听起来都和知识库有关，但实际体验差别很大。

RAG 的问题是，它经常没有积累。你今天问一个问题，它检索一遍，拼一次答案；明天换个角度问，它又从头检索、从头拼。中间产生的理解、对比、矛盾、结论，很容易留在聊天记录里，然后慢慢消失。

LLM Wiki 的判断是：

有价值的知识加工结果，不应该只存在于一次对话里，而应该被写回知识库。

我觉得这点很关键。

尤其是现在大家越来越依赖 Agent 做事，真正稀缺的不是“模型会不会回答”，而是模型能不能稳定读到一份干净、最新、可追溯的上下文。

所以这篇不只是介绍个人知识库。我更想说的是：LLM Wiki 也很适合用来管理组织共享 context。

比如团队的项目背景、客户信息、会议结论、架构决策、产品路线、历史坑点、运营复盘。以前这些东西散在 Slack、飞书、Notion、GitHub issue、会议纪要和人的脑子里。LLM Wiki 的价值，就是把它们慢慢编译成一套组织可复用的上下文层。

1. LLM Wiki 到底是什么#

Karpathy 原文把 LLM Wiki 描述成一种 pattern：用 LLM 构建个人知识库。

它不是一个具体产品，而是一套工作方法。核心结构很简单，三层：

1
raw sources  ->  wiki  ->  schema
2
原始资料        LLM 维护的页面   规则和工作流

Raw sources：原始资料#

这是事实来源。文章、论文、会议纪要、PDF、网页剪藏、客户访谈、项目文档都可以放这里。

原则是：

原始资料尽量不可变
LLM 可以读，但不要随便改
后续 Wiki 页面要能追溯到来源

这层像 git 里的 source of truth。

Wiki：LLM 维护的 Markdown 页面#

这是真正被“编译”出来的知识层。

LLM 会把原始资料整理成：

source summary
entity page
concept page
comparison
synthesis
overview
index
query result

更重要的是，LLM 不只是新增页面，还要更新已有页面。

比如你导入了一篇新文章，它不应该只生成一篇摘要就结束，而应该顺手检查：

是否有相关人物 / 项目 / 概念页面需要更新
是否和旧资料有矛盾
是否能补充某个主题总结
是否要增加新的 [[wikilink]]
是否要在 index 里登记

这就是“会生长”的部分。

Schema：让 LLM 不要乱写的规则#

Schema 可以是 AGENTS.md、CLAUDE.md、schema.md 之类的文件。

它告诉 LLM：

目录怎么组织
页面类型有哪些
frontmatter 怎么写
ingest 怎么做
query 怎么做
lint 检查什么
哪些内容需要人类确认

我会把 schema 理解成这个 Wiki 的“操作系统说明书”。

没有 schema，LLM 很容易变成一个泛泛的聊天助手；有了 schema，它才更像一个纪律比较稳定的知识库维护员。

2. 它和 RAG 最大的区别：不是检索，而是积累#

很多人看到 LLM Wiki，第一反应可能是：这不还是 RAG 吗？

我觉得不是。

当然，它也会检索，也会回答问题，也可能用 embedding。但它的核心不在检索，而在把知识加工结果持久化。

可以这样对比：

维度	传统 RAG	LLM Wiki
资料处理	多数在查询时临时检索	摄入时就整理进 Wiki
知识状态	偏无状态	有持续更新的中间层
回答来源	原始 chunk	Wiki 页面 + 原始来源
维护方式	依赖索引和召回	依赖页面更新、链接、lint
产物	一次回答	可复用 Markdown 页面
人类角色	上传资料、提问	策展资料、校正方向、审核关键判断

RAG 更像是“给模型一个资料仓库”。

LLM Wiki 更像是“让模型持续维护一套读书笔记、项目手册、研究档案”。

这就带来一个很实际的变化：

你问过的好问题、生成过的好对比、整理过的好结论，都可以被保存成 Wiki 页面，之后继续被引用、更新和链接。

不是一次对话结束就没了。

3. 三个核心操作：Ingest、Query、Lint#

Karpathy 原文里把操作分成三个，我觉得这个拆法很适合落地。

Ingest：摄入资料#

摄入不是“上传文件并向量化”这么简单。

一个好的 ingest 应该包括：

读取新资料
提取关键实体、概念、论点
生成资料摘要页
更新相关 entity / concept 页面
记录矛盾、补充、变化
更新 index 和 log
需要人判断的地方标出来

比如一篇关于某个开源项目的文章被导入后，它可能会影响这些页面：

1
wiki/sources/article-name.md
2
wiki/entities/project-name.md
3
wiki/concepts/context-management.md
4
wiki/synthesis/current-architecture.md
5
wiki/index.md
6
wiki/log.md

一个源文件影响 10 个页面并不奇怪。

这也是 LLM 比人适合维护 Wiki 的地方。人会觉得“更新交叉引用、维护索引、同步摘要”很烦，但 LLM 不会。

Query：查询 Wiki#

查询时，不是直接从原始资料里找 chunk，而是先读 Wiki。

流程大概是：

读 index.md 找相关页面
读取相关 Wiki 页面
必要时追溯 raw sources
综合回答
如果回答有长期价值，写回 wiki/queries/ 或 wiki/synthesis/

这里最后一步很重要。

很多时候，真正有价值的不是原始问题，而是回答里生成的新结构：

一个对比表
一个决策记录
一个路线图
一个概念之间的关系图
一个“目前我们知道什么 / 不知道什么”的总结

这些都应该进入 Wiki，而不是停在 chat history。

Lint：维护健康度#

Wiki 长大以后一定会变脏。

会出现：

重复页面
孤立页面
旧结论没有更新
新资料和旧结论冲突
重要概念被频繁提到，但没有独立页面
页面之间缺少链接
index 已经过时

所以需要定期 lint。

我觉得 LLM Wiki 里的 lint 很有意思，因为它不是代码格式化那种 lint，而是“知识库体检”。

可以让 LLM 定期检查：

1
请检查当前 Wiki：
2
1. 有没有孤立页面
3
2. 有没有互相矛盾的结论
4
3. 有没有应该创建但还没有创建的概念页
5
4. 有没有页面缺少 sources
6
5. 有没有过时的 index 条目
7
6. 有没有值得继续研究的知识空白

这件事如果让人做，大概率没人愿意长期坚持。

但让 LLM 做，就很合理。

4. nashsu/llm_wiki：把这个 pattern 做成桌面应用#

Karpathy 的 gist 更像是一份思想说明，真正落地还要自己搭目录、写 schema、选工具、接 LLM。

nashsu/llm_wiki 做的事情，就是把这个 pattern 做成了一个跨平台桌面应用。

它的定位是：

LLM reads your documents, builds a structured wiki, and keeps it current.

也就是让 LLM 读取你的文档，构建结构化 Wiki，并持续更新。

它保留了 Karpathy 的核心设计：

三层架构：Raw Sources → Wiki → Schema
三个操作：Ingest / Query / Lint
index.md 作为导航入口
log.md 记录操作历史
[[wikilink]] 做交叉引用
YAML frontmatter 保存元数据
Obsidian 兼容
人类策展，LLM 维护

然后它在这个基础上加了很多产品化能力。

我比较关注这几个。

4.1 两步摄入#

原始 pattern 里，LLM 读取资料并写入 Wiki 可以是一个连续动作。

llm_wiki 把它拆成两步：

1
第一步：分析资料
2
第二步：生成 Wiki 页面

第一步先让 LLM 提取：

关键实体
核心概念
主要论点
和现有 Wiki 的关联
潜在矛盾
页面结构建议

第二步再根据分析结果生成或更新页面。

这个设计我觉得是对的。因为“边读边写”很容易让模型只写出一篇普通摘要，而不是认真思考它该影响 Wiki 的哪些部分。

先分析，再落库，质量会更稳一点。

4.2 purpose.md：不只规定结构，还规定方向#

llm_wiki 在 schema 之外增加了 purpose.md。

schema 更像是“怎么写”：页面类型、命名规则、工作流。

purpose 则是“为什么写”：

这个 Wiki 的目标是什么
关键问题是什么
研究范围是什么
当前演进中的观点是什么

这点很重要。

因为同一份资料，在不同目的下应该被整理成不同的知识。

比如一篇关于 Agent 的文章：

如果你的目的是学习技术，它可能进入 concepts/agent-architecture.md
如果你的目的是做产品竞品分析，它可能进入 entities/product-x.md
如果你的目的是组织知识沉淀，它可能进入 synthesis/team-agent-practices.md

没有 purpose，LLM 只能泛泛总结。

有了 purpose，它才知道哪些信息该强调，哪些只是背景。

4.3 知识图谱和洞察#

llm_wiki 不只是生成 Markdown，还会根据 wikilinks、sources、页面类型等信号建立知识图谱。

它的关联度模型包括：

直接链接
来源重叠
Adamic-Adar 共同邻居
类型亲和

还支持 Louvain 社区检测，用来发现自然形成的知识聚类。

我觉得图谱的意义不是“看起来很酷”，而是帮你发现 Wiki 的结构问题：

哪些页面是孤岛
哪些主题之间有意外关联
哪些社区内部太松散
哪些节点连接了多个领域
哪些地方值得继续 Deep Research

也就是说，它不是单纯可视化，而是把 lint 和研究方向结合起来。

4.4 多格式资料和网页剪藏#

实际用知识库时，资料不会只来自 Markdown。

llm_wiki 支持 PDF、DOCX、PPTX、表格、图片、视频音频预览，也有 Chrome Web Clipper，把网页通过 Readability.js 和 Turndown.js 转成干净 Markdown 后摄入。

这个点很现实。

很多知识库失败不是因为理念不对，而是资料入口太麻烦。

如果导入资料这一步很痛苦，后面再好的 Wiki 也长不起来。

5. 不只是个人知识库，也可以是组织共享 context#

Karpathy 原文虽然标题说 personal knowledge bases，但他也提到了 business/team 场景。

我觉得这是 LLM Wiki 更值得展开的方向。

因为现在很多团队其实都在缺一种东西：稳定、共享、可更新的上下文层。

不是缺文档。

文档大家都有。缺的是这些文档能不能被持续整理成 Agent 和人都能读懂的 context。

组织里的 context 通常散在哪里#

一个真实团队的上下文大概会散在这些地方：

Slack / 飞书群聊天
会议纪要
GitHub issue / PR
Notion / 语雀 / 飞书文档
客户访谈录音
产品需求文档
事故复盘
架构设计文档
代码里的注释和 README
老员工脑子里

最麻烦的是，这些信息不是静态的。

产品方向会变，技术方案会变，客户需求会变，旧决策会被新约束推翻。

如果没有一个持续维护的中间层，团队上下文很快就会变成“谁记得谁知道”。

LLM Wiki 可以怎么用于团队#

一个组织版 LLM Wiki 可以这样设计：

1
company-context/
2
  purpose.md
3
  schema.md
4
  raw/
5
    meetings/
6
    prds/
7
    customer-calls/
8
    incidents/
9
    github/
10
    research/
11
  wiki/
12
    index.md
13
    log.md
14
    overview.md
15
    entities/
16
      customers/
17
      products/
18
      teams/
19
      systems/
20
    concepts/
21
    decisions/
22
    incidents/
23
    projects/
24
    playbooks/
25
    queries/
26
    synthesis/

它不一定替代 Notion，也不一定替代代码仓库。

它更像是一个“context repo”。

团队可以把重要资料持续喂进去，让 LLM 维护：

项目背景页
客户画像页
系统架构页
ADR 决策页
事故复盘索引
产品路线总结
竞品比较
新人 onboarding 手册
Agent 执行任务前需要读的上下文

这对 Agent 尤其有用。

因为 Agent 最怕的不是不会写代码，而是上下文不完整。它不知道这个项目为什么这样设计，不知道之前踩过什么坑，不知道哪些方案已经被否了，不知道某个客户为什么重要。

如果组织有一套共享 LLM Wiki，Agent 每次做事前就可以先读相关 context，而不是重新问人。

人和 LLM 的分工#

我会这样分：

角色	负责什么
人	决定哪些资料可信、哪些结论重要、哪些内容能公开
LLM	摘要、归档、交叉引用、更新页面、发现矛盾
Reviewer	审核关键判断，处理冲突和敏感信息
Agent	在执行任务前读取相关 context，并把新结果写回

这里一定要保留人类审核。

尤其是组织场景，LLM 不应该直接把所有东西都自动变成“团队共识”。

我比较建议把页面分层：

1
wiki/drafts/       # LLM 初稿
2
wiki/review/       # 待审核
3
wiki/accepted/     # 已确认，可作为共享上下文
4
wiki/deprecated/   # 过时内容

或者在 frontmatter 里标状态：

1
status: draft | reviewed | accepted | deprecated
2
confidence: low | medium | high
3
sources:
4
  - raw/meetings/2026-04-20-weekly.md
5
owners:
6
  - platform-team
7
updated: 2026-04-27

这样 Agent 读的时候就知道哪些内容能直接当依据，哪些只是参考。

6. 我会怎么落地一个团队版 LLM Wiki#

如果是我来做，我不会一开始就把整个公司资料都倒进去。

那样很容易变成另一个没人维护的大坟场。

我会从一个小范围开始，比如：

一个项目组
一个产品线
一个客户成功团队
一个正在重构的系统
一个需要长期研究的技术方向

第一步：先写 purpose#

先回答这些问题：

1
这个 Wiki 服务谁？
2

3
它主要解决什么问题？
4

5
哪些内容应该进入？
6

7
哪些内容不应该进入？
8

9
哪些结论需要人工审核后才能成为 accepted？
10

11
当前最重要的 5 个问题是什么？

我觉得 purpose 比工具选择更重要。

如果目的不清楚，Wiki 只会变成更漂亮的资料堆。

第二步：定义 schema#

schema 不要太复杂，先够用。

1
## 页面类型
2

3
- source：资料摘要
4
- entity：客户、系统、团队、产品
5
- concept：概念、方法、技术
6
- decision：架构 / 产品决策
7
- incident：事故复盘
8
- playbook：操作手册
9
- synthesis：跨资料综合
10

11
## 必填 frontmatter
12

13
- title
14
- type
15
- status
16
- sources
17
- owners
18
- updated
19

20
## 规则
21

22
- 所有事实性判断必须有 sources
23
- 不确定内容标 confidence: low
24
- 冲突结论不要覆盖，先写到 review
25
- accepted 页面才能作为 Agent 默认上下文