夜雨聆风
实用解读 nashsu/llm_wiki：这款桌面应用把 Andrej Karpathy 的 LLM Wiki 模式落地为一套可自我维护的知识库。
每次你把文档上传到 ChatGPT 或 NotebookLM，模型都得从零开始重新理解它。明天在全新的会话里问同一个问题，系统往往又要从检索到的片段里重建一遍含义。
这就是大多数“文档聊天”工具鲜为人知的秘密：它们的检索很强，但它们不会积累理解。
Andrej Karpathy 最近提出了另一种思路。与其把 AI 当搜索引擎，不如把它当“真正维护图书馆的图书管理员”。每份新文档都会被阅读、分析、与其他一切交叉引用，并归档到一个永久、互联的知识库中。AI 会为你的研究构建一座 wiki，而每喂给它一份新材料，这座 wiki 就会变得更聪明。
已经有人做出来了。这个项目叫做 nashsu/llm_wiki，是我今年见过最有意思的开源 AI 模式之一。
我想带你了解它到底怎么运作、为什么重要，以及就算你不下载安装，也能从今天开始用起来的方法。
你现在使用 AI 的问题
一个很熟悉的场景：
你在研究一个主题。也许是竞品分析、论文综述，或是在理解一个复杂技术领域。你把 30 份 PDF 上传到你喜欢的 AI 工具。你问了个问题，得到一个还不错的答案。两天后你又问了个问题。这次 AI 给出略有不同的回答，因为它这回从 embedding 数据库里拉的是另一批片段。
综合在哪里？积累在哪里？系统何时能比你更懂你的研究？
在最常见的 RAG（检索增强生成）里，这些并不存在。这个标准范式就是一个无状态的查找工具。它非常擅长“找到东西”，却非常不擅长“构建理解”。一些高级方案会外挂记忆层、摘要缓存、agentic retrieval 等，但大多数人当下的默认体验仍是“搜完即忘”。
换个比喻。你雇了个研究助理。每天早上 TA 来上班，完全不记得昨天的事。你指给 TA 一些文档，TA 读完、答复你的问题，然后下班把一切都忘掉。你现在花钱买到的就是这个。
Wiki 范式：一种不同的心智模型
转变很微妙，但意义巨大。别再让 AI 只“检索信息”，而是让它“维护一座知识库”。
当一份新文档到来时，AI 不只是给它建索引。它会阅读原文、识别关键实体、找到与现有页面的连接、标记与既有认知的矛盾点，并更新相关的 wiki 页面。产出是一整夹层的 Markdown 文件，页面之间用 [[wikilinks]] 互相连接，分门别类，并带有完整的引用线索回溯到原始来源。
复利效应正是要点。你的第十份文档不只是“再加 10% 信息”。它会与前九份交叉引用，生成新的连接，暴露你此前没注意到的矛盾。
放大来看：知识库不再是被动的文件夹，而是一件被持续维护的“作品”。AI 不只是基于你的笔记来回答，而是在持续把这些笔记塑造成更可查询、更相互关联、也更有用的结构——超出你个人精力所能维护的上限。
这一步转变，就是全部的关键。
架构到底如何运作
nashsu/llm_wiki 实现分三层。理解这三层很重要，因为即使不用这款应用，你也能借鉴它的结构。
ground truth 层：就是你的原始文件。PDF、Word、表格、网页剪藏。AI 被禁止修改这里的任何内容，只读。这是你的审计追踪。 综合层（synthesized layer）：AI 的工作区。一个按子目录组织的 Markdown 文件夹，比如 entities/、concepts/、sources/、synthesis/。AI 会创建、编辑、互相链接这些页面，并在新信息到来时进行更新。 监管层（regulatory layer）：两份治理一切的文件：schema.md 定义格式规则，purpose.md 定义这座 wiki 存在的目的。后者常被忽略，却是让整个系统运转的关键。
purpose.md 在实践中的作用是这样的：假设你研究的是 AI 安全政策。没有 purpose 文件，AI 也许会“尽职尽责”地从每篇论文里抽取方方面面，包括几十条与主题无关的机器学习架构细节和公司组织架构。若 purpose 文件写着“我只关心欧盟对前沿模型（frontier model）部署的监管框架”，AI 就会强力过滤，知道什么该忽略。
这个单一的设计选择，解决了大多数自动化研究流程的信噪比难题。
为何“两步式摄取”至关重要
系统处理一份新文档时，并不是把文件一股脑丢给 AI 让它直接出结果，而是拆成两次独立的 API 调用。
第一次调用纯分析。AI 会结合文档本身、purpose 文件和现有索引，产出结构化分析：有哪些实体？主要论点是什么？与现有 wiki 哪些地方矛盾？哪些需要新建页面，哪些要更新既有页面？此时不产出最终文件，只“思考”。
第二次调用把这份分析当作蓝图，生成真正的 Markdown 页面。
这种解耦很关键，因为语言模型一口气做两类认知任务时臭名昭著地不稳。你让模型同时“分析文档”并“产出严格格式的结果（含规范的 YAML frontmatter 与一致的 wikilinks）”，基本就是在求它翻车。拆分任务能显著减少格式错误和语义漂移。
这个启示不止适用于这款应用。你可以把它用到任何 AI 工作流里：不要在同一个 prompt 里同时要“分析”和“最终交付”。先要分析，审阅通过后，再要交付品。质量会立刻跃升。
知识图谱才是“疯狂”的地方
当你拥有一座互联的 Markdown wiki 后，你可以在其上做图分析。应用用一个“四信号相关性模型”来计算任意两个概念的关联度：
Source overlap 权重 4.0（共享来源文档的概念） Direct links 权重 3.0（页面之间存在显式 [[wikilinks]]） Adamic-Adar index 权重 1.5（在网络中共享邻居的概念） Type affinity 权重 1.0（同类别的概念）
在此基础上，系统能把相关页面聚成主题“邻域”，给你一张可视化地图，显示你的知识在哪些地方密集、稀疏，或是怪异地彼此脱节。这是杀手级能力，值得放慢脚步体会：系统可以自动发现“知识缺口”——两簇相关概念之间没有连接；一个孤儿节点不连向任何页面；某个主题相较其邻域明显发育不足。随后它会触发“Deep Research”模块，调用 Tavily API，围绕主题发起多轮搜索、抓取结果，并把新发现摄取进来补齐缺口。
这座 wiki 能告诉你“它不知道什么”。然后在你确认后，它还能去研究这个缺口，再把结果带回你的知识库里。
真实的局限
在告诉你怎么用之前，我要先说明这个方法的边界。三点很重要。
AI 维护 wiki，也可能维护“错误”。会出现幻觉式的实体页面、杜撰的关联、自信但错误的摘要。这个模式只在以下前提下可用：原始来源不可变更；每条论断都能回溯到来源引用；含糊不清的更新交给人工审核。wiki 应该成为你的“思考层”，而不是“真相来源”。阅读综合页面时，原始文件就在旁边，重要之处请回查。 这不便宜。两步式摄取对准确性很棒，但 token 成本高。处理一份 30 页的 PDF，需要阅读、生成分析、再生成最终 Markdown；在前沿模型上可能意味着每个来源消耗成千上万 token。如果你用 API key，请做好预算；若成本敏感，可以用 Ollama 搭配合适的开源模型在本地运行。 模型在这项任务上的差异巨大。严格的 Markdown 格式、YAML frontmatter、一致的 wikilinks，都需要强结构化纪律性，小模型或老模型常常搞砸。我的经验是：Claude Sonnet、GPT-4 级别模型，以及较大的 DeepSeek 与 Qwen 表现不错；更便宜或更老的模型容易漂移、幻连或破坏 schema，而你往往在 wiki 已被腐蚀后才发现。[在大规模导入前，请针对你的具体模型进行验证。]
这些不是放弃此模式的理由，而是要更审慎地使用它的理由。
如何今天就用起来
按你的技术熟练度，有三条路径。
简单路径：在 Obsidian 里“模拟”这套模式。你不会拥有自动化、图打分、剪藏管线或摄取队列，但今天就能借用心智模型。新建一个 Obsidian 库（vault），添加 sources/、entities/、concepts/、synthesis/ 等文件夹。写好 purpose.md 说明你的研究目标。然后用任一 AI（Claude、ChatGPT、Gemini）逐个处理文档：粘贴文档和 purpose 文件，请 AI 抽取实体、识别与现有页面的连接，并写出带 [[wikilinks]] 的摘要。把输出存为 Markdown。一个月内你就会拥有一座“真”的知识库，也能判断是否值得安装完整应用。
这个手工法在 wiki 规模较小时最好用。Karpathy 本人的 gist 指出：基于索引的模式在中等规模（约百来个来源、几百个页面）仍能稳住；超过这个量级后，LLM 的上下文容不下整个索引，你就会需要真正的搜索、embedding，或是这款完整应用。
中间路径：直接跑应用。若想要完整体验，到 GitHub 安装 nashsu/llm_wiki。它为 Mac/Windows/Linux 提供了预编译二进制。项目更新很快，直到 2026 年 4–5 月都有新版本。你需要 OpenAI、Anthropic 或 Google 的 API key；或选择完全本地用 Ollama 跑到“零数据泄露”。Chrome 扩展能一键剪藏网页，通过本地 API 直接进入摄取管线；两步式摄取会自动运行；内置知识图谱可视化。
进阶路径：借鉴这些模式。如果你会写点代码，架构性模式才是最有价值的资产：purpose 文件、schema 文件、两步式摄取；用文件哈希或缓存避免重复处理未变更来源；用持久化队列提升韧性；用异步审核系统把含糊数据交给人，而不是让模型凭空瞎补。任何语言、任何 AI 供应商都能实现这些。护城河在“模式”，不在“具体工具”。
无论选哪条路，每隔几周安排一次维护巡检。应用把这叫做“linting”。手工做就是请 AI 扫描：孤儿页面、失效 wikilinks、页面间的矛盾，以及被新来源推翻的陈旧主张。没有这道工序，再好的知识库也会在几个月内腐化成半真半假的笔记坟场。
你真正该带走的
当下大多数 AI 提效建议都在讲“更好的提示词”：更好的 prompt、更好的示例、更好的 few-shot 设置。这些有用，但它们优化错了层级。
更大的杠杆在 AI 周边的架构：信息如何进来？如何存储？如何随时间累积？如何维护？
Wiki 范式对这些问题给出了一个靠谱答案，也是少数把 AI 当“长期协作者”而非“反复重启的搜索引擎”的设计。
从小处开始。选一个研究项目。建一个文件夹，放三个子文件夹，再写一个 purpose 文件。用你手头可用的任意 AI，一次处理一份文档。看看把你的思考外化成一座结构化、互联的知识库，会不会改变你对这个主题的理解方式。
我猜会的。这个方法之所以有效，其实与 AI 本身关系不大——关键在于把你的思考结构外化到一个可以生长的地方。
AI 只是把这份“簿记”变得足够便宜，于是你终于会真的去做。
如果你觉得这篇拆解有用，我会定期写 AI 基础设施、Agentic 系统，以及正在塑造 AI 构建方式的工具。关注我，获取更多关于关键模型与框架的实用深挖。
链接：
仓库：github.com/nashsu/llm_wiki
Andrej Karpathy 的原始 LLM Wiki gist：gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
两份 README 都异常写得好——就算你不打算安装，也值得一读。
