AI工程论：详细拆解LLM Wiki

原文链接：https://mp.weixin.qq.com/s/kVmRPkfDJMEh58mD8pXgfw

万字详细拆解LLM WiKi，讲解Karpathy所描述的LLM WiKi的定义、架构、场景、实操示例等。

详细拆解LLM Wiki

今天详细拆解一下LLM wiki。

Andrej Karpathy 在 2026 年 4 月提出的 LLM Wiki，更准确地说，是一种由 LLM 持续维护的知识库模式：原始资料被保留下来，LLM 负责把资料逐步整理成结构化、可交叉引用、可持续演进的 Markdown Wiki。

它不是“上传文件后临时问答”，而是“持续把资料和问题编译成知识中间层”。

可以先用一句话概括：

LLM Wiki 的核心不是检索，而是让 LLM 持续维护一个可演进、可复利增长的 Wiki。

– 前文几篇简单介绍了部分个人的实践《Docs As Code，AI 研发转型中，我们为什么把研发知识放进 Git》+《Harness Engineering实践之：我们是怎么结合 CLAUDE.md、AGENTS.md 以及 dir-graph.yaml 来减少飘移的》、《Harness Engineering 实践：LLM Wiki 什么时候、怎么引入?》，可以翻一下，后面完完整整的介绍下我们3月份就开始做的实践。

这个模式可以用于个人知识管理、研究、阅读、竞品分析、尽调、课程笔记，也可以用于研发团队的项目知识和 Agent 上下文管理。

同时，LLM Wiki 也有明确边界：它适合维护、组织、解释和发现知识，不适合替代事实责任、业务判断和正式审批。

一、LLM Wiki 与普通 AI 知识库的差异

很多 AI 知识库的典型使用方式是：

1.上传一批文档；2.系统把文档切块、索引；3.用户提问；4.系统在查询时召回相关片段；5.LLM 基于召回内容生成答案。

这就是常见的 RAG 体验。

RAG 的价值很明确：它让回答能够基于用户提供的资料，而不是完全依赖模型参数里的通用知识。

但 Karpathy 提出的 LLM Wiki 关注的是另一个问题：普通 RAG 在每次查询时重新检索、重新拼接、重新综合，知识并不会自动积累成一个更好的结构。

例如，一个问题需要综合五份资料。RAG 系统会在本次查询时找出相关片段并生成回答。下次问一个相似问题，系统通常还要再次检索、再次拼装。

LLM Wiki 的做法不同。

新增一份资料后，LLM 不只是把它放进索引，而是读取它、提炼它，并把它合并到已有 Wiki 中。它可能会：

•新建 source summary；•更新 entity page；•更新 topic page；•增加 comparison 或 synthesis；•补充交叉引用；•标记新资料和旧页面之间的冲突；•更新 overview；•更新 index；•追加 log。

因此，LLM Wiki 的关键变化是：Wiki 本身成为一个持久产物。

资料被读过之后，不只是“可检索”，还会被“整理进结构”。问题被回答之后，不只是留在聊天记录里，也可以沉淀成新的 Wiki 页面。

普通 RAG 偏向查询时召回；LLM Wiki 偏向持续性知识编译。

二、Karpathy 模式的三层架构

Karpathy 原始描述中的 LLM Wiki 架构主要包括三层：raw sources、the wiki、schema。

1. Raw Sources：原始资料层

raw sources 是原始资料集合。

这些资料可以是文章、论文、书摘、网页、图片、数据文件、会议纪要、项目文档。放到研发场景中，也可以是代码、README、PRD、SDD、ADR、Issue、PR、测试记录、发布记录、故障复盘。

这一层的原则是：原始资料尽量保持不可变。

LLM 可以读取、引用和总结这些资料，但不应随意修改它们。因为 raw sources 是来源依据，用来回答“某个结论从哪里来”“某个页面依据什么资料生成”。

如果 LLM 维护的 Wiki 出现不准确的表述，需要能够回到 raw sources 检查来源。

因此，raw sources 在 LLM Wiki 中承担事实锚点的角色。

2. The Wiki：LLM 维护的知识层

the wiki 是 LLM 生成和维护的 Markdown 页面集合。

这一层通常包括：

•source summary；•entity page；•concept page；•topic page；•comparison；•synthesis；•overview；•analysis；•FAQ；•index；•log。

它不是原始资料，也不是简单摘要，而是 LLM 对原始资料进行整理、关联和更新后的知识中间层。

例如，研究一个行业时，raw sources 里可能是新闻、财报、访谈、产品介绍、竞品资料；Wiki 中则可能逐步形成“主要公司”“关键人物”“产品路线”“商业模式”“技术路线”“争议点”“时间线”等页面。

