企业官网建设流程全解析

我自己搭了快两年的个人知识库，中间换过文件夹、换过笔记软件、也跟风上过RAG，说实话折腾下来最深刻的感受是：工具选得再花哨，不如先把“知识到底怎么被组织起来”这件事想清楚。

这几天看到Karpathy公开说RAG不是个人知识库的最优解，LLM Wiki才是，我第一反应不是赞同或不赞同，而是想起自己拿RAG搭知识库时踩过的那些坑。RAG这个名字听起来很唬人，但放到个人场景里，它的问题其实特别具体。如果你也在用RAG管个人笔记、或者在纠结知识库到底该用什么方案，这篇文章值得你花十分钟看完。

1. 为什么RAG在个人知识库场景里水土不服

先说清楚一个前提：RAG本身不差，它的问题不在技术上，而在适用场景上。RAG全称是检索增强生成，核心思路是先把你想要回答的问题转成向量，去向量库里找最相似的文本片段，再把找到的片段塞进大模型的上下文里，让模型基于这些内容来生成答案。这个流程在“大规模企业文档问答”里是成立的，因为企业文档动辄几十万份，确有高效召回的需求。但对个人知识库这种通常只有几百个文件、甚至几十个Markdown笔记的场景来说，RAG有个非常尴尬的地方：它把简单问题做复杂了。

我自己的经验是，个人知识库的规模一般在几十MB到几百MB之间，拆分出来的文本块撑死几千个。几千个向量库，用倒排索引甚至直接暴力扫描都能秒级返回，根本不需要上向量检索。可RAG的常规流程要求你先做文本清洗、分块、嵌入、建索引、调检索参数，每一步都有坑。比如分块大小就是玄学：分大了，检索出来的块里有大量无关内容，模型生成时容易被带偏；分小了，语义不完整，召回的片段前言不搭后语。我最初设置512字符一块，检索效果稀碎，调到1024字符又发现块数太多、互相重叠，照样影响准确率。前后折腾了两周，才勉强让问答效果能用。

比工程复杂度更要命的是RAG的“检索即一切”思路，在个人知识场景里会放大一个隐患：模型会一本正经地用它检索到的片段来回答你，哪怕这个片段本身是错的。我做过一次实验，让RAG系统回答“MySQL索引失效的几种典型场景”，它抓取到的笔记里有条内容是我早期记录的、后来发现结论不准确的一段笔记，系统直接顺着这个错误结论往下编，还给我补了几个根本不存在的“官方建议”。所以从那之后我对RAG的输出基本都要二次验证，时间成本反而比直接搜原文还高。

RAG还有一个看不见的问题——它割裂了知识之间的关系。个人知识库最大的价值不在单个文件，而在文件之间的连接。你可能会在A笔记里提到某篇文章的思路，在B笔记里记录了这个思路的延展实验，在C笔记里总结了对这个实验的反思。这三个文件之间是有逻辑链条的，可RAG只会按相似度把片段抓出来，它不理解这条链，也不会帮你把链补齐。结果就是，你以为自己在和知识库对话，其实面对的是一堆被切成碎片的表格。

用一句生活类比来说：RAG像搜索引擎，你问一句它给你一页结果；LLM Wiki更像一个私人数码图书馆管理员，他提前把书分类整理、做了摘要卡片，还把相关书籍放在相邻的书架上。你要什么，他指给你看，而不是把几页复印纸塞给你自己拼。

2. LLM Wiki到底在解决什么问题

Karpathy提出的LLM Wiki，本质上是对“个人知识库应该长什么样”这个问题的重新回答。它不再把知识库当成一个“可以提问的数据库”，而是把它当成一个“可以阅读的Wiki站点”。用大模型把杂乱笔记整理成互相关联的页面，每个页面有清晰的主题、有摘要、有到相关页面的链接，你自己就能直接读懂这个Wiki，甚至在阅读的过程中发现新的知识连接。这个定位的变化，我举双手赞成。

LLM Wiki这个名字里有两个关键词：LLM和Wiki。LLM负责的是“归纳和压缩”，Wiki负责的是“结构和链接”。它和传统笔记软件的根本差异在于：普通笔记软件要你手动维护目录和标签，LLM Wiki则让你用自然语言描述知识的组织和关联方式，由大模型来完成内容清洗、摘要生成、主题聚类和链接建立。语言描述能力和上下文理解能力越强的模型，能建出的Wiki就越聪明。

