LLM Wiki 个人知识库搭建教程

这期讲了什么

• LLM Wiki 是什么：Karpathy 提出的思路——原始资料放 raw 文件夹当源代码不直接改，能读写文件的 AI agent 当编译器，去维护一个建概念页、加反链、标矛盾的 Markdown wiki，Obsidian 浏览、Git 管版本可回滚
• 和 RAG 的区别：RAG 每次提问临时检索几段原文塞给模型，是临时抱佛脚；LLM Wiki 让 AI 当维护者而不是问答机器人，把资料持续编译成可复用的知识结构
• 为什么现在能在个人电脑上做：国产模型 API 价格低（每月几块到一两百元量级）、开源模型成熟、Ollama 和 LM Studio 这类本地推理工具成熟
• 两条路线：纯国产 API 零硬件门槛适合起步验证流程；本地部署适合资料敏感或每日大量编译的人——8B 做分类摘要、14B 做主力、32B 做复杂整合，别为 wiki 单独买顶级显卡
• 工具与防坑：字节的 Trae、阿里的通义灵码自带国产模型下载即用；Cherry Studio 的知识库本质是 RAG 不适合当维护者；第一周全开人工确认看 diff；编译指令必须含页面建设、来源保真、增量更新三层

文字稿

LLM Wiki 是什么：资料当源代码，大模型当编译器

你有没有这种感觉：收藏夹里几百篇文章、网盘里一堆 PDF、Obsidian 里也写过不少笔记，但每次真要写东西、做方案、查一个观点，还是重新开始——搜索、翻资料、问 AI 来一轮。这些知识好像被你存下来了，但从来没有真正长到你的系统里。今天就聊一个很适合解决这个问题的新模式：LLM Wiki。LLM 是大语言模型，Wiki 是像维基百科那样一页一页互相链接的知识库。

这个思路是 Karpathy 在 2026 年四月前后公开讨论过的，网上常见的总结是：把原始资料当源代码，LLM 当编译器，最后生成的 Markdown Wiki 当编译产物。注意这是思路和类比，不是逐字引用。它真正厉害的地方不是又多了一个笔记软件，而是把知识管理从人手动整理变成 AI 持续帮你编译。

和 RAG 的区别：维护者而不是问答机器人

传统 RAG，中文常翻成检索增强生成，白话讲就是你问一个问题，系统先去资料库搜几段相关原文，再塞给大模型让它回答。这当然有用，但有个问题：每次提问都是临时抱佛脚，今天问检索一次，明天问又检索一次，它没有真正把资料整理成一套长期可复用的知识结构。

LLM Wiki 换了个角度。原始资料放在 raw 文件夹里不直接改——文章、网页、论文、PDF、会议记录、随手笔记都行。然后让一个能读写本地文件的 AI agent 去读这些资料；agent 就是能连续做多步任务的 AI 助手，不只回答一句话，还能读文件、改文件、创建新文件、跑命令。它读完不是只给你一段总结，而是去维护一个 wiki 文件夹：建概念页、把相似主题归类、加反向链接、更新已有页面、标出资料之间的矛盾、写清来源。最后产出的是一堆纯 Markdown 文件，可以用 Obsidian 打开。Obsidian 在这里像 IDE，LLM 像程序员，wiki 像代码库，Git 负责版本控制——哪天 AI 把页面改坏了可以回滚。这个类比非常关键：资料不是仓库里的杂物，是源代码；知识库不是剪贴板，是编译产物。

为什么现在能做：国产 API、开源模型、本地工具

这套东西普通人真能在自己电脑上做吗？答案是现在比以前容易得多，原因有三个。第一，国产模型的 API 价格已经很低：DeepSeek、通义千问 Qwen、智谱 GLM、Kimi、MiniMax、豆包都有不同价位的接口，很多还兼容 OpenAI 格式，换一个 base URL 和 API key 就能接上。第二，国产开源模型成熟了：本地部署优先看 Qwen、DeepSeek、GLM 这些有开源或开放权重生态的模型，Kimi、MiniMax、豆包更多归类到便宜 API 那条路，具体版本能不能商用看当期官方页面。第三，本地推理工具成熟了：Ollama、LM Studio、llama.cpp 可以轻松在电脑上跑量化模型——量化就是把模型压缩一下，用更少内存跑，质量损失一点但门槛低很多。