在研发团队中，raw sources 可能是代码、需求、故障复盘和测试报告；Wiki 中则可以形成“订单取消链路”“支付回调风险点”“库存补偿机制”“核心测试矩阵”“新人阅读路径”等页面。

Karpathy 对这个模式有一个比喻：Obsidian 像 IDE，LLM 像程序员，Wiki 像代码库。

这个比喻说明了 LLM Wiki 的性质：它不是单纯展示页面的工具，而是一套由 LLM 持续维护的知识代码库。

3. Schema：维护规则层

schema 是告诉 LLM 如何维护 Wiki 的规则文件。

这里的 schema 不一定是数据库 schema，更接近工作协议或维护规范。在 Claude Code 中可以是 CLAUDE.md，在 Codex 中可以是 AGENTS.md，也可以是团队自定义的 wiki-rules.md。

它通常需要说明：

•raw sources 放在哪里；•wiki 页面怎么命名；•entity、topic、source summary 各自怎么写；•ingest 新资料时要执行哪些动作；•query 时先读哪些索引；•如何记录 log；•如何引用来源；•如何标记不确定和冲突；•什么时候新建页面；•什么时候更新已有页面；•lint 时检查什么。

没有 schema，LLM 更像一个泛用聊天机器人。

有了 schema，LLM 才能按照稳定规则维护 Wiki。

可以把三层关系概括为：

-
-

1	`raw sources -> the wiki -> schema``事实锚点知识中间层维护协议`

三、三个核心操作：Ingest、Query、Lint

LLM Wiki 的运转主要依赖三个操作：ingest、query、lint。

1. Ingest：把新资料编译进 Wiki

ingest 不是简单上传文件，而是让 LLM 读取新资料，并把新资料融入已有 Wiki。

一个典型 ingest 流程可以包括：

1.读取新 source；2.提炼关键内容；3.判断它关联哪些已有页面；4.创建 source summary；5.更新相关 entity page 和 topic page；6.标记与旧资料冲突的地方；7.更新 index；8.追加 log；9.输出需要人工确认的问题。

普通知识库把资料“放进去”，LLM Wiki 更强调把资料“消化进已有结构”。

例如，研发团队新增一篇故障复盘。普通 Wiki 只是多一篇文档；LLM Wiki 可以进一步更新相关模块风险页、Runbook、历史事故时间线、测试缺口列表和新人阅读提示。

Ingest 的关键目标是：新增资料不孤立存在，而是进入已有知识网络。

2. Query：问题也可以沉淀成页面

query 是提问。

在 LLM Wiki 中，query 不只是为了得到一次性答案。高质量问题和答案也可以反向沉淀为 Wiki 页面。

例如，用户问：

“订单取消、退款、库存回补这三条链路的边界分别是什么？”

LLM 读取已有 Wiki 后，可能生成一篇 comparison page。如果这篇回答经过确认，它可以被写回 Wiki，成为后续新人、测试人员或 Agent 可复用的知识资产。

这和普通聊天式问答不同。

在聊天式问答里，好答案经常停留在对话历史中；在 LLM Wiki 中，好答案可以转化为结构化页面。

因此，query 也是 Wiki 增长的一部分。

3. Lint：定期检查知识库健康状态

lint 是定期检查 Wiki 的健康状态。

PS. 这个健康检查是非常重要的，是wiki有效性的重要保障.

传统 Wiki 容易失败，并不只是因为没人写，而是因为没人持续维护。页面增长后，常见问题包括：

•页面之间互相矛盾；•旧结论没有被新资料覆盖；•重要概念反复出现，但没有独立页面；•有些页面没有入链；•交叉引用缺失；•index 过期；•log 不完整；•某些判断缺少来源；•高频问题没有沉淀成稳定页面。

Lint 的作用就是让 LLM 定期检查这些问题。

相比人工维护，LLM 更适合处理这类重复性工作：检查一致性、补充链接、发现孤立页面、提示冲突、生成待办。

没有 lint，LLM Wiki 也可能逐渐退化成普通 Wiki：前期页面丰富，后期内容过期、冲突增多，可信度下降。

四、两个关键文件：index.md 和 log.md

Karpathy 特别提到 index.md 和 log.md。这两个文件看起来简单，但对 LLM Wiki 的可维护性很重要。

PS. 我这里用的不是md文件，而是yaml文件，这属于台账类文档，yaml/json这种结构化的文本文档可能更合适一点.

1. index.md：内容导航

index.md 是内容导览。

它列出 Wiki 中有哪些页面，每个页面讲什么，属于哪个分类，以及必要的元信息。