我理解Karpathy的思路，他把个人知识库的使用方式倒过来了：RAG是“先存进去，用时检索”，LLM Wiki是“先归纳整理，平时直接浏览、用时精确查找”。不要小看这个顺序调换，它解决了一个核心矛盾。知识库真正要被“检索”的频率其实很低，大多数时候你是在看、在回忆、在把旧知识和新知识做连接。RAG把主要精力都花在优化“检索”这个低频动作上，而LLM Wiki把精力花在“整理”和“展示”上，这恰恰是个人知识库最高频的需求。

我实测了一段时间后发现，LLM Wiki让我重新捡起了以前随手存下却再也想不起在哪的笔记。有个例子：我很久以前记录过一个关于Git rebase变基操作的心得，当时觉得没用就丢在了某个子文件夹里。后来有次做版本回退，想起自己好像写过相关笔记，但在RAG系统里问了好几个关键词都没检索到（估计是被分块切碎了），最后是用LLM Wiki的导航页一条条浏览时发现的。这个感受很直接——知识库的价值不在于能回答多少问题，而在于你的知识真的能被自己“看见”。

LLM Wiki还有一个隐性优势：它天然是可解释的。RAG给你一个答案，你很难判断这个答案是依据哪份资料生成的；LLM Wiki则像维基百科一样，每个页面都有它对应的原始来源，你可以直接点击跳转到原始笔记去验证。这种“可溯源”对人脑记忆的巩固非常重要，因为你在阅读Wiki页面时，看到的不是一段凭空生成的答案，而是你自己曾经输入过的知识被重新组织后的样子，你很容易回忆起当时记录时的情境和思路，知识就真正内化了。

3. LLM Wiki的搭建核心：大模型不是在检索，而是在整理

理解了LLM Wiki要解决的问题，接下来的问题是：它到底是怎么搭建起来的？这里我要把Karpathy方案中最精华的部分拆开来讲。LLM Wiki的构建并不是简单地把文件夹丢给大模型让它生成一个导航页，而是一个分步骤的自动化流程。关键不在于某个具体工具，而在于你对“大模型如何参与知识整理”的设计。

我当时的做法是这样：把所有原始笔记统一格式化为Markdown，然后按主题打包交给模型处理，处理分四个阶段。第一阶段是清洗，让模型把笔记中的重复内容、临时记录、无效链接去掉，输出一份干净版；第二阶段是生成摘要，让模型为每个独立文件生成一段两百字以内的概述，并提取5到10个关键标签；第三阶段是聚类，让模型基于摘要和标签把所有文件分组，每组对应一个Wiki主题页；第四阶段是建立链接，让模型找出各文件之间的引用关系，写入双向链接。

这四个阶段有一个共性：它们全部依赖大模型的理解能力，而不是关键词匹配或向量相似度。这就和RAG产生了本质区别。RAG是把笔记切成块、用向量表示相似度，检索时靠“空间距离”找到文本；LLM Wiki是大模型真正“读懂”笔记之后，用语义来组织文档结构。举个直观的例子：我有两篇笔记，一篇讲Docker网络配置，一篇讲微服务部署中的网络坑，两篇文章里“网络”这个词出现了很多次，但内容核心其实完全不同。RAG会把它们当成相似内容，LLM Wiki的聚类却能分清楚——第一篇关注容器网络的内部原理，第二篇关注跨服务调用的实际问题，它们该出现在不同的主题导航下。

让模型一次性处理几千个文件是不现实的，也是我没推荐的做法。我的经验是分批处理：每批只让模型读50个左右的笔记文件，生成阶段性摘要和索引。等全部批次处理完，再让模型汇总所有阶段摘要，生成最高层的导航页。这个分层归纳的思路很像人做读书笔记：先逐篇写摘要，再把摘要归类到主题，最后按主题写目录。模型在每一层上的工作都很轻，质量也更容易保证。

这里要特别强调链接这一步不可省略。我最初做LLM Wiki时偷懒，只让模型生成了主题导航，没有生成文件之间的互相链接。用了一周后发现，Wiki确实比RAG好用，但它像一个只有目录没有正文页码的图书馆，你知道某个主题下有哪些笔记，却不知道这篇笔记引用了哪篇、扩展了哪篇。后来补上双向链接之后，知识库才真正有了“网络”的感觉。我在阅读一篇关于日志采集的笔记时，系统能顺带指出，这里还关联了之前关于日志格式规范、以及后来的日志告警策略两篇笔记，我顺着链接一路读下去，一次就完成了整个日志知识链的复习。

