AI 圈的 “Wiki” 到底是什么：从 LLM Wiki 到 DeepWiki
日期：2026年9月19日
作者：Honlnk/鸿影
适用读者：AI 工具使用者、知识管理爱好者、想搞清”wiki 热”的开发者
定位说明：2026 年 AI 圈有两个都叫 “wiki” 的热点——Karpathy 的 LLM Wiki 和 DeepWiki 家族。本文梳理它们的来龙去脉、技术原理与共同本质，不涉及具体实现教程。
一、先理清：“wiki” 在 AI 领域的传统含义
在 2026 年的新热点之前，AI 圈说 “wiki” 基本就是指维基百科（Wikipedia）及其衍生品：
- 训练语料：Wikipedia 的数据库 dump 是大模型预训练语料里最经典的高质量来源，讨论数据配比时经常直接简称 “wiki”；
- 经典数据集：WikiText-2/103（语言建模）、WikiSQL（Text-to-SQL）、WikiQA（问答）、WikiBio（文本生成），NLP 论文里的常客；
- 知识源：做 RAG、事实核查、实体消歧时，Wikipedia 和 Wikidata 是最常用的知识库。NLP 里甚至有个动词 wikify，意思是”把文本中的实体链接到对应的维基词条”。
顺带一提词源：wiki 来自夏威夷语 “wiki wiki”（意为”快”），1995 年 Ward Cunningham 创建第一个 wiki 网站 WikiWikiWeb；维基百科只是这种”人人可编辑的协作网站”中最成功的实例。
但 2026 年大家讨论的 “wiki” 是另外两件事。
二、热点一：Karpathy 的 LLM Wiki——AI 替你维护的个人知识库
2.1 它是什么
2026 年 4 月，Andrej Karpathy 发布了一个 GitHub gist（llm-wiki.md），提出 LLM Wiki：一种用 LLM 构建个人知识库的模式（pattern）。注意是模式，不是产品——文档开头就明说这是 “idea file”，用法是复制粘贴给你自己的 Agent（Claude Code、Codex、ZCode 这类工具皆可），让 Agent 按这个思路和你协作搭建。发布后几天内爆火，GitHub 上涌现出大量实现。
2.2 核心思想：反对”每次查询都从零拼凑”
Karpathy 的出发点是：现在主流的 LLM 文档问答（NotebookLM、ChatGPT 传文件、各种 RAG 系统）都是查询时才临时检索原始文档切片，每次回答都从零重新拼凑知识，没有任何积累。
LLM Wiki 反其道而行：LLM 不只是索引原始资料，而是增量地构建并维护一个持久的 wiki——一层结构化的、互相链接的 markdown 页面，挡在你和原始资料之间。每加入一篇新资料，LLM 会读完它、提取要点、更新相关实体页和主题页、标注新旧数据之间的矛盾。知识被”编译”一次之后持续保鲜，而不是每次查询重新推导。
2.3 三层架构
| 层 | 内容 | 谁负责 |
|---|---|---|
| Raw sources | 原始资料（文章、论文、播客笔记），只读不可改，是 source of truth | 你负责收集投喂 |
| Wiki | LLM 生成的 markdown 页面：摘要页、实体页、概念页、综述 | LLM 全权写和维护，你负责读 |
| Schema | 一个 CLAUDE.md / AGENTS.md 文件，规定 wiki 的结构、约定和工作流 | 你和 LLM 共同演化 |
配套两个特殊文件：index.md（内容目录，查询时先读它定位页面，几百页规模内可以不走向量检索）和 log.md（只追加的时间线日志）。
2.4 三个核心操作
- Ingest（收录）：丢一篇新资料进去，告诉 Agent 处理它；Agent 读完后写摘要页、更新索引、顺带更新相关的 10~15 个页面；
- Query（查询）：基于 wiki 回答问题。关键设计是——好的答案可以回填成 wiki 新页面，提问本身也在积累知识；
- Lint（体检）：定期让 LLM 检查矛盾、过时论断、孤儿页面、缺失的交叉引用。
Karpathy 本人的用法：左边开 Agent，右边开 Obsidian 实时浏览。他的比喻是：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。
2.5 为什么这个模式现在才成立
人类维护 wiki 从来都是败给维护成本——交叉引用、摘要更新、矛盾标注这些 bookkeeping 太繁琐，所以个人 wiki 几乎必烂尾。而 LLM 不会烦、不会忘、一次能改 15 个文件，维护成本趋近于零。人的角色退回到”选资料、提问题、思考意义”。
思想上它承袭了 1945 年 Vannevar Bush 的 Memex 构想——私人的、主动策展的知识库，文档之间的连接和文档本身一样有价值。Bush 当年解决不了”谁来维护”的问题，现在 LLM 解决了。
三、热点二：DeepWiki 家族——AI 替你读代码库
3.1 DeepWiki 是什么
DeepWiki 是 Cognition AI（AI 程序员 Devin 的开发团队）2025 年 4 月底推出的产品，用法优雅到近乎病毒式传播：把任何 GitHub 仓库 URL 里的 github.com 换成 deepwiki.com，就得到这个仓库的一整套 AI 生成的 Wiki 文档。公开仓库免费、无需登录——它给全球公开仓库预建索引，你访问时页面大概率早已生成好。
它命中的痛点是：读别人的代码痛苦。README 只讲怎么装，没人给你讲架构。
3.2 生成什么
- 总览页：项目定位、核心特性、技术栈；
- 架构文档：系统分层、模块划分、依赖调用关系，配自动生成的架构图（Mermaid）；
- 模块级页面：每个子系统的职责、关键类和函数、数据流；
- 行号级代码引用：文档论断直接链到具体文件和行，可核对可跳转。
3.3 两个关键扩展
- Ask / DeepResearch（对话式查询）：直接用自然语言问这个仓库的任何问题——“认证流程怎么走的？""加支付渠道该改哪几个模块？“AI 基于预建的仓库语义图谱和文档知识库回答，而不是现场瞎猜。
- MCP Server：每个仓库的 wiki 暴露 MCP 接口，意味着不止人能读，AI 也能读——你在编辑器里写代码时，Agent 可以直接查询依赖库的 DeepWiki 作为上下文。Wiki 从”给人看的文档”变成了”人机双读的知识库”，这是它成为基础设施的关键一步。
私有仓库不在免费版范围内，那是商业版能力。
3.4 技术管线（社区逆向分析还原）
- 拉取仓库，递归扫描目录结构；
- 多语言 AST 解析 + 静态分析：提取函数、类、模块实体及 import、调用、继承关系；
- 构建语义图谱：实体为节点、关系为边，拆解成”系统 → 子系统 → 模块”层级；
- LLM 逐层生成文档：基于图谱和源码产出 wiki 页面和架构图；
- 索引沉淀：Ask 功能复用预建图谱做检索，而不是每次现读全仓。
3.5 一个家族，不止一家
DeepWiki 验证模式后，这个形态迅速被复制成品类：
- Qoder Repo Wiki（阿里，2025 年 8 月随 Qoder IDE 上线）：IDE 内置，本地项目自动生成 wiki，随代码变更持续更新，并反哺给 IDE 里的智能体当项目级上下文；
- ZCode Repo Wiki（智谱）：同一思路，采用云端生成 wiki 页面的实现路线；
- Google Code Wiki、Zread 等国内外产品也在做类似的事。
“DeepWiki 家族”指的就是这一整类**“代码库 → 结构化、人机双读、可持续更新的知识库”**产品形态。
四、两个家族的对比与共同本质
4.1 差异：编译什么、为谁编译
| LLM Wiki | DeepWiki 家族 | |
|---|---|---|
| 编译对象 | 个人知识源（文章、论文、笔记） | 代码库 |
| 主要服务 | 自己的长期知识积累 | 读懂别人的（或祖传的）项目 |
| 形态 | 开放模式，无官方实现，工具链自由组合 | 具体产品/IDE 内置功能 |
| 驱动方式 | 对话式、增量、人深度参与 | 自动化批量生成 |
4.2 共同本质：知识的”预编译中间层”
两者都不是新技术栈，而是处理内容的方案，且方案的内核是同一个：
在原始内容和消费者之间，加一层”预编译的知识中间层”。
它们共同反对的是纯 RAG 模式——“知识留在原地，查询时临时检索、临时拼凑”，每次问答从零开始，毫无积累。两个 wiki 家族的回答一致：把知识提前编译成结构化、互链、持久化的产物，之后人和 AI 都消费这个编译产物，而不是原始材料。编译一次，持续保鲜，越用越值钱。
于是 “wiki” 这个词在 AI 时代的含义也悄然变了：不再是”人人可编辑的网页”，而是**“知识的编译产物”**。
而两个方案成立的前提只有一个：LLM 把”整理和维护知识”的成本打到了接近零。代码文档、个人 wiki，这些形态历史上全都死于”没人维护”；现在维护者换成了 AI，它们集体复活了。
五、延伸思考
顺着”预编译知识层”这个框架可以预判：任何原料堆积但没人整理的领域都会被这套模式洗一遍——会议纪要、客户资料、论文库、聊天记录……其实已经有人在做了。
对个人开发者的实际建议：
- 想试试 LLM Wiki：开个空目录，把 Karpathy 的 gist 丢给你的 Agent，让它搭出三层结构即可起步；
- 想看 DeepWiki：随便找个你正在用的开源库，把 URL 里的域名换成
deepwiki.com体验五分钟，感受最直接。