在小中等规模下，index.md 可以让 LLM 不依赖复杂向量库，也能先找到相关页面。

因此，LLM Wiki 的起点并不一定是 embedding、向量数据库、rerank 或复杂检索服务。一个 Markdown 目录加一个维护良好的 index，就可以形成最小可运行模式。

对个人知识库来说，index 是阅读导航。

对研发团队来说，index 可以是项目上下文地图。Agent 执行任务前，可以先读 index，了解当前项目有哪些模块页、风险页、测试页、架构页和术语页。

2. log.md：演进时间线

log.md 是演进记录。

PS. 我们重要知识采用了git的管理模式，每个版本只维护其匹配的版本，这样知识不仅能有记录，同时还有版本。

它记录每次 ingest、query、lint 发生了什么。

示例：

-
-

1	`## [2026-04-02] ingest \| Payment callback incident review``## [2026-04-05] query \| Refund vs cancel boundary comparison``## [2026-04-08] lint \| Found stale claims in order-cancel topic`

log 的价值在于记录 Wiki 的变化过程：哪些知识刚更新过，哪些页面被反复触碰，哪些问题还没有解决。

如果 log 前缀格式稳定，还可以用简单命令行工具搜索最近记录。

没有 index，LLM 不知道从哪里读。

没有 log，团队不知道知识如何演进。

五、LLM Wiki 和 RAG 的本质区别

LLM Wiki 可以结合 RAG，但它的核心不是 RAG。

如果资料量很大，或者资料分散在多个系统中，LLM Wiki 可以接搜索引擎、BM25、向量检索、混合检索、rerank，甚至 MCP 工具。

但这些是能力扩展，不是模式本身。

普通 RAG 的典型路径是：

-
-

1	`raw documents``-> retrieve chunks at query time``-> generate answer`

LLM Wiki 的典型路径是：

-
-

1	`raw sources``-> LLM-maintained wiki``-> query / analysis / new pages``-> wiki keeps improving`

二者的主要区别在于：

•RAG 的知识组织主要发生在查询时；•LLM Wiki 的知识组织主要发生在 ingest、query 写回和 lint 维护过程中；•RAG 关注一次问题如何回答；•LLM Wiki 关注知识结构如何持续变好；•RAG 的核心产物是回答；•LLM Wiki 的核心产物是持续演进的 Wiki。

也可以把 LLM Wiki 理解成一种知识编译机制：

-
-

1	`raw sources``-> LLM-maintained wiki``-> index / log / schema``-> human & agent workflows`

原始资料是输入，Wiki 是编译产物，schema 是构建规则，index 和 log 是辅助文件，query 和 lint 是持续运行机制。

六、为什么 LLM Wiki 现在成立

传统 Wiki 的主要难点不是创建页面，而是长期维护。

常见维护动作包括：

•新资料出现后更新旧页面；•新结论覆盖旧结论时标记冲突；•新概念出现时建立页面；•页面之间补充链接；•更新 index；•归档旧页面；•将高质量问答沉淀为页面；•标记不确定内容；•定期检查整个知识库。

这些动作重复、琐碎、持续时间长，因此传统 Wiki 经常出现“前期建设热闹，后期维护不足”的问题。

LLM Wiki 成立的基础，是 LLM 降低了这类维护动作的成本。

人仍然负责资料选择、问题提出、重要结论确认和最终判断。

LLM 负责摘要、归档、交叉引用、页面更新、索引维护、冲突提示、演进日志和健康检查。

这个分工使 Wiki 的维护成本下降，从而让知识库具备持续演进的可能。

七、研发团队场景中的形态

Karpathy 原始例子更多面向个人知识库和研究型知识管理。放到研发团队中，LLM Wiki 可以变成项目知识和 Agent 上下文的中间层。

研发团队的知识往往分散在代码、需求、设计、测试、发布、故障、客户反馈和运维约束中。这些资料之间存在大量连接，而连接本身往往最难维护。

一个研发团队中的 LLM Wiki 可以包括：

•模块页：模块职责、边界、入口；•链路页：业务流程经过哪些服务、接口、表和消息；•风险页：历史事故、薄弱测试、兼容性约束；•决策页：ADR、历史方案取舍、当前有效性；•测试页：核心测试矩阵、回归范围、自动化覆盖；•新人页：阅读路径、术语表、常见问题；•Agent 页：任务前上下文、禁止事项、测试命令。

这里需要区分底层事实源和知识中间层。

底层事实可以仍然在 Git、代码仓库、需求系统、测试平台、发布平台中。LLM Wiki 负责把这些散落资料组织成更容易理解、查询和复用的上下文。

可以概括为：