如果你在搭建时不知道怎么提示模型生成链接，可以参考这句提示词模板：“请找出这些文件中相互关联的引用点，为每篇笔记推荐5到8条相关笔记的链接，并说明推荐理由。理由是帮助我理解它们之间的逻辑关系，而不是简单的内容相似。”这个提示词几乎适用于所有消费级大模型。

4. 比选工具更关键：个人知识库的LLM Wiki落地实操

很多朋友看到LLM Wiki的概念，第一反应是问我用什么工具软件。说实话，我前前后后试过不少开源和商业方案，有专门做本地知识库的，也有笔记软件自带AI插件的，但最终稳定使用下来的，是一个我自己拼出来的流程，核心并不是某个特定工具，而是“文本文件加提示词”的极简组合。这个部分我把实操细节完整写出来，你可以直接照着搭。

材料方面需要三样东西：一是所有笔记统一为Markdown格式，这是基础，如果有一部分是Word或PDF，提前转成纯文本；二是一个大模型入口，API或网页对话均可，实测下来网页对话完全够用；三是一个你熟悉的文件目录结构。我的目录设计一般是：根目录下有01_原始笔记、02_清洗笔记、03_Wiki页面三个文件夹，分别放未处理的笔记、清洗后的干净版、以及生成好的Wiki页面。这样原始文件与生成文件分离开，不会互相干扰。

第一步先将原始笔记分批次送入模型，让模型生成清洗版。这一步提示词要写清楚“保留原始结论和关键数据”，“不要主观添加你没有看到的细节”，“修正错别字但不要修改术语”。我刚开始没写清楚，模型自作主张给笔记内容做了大量扩写，甚至自己编了几个案例，这种“加戏”是LLM Wiki搭建中最需要防的一件事。

第二步和第三步可以合并处理：把清洗版文件列表和内容一次性发给模型，让它分批生成摘要与标签。摘要控制在200字左右，标签控制在5到10个。注意这里要求模型输出JSON格式，方便你下一步做自动化处理。如果你用API方式跑，这一步就能批量完成；如果是用网页版对话，那就一次粘贴几十篇笔记，让它逐篇生成，实测效率也可接受。

第四步是聚类和导航页生成。把每篇笔记的摘要在一次对话中发给模型，让它根据主题相似度分组，分组数量按笔记总量来定：几十篇就分5到10组，几百篇就分20到30组。每组起一个清晰的主题名，并撰写该主题的简介。然后让模型生成总导航页，导航页包含所有主题名和链接，这个页面就是你知识库的入口。

第五步建立双向链接，这是整个LLM Wiki最出彩也最容易被忽略的环节。做法是分批把每个主题下所有清洗笔记发给模型，让它挑出笔记中的关键概念和相关笔记标题，生成“相关笔记”的链接段。我还会额外让模型为几个重要主题写“综述页面”，把该主题下所有笔记的脉络打通，相当于给每个知识领域画了一张地图。这个过程比较耗时间，但收益也是最大的。

落地的工具选择上，我试过一条路径供你参考：本地用VSCode作为Wiki页面阅读器，配合Markdown文件预览；索引和链接的批量生成，用脚本调API完成；日常阅读直接在浏览器里打开生成的HTML版Wiki页面。这套方案的好处是所有文件都是纯文本，不会受限于某个软件的导出格式，只要你的文件不乱删，知识库就一直可用。

不过我不建议一上来就搞自动化脚本。第一次搭建时，我花了两周写了一套处理流程，最后发现还不如老老实实分批次手工操作来得快。原因很简单，个人知识库的文件量级根本支撑不起复杂的自动化设计，手工操作看起来朴素，但你能在过程中持续观察模型输出的质量，随时调整提示词。等你跑通了一遍、清楚哪些环节容易出错之后，再考虑脚本化，节奏会顺很多。

5. 常见问题与排查实录：我踩过的那些LLM Wiki坑

测试LLM Wiki的过程中，我总结了一堆问题，干脆整理成一张速查表，遇到问题直接对照排查。

最有代表性的坑是我自己踩过的“摘要扩写”问题。第一次跑模型清理笔记时，我发现生成的清洗版里多了一段我没有写过的“背景介绍”，读起来还挺流畅，要不是我对自己的笔记内容熟到每个段落都记得，根本发现不了这段是模型编的。这个坑的教训是，个人知识库的LLM Wiki流程中，你一定要把人放在审核链路上，任何模型生成的内容都要抽查原文比对。模型生成的内容和你自己输入的原始内容一旦混淆，整个知识库的可信度就崩塌了。把清洗版和原始版同时保留，就是为了这件事兜底。