落地先看两条路，别急着纠结要不要本地部署。路线 A 纯国产 API，零硬件门槛，最适合大多数人起步：电脑只负责存文件、跑 agent、打开 Obsidian，推理交给云端 API，不用买显卡不用折腾驱动。成本大致是：一个月编译几十到几百篇文章、几百万到一两千万 token，低价档通常几块到几十块人民币，大量用长上下文和旗舰模型可能几十到一两百。先用便宜模型做粗编译、再用强模型处理关键页面，性价比更高——第一阶段要验证的不是模型跑不跑得动，而是这套流程对你有没有用。

路线 B 本地部署开源模型，零边际成本还能保护隐私，适合两类人：资料敏感不希望出本机的，和每天都要编译大量资料的。核心工具是 Ollama（命令行）或 LM Studio（图形界面），底层多绕不开 llama.cpp；多用户高并发再考虑 vLLM，个人起步不建议一上来就 vLLM。模型选择：8B 左右适合分类、摘要、初稿页面，14B 综合质量明显更稳适合当主力，32B 适合复杂整合和冲突判断，70B 以上个人电脑能跑但慢且贵。硬件分档：零硬件档走纯 API，能跑 VS Code、终端、Obsidian 和 Git 就行，每月十几到几十块预算；入门本地档是 16G 到 32G 内存的 Mac 或 8G 到 16G 显存的显卡，8B 舒服、14B 量化可试但上下文开太长会慢，M4 Mac mini 官方起步几千元、M4 Pro 上万，RTX 4060 Ti 16G 或 RTX 4070 12G 适合入门；进阶档是 64G 以上统一内存的 Mac 或 24G 显存的消费卡，能舒服跑 14B、32B 量化，70B 可尝试但要接受慢。我的判断很直接：只是搭个人 LLM Wiki，别为它单独买顶级显卡，先 API 跑起来验证流程，真用起来再决定本地化。

用哪个工具当 agent 和最小目录结构

Karpathy 演示里用的是 Claude Code 这类国外工具，但咱们的需求很朴素：一个能用国产模型、又能直接读写电脑上 Markdown 文件的工具。你可能会问，我又不写代码，为什么要用编程工具？因为对这些工具来说 Markdown 跟代码文件是一回事，它们本来就是设计来打开一个文件夹、主动新建修改整理里面文件的——正好是我们要的让 AI 当维护者。

两个普通人下载就能上手的推荐：第一个是字节的 Trae，带图形界面、自带豆包模型，把整个 wiki 项目文件夹拖进去，用它的 agent 模式让它读 raw 里的资料去维护 wiki 页面；第二个是阿里的通义灵码，自带通义千问模型，玩法一样。很多国产模型兼容主流接口，这类工具基本都接得上。有个边界要说清：Cherry Studio 这种桌面 AI 客户端拿来问答很方便，但它的知识库默认是 RAG 那一套——切片检索，不是主动替你改 wiki 文件；想要让 AI 当维护者这个核心体验，还是建议先用能直接读写文件夹的编程工具。不管用哪个，第一次用一定开人工确认模式：让它每改一处先把前后对比（diff）摆给你看，你点了确认它才动手，不要让 agent 自动大批量改文件。

最小可用目录结构：项目根目录叫 my-wiki，里面三个核心文件夹——raw 放原始资料只追加不修改，wiki 放编译后的知识页，prompts 放编译指令，再加一个 SCHEMA 文件定义页面格式、标签、链接和来源规则。Obsidian 的 vault 建议指到整个项目但把 raw 当只读资料区。

编译指令怎么写和三条防幻觉铁律

