企业官网建设流程全解析

先说结论：LLM-Wiki 是我目前在个人知识管理和大模型应用之间找到的最顺手的中间层。它不是什么新框架，也不是某个具体软件，而是一套思路——把散乱的知识库内容先“编译”成 Wiki 形态的语义网络，再把检索的主动权交给 LLM，让模型像人一样沿着链接和条目去查资料，而不是每次都在一堆碎片里做相似度匹配。这篇是总论，先把核心逻辑讲透，后续再拆具体实现。

1. 为什么传统知识库总是不顺手——存得进去，取不出来

1.1 知识库的“最后一公里”问题

我见过太多团队和个人把知识库搭起来了，Obsidian 里塞了几百个 MD 文件，Confluence 上堆了几千篇文档，Notion 里建了几十个数据库。但真到用的时候，要么搜不出来，要么搜出来的东西对不上问题。这不是工具的问题，是组织和检索方式的问题。

传统知识库的典型用法是“关键词匹配 + 人工浏览”。你记得文档里有“超时重试”这个词，你就去搜它；你不记得，就只能靠目录一层层翻。这种模式下，知识库本质上是一个“可搜索的文件夹”，它帮你把文件按目录放好，但不会帮你把知识之间的联系讲清楚。我的文档里有篇讲服务降级的，有篇讲熔断设计的，还有一篇讲超时配置的，它们散落在不同目录里，但它们其实是同一个问题的三个侧面。传统知识库不会主动告诉你这一点。

LLM 的出现改变了这个局面。模型能理解语义、能总结、能推理，但这也带来了一个新问题：模型本身没有记忆，它的知识截止在训练时刻，你的私有知识它一概不知。所以大家开始做 RAG，把文档切碎、向量化、存起来，查询时先检索再拼接给模型。这条路子方向是对的，但我用了很久之后发现一个尴尬之处：传统 RAG 的检索和阅读是分离的。检索是向量相似度说了算，阅读是 LLM 说了算，两边经常各说各话。

1.2 Wiki 是“最接近人类理解”的知识组织形式

维基百科之所以好用，不是因为它的词条写得多全面，而是因为它的组织方式符合人的认知习惯：一个主题一个页面，页面之间有明确的链接，开头有摘要，正文有分层结构。你要了解“JVM 内存模型”，你会先打开这个条目，看一眼概述，再按需点进“垃圾回收”或“堆内存分配”的链接，一层层读下去。

这种“节点 + 链接 + 摘要”的结构，其实特别适合让 LLM 来使用。LLM 的上下文窗口再大也是有限的，你不可能把几百篇文档一次性塞给它。但如果你把知识库编译成 Wiki 形态——每个主题一个条目，每个条目有摘要和正文，条目之间有明确的语义链接——LLM 就能像一个聪明的研究员一样，先看摘要，再决定点进哪个链接，像人浏览维基百科那样分步获取信息。

这就是 LLM-Wiki 的核心出发点：不要试图把知识塞进模型的上下文，而是把知识组织成模型可以自主导航的网络。

2. LLM-Wiki 的核心思路：编译与交权

2.1 “编译”知识库：从文本堆积到语义网络

这里我用“编译”这个词，是有意为之的。编译的本质是“从一种表达形式转换到另一种表达形式”，而且在这个过程中通常有信息结构的重组。把一个目录里散落的文档变成 Wiki 条目，不是简单的复制粘贴或格式转换，要做三件事：

第一，主题化重构。原始文档往往是按项目、按时间、按作者组织的，比如“2024年Q2技术总结”“张三的性能优化笔记”。但 Wiki 的条目是按主题组织的，比如“JVM 调优”“缓存一致性”“日志采集方案”。编译过程的第一步，就是把文档重新切分、归类，落到一个个主题条目下。这一步最费功夫，也最值得用 LLM 来做。

第二，链接建立。Wiki 的灵魂是链接。一个条目里提到另一个概念，就应该有对应的链接。比如“服务降级”条目里提到“熔断器”，那“熔断器”这三个字就应该指向它的专属条目。手工维护这种链接在文档少的时候还行，文档一多就完全顾不过来。LLM 非常擅长做这件事——它能在通读全文后判断哪些概念值得单独建条目，哪些地方该埋链接。

第三，摘要生成。每个条目的开头必须有一段 100 到 200 字的摘要，用几句话说清楚这个主题的核心结论、适用范围和关键注意事项。我自己的经验是，摘要的质量直接决定 LLM 检索的效率。模型在导航时，首先读到的就是摘要，如果摘要能准确概括条目内容，模型就能快速判断“这个条目不相关，不点进去”，省下大量的上下文空间。