另外一个真实感受是“更新比搭建更考验耐力”。初次搭建LLM Wiki的时候很有新鲜感，每天都有新的页面和链接生成出来，成就感拉满。但两周之后新鲜劲过了，新笔记不断产生，旧页面需要更新，如果没有固定的更新节奏，Wiki很快就会过时。我的解法是把更新频率设定为每周一次，周日花20分钟把当周产生的笔记批量处理，生成增量摘要，然后让模型检查已有导航页是否需要补充或修订。实测下来，20分钟足够维护一个几百篇笔记规模的Wiki。关键是不要天天更新，批量处理的效率远超实时处理。

还有一个值得注意的坑是关于隐私和安全的。个人笔记里往往包含大量不该外传的信息，比如账号线索、家庭安排、公司内部数据等。如果使用云端大模型的API或者网页对话，要做好脱敏处理。我的习惯是把笔记里的具体账号信息替换成占位符，等模型处理完再替换回来；涉及敏感话题的笔记，宁可不进入Wiki。这一点比起RAG反而更值得警惕，因为RAG只是切块检索，而LLM Wiki会让模型完整阅读你的笔记，数据暴露面更大。

用云服务处理前，先建一个脱敏清单，把里面的个人敏感字段一键替换成无意义代号，跑完再替换回来。这个操作看上去多了一道工序，实际耗时不到两分钟，却能避免90%以上的隐私风险。

6. 一个被忽略的扩展用法：让Wiki反向帮你思考

写到这，其实LLM Wiki的搭建已经基本讲完了。但我想花一点篇幅说说LLM Wiki更深层的用法，因为只把它当“知识索引工具”有些浪费，它在辅助思考方面有RAG完全做不到的价值。

我做过一个比较有意思的尝试：让模型基于我的Wiki页面生成一份“知识盲区报告”。做法是把所有主题导航页和相关笔记摘要发给模型，提示它找出我记录较少但在逻辑上很重要的主题，以及各主题之间缺失的连接。结果模型指出，我关于“数据库索引”的笔记很多，但“索引与查询优化之间的映射关系”没怎么记录；关于“缓存策略”的笔记很全，但“缓存一致性问题的实际案例”是空白。这些盲区是我自己看导航页时很难一眼发现的，模型却能把它们结构化地呈现出来。

还有个用法是让Wiki变成“写作素材库”。我写技术博客时，经常需要回顾某一条知识线的完整来龙去脉，以前需要翻十几篇笔记才能理清，现在直接在Wiki的主题页上看综述，再顺着链接抽查具体笔记，效率高了好几倍。有一次我写一篇日志系统的架构解析，直接引用Wiki中“日志采集、格式化、传输、存储、展示”五个主题页的综述，两个小时就完成了初稿。

这类用法说明，LLM Wiki的价值不光是“把旧知识整理好”，更是“让旧知识产生新连接”。RAG的定位永远是“被动应答”，你问它才答；LLM Wiki的定位是“主动呈现”，它会让你看到自己知识结构中的空隙、冗余和潜在关联。当你把一个领域比较完整地Wiki化之后，再去学这个领域的新东西，就有了一个清晰的“挂载点”，新知识不再是孤零零的笔记，而是挂在这个Wiki语义网络上的邻居节点，记忆会牢固很多。

我个人现在的新习惯是，每个月末把自己一个月内新学的主题和已有Wiki导航对比一次，看哪些主题扩张了、哪些主题停滞了、哪些主题之间开始出现新的关联。这种事如果靠RAG来做，它只能告诉你“哪两篇文档内容接近”，而LLM Wiki能让你真正反思“这一个月的学习方向和重心是否合理”。这种自上而下的知识体检，是工具层面最有价值的东西。

回到Karpathy那句判断，我现在基本认同他把LLM Wiki当作个人知识库的正确方向。不过我更倾向于把它理解成一种理念而不是某个具体工具：大模型不该用来“检索”你的笔记，而该用来“阅读并重写”你的笔记，让它们变成一种能被你自己舒服浏览、理解、连接的结构。如果你正在被RAG的检索效果折磨，或者苦于笔记越记越多、却越来越不想翻看，真心建议你花一个周末，把自己的几十篇核心笔记洗成一个小Wiki，跑一遍整个流程。你大概率会发现，知识库这回事，真正让人舒服的形态不是“有问必答”，而是“一目了然”，这个转变只有亲自做完才体会得到。