很多人失败不是模型不行，是指令写成了「帮我总结一下」——那不叫 LLM Wiki，只是摘要。系统提示至少要含三层要求。第一，页面建设：根据资料创建或更新概念页，每页只讲一个核心概念、标题统一，页面里要有一句话定义、关键观点、适用场景、反例或误区、相关页面链接。第二，来源保真：每个关键事实标来源，必须区分原文事实（资料里明确写了）和 LLM 推断（模型综合后的判断），不分清楚 wiki 会越长越像幻觉合集。第三，增量更新：优先更新已有页面而不是每次重写整个 wiki，新资料和旧页面冲突不能偷偷覆盖，要在页面里加「冲突与待核实」小节。这步是命门——LLM Wiki 的价值不是第一次生成一堆漂亮页面，而是能持续维护、越用越整齐。

增量节奏建议：轻量资料随手编译，重资料攒一批再编译，因为知识库最怕被零散材料带偏，攒一批模型更容易看出共同主题。我的经验是每天随手丢 raw、每周做一次集中编译；编译前先 Git commit，编译后看 diff，满意再 commit。想更稳可以让 agent 先在 wiki-draft 文件夹生成草稿，确认后合并进 wiki。

防幻觉三条铁律：所有事实必须带来源，不写「研究表明」要写来自哪篇文章哪一页；模型不确定就写「资料不足，待核实」，不能装作知道；不要让模型改 raw——raw 是源代码是审计依据，wiki 可以被重构，raw 不能被污染。

几个坑和最小行动清单

LLM Wiki 跟普通知识库最大的区别，就是 AI 被放在维护者的位置上。以后你问问题，问的是自己的 wiki：答案更贴近你的资料边界，好答案还能回写进 wiki——比如你问完「哪几个 agent 工具最适合个人知识库」，可以让它新增一页选型页，把结论、证据、反例都写进去，知识就这样滚起来了。

几个坑：别一上来追求全自动，第一周一定半自动、看 diff 再合并；目录别太复杂，raw、wiki、prompts、SCHEMA 够了，分类是知识长出来后再重构的；别把 wiki 当聊天记录仓库，一页一个概念、有链接、来源可追溯才叫 wiki；别让本地小模型硬做复杂综合，小模型做初筛提取改格式，复杂判断交给更强的 API 模型——本地模型做粗活、国产 API 做细活，这就是高性价比方案。再往远看，Karpathy 这类思路更进一步是把个人 wiki 变成合成训练数据微调进模型权重，但对大多数人第一步不是微调，是先让资料变成持续生长的知识库。

最小行动清单：建文件夹 raw、wiki、prompts、SCHEMA；装好 Obsidian 初始化 Git；先走 API 路线，下载 Trae 或通义灵码用自带国产模型；丢 10 篇你真正关心的文章进 raw，让 agent 编译成第一批概念页。然后看一个问题：下次写东西做方案时，你会不会真的回到这个 wiki——会就值得继续投，不会就先别买显卡。LLM Wiki 的核心不是炫技，是把你散落的资料编译成一个会复利增长的个人知识系统。

常见问题

LLM Wiki 和 RAG 有什么区别？

RAG 是每次提问时临时检索几段原文塞给模型回答，不沉淀结构。LLM Wiki 让 AI agent 持续把 raw 里的资料编译成有概念页、反向链接和来源标注的 Markdown 知识库，AI 是维护者而不是问答机器人。

个人搭 LLM Wiki 需要什么工具？

最小组合是：一个能读写本地文件的 agent 工具（如字节的 Trae、阿里的通义灵码，自带国产模型）、Obsidian 负责浏览、Git 负责版本控制，外加 raw/wiki/prompts/SCHEMA 四个目录文件。

本地部署和用 API 怎么选？

先用国产模型 API 起步，每月几块到一两百元就能验证流程；资料敏感或每日编译量大再考虑本地部署——8B 模型做分类摘要、14B 当主力、32B 做复杂整合，16G 内存的 Mac 或 8G 显存的显卡即可入门。