2.2 把“检索权”交给 LLM：从工具调用的角度

传统的 RAG 流程是“用户提问 → 系统向量检索 → 拼接上下文 → 模型回答”。这个流程最大的问题在于，检索策略是预设死板的——固定取 top-k 个片段，固定的相似度阈值，没有中间过程，模型只能被动接受检索结果。

LLM-Wiki 的思路是把检索权直接交给 LLM 本身。具体来说，Wiki 系统暴露出几类“工具”：查看条目列表、读条目标题、读条目摘要、读正文某一段、查看条目之间的链接关系。LLM 在回答问题时，自己规划检索路径，自己决定第一步查什么，根据返回结果再决定下一步。

比如说，用户问“我们的支付服务最近老是超时，该怎么排查？”传统 RAG 会机械地把“支付服务”和“超时”相关的碎片全拎出来，不管它们是讲数据库的、讲网络层的还是讲配置的，一股脑塞给模型。LLM-Wiki 则会让模型先去查“支付服务架构”这个条目，读完摘要发现“超时可能和下游银行接口响应慢有关”，再顺着链接点进“外部接口超时处理”条目，再点进“重试机制与幂等设计”，最后综合这些信息给出回答。

这个区别本质上就是“被动喂料”和“主动觅食”的区别。让 LLM 自己控制检索路径，它就能根据实际返回内容动态调整，像人一样边看边想。实测下来的效果是，答案的完整性和准确性都有明显提升，尤其是面对跨领域、需要多步推理的问题时。

2.3 LLM-Wiki 与 RAG 的边界问题

我知道很多人看到这里会问：这不还是 RAG 吗？检索增强生成，本质没变吧？

我的理解是，LLM-Wiki 是 RAG 的一种更高阶的组织形态。传统 RAG 关注的是“怎么检索”，核心工作在向量化和索引上；LLM-Wiki 关注的是“检索什么”，核心工作在知识的结构化和导航设计上。你可以把向量检索当作 LLM-Wiki 底层的一种辅助手段，但真正的检索主路径应该是 Wiki 的链接导航，而不是向量相似度。

向量检索有一个天然缺陷：它只能找到“看起来像”的片段，却很难找到“逻辑相关”的内容。我在一个知识库里查“限流算法”，向量检索返回的是所有包含“限流”字样或语义相近的段落，但这些片段可能只是泛泛而谈，真正把“令牌桶”和“滑动窗口”实现细节讲清楚的关键内容，因为用词比较具体，反而排在后面。LLM-Wiki 的链接导航能解决这个问题，因为知识在编译阶段就已经被人或模型梳理过一遍，关系和路径是明确的，而不是靠相似度模糊匹配的。

当然，LLM-Wiki 也不会替代传统 RAG，两者互补。RAG 适合快速接入、结构不复杂、内容量偏大的场景；LLM-Wiki 适合追求回答质量、需要多步推理、知识之间关联关系强的场景。下面讲落地实操。

3. 落地路径：把知识库编译成 LLM-Wiki 的五步实操

3.1 第一步：清洗与分层——先给知识库“分桶”

不要急着让 LLM 开始编译。第一步一定是人工清理原始知识库，把垃圾扔出去，把黄金留下来。我踩过一个大坑：知识库里混着大量过时的产品文档、临时讨论记录和重复的内容，LLM 编译时根本分不清优先级，结果把一些已经废弃的配置方案编成了正统战法，差点误导后面的检索。

清洗我用的是“三层分桶”策略：第一层是“确定性知识”，比如接口文档、配置手册、流程规范，这层是知识库的骨架，内容相对稳定；第二层是“经验性知识”，比如排障记录、优化方案、复盘总结，这层有价值但表述往往比较随意，需要重写；第三层是“临时性信息”，比如某次会议的聊天摘要、某个版本的临时决策，这层要么删掉，要么归档到独立分区，不参与后续编译。

每一层在清洗时的处理方式也不同。确定性知识主要做格式归一化，统一标题层级、统一术语、统一代码块缩进；经验性知识要提炼核心结论，去掉废话和上下文依赖；临时性信息最简单，直接设个过期时间，半年后再看，没用了就清掉。清洗这一步听起来不酷，但它决定了整个 LLM-Wiki 的天花板。你扔进去的是垃圾，编译出来的必然是更大的垃圾。

3.2 第二步：主题化切片——“一个主题一个条目”

清洗完毕，接下来要做主题化切片。这个阶段要把一个个原始文档拆开、重新组合，形成独立的主题条目。判断“一个主题”的标准很简单：如果两个内容可以在不同的场景下被独立引用，它们就应该分属两个条目。

