Karpathy 的 LLM Wiki 构想

原文：raw/sources/karpathy-llm-wiki-idea.md（gist，作者 Andrej Karpathy）。这是一份刻意抽象的 idea file，设计用途是丢给 LLM agent 协作实例化——本知识库项目的思想源头。

核心论点

• RAG 的问题是不积累：上传文件、查询时检索片段、生成答案——LLM 每次都在从零重新发现知识，五份文档才能回答的微妙问题每次都要重新拼凑。NotebookLM、ChatGPT 文件上传和多数 RAG 系统都是这个模式。
• 反其道而行：LLM 增量地构建并维护一个持久 wiki——结构化、互链的 markdown 文件集合，位于人和原始资料之间。新资料入库时不只是被索引，而是被读取、提炼、整合进已有 wiki：更新实体页、修订主题综述、标记新旧矛盾。知识编译一次、持续保鲜，而非每次查询重新推导。
• wiki 是持久的、复利的 artifact：交叉引用已就位、矛盾已标记、综合已反映读过的一切，每加一份资料、每问一个问题都在变厚。
• 角色分工：人负责策展来源、探索、提问；LLM 负责全部苦活——总结、交叉引用、归档、记账。“Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。”

架构与操作

• 三层：raw sources（不可变，source of truth）/ wiki（LLM 全权拥有）/ schema（CLAUDE.md 之类的配置文件，人和 LLM 共同演化——让 LLM 成为“有纪律的 wiki 维护者而非通用聊天机器人”的关键）。
• 三操作：ingest（一份资料可能触及 10-15 个页面；作者偏好一次一份、全程参与）/ query（好答案应归档回 wiki，让探索也复利）/ lint（矛盾、过时论断、孤儿页、缺页概念、缺失交叉引用）。
• 两个导航文件：index.md 面向内容（目录 + 一行摘要，LLM 先读索引再深入，在 ~100 份资料规模下够用，无需 embedding RAG 设施）；log.md 面向时间（追加式，统一前缀可 grep）。

为什么可行

维护知识库最累的不是阅读和思考，是记账（更新交叉引用、保持摘要新鲜、标记矛盾）。人类放弃 wiki 是因为维护负担增长快于价值；LLM 不会烦、不会漏，一次能碰 15 个文件——维护成本趋近于零。思想上承接 Vannevar Bush 的 Memex（1945）：私有、主动策展、文档间关联与文档本身同等珍贵，Bush 没解决的“谁来维护”由 LLM 补上。

与本知识库的关系

本项目直接实例化了这份 idea file，细节见 LLM Wiki 模式与 RAG vs 编译式 wiki。