当文档不再腐烂：从 Karpathy 的 LLM Wiki 到软件工程文档管理

Thu, 09 Apr 2026 00:00:00 +0800

人负责写原始文档和做决策，LLM 负责综合、更新和一致性检查。文档不再是写完即腐烂的静态产物，而是一个由 LLM 持续维护的活知识库。

一个古老的问题

每个软件工程师都经历过这样的场景：你接手一个项目，翻开文档，发现 README 还在描述半年前删掉的模块，API 文档里的字段和代码完全对不上，架构图画的是两个版本前的设计。你问同事，同事说"别看文档，直接看代码吧"。

文档腐烂（documentation decay）不是因为工程师不想写文档，而是因为维护文档的成本太高。写一份设计文档可能花两个小时，但之后每次代码变更都需要回来同步更新 —— 检查交叉引用是否还成立、术语是否一致、边界条件是否还对 —— 这些琐碎的记账工作让人疲惫，最终被放弃。

2025 年，Andrej Karpathy 提出了一个关于 LLM 与知识管理的重要观察。他的核心主张出奇地简单：

不要让 LLM 每次都从原始文档中重新发现模式，而应该让它构建和维护一个结构化的知识库，让知识持续积累。

这就是 LLM Wiki 模式。它和传统的 RAG（检索增强生成）有一个关键区别 —— RAG 每次查询都强迫 LLM 从零开始重建理解，而 Wiki 模式将综合（synthesis）本身视为一等公民的产物。知识不断积累，因为交叉引用已经建立，矛盾已经被标记，概念之间的关系已经被梳理。

Karpathy 勾勒了一个三层架构：

以及三个核心操作：Ingest（摄入新来源并更新 wiki）、Query（查询并将有价值的发现回写 wiki）、Lint（健康检查 —— 找矛盾、找孤立页面、找缺失引用）。

他还提出了一个深刻的分工：

人的工作是策划来源、指导分析、问好的问题。LLM 的工作是其他一切。

这个"其他一切"，恰好是杀死人类 wiki 的那些事情 —— 更新摘要、维护交叉引用、检查一致性。这些工作对人来说是乏味的苦差事，对 LLM 来说却是可靠且不知疲倦的日常。