Karpathy 提出的 LLM Wiki 模式，是把 LLM 的角色从单一的"检索员"升级为可自我进化的知识伙伴——它是你的总编辑、知识库管理员、领域专家、决策顾问。
知识在每次使用中被理解、关联、抽象、沉淀，形成一个会自我复利的长期资产，而不是每次查询都从零重拼。
这篇文章是在实践中写出来的：用 LLM Wiki 这套方法，蒸馏了三份讲 LLM Wiki 的素材——Karpathy 的原始想法、两个 GitHub 公开实现、一份企业落地方案——再基于蒸馏出的结构化 wiki 写成本文。文章自身就是这个模式的产出物，也是对它的一次自证。
LLM wiki的蜕变：不只是帮你翻书
LLM Wiki 是让 AI 把书、文档读完、写成笔记、替你一直维护，还能在你“失忆”时提醒"这个决定三个月前讨论过，当时结论是……"
LLM 核心在做四件事：
- 编辑——新素材进来，拆文件、起名字、改所有交叉引用。人工维护繁琐、易错，但它不会累、不会漏。
- 知识库管理员——边读边判断：这份材料合进哪篇、还是新开一页？跟上周那篇是不是打架？某个概念被提了八次却没有自己的页，补一条。
- 领域专家——素材攒够了它开始看出模式。"你这三个项目的卡点其实是同一个"、"那个两年前的结论已经被最近的素材推翻了"——这活以前只有读完全部材料的老法师能干，老法师最贵的就是时间。
- 决策顾问——你问"要不要做 X"，它不讲 X 是什么，它告诉你"这事我们半年前讨论过、当时因为 A 原因否了、现在 B 条件变了、所以要不要重开"。这不是通用建议，是你自己的知识库在给你建议。
过去这四个活分属四个岗位，彼此还不通气——实习生整理的没洞察，分析师有洞察但没时间整理，顾问给完建议就走。组织里最常见的结局是：要么只干了前两层（一个勉强能用的文档库），要么临时找人做后两层（出份报告然后归档吃灰） 。
LLM 的厉害之处不在某一层格外强，而在一个人把四层的活都干了，边际成本还近乎为零。第一百次摄入它不会变笨，第一千次查询它也不会变贵。
复利真正的来源就在这里——不是笔记整齐（那只是地基），而是每一次判断、每一次洞察、每一次建议都被留下来，变成下次的起点。
Karpathy 的贡献不是发明算法，是指出 LLM 今天已经能同时扛这四个岗位，而我们之前只拿它切菜。这是分工的事，不是技术的事。
你大概已经被"AI 知识库"坑过了
回想下这样的场景：
你给公司内部 AI 助手喂了 500 份产品文档，想让它回答"为什么我们去年把会员体系从积分制改成了等级制"。
你得到的是：一段流畅但空洞的复述。AI 找到了几份相关文档的片段，拼成了一个看起来合理的答案，但关键的那个"为什么"——当时的市场环境、三选一对比的另外两个方案、CEO 在某次会议上说了什么——永远不在文档里。
下一次同事问同样的问题，AI 还会从头再走一遍这个徒劳的流程。一个月后你问它，答案可能还会变——因为它从来没真正"记住"什么。这就是 RAG（Retrieval-Augmented Generation，检索增强生成）的天花板，也是 NotebookLM、ChatGPT 文件问答、大多数企业 AI 助手共同的问题：它们擅长"翻书"，不擅长"做笔记"。
而不擅长"做笔记"的代价是什么？知识不能复利。
复利意味着：你每增加一份材料、每问一个问题，整个知识库应该比上一秒更厚、更互联、更不容易被同类问题再次卡住。RAG 不复利——加第 500 份材料和加第 5 份材料给系统带来的"智慧增量"几乎一样薄。传统人工 wiki 理论上能复利，但维护成本指数级涨，99% 的公司 wiki、个人 wiki 都死在这个环节——不是没人读，是没人愿意维护。
Karpathy 用一句话点出了这个两难的出口：
"LLM 写并维护 wiki，人负责读和提问。"
这是 LLM Wiki 模式的全部——不是让 AI 更会检索，而是重新分工。把写、维护、交叉引用这些"簿记"活交给不会累的 LLM，人只做真正需要判断力的事：挑素材、提问题、审方向。
有团队基于数十篇文档和十道测试题做过三个方案的横向评估（LLM Wiki、精排型检索、快速型 RAG），最后选了 LLM Wiki，理由一句话： "知识管理体系的能力 > 查询速度" 。快 20 秒不如能答出"为什么当初这么决定"——这正是本文要展开的核心判断。
构建知识就像做菜：治大国如烹小鲜
抛开术语，LLM Wiki 的结构就是任何一个认真做读书笔记的人都熟悉的那套——食材、菜、菜谱，外加一个负责做饭的厨师。
| 这个模式里的部分 | 类比 | 说明 |
|---|---|---|
| raw/ （原始素材） | 食材柜 | 你收集的文章、会议记录、PDF。只读不改。 |
| wiki/ （蒸馏笔记） | 做好的菜 | AI 生成的结构化笔记：人物页、概念页、决策页。AI 全权拥有，你只读不写。 |
| schema（规则文件） | 菜谱 | 一份告诉 AI "这个 wiki 怎么组织、哪些字段必须有、什么情况下开新页" 的配置文档。 |
| LLM | 厨师 | 每次你加新食材，它就调整一次菜。 |
然后围绕这三层发生三种操作：
- Ingest（摄入） ：扔一份新素材进来，LLM 读完，更新所有受影响的 wiki 页面（一份材料可能同时改 10-15 页），刷新索引，追加日志。
- Query（查询） ：问个问题，LLM 先读索引决定去哪查，钻到相关页面，带引用合成答案。这里有个关键细节——好的查询答案可以归档回 wiki 变成新页面，这意味着你的提问本身也能让 wiki 变厚。
- Lint（质检） ：定期体检——找矛盾、找过时信息、找孤岛页面、找被频繁提及但没独立页的概念。能自动修的自动修，需要人判断的报给你。
两个特殊文件把整个 wiki 串起来：index.md 是目录（LLM 每次查询都先读它），log.md 是时间线（每次 ingest/query/lint 都记一行）。Karpathy 给出了一个反直觉的经验值：在中等规模下（约 100 份素材、几百页），光靠 index.md 做导航就够用——你根本不需要向量数据库、不需要 embedding 基础设施。这一点后面会再回来讨论。
复利是怎么发生的
这是本文最核心的判断。为什么维护一个结构化知识库的价值，会胜过让查询快 20 秒？
因为真实场景里的高价值问题，答案本身从来不是瓶颈。瓶颈是答案背后的"链路"和"结构"——而这两样恰恰是 RAG 拿不出来的。
复利的三种具体形态
LLM Wiki 的复利是三种具体、可度量的增量：
① 决策链路的复利
问一个 RAG 常见的失败问题："为什么产品 V3 把推送时间从晚上 9 点改到 8 点？"
- RAG 答："V3 在某日上线，调整了推送时间。" —— 正确但无用。
- LLM Wiki 答："因为 9 点推送太晚、用户已下线或不看消息，导致日报沦为'次日看'。核心矛盾：日报的价值在驱动行动，不是信息归档。所以整体节奏调整为 7 点会议提醒 → 7:30 风险提醒 → 8 点日报推送。" —— 这是知识，不是查找。
差别在哪里？ 决策链路——"背景、选项、决定、理由"——从来不写在任何一份原始文档里。它散落在当时的会议口头对话、讨论、改版前后的对比里。RAG 无法重建这种东西。LLM Wiki 把它做成独立的 decisions/ 页，让它成为一等公民。
每做一个决策，decisions/ 就多一页。这是不会丢、不会被重复追问的知识积累。
② 跨域关联的复利
问："产品 A 的某个功能和产品 B 的定位战略是什么关系？"
RAG 会给你两份文档片段，让你自己连。LLM Wiki 通过 wikilinks 双向链接把相关页面串成图——你打开 A 的页面会看到 "被引用于：产品 B 战略"，反之亦然。每一次新摄入都在自动织网。成熟的实现（比如后面要讲的桌面应用版）甚至能自动做社区检测，发现"哪些页面形成了一个紧密关联的知识簇"，"哪些页面是桥节点，连接了不同领域"。
这种关联密度就是复利的第二个维度。RAG 是一堆独立的原子，LLM Wiki 是一张越织越密的网。
③ 高频查询的复利
新人入职问过的问题、老员工反复查的问题，LLM Wiki 会把答案归档成 queries/ 页面——下次同样问题直接命中已归档答案，不用再检索。问题本身也沉淀成了知识。
RAG 不做这件事，每次问都要重新走全流程。一百次相同问题，就是一百次重复劳动。
Karpathy 的贡献：不是发明算法，是指出分工
这个模式追溯到 Vannevar Bush 在 1945 年提出的 Memex 构想——一个个人的、主动整理的知识库，文档之间的关联和文档本身一样重要。Bush 的愿景一直没能实现，不是因为存储不够、界面不好，是因为没人能承受"持续整理"的维护成本。80 年过去了，所有想做"第二大脑"的工具都死在这个坎上。
Karpathy 的贡献不是技术层面的——他没有发明新算法。他指出的是一件更简单但更根本的事：LLM 在今天已经足够胜任"持续整理"这份工作，而我们之前都只把它当成"检索员"在用。
这是分工的变化，不是算法的变化。但它足以让 80 年前的 Memex 构想第一次真正落地。
同一个理念，两种迥异的实现
Karpathy 的原始想法只有 76 行 markdown，明确写： "这是一个想法文件，不是某种特定实现。" 所以不同人长出来的东西可以差非常远。GitHub 上目前两份公开实现，正好站在产品谱系的两端。
实现 A：一份提示词（Agent Skill 版）
整个"产品"就是一份约 200 行的规则文件 + 四份模板。安装后，任何兼容 Agent Skills 协议（一种让 AI agent 加载可复用能力包的开放规范）的 AI 工具都能调用它。没有代码、没有数据库、没有服务端——它只是一份写给 LLM 的操作说明书。
这种实现的美在于它拥抱了"模式而非产品"的本意。你的 wiki 就是一个 markdown 目录，能 git 管理、能用 Obsidian 打开、能 diff，没有任何厂商锁定。缺点是获取能力完全交给宿主 agent：能不能读 PDF、能不能抓网页，取决于 agent 自身的能力。
实现 B：一个完整桌面应用
同样从那 76 行读出来的，是一个桌面应用，带知识图谱可视化（节点可视化 + 自动社区检测）、可选的向量检索（增强语义召回）、浏览器网页剪藏扩展、多格式文档抽取（PDF/DOCX/PPTX/XLSX）、自动联网研究管线。它还在原模式之外加了几个重要概念：
- 两步 CoT ingest（Chain-of-Thought，思维链）——先分析再生成两次 LLM 调用，成本高但产出质量明显更好。
-
purpose.md——一份描述"这个 wiki 为什么而建"的元文件。LLM 每次操作前都会读一遍，有了方向感，不会越帮越乱。
它的立场是：要跑几百到上千页的严肃 wiki，只靠提示词不够，需要基础设施。
关注公众号发送：知识库，即可获取相关信息
两种实现的软性分歧
原始想法里说"中等规模下 index.md 就够用，不需要向量检索"。桌面应用加了向量检索，并声称召回率能从约 58% 提升到约 71% 。这算矛盾吗？不算。它是一种规模分界：
- 100 份素材以下：提示词版足够，向量检索是过度设计。
- 500 份素材以上：向量检索明显有价值。
- 中间地带：取决于你的问题偏"结构理解"还是"关键词检索"。前者 Karpathy 对（结构足够），后者桌面版对（召回更重要）。
我的倾向：先不开向量检索，跑够 100 份素材再评估要不要加。过早优化是软件工程的经典陷阱，知识库领域同样适用。
什么时候选哪个
- skill版——wiki 预计 < 100 份素材、想零安装零进程、wiki 和代码一起管理、你用的 AI agent 已有足够强的获取工具。
- 桌面应用——wiki 预期上千页、需要图谱可视化、需要内建重格式文档抽取、希望知识库独立于编码环境。
两者都产出纯 markdown + 兼容 Obsidian，可以互相迁移——从提示词版起步，规模到瓶颈再切桌面应用继续。
从个人场景走进组织：三个真正重要的扩展
个人场景之外，这个模式在实际团队里正在被改造落地。能被观察到的案例显示出一种很有启发的方向——它们都在原模式基础上加了三类东西：
扩展 ① 三种新的 wiki 页面类型
-
decisions/（决策记录） —— 背景 / 选项 / 决定 / 理由，结构固定。前面讲过这是最具辨识度的能力。 -
comparisons/（变化点对比） —— 版本 A vs 版本 B、方案甲 vs 方案乙，让横向差异沉淀。 - 自定义 entity 类型 —— 按岗位职能预定义实体类型。比如产品经理场景预设"需求 / 功能 / 用户故事"，项目经理预设"项目 / 里程碑 / 风险"。
这三种类型补上了原模板不覆盖但产品化最容易缺的维度。
扩展 ② 权限模型
原模式假设单用户，没有权限概念。团队场景里这不可接受。可以考虑在 entity/topic 层打权限标签（比如 private/team/public），查询时先鉴权，有权才返回。相关摘要继承关联实体的权限。
一个实现细节值得指出：权限元数据可以打在 wiki 上，但真正的鉴权执行最好下沉到服务端。原因是 LLM 本身有不确定性，靠提示词控制权限不可靠。
扩展 ③ 一个明确的人工角色
原模式里"人"是模糊的使用者。团队场景需要一个明确的维护负责人——他负责所有素材的蒸馏入库、wiki 质量验收、内容持续更新。一个知识库一个人。
把这个职责锁给一个人，回避了一个棘手问题：多人向知识库贡献素材时，怎么保证质量一致性？MVP 阶段先走独人模式，未来可能演化成"AI 初审 + 人复核"。
落地案例的量级参考
观察到的一个试点案例：输入约 400 份原始材料（含产品文档、会议记录、内部讨论沉淀），产出约 90 页 wiki——十几页实体、近十页主题、十来条决策、少数对比页、五十来份材料摘要。整个试点节奏大约2周（从方案确定到实际推广）。
结尾：这篇文章本身就是证明
本文就是一次这个模式的验证。
素材：一份 Karpathy 原始想法的 gist、两个 GitHub 公开实现的文档、一份企业落地方案。
流程：把素材扔进 LLM Wiki skill（本文讲的第一种实现），蒸馏出 3 篇结构化 wiki 文章（模式总览 / 实现对比 / 企业扩展），再基于蒸馏出的 wiki 写成本文。
你刚才读的每一个判断、每一组对比表、每一条边界条件，都能从蒸馏出的 wiki 里直接溯源——如果你想追"本文里哪句话来自哪篇素材"，沿着 wiki 的引用链下去就是答案。
从一个 76 行的想法文档长出这些差异巨大却都忠于原意的实例，本身就是一个很 Karpathy 的证明——好的想法不需要规定实现，只需要说清楚分工。
而分工一旦清晰，复利就会自动发生。
以上就是 LLM Wiki 的完整解析，从底层逻辑到实现对比，再到企业落地的真实案例。
后续我会持续更新 LLM Wiki 的实战玩法、Schema 设计技巧和行业定制方案，感兴趣的可以点个关注，不迷路～