举个例子，我的知识库里有一篇很长的《支付系统重构实录》，里面既讲了架构演进，也讲了分库分表方案，还穿插着几个线上故障的复盘。按主题切分后，它至少应该变成“支付系统架构演进”“分库分表方案设计”“线上故障复盘：重复支付”“幂等性设计要点”这四个条目。每个条目都足够独立，但它们之间通过链接保持关联。

这一步可以人肉做，但效率太低。我建议用 LLM 辅助：把清洗后的文档分段输入模型，让它先给每个段落打上主题标签，再根据标签聚类成候选条目。模型给出的原始切分不一定准，但它的初稿能给人工审校省掉一半以上的时间。我自己常用的 prompt 大概是这样的：

请把以下文档内容按主题进行切分，输出为一个 JSON 数组。每个元素包含： - title：建议的条目名称（控制在 20 字以内） - summary：100 字左右的条目摘要 - content：该主题对应的正文内容，保留原有的代码块、列表和表格 - related_terms：本条目中提到的其他值得建条目的术语列表 要求： 1. 同一主题的内容必须聚合在一起，不按原文档顺序机械切分 2. 不同主题之间内容不能重叠 3. 如果一段内容横跨多个主题，以更主要的主题为准

切片完成后，你要做一次全面的人工审阅。重点看两处：一是条目的粒度是否合适，太细的条目（比如“某个常量的命名规则”）合并掉，太粗的条目（包含太多子主题）重新拆开；二是摘要是否准确，这条尤其重要，因为摘要就是条目在全库范围内的“索引”，写偏了，后续 LLM 导航时就会判断失误。

3.3 第三步：Wiki 化编译——自动建链、生成摘要

主题切片完成后，你手里已经有了一套结构化的条目库，但此时它还只是一堆孤立的条目，缺的是链接和层级。Wiki 化编译就是为了给这些条目装上“路标”。

这一步里，最耗时的是建链接。我的做法是让 LLM 读一遍全库条目索引和摘要，让它找出每一个条目中有价值的内链锚点。要提示模型，链接语言不要用“参见”这类原始词汇，而要自然融入正文。比如在“JVM 内存模型”条目的正文里写“对象的分配主要在堆上，堆的划分与回收策略直接决定了 GC 停顿时间”，那“堆”和“GC 停顿时间”就应该加上内部链接。这样读起来是通顺的技术文章，而不是干巴巴的链接陈列。

我还让 LLM 给每个条目生成三条“入链推荐”，也就是别的哪些条目应该引用当前条目。这一步做的是反向链接补全，保证条目网络是双向的——每个条目既是指向别人的起点，也是被别人指向的终点。

层级结构也同样重要。我会维护一个“主题分类页”，类似维基百科的“分类:计算机科学”页面。这个页面列出顶层分类，每个分类下放子分类和代表性条目。LLM 在接到一个不熟悉的提问时，会先落到分类页上，确定问题属于哪个大类，再逐层向下导航。没有这个层级，模型面对几百个平铺的条目时会像走进了一个没有路标的迷宫，效率断崖式下跌。

3.4 第四步：检索接口封装——给 LLM 一个“导航工具”

编译完成后，知识库已经有 Wiki 的形态了，接下来要让 LLM 能够真正“用”起来。这一步不是把整个 Wiki 塞给模型，而是把 Wiki 封装成一组工具接口，放在模型的工具调用（function calling）框架里。

我做的最小可用工具集是五个：

wiki.search(query)：根据关键词或语义查询，返回命中的条目列表（标题 + 摘要） wiki.read(topic)：返回指定条目的完整正文 wiki.summary(topic)：返回指定条目的摘要字段 wiki.links(topic)：返回指定条目的出链和入链列表 wiki.toc()：返回整个 Wiki 的分类目录结构

模型拿到这五个工具，就能自己规划检索路径。在配置工具调用时，我特别强调了一点：给每个工具加上使用场景说明。比如wiki.search的描述是“当用户的问题比较开放、不确定哪个条目相关时使用”；wiki.links的描述是“当需要探索与当前主题相关的其他知识时使用”。模型在决定调哪个工具时，会读这些描述来匹配意图，描述写得越精准，调用就越合理。

实测中我发现，只要工具定义得好，LLM 几乎不需要额外的“推理提示”就能自主导航。它会在多个工具之间跳转，读摘要、点链接、回退再换一条路径，行为模式和人类查阅 Wiki 几乎一致。当然，要给模型设定最大步数限制，我一般设为 8 步，防止它在知识网络里无限游荡。

3.5 第五步：代理与评测——验证检索质量