底层系统负责事实生产，LLM Wiki 负责知识组织和上下文供给。

因此，LLM Wiki 不应替代底层事实源。它生成的页面应保留来源引用、状态标识和不确定提示。

例如，LLM Wiki 可以提示“根据当前资料，存在三个风险点”，但不应直接替代正式上线判断。

八、最小 LLM Wiki 示例

不考虑平台化时，一个最小 LLM Wiki 可以采用简单目录结构：

-
-

1	`llm-wiki/``raw/``sources/``assets/````wiki/``index.md``log.md``overview.md``sources/``entities/``topics/``analyses/``questions/````AGENTS.md`

如果使用 Claude Code，可以把 AGENTS.md 换成 CLAUDE.md。

其中：

•raw/ 放原始资料；•wiki/ 放 LLM 维护的页面；•wiki/index.md 放内容导航；•wiki/log.md 放演进记录；•wiki/sources/ 放每份资料的摘要；•wiki/entities/ 放人、产品、模块、系统、公司等实体页；•wiki/topics/ 放主题页；•wiki/analyses/ 放经过确认的分析结果；•wiki/questions/ 放高价值问题和回答沉淀；•AGENTS.md 或 CLAUDE.md 放维护规则。

规则文件可以描述如下流程：

-
-

`当 ingest 新 source 时：``1. 读取 raw source；``2. 在 wiki/sources/ 生成摘要；``3. 检查是否需要更新 entities 和 topics；``4. 对冲突结论加 TODO 或 conflict 标记；``5. 更新 wiki/index.md；``6. 在 wiki/log.md 追加记录；``7. 输出需要人工确认的问题。````当 query 产生高价值答案时：``1. 判断是否值得写回 wiki；``2. 如果值得，写入 analyses 或 questions；``3. 引用相关 sources；``4. 更新 index 和 log。````当 lint 时：``1. 检查孤立页面；``2. 检查过期结论；``3. 检查缺失来源；``4. 检查冲突标记；``5. 生成待办清单。`

这个最小版本不依赖复杂系统、向量数据库或前端页面，但已经具备 LLM Wiki 的核心要素：原始资料、LLM 维护的 Wiki、维护规则、索引、日志和健康检查。

九、常见误解

误解一：LLM Wiki 就是 RAG。

LLM Wiki 可以使用 RAG，但不等同于 RAG。它的核心是持久 Wiki，而不是查询时检索。

误解二：LLM Wiki 会自动保证知识正确。

LLM Wiki 可以降低维护成本，但不能消除事实责任。重要结论仍然需要人工确认。

误解三：LLM Wiki 是让人不用写文档。

更准确地说，LLM Wiki 是让人减少机械维护，把注意力放在资料选择、问题提出和判断确认上。

误解四：LLM Wiki 一定需要复杂平台。

Karpathy 的原始模式可以从 Markdown 文件、Obsidian、Agent 和规则文件开始。小规模场景不一定需要复杂平台。

误解五：LLM 生成页面就是主事实源。

LLM 生成页是知识中间层，应引用 raw sources，而不是替代 raw sources。

误解六：LLM Wiki 只适合个人知识库。

个人知识库是容易启动的场景，但研究、竞品分析、尽调、课程学习、客户访谈沉淀、研发项目知识管理，也都可以采用这种模式。

进入团队场景后，需要额外处理权限、来源、状态和责任边界。

十、总结

LLM Wiki 的重点不是新建一个知识展示工具，而是改变知识库的维护方式。

传统 Wiki 依赖人持续维护，因此容易在使用一段时间后出现页面过期、链接缺失、结论冲突、没人敢信的问题。

LLM Wiki 把大量维护动作交给 LLM：摘要、归档、交叉引用、索引更新、冲突提示、日志记录和健康检查。

人仍然负责资料选择、问题提出、重要结论确认和最终判断。

因此，LLM Wiki 可以被看作一种知识中间层：

raw sources -> LLM-maintained wiki -> human & agent workflows

评价一个 LLM Wiki 是否成立，可以看三个问题：

1.重要结论是否能回到来源；2.新增资料是否会更新已有知识结构；3.是否能定期发现矛盾、过期和缺口。

如果这三件事做不到，它更接近一个带问答能力的搜索框。

如果这三件事做到了，它才符合 Karpathy 所描述的模式：一个由 LLM 持续维护、会复利增长的 Wiki。

PS. 这个拆解内容其实有点脱离具体的真实工程体系，我们从3月份开始把工程体系与这块结合起来实践，后面整理下把我们完整的从Knowledge的管理实践，以及工程体系搭建的实践完整的整理一下。

本文转载自微信公众号，如有侵权请联系删除。