GitHub Trending 上一个日增 640 星的项目，解决的问题看起来很朴素：让 LLM 替你维护一个持续更新的个人知识库。nashsu/llm_wiki 目前 18,564 星，是一个跨平台桌面应用，把 Karpathy 今年发布的 LLM Wiki 模式文档实现成了完整产品。它值得展开看的地方在于，项目对 RAG 的替代思路、两层架构的分工，以及从设计文档到产品之间补上的十几块工程拼图。
RAG 的结构性问题：知识不积累
常见的文档问答方案是 RAG（检索增强生成）：文件切块、建索引，提问时检索相关片段，让 LLM 拼出答案。Karpathy 在 LLM Wiki 文档里指出了这套流程的结构性问题——每次提问，LLM 都在从头重新发现知识。问一个需要综合五份文档的问题，系统就要每次都把五个碎片重新找出来拼一次。没有任何东西被积累下来。NotebookLM、ChatGPT 的文件上传和多数 RAG 系统都属于这一类。
LLM Wiki 的思路不同：它跳过了查询时的原始文档检索，让 LLM 增量地构建和维护一个持久化的 wiki——一组结构化、互相链接的 Markdown 文件，位于你和原始资料之间。新增一份资料时，LLM 读取它、提取关键信息、整合进现有 wiki：更新实体页面、修订主题综述、标记新数据与旧结论的矛盾。知识被编译一次，然后保持更新，而不是在每次查询时重新推导。
按 Karpathy 的表述，wiki 是一个持久的、有复利效应的产物：交叉引用已经建好，矛盾已经标出，综述已经反映了你读过的所有材料。每加一份资料、每问一个问题，wiki 都变得更丰富。
三层架构与人的位置
模式分三层：
- Raw Sources：原始资料层。文章、论文、图片、数据文件，不可变，LLM 只读不改，是事实的唯一来源。
- Wiki 层：LLM 生成的 Markdown 文件目录，包括综述、实体页、概念页、对比页。LLM 完全拥有这一层，负责创建、更新、维护一致性。你只读，它只写。
- Schema 层：一份规则文档（Claude Code 里是 CLAUDE.md，Codex 里是 AGENTS.md），规定 wiki 的结构约定和 ingest、查询、维护时的工作流程。你和 LLM 随使用共同演化这份文档。
三个核心操作：Ingest（新资料进站，LLM 读源、写摘要页、更新关联的实体页和概念页、更新索引并追加日志，一份资料通常触及 10 到 15 个页面）、Query（提问时 LLM 先读索引定位页面再综合引用，好答案可以归档回 wiki 成为新页面）、Lint（定期体检，查页面间矛盾、被新资料推翻的旧结论、孤儿页面和缺失的交叉引用）。
角色分工里有个关键设定：人类负责策划资料来源、提出好问题、判断分析方向；摘要、交叉引用、归档、簿记这些让知识库长期有用的杂活全部交给 LLM。Karpathy 的用法是一边开着 agent 一边开着 Obsidian，Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。
这套思路在精神上承接了 Vannevar Bush 1945 年设想的 Memex——私人策划、以文档间关联路径为核心的知识库。Bush 没解决的问题是维护由谁来做；现在答案变成了 LLM：它不会厌倦，不会忘记更新交叉引用，一次可以触及 15 个文件。人类放弃 wiki 的原因是维护负担的增长快于价值，而这里维护成本被压到接近零。
从文档到桌面应用：nashsu/llm_wiki 补了什么
Karpathy 的原文是一份刻意抽象的设计文档，定位是复制给你自己的 agent 使用。llm_wiki 把它实现成了 Tauri v2 桌面应用（Rust 后端 + React 19 前端），README 里逐项列出了保留与扩展的边界。保留的核心：三层架构、三大操作、index.md 内容目录、log.md 时间线日志、[[wikilink]] 交叉引用语法、YAML frontmatter、与 Obsidian vault 的兼容。扩展的部分分几类。
两步 ingest。原模式里 LLM 读资料和写页面一次完成，llm_wiki 拆成两个串行调用：第一步做结构化分析（关键实体、概念、论证，与现有 wiki 的关联与矛盾，结构建议），第二步拿分析结果生成页面（带 frontmatter 来源字段的摘要页、实体页、概念页，更新 index.md 和 log.md）。配套 SHA256 增量缓存，未变化的文件自动跳过；ingest 队列持久化到磁盘，应用重启后恢复，失败任务自动重试最多三次。
四信号知识图谱。原模式只有 [[wikilink]]，没有图分析。llm_wiki 建了完整的相关性引擎，页面相关度由四个信号加权：直接链接 ×3.0、共享原始来源 ×4.0、Adamic-Adar 共同邻居 ×1.5、同类型加成 ×1.0。可视化用 sigma.js + ForceAtlas2 力导向布局，节点按类型或社区着色。在此之上跑 Louvain 社区检测自动发现知识簇，每个簇按内部边密度打凝聚度分，低于 0.15 的簇会被标记。图洞察还能自动发现跨社区连接的「意外关联」和三类知识缺口：度数≤1 的孤立页、低凝聚度稀疏簇、连接三个簇以上的桥接节点，后两者附一键 Deep Research。
四阶段查询管线。分词检索（英文去停用词，中文 CJK 二元分词，标题命中加 10 分）→ 可选向量语义检索（LanceDB，任何 OpenAI 兼容 embeddings 端点）→ 图扩展（检索结果作种子节点，四信号模型做两跳遍历）→ 上下文预算控制（4K 到 1M token 可调，按 60% wiki 页面、20% 对话历史、5% 索引、15% 系统提示比例分配）。README 给了一个基准数字：开启向量检索后，整体召回率从 58.2% 提升到 71.4%；向量检索默认关闭，关闭时回退到分词检索加图扩展。
删除的级联清理。删一份原始资料时，按 frontmatter 来源字段、摘要页名、frontmatter 章节引用三种方式匹配关联页面；被多个资料引用的共享实体页只从 sources[] 里移除该来源而不删除；死链随删除清理。
工程周边：PDF/DOCX/PPTX/XLSX/EPUB 等多格式解析（复杂 PDF 可选 MinerU，失败回退内置解析器）、异步 Review 队列（LLM 在 ingest 时标记需要人判断的条目，动作预定义防幻觉）、基于 Tavily/SerpApi/SearXNG 的 Deep Research（研究结果自动 ingest 入库）、Chrome Web Clipper、本地 HTTP API（127.0.0.1:19828，token 保护）加捆绑的 MCP server，Claude Code 或 Codex 可以直接查询你的 wiki。
对开发者的实际意义
llm_wiki 目前处于积极开发期，README 自述 API 和部分桌面行为还会演进，安装走 Releases 的 dmg/msi/deb/AppImage，或从源码构建（Node.js 20+、Rust 1.88+、protoc）。
它代表的方向对两类人有直接参考价值。做知识管理工具的人可以把它当作「RAG 之外」的完整样本：wiki 目录在中等规模（约 100 份资料、数百页面）下靠 index.md 就能导航，回避了向量数据库基础设施；规模上去后再按需加 LanceDB 向量检索，四信号图谱和社区检测提供 RAG 检索不出的结构性洞察。用 LLM 做个人知识库的人则可以不装任何应用，直接把 Karpathy 的原文档喂给自己的编码 agent，配上 Obsidian 自己搭——模式本身是抽象的，llm_wiki 只是把两条路里工程量大的那条提前走完了。
三种用法对应三种投入：纯模式复用，成本是调试你的 agent 和 Schema 文档；桌面应用开箱即用，成本是接受它的 EARLY PREVIEW 状态；接 MCP 把 wiki 变成编码 agent 的外部记忆，成本是本地 API 的端口和 token 管理。文档、实现、原始模式三方都在活跃状态，这个项目的后续值得跟。
来源：