这套系统不能上线就不管了，要做评测，而且要持续做。我的评测方案分三层。

第一层是覆盖率评测：准备一份要求覆盖全库所有主要条目的提问清单，每问一个问题，记录模型的检索路径，看它是否在合理的步数内覆盖了应该涉及的核心条目。这个指标用来衡量 Wiki 结构是否清晰，导航是否顺畅。

第二层是答案质量评测：把 LLM-Wiki 的答案和传统 RAG 的答案放在一起，对比回答的完整性和准确率。我会挑 20 个有代表性的复杂问题，让两套系统分别作答，再用人工按“信息完整性”“引用准确率”“逻辑连贯性”三个维度打分。我自己的测试结果是：在需要多步推理的问题上，LLM-Wiki 比传统 RAG 的正确率高出大约四成，尤其是在涉及多主题关联的问题上，优势更明显。

第三层是链接质量评测：随机抽检条目，看链接是否有指向错误、是否链接到了无关主题、是否遗漏了重要引用。链接质量是编译阶段的产出，这一步出的问题反映的是编译 prompt 不够严谨，需要回炉修 prompt 而不是手工改链接。

评测做完，整个 LLM-Wiki 系统的闭环就建立了：知识库 → 清洗 → 切片 → Wiki 化编译 → 工具封装 → 评测反馈。下一轮知识库更新时，增量编译会基于上一轮的条目标题和链接结构做对齐，保证网络不会因为新增内容而散架。

4. 常见问题与避坑实录

4.1 链接漂移与知识过时

LLM-Wiki 上线后最容易遇到的第一个问题就是链接漂移。知识库是活的，今天新增了一个条目，明天修改了一个条目，后天可能删掉了一个条目。条目删除后，所有指向它的链接都会变成“死链”。我最初没做防护，运行一个月后，全库大概有 3% 的链接指向了不存在的条目，模型点击时返回空内容，整个检索路径当场断掉。

解决办法是维护一个“条目变更日志”，每次增删改都记录操作。每周末跑一次死链检查，把所有指向不存在条目的链接找出来。处理策略有两种：如果链接指的是“概念性内容”，那就把它改指向最接近的上层分类页；如果链接内嵌在正文的一句话里，那就把链接文本改成普通文本，保字弃链。

知识过时是另一个隐患。Wiki 形态会让旧知识看起来非常“权威”，因为条目结构规整、有链接有摘要，模型引用起来理直气壮。处理办法是在清洗阶段给每条内容打上“知识版本”标签，编译条目时把知识版本写进条目的元数据里。模型读取条目正文时，元数据会被附加在上下文中，如果新旧版本之间有冲突，模型能感知并提醒用户“该知识基于旧版本，可能已过期”。

4.2 检索权放开后的幻觉控制

把检索权交给 LLM 听起来很美好，但代价是模型的自主性变强了，它可能发挥过头。我遇到过一种典型情况：模型在导航时发现没有完全匹配的条目，但它又不想空手而归，于是开始拿不相关的条目内容硬凑答案。比如用户问“支付回调怎么保证幂等”，知识库里只有“缓存设计”和“消息队列”两个条目，模型硬是把这两个条目的内容缝合在一起，编出了一个看起来可行但实际上没人验证过的方案。

这个问题不能完全靠 prompt 解决，我从两个方向下手。第一是在工具定义里明确“如果检索结果与当前问题相关性不足，明确拒绝回答并建议用户补充资料”；第二是在评测阶段增加“拒答率”指标，数学模型拒绝回答的比例高于 10% 就说明知识库缺内容，低于 2% 则说明模型可能开始瞎编了。这个区间是我试出来的经验值，不同领域可以微调，但一定要把这个指标盯着，别让模型为了“有用”而放弃“准确”。

4.3 权限隔离的落地办法

很多知识库是团队共享的，不同角色看的范围不同。这个在传统 RAG 里好办，向量库里给每个文档打上权限标签，检索时过滤就行。但 LLM-Wiki 的链接导航是跨条目的——A 角色能看的条目里有链接指向 B 角色不能看的条目，这时候该怎么处理？

我的方案是在工具层拦截。两套权限模型：第一套是“条目级权限”，模型读取条目前，工具先检查调用者的权限组，无权限直接返回“无访问权限”；第二套是“链接级权限”，无权限的链接在返回的链接列表中被剔除。实际操作时要注意，权限剔除后链接总数变少了，模型不知道被隐藏了什么，所以导航路径自然地沿着可见条目推进，不会因为不存在的链接而产生误导。

权限设计一定要在编译阶段就对齐。如果用一套编译结果强行适配多套权限，很容易出现“模型知道有条目存在但读不了”的情况，导致明明是很简单的问题却答不上来。在编译时多花点功夫，把每个条目的可见范围标记清楚，后续就能省掉大量麻烦。

4.4 成本与性能的平衡

LLM-Wiki 的调用成本比传统 RAG 高不少，因为它是在多轮工具调用中完成的，每轮都是一次模型推理。我去查了一下，一个典型的三步导航问题，平均要消耗传统 RAG 两到三倍的 token。前面说的 8 步上限，大多数问题走 3 到 5 步就解决了，但依然是一笔不可忽视的成本。

控制成本我有两个做法。第一是给导航模型和答案生成模型分开用不同规格，导航时用一个小参数模型，只判断“下一步查什么”；拿到全部素材后，再用大参数模型来生成最终答案。这样做成本能降四到五成，而回答质量几乎不受影响。第二是加一层“查询缓存”，对重复性较高的问题直接缓存最终答案和引用来源。团队内超过三成的问题都是同一批：新同事问的入职类问题、运营问的固定报表口径问题，这些完全可以命中缓存。

5. 工具生态与配套参考

5.1 可以组合使用的工具链

LLM-Wiki 不绑定特定平台，但如果你要从零搭一套，我推荐几个顺手的方向。

笔记库部分，Obsidian 是最佳选择，没有之一。它的原生格式就是 Markdown，支持双向链接和标签，前端还能用图谱视图直观展示条目之间的关系。我实测过好几款笔记工具，Obsidian 的链接概念和 Wiki 形态天然对齐，几乎没有转换成本。你甚至可以直接把 Obsidian 的仓库当作 LLM-Wiki 的源数据库，编译脚本直接读取.md文件，生成新的链接和摘要再写回。

知识库流水线方面，Dify 和 RAGFlow 都值得关注。Dify 的工作流设计特别适合做“编译”这步的自动化——你可以搭一条流水线，触发条件是知识库目录变化，执行动作是调用 LLM 做切片和摘要生成，输出写给目标 Wiki 仓库。RAGFlow 在知识库解析上做得比较扎实，对 PDF、Word 这类富文本的支持很稳，适合清洗阶段的文件预处理。

本地 Agent 营地里，Trae、OpenClaw 这类工具也能嵌入 LLM-Wiki 的调度逻辑。它们的共性是支持工具调用的编排，你把 Wiki 的五个检索接口注册进去，它们就能替你在对话中自主使用。我自己现在的工作流是 Obsidian 做仓库 + 自研编译脚本 + OpenClaw 做运行时推理，整体链路跑起来很顺。

5.2 下一步的扩展方向

这套东西做到后面，可扩展的点很多。我的路线图里排了三个方向。

第一是自动更新机制。现在不少团队接入工作流后，知识库的增量更新还是很依赖手动触发。我想把编译做成完全自动化的，每天定时扫描 Obsidian 仓库的变更，新增内容自动切片、自动建链、自动生成摘要。每天清晨跑一遍，我当时看了下，一天增量编译大概消耗 1 到 2 万 token，完全可以接受。

第二是多模态内容的纳入。很多知识库里都躺着图片、表格、白板截图，传统 RAG 处理图片很弱，RAGFlow 也没有完全解决。LLM-Wiki 的条目可以把图片作为附件挂载，模型读正文时拿到的是图片的描述文本，而不是图片本身。描述文本可以在编译阶段由视觉模型生成，这样既保留了图片信息，又不会因为多模态 token 太贵而拖垮成本。

第三是评测自动化。前面说的三层评测，现在还是半人工的。我想把它做成一个持续运行的评测任务，每周自动抽取问题，对比 LLM-Wiki 和传统 RAG 的答案，输出一份质量报告。评测报告既能定位 Wiki 结构中还需要优化的部分，也能沉淀出高频问题清单反向补充知识库。

最后分享一点我自己的感受。做 LLM-Wiki 这件事，技术难点不在于模型调用，也不在于工具配置，而在于“知识本身如何组织”这件事上。大部分人把精力花在了怎么让模型更聪明，却忘了先把手头的知识整理清楚。把知识库编译成 Wiki，本质上是强制自己对知识做一次结构化梳理，而把检索权交给 LLM，本质上是信任模型能在结构清晰的知识网络上做出合理判断。我在搭建和使用的过程中，最大的收获不是系统本身，而是重新理解了自己的知识库——哪些是核心，哪些是过时的噪音，哪些知识之间存在着我还从未意识到的关联。这种对既有知识资产的二次挖掘，恰恰是 LLM 时代很多人忽略的价值。