企业官网建设流程全解析

1. 为什么要把知识库“编译”成 Wiki

1.1 从一堆文档到一座可导航的知识城

大多数人第一次接触 LLM 知识库，脑子里想的都是“把 PDF 丢进去，然后问它问题”。这个思路本身没错，但真正动手做过几个项目之后你会发现，原始文档的堆积和可用的知识库之间，隔着一道巨大的鸿沟。你手头可能有几百篇技术文档、几十份产品手册、一堆会议纪要，甚至还有从各种渠道保存下来的文章。这些东西放在文件夹里，人类自己找起来都费劲，更别说让 LLM 去精准检索了。

我踩过的第一个坑就是：直接把一堆 Markdown 文件塞进向量数据库，然后做语义检索。结果呢？用户问“这个系统的鉴权流程是怎样的”，检索出来的却是三篇不同文档里零散的段落，有的讲 token 刷新，有的讲权限模型，有的讲网关配置，拼在一起逻辑是断裂的。LLM 拿到这些碎片，生成的回答自然也是东一榔头西一棒子。

后来我想明白了一件事：知识库不应该是一个“仓库”，而应该是一座“城市”。仓库里的东西是堆着的，你得自己翻；城市里的东西是有路标、有分区、有门牌号的，你顺着路就能找到。Wiki 这种形式，本质上就是给知识建了一座城市——有目录结构、有交叉引用、有分类标签、有层级关系。把知识库“编译”成 Wiki，就是给散落的文档修路、编号、建索引。

这个“编译”的过程，不是简单地换个格式存储，而是要做几件核心的事：结构化重组、语义关联建立、检索入口设计。做完之后，LLM 面对的就不再是一堆无差别的文本块，而是一个有拓扑结构的知识网络。它可以根据问题先定位到某个 Wiki 页面，再顺着页面内的链接和层级往下钻，检索的精准度和可解释性都会大幅提升。

1.2 检索权交给 LLM 意味着什么

“把检索权交给 LLM”这句话，听起来有点抽象。我换个说法你就明白了：传统的 RAG 流程是“你问问题 → 系统去向量库捞 Top-K 片段 → 拼成 Prompt → LLM 生成回答”。整个过程中，LLM 是被动的，它只能看到系统喂给它的那几段文字，没有选择权。

而“把检索权交给 LLM”之后，流程变成了“你问问题 → LLM 先看 Wiki 的目录结构 → 自己决定去哪个页面找 → 找到后再决定要不要顺着链接深入 → 最后综合多个页面的信息生成回答”。LLM 从一个“被动接收者”变成了“主动探索者”。

这个转变带来的好处非常直接。第一，检索路径可追溯。LLM 去了哪些页面、看了哪些内容，你都能看到，出了问题好排查。第二，多跳推理成为可能。有些问题需要跨多个知识点才能回答，传统 RAG 一次性捞片段很难覆盖，但 LLM 可以顺着 Wiki 的链接一跳一跳地找过去。第三，知识更新更友好。Wiki 页面是独立维护的，改一个页面不影响其他页面，LLM 下次检索时自然就能拿到最新内容。

当然，这个方案也不是没有代价。最大的挑战在于：Wiki 的结构设计必须合理。如果目录层级太深，LLM 找起来费劲；如果层级太浅，又起不到分类导航的作用。后面我会详细讲怎么设计这个结构。

1.3 适合谁来参考这套方案

这套方案不是给“只想快速搭个 Demo”的人准备的。如果你只是想试试 RAG 的效果，直接用现成的框架跑个向量检索就够了。但如果你面临的是下面这些场景，那这套思路就值得认真研究：

• 知识体量大且持续增长：几百上千篇文档，而且还在不断新增，靠人工维护检索规则不现实。
• 知识之间有复杂的关联关系：比如产品文档里，安装指南会引用配置说明，配置说明会引用故障排查，故障排查又会引用架构设计。这种网状关系用扁平检索很难处理好。
• 对回答的可解释性有要求：用户不仅想知道答案，还想知道这个答案是从哪几个文档里来的，为什么这些文档是相关的。
• 需要支持多跳推理：问题本身比较复杂，需要综合多个知识点的信息才能回答。

如果你符合其中两条以上，那这套“Wiki 编译 + LLM 自主检索”的方案就值得你花时间研究。接下来我会从整体设计、核心细节、实操过程、问题排查四个层面，把这件事讲透。

2. 整体设计与核心思路拆解

2.1 为什么选 Wiki 而不是纯向量库

先说一个我经常被问到的问题：“向量库不是已经能做语义检索了吗，为什么还要搞 Wiki 这一层？”这个问题问得好，因为它直接关系到方案选型的根本逻辑。

向量库的强项是模糊匹配。你问“怎么配置数据库连接”，它能找到语义相近的段落，哪怕原文用的是“数据库链接设置”这种措辞。但向量库的弱项也很明显：它没有结构感。所有的文本块在它眼里都是平等的，它不知道哪个块是概述、哪个块是细节、哪个块是前置条件、哪个块是注意事项。

Wiki 恰好补上了这块短板。Wiki 的页面有标题、有层级、有分类、有链接，这些结构信息本身就是一种“元知识”。LLM 在检索时，可以先看标题判断这个页面大概讲什么，再看层级判断这个知识点在整体中的位置，再看链接判断它和哪些页面有关联。这些判断，向量库是给不了的。

我做过一个对比实验：同一套技术文档，一套直接做向量检索，一套编译成 Wiki 后让 LLM 自主检索。在“简单事实查询”类问题上，两者准确率差不多，都在 85% 左右。但在“需要综合多个知识点”的复杂问题上，向量检索的准确率掉到了 60% 出头，而 Wiki 方案还能维持在 80% 以上。差距主要就来自结构信息带来的导航能力。

提示：这不是说向量库没用。实际上，Wiki 方案里通常也会保留向量检索作为辅助手段——当 LLM 不知道去哪个页面找时，可以用向量检索做兜底。两者是互补关系，不是替代关系。

2.2 知识编译的三个核心层次

把知识库编译成 Wiki，我把它拆成三个层次来做，每个层次解决不同的问题。

第一层是物理结构层，解决“东西放在哪”的问题。这一层要做的是把原始文档按照主题、类型、受众等维度重新组织成目录树。比如一个技术知识库，顶层可以按“入门指南 / 核心概念 / 操作手册 / 故障排查 / 参考手册”来分，每个顶层下面再按具体主题细分。这一层的产出是一个清晰的目录结构，LLM 拿到问题后，第一件事就是看这个目录，决定往哪个分支走。

第二层是语义关联层，解决“东西之间有什么关系”的问题。这一层要在页面之间建立链接，包括前置依赖链接（读 A 之前需要先读 B）、相关主题链接（A 和 B 讲的是同一件事的不同方面）、上下位链接（A 是 B 的详细展开）。这些链接让 Wiki 从一棵树变成了一张网，LLM 可以顺着链接做多跳检索。

第三层是检索接口层，解决“LLM 怎么访问”的问题。这一层要设计一套 LLM 能理解的检索协议，包括：目录查询接口（给我看顶层目录）、页面读取接口（给我看某个页面的内容）、链接追踪接口（这个页面链接到了哪些页面）、搜索接口（按关键词找页面）。LLM 通过这些接口来探索知识库，而不是一次性拿到所有内容。

这三层是递进关系。物理结构层是基础，没有清晰的目录，后面两层无从谈起。语义关联层是增值，它让知识库从“可查”变成“可推理”。检索接口层是通道，它决定了 LLM 能以多高的效率使用这个知识库。

2.3 检索权下放的技术前提

“把检索权交给 LLM”不是一句话就能实现的，它需要几个技术前提。

前提一是 LLM 要有足够的上下文窗口。LLM 在探索 Wiki 时，需要同时看到目录结构、当前页面内容、以及可能的链接列表。如果上下文窗口太小，它看几页就满了，没法做多跳推理。我的经验是，至少需要 32K 以上的有效上下文，64K 以上会比较从容。当然，这不是说小窗口就完全做不了，只是需要更精细的上下文管理策略。

前提二是要有可靠的函数调用能力。LLM 需要通过调用接口来获取 Wiki 内容，而不是被动接收。这要求 LLM 能稳定地输出结构化的函数调用请求，包括函数名和参数。目前主流的大模型在这方面都做得不错，但实际使用中还是要注意参数校验和异常处理。

前提三是要有检索路径的追踪机制。LLM 去了哪些页面、做了哪些决策，这些信息需要被记录下来。一方面是为了调试和优化，另一方面也是为了在生成最终回答时，能给出引用来源。没有这个机制，整个方案就是个黑盒，出了问题没法排查。

前提四是 Wiki 内容要足够干净。如果 Wiki 页面里充斥着无关信息、重复内容、过时数据，LLM 的检索效率会大打折扣。所以在编译阶段，内容的清洗和去重是必不可少的步骤。我一般会做三轮清洗：第一轮去重，把内容高度相似的页面合并；第二轮去噪，把与主题无关的段落删掉；第三轮校验，确保每个页面的内容都是准确且最新的。

2.4 和 GraphRAG 的关系与区别

说到 Wiki 式检索，很多人会联想到 GraphRAG。两者确实有相似之处——都强调结构化和关联性——但底层逻辑不太一样。

GraphRAG 的核心是实体关系图。它从文档中抽取实体和关系，构建一张知识图谱，检索时通过图遍历来找到相关信息。它的优势在于能处理非常复杂的关联查询，比如“A 公司的 CEO 曾经就读的大学的所在地是哪里”这种多跳问题。

Wiki 式检索的核心是层级目录加页面链接。它不追求把知识拆成最小的实体和关系，而是保留文档的自然结构，通过目录和链接来导航。它的优势在于实现成本低、可维护性好、对原始文档的改动小。

我个人的选择是：如果原始文档本身就有比较好的结构，优先用 Wiki 方案；如果文档结构混乱但实体关系丰富，可以考虑 GraphRAG。两者也可以结合——用 Wiki 做粗粒度的导航，用图谱做细粒度的关系查询。不过结合方案复杂度会高不少，建议先把 Wiki 方案跑通再考虑。

3. 核心细节解析与实操要点

3.1 目录结构设计的四条原则

目录结构是 Wiki 的骨架，设计得好不好，直接决定了 LLM 能不能高效导航。我总结了四条原则，都是踩坑踩出来的。

原则一：顶层分类不超过七个。这是从认知心理学借来的经验——人类短期记忆的容量大概是七加减二。LLM 虽然不受这个限制，但顶层分类太多会导致它在第一步就犹豫不决。我一般控制在五到七个，比如“入门 / 概念 / 操作 / 排查 / 参考 / 案例”这样的划分。

原则二：每个页面的标题要能独立表意。什么叫独立表意？就是光看标题，不看内容，也能大概知道这个页面讲什么。“配置说明”这种标题就不合格，太泛了；“数据库连接池配置参数详解”就合格，具体、有信息量。LLM 在导航时主要靠标题做判断，标题的信息量越大，它的决策越准。

原则三：层级深度控制在三到四层。太浅了分类不够细，太深了 LLM 要跳好几次才能找到目标。我的经验是，从顶层到具体页面，三到四层是比较舒服的。比如“操作手册 → 数据库操作 → 连接配置 → 连接池参数”，四层，每层都有明确的信息增量。

原则四：同级页面之间要有明确的区分度。如果两个页面标题看起来差不多，LLM 就不知道该选哪个。比如“性能优化”和“性能调优”这种，人类可能觉得是一回事，但 LLM 会困惑。解决办法是给每个页面加一句简短的描述，说明它和其他相似页面的区别。

下面是一个目录结构的示例，你可以参考这个格式来设计自己的：

技术知识库/ ├── 01-入门指南/ │ ├── 01-环境准备与安装.md │ ├── 02-快速上手示例.md │ └── 03-核心概念速览.md ├── 02-核心概念/ │ ├── 01-架构设计原理.md │ ├── 02-数据模型说明.md │ └── 03-鉴权与权限体系.md ├── 03-操作手册/ │ ├── 01-数据库操作/ │ │ ├── 01-连接配置.md │ │ ├── 02-连接池参数.md │ │ └── 03-读写分离设置.md │ └── 02-缓存操作/ │ ├── 01-缓存策略配置.md │ └── 02-缓存失效处理.md ├── 04-故障排查/ │ ├── 01-常见错误码对照.md │ ├── 02-连接超时排查.md │ └── 03-性能问题定位.md └── 05-参考手册/ ├── 01-配置项全表.md └── 02-API接口说明.md

3.2 页面内容的标准化模板

目录结构定好之后，每个页面里写什么、怎么写，也需要有标准。我一般会给每个页面定义一个模板，包含以下几个部分：

页面标题：和目录中的文件名一致，确保 LLM 在目录里看到的和页面里看到的是同一个东西。

一句话摘要：用一句话说明这个页面解决什么问题。这句话会出现在目录索引里，帮助 LLM 快速判断是否相关。

前置知识：列出读这个页面之前需要了解的概念或页面链接。这相当于给 LLM 一个“前置依赖”提示，避免它在缺乏背景知识的情况下强行理解。

正文内容：按逻辑分小节展开，每个小节有明确的小标题。正文里要避免大段无结构的文字，尽量用列表、表格、代码块来组织信息。

相关页面：列出和本页面主题相关的其他页面链接，方便 LLM 做横向扩展检索。

最后更新日期：让 LLM 知道这个页面的时效性，对于快速变化的知识领域尤其重要。

这个模板看起来简单，但实际用起来效果很好。我做过对比，用模板标准化后的页面，LLM 的检索命中率比自由格式的页面高出 20% 以上。原因很简单：模板给了 LLM 稳定的预期，它知道去哪里找摘要、去哪里找前置知识、去哪里找相关内容，不用每次都在页面里乱翻。

3.3 链接网络的构建策略

页面之间的链接是 Wiki 从“目录树”升级为“知识网络”的关键。链接建得好，LLM 就能做多跳推理；建得不好，链接就成了摆设。

我一般会建三种链接：

第一种是前置依赖链接。如果理解页面 A 需要先读页面 B，那就在 A 的前置知识部分链接到 B。这种链接帮助 LLM 在遇到不懂的概念时，知道去哪里补课。

第二种是相关主题链接。如果页面 A 和页面 B 讲的是同一主题的不同方面，就在 A 的相关页面部分链接到 B。这种链接帮助 LLM 做横向扩展，避免遗漏相关信息。

第三种是上下位链接。如果页面 A 是页面 B 的详细展开，就在 A 里链接到 B 的概述部分，在 B 里链接到 A 的详细部分。这种链接帮助 LLM 在“概览”和“细节”之间灵活切换。

链接的构建不需要追求大而全，关键是准确。一个错误的链接比没有链接更糟糕，因为它会把 LLM 引到错误的方向。我的做法是，链接先由人工标注核心的几十条，然后通过分析页面内容的语义相似度，自动推荐一批候选链接，再由人工审核确认。这样既保证了覆盖率，又保证了准确性。

注意：链接不要建得太密。如果每个页面都链接到几十个其他页面，LLM 会陷入“选择困难”。我的经验是，每个页面的链接数量控制在五到十个之间，只保留最相关的那几个。

3.4 检索接口的设计要点

检索接口是 LLM 访问 Wiki 的通道，设计得好不好，直接影响 LLM 的探索效率。我一般会提供四个接口：

目录查询接口：输入一个路径前缀，返回该路径下的子目录和页面列表，每个条目包含标题和一句话摘要。LLM 用这个接口来“看地图”，决定往哪个方向走。

页面读取接口：输入页面路径，返回页面的完整内容，包括正文、前置知识、相关页面链接。LLM 用这个接口来“进房间”，获取详细信息。

搜索接口：输入关键词或自然语言查询，返回匹配的页面列表。LLM 用这个接口来做“兜底检索”，当它不知道去哪个目录找时，用搜索来定位。

链接追踪接口：输入页面路径，返回该页面链接到的所有页面列表。LLM 用这个接口来做“顺藤摸瓜”，从一个页面跳到另一个页面。

这四个接口的组合使用，就构成了 LLM 的完整探索能力。实际运行中，LLM 的典型行为模式是：先调目录查询看顶层结构，然后调搜索接口定位候选页面，再调页面读取获取内容，最后调链接追踪做扩展验证。整个过程可能来回好几轮，直到它认为收集到了足够的信息。

接口的返回格式要尽量简洁，避免给 LLM 太多无关信息。比如目录查询接口，返回的每个条目只需要标题和摘要就够了，不需要返回文件大小、创建时间这些 LLM 用不上的元数据。信息越精简，LLM 的决策效率越高。

4. 实操过程与核心环节实现

4.1 从原始文档到 Wiki 页面的编译流水线

把原始文档编译成 Wiki 页面，我一般会走一条五步流水线。这条流水线不是全自动的，中间有几个环节需要人工介入，但整体效率比纯手工高很多。

第一步是文档收集与分类。把散落在各处的文档集中起来，按照来源和类型做初步分类。这一步主要是体力活，但有一个技巧：优先处理结构清晰的文档。比如已经用 Markdown 写好的技术文档，转换成本最低；PDF 和 Word 文档需要先做格式转换，成本高一些；图片和扫描件成本最高，建议单独处理。

第二步是内容抽取与清洗。把文档内容抽取成纯文本，去掉页眉页脚、页码、广告等无关内容。这一步可以用脚本自动化，但清洗规则需要根据文档特点来定制。我一般会写一个清洗配置，指定哪些行要删、哪些格式要保留、哪些特殊字符要替换。

第三步是主题聚类与页面拆分。把内容按照主题聚类，每个主题生成一个 Wiki 页面。这里的关键是拆分粒度。拆得太细，页面数量爆炸，LLM 导航成本高；拆得太粗，单个页面内容太多，LLM 读取效率低。我的经验是，单个页面的正文控制在 500 到 2000 字之间比较合适。超过 2000 字的，考虑拆成多个子页面；少于 500 字的，考虑合并到相关页面。

第四步是模板填充与链接标注。按照前面说的页面模板，把内容填充进去，同时标注前置知识、相关页面等链接。这一步可以半自动化：用脚本生成模板框架和候选链接，人工审核确认。

第五步是质量校验与发布。检查每个页面的内容准确性、链接有效性、格式规范性。我一般会做一个检查清单，逐项过一遍。校验通过后，把 Wiki 发布到 LLM 可以访问的存储位置。

这条流水线跑下来，处理一百篇左右的文档，大概需要两到三天。其中大部分时间花在第三步和第四步的人工审核上。如果你有现成的结构化文档，时间可以缩短到一天以内。

4.2 LLM 自主检索的提示词设计

LLM 自主检索的效果，很大程度上取决于提示词怎么写。我试过很多版本，最后稳定下来的提示词结构大概是这样的：

你是一个知识库检索助手。你可以通过以下工具来探索知识库： 1. list_directory(path) - 列出指定路径下的子目录和页面 2. read_page(path) - 读取指定页面的完整内容 3. search(query) - 按关键词搜索相关页面 4. get_links(path) - 获取指定页面链接到的其他页面 你的任务是：根据用户的问题，自主决定检索路径，收集足够的信息来回答问题。 工作流程建议： - 先看顶层目录，了解知识库的整体结构 - 根据问题关键词，用 search 定位候选页面 - 读取候选页面，判断是否包含所需信息 - 如果信息不足，通过 get_links 追踪相关页面 - 收集到足够信息后，综合生成回答，并注明信息来源 注意事项： - 不要一次性读取太多页面，按需读取 - 如果某个页面不相关，及时换方向 - 最终回答要基于实际读取到的内容，不要编造

这个提示词的关键在于：给 LLM 明确的工具列表和推荐的工作流程，但不要限制得太死。我试过把流程写得很细，比如“第一步必须调 list_directory，第二步必须调 search”，结果 LLM 变得很死板，遇到特殊情况不会变通。后来改成“建议”而不是“必须”，LLM 的灵活性明显提升。

还有一个细节：在提示词里强调“不要编造”。LLM 在检索过程中，有时候会“脑补”一些它没有实际读到的内容。加上这句约束后，这种情况少了很多。

4.3 检索路径的追踪与日志记录

LLM 自主检索的过程，如果不记录日志，出了问题根本没法排查。我一般会记录以下几类信息：

工具调用日志：每次 LLM 调用工具，记录调用时间、工具名、参数、返回结果的摘要。这个日志用来分析 LLM 的检索行为模式。

决策日志：记录 LLM 在每一步的“思考过程”——它为什么选择这个页面而不是那个页面，它从当前页面得到了什么信息，下一步打算去哪里。这个日志用来优化提示词和 Wiki 结构。

最终回答的引用来源：记录最终回答引用了哪些页面，每个页面贡献了什么信息。这个日志用来评估检索质量，也方便用户追溯。

日志的存储格式我一般用 JSON Lines，每行一条记录，方便后续分析。下面是一个示例：

{"timestamp": "2025-01-15T10:23:01Z", "action": "list_directory", "path": "/", "result_count": 5} {"timestamp": "2025-01-15T10:23:03Z", "action": "search", "query": "数据库连接配置", "result_count": 3} {"timestamp": "2025-01-15T10:23:05Z", "action": "read_page", "path": "/03-操作手册/01-数据库操作/01-连接配置.md", "content_length": 1200} {"timestamp": "2025-01-15T10:23:08Z", "action": "get_links", "path": "/03-操作手册/01-数据库操作/01-连接配置.md", "links": ["02-连接池参数.md", "03-读写分离设置.md"]} {"timestamp": "2025-01-15T10:23:12Z", "action": "read_page", "path": "/03-操作手册/01-数据库操作/02-连接池参数.md", "content_length": 800} {"timestamp": "2025-01-15T10:23:15Z", "action": "final_answer", "sources": ["01-连接配置.md", "02-连接池参数.md"]}

有了这些日志，你就可以分析：LLM 平均要调多少次工具才能找到答案？哪些页面被频繁访问？哪些链接从来没被用过？这些数据都是优化的重要依据。

4.4 性能优化的几个关键参数

Wiki 式检索的性能，主要受几个参数影响。我把实测下来比较有效的配置整理成了一张表：

这些参数不是固定的，需要根据你的知识库规模和 LLM 的能力来调整。我的建议是：先用推荐值跑起来，然后根据日志分析结果逐步调优。比如你发现 LLM 经常在找到答案之前就用完了工具调用次数，那就把上限调高；如果发现 LLM 经常被太多搜索结果干扰，那就把返回数量调低。

还有一个容易被忽视的优化点：页面内容的排序。同一个页面里，把最重要的信息放在前面，次要的放在后面。LLM 读取页面时是从头开始读的，如果关键信息在页面末尾，它可能读了一半就跳走了。我一般会把“一句话摘要”和“核心结论”放在页面最前面，详细说明放在后面。

5. 常见问题与排查技巧实录

5.1 LLM 找不到明明存在的页面

这是最常见的问题之一。你明明在 Wiki 里写了某个页面，但 LLM 就是找不到。排查下来，原因通常有几种。

原因一是标题和查询词不匹配。用户问“怎么设置超时时间”，但页面标题是“连接参数配置”，LLM 用“超时时间”去搜索，可能搜不到这个页面。解决办法是在页面的摘要和正文里，把常见的同义词都写进去。比如“超时时间”这个页面，摘要里可以写“连接超时、读取超时、写入超时的配置方法”，这样搜索命中率会高很多。

原因二是目录层级太深。如果页面藏在第四层甚至第五层目录下，LLM 在顶层目录里看不到它，搜索又没命中，就容易漏掉。解决办法是控制层级深度，同时给深层页面在浅层目录里加“快捷入口”链接。

原因三是搜索接口的关键词匹配策略太严格。如果搜索用的是精确匹配，稍微换个说法就搜不到。我一般会用“关键词 OR 匹配 + 语义相似度”的混合策略，先做关键词召回，再用向量相似度排序，效果比单一策略好很多。

排查这类问题时，我一般会先手动模拟 LLM 的检索路径：用同样的查询词去调搜索接口，看返回什么结果；如果搜索没返回目标页面，再看目录结构，判断 LLM 是否有可能通过目录导航找到它。这样一步步定位，很快就能找到症结。

5.2 检索结果太多导致 LLM 迷失

另一个极端是：LLM 找到了太多相关页面，反而不知道该看哪个，最后生成一个泛泛而谈的回答。这种情况通常发生在知识库规模较大、主题重叠较多的时候。

我的解决办法是引入相关性评分和分层返回。搜索接口返回结果时，不只返回页面列表，还给每个页面打一个相关性分数，并按照分数从高到低排序。同时，把结果分成“高度相关”和“一般相关”两档，LLM 优先看高度相关的，如果信息不够再看一般相关的。

另一个技巧是在提示词里加约束。比如：“如果搜索结果超过 5 条，先看前 3 条，判断是否足够回答问题。如果不够，再看剩下的。”这个简单的约束能有效防止 LLM 在大量结果中迷失。

还有一个根本性的解决办法：优化 Wiki 结构，减少主题重叠。如果两个页面讲的内容有 70% 以上重叠，那就应该合并。我一般会定期做一次“页面相似度分析”，把相似度过高的页面找出来合并或重新划分。

5.3 多跳检索时链接断裂

多跳检索是 Wiki 方案的核心优势，但实际用起来，经常出现“跳着跳着就断了”的情况。比如 LLM 从页面 A 跳到页面 B，想再从 B 跳到 C，但 B 里没有链接到 C，检索就卡住了。

这个问题的主要原因是链接覆盖不全。人工标注链接时，很难穷举所有可能的关联。我的解决办法是自动链接推荐 + 人工审核。具体做法是：用文本相似度算法，计算每两个页面之间的语义相关度，把相关度超过阈值的页面对推荐为候选链接，然后人工审核确认。这样能把链接覆盖率从人工标注的 60% 左右提升到 90% 以上。

还有一个技巧是在页面里加“相关主题”区块，用自然语言描述这个页面和哪些主题有关，而不是只给链接。比如“本页面的内容与‘连接池参数’、‘读写分离设置’、‘故障排查-连接超时’等页面密切相关”。这样即使没有直接链接，LLM 也能通过搜索找到相关页面。

5.4 常见问题速查表

为了方便你快速定位问题，我把常见的症状、可能原因和解决办法整理成了下面这张表：

提示：这张表建议收藏，遇到问题时先对照排查，能省不少时间。大部分问题都能在前三行找到对应原因。

5.5 几个踩坑之后才明白的经验

最后分享几个我在实操中踩坑之后才明白的经验，都是文档里不会写的。

经验一：不要追求一次性把 Wiki 建完美。我一开始花了大量时间设计目录结构、标注链接，结果发现 LLM 的实际使用模式和我的预期差别很大。后来改成“先建一个最小可用版本，跑起来看日志，根据实际使用情况迭代优化”，效率高了很多。Wiki 是长出来的，不是设计出来的。

经验二：页面标题比页面内容更重要。LLM 在导航时，90% 的判断依据是标题。标题写得好，LLM 找页面的效率翻倍；标题写得差，内容再好也白搭。我现在的做法是，每个页面的标题都要经过“如果我只看到这个标题，能不能判断它讲什么”的测试。

经验三：日志分析比主观感觉靠谱。我一度觉得某个页面的链接建得挺好，但日志显示 LLM 从来没通过这个链接跳转过。后来分析发现，这个链接的位置太靠后，LLM 读到一半就跳走了。把链接移到页面开头后，使用率立刻上来了。所以，多看看日志，少凭感觉。

经验四：给 LLM 留“放弃”的余地。早期版本的提示词里，我要求 LLM“必须找到答案”。结果它在找不到时，会强行编造一个回答。后来改成“如果经过充分检索仍然找不到答案，如实告知用户”，编造的情况就少了很多。让 LLM 承认“不知道”，比让它胡说八道要好得多。

经验五：定期做“检索质量抽检”。我每个月会随机抽 20 个问题，人工检查 LLM 的检索路径和最终回答，评估准确率和效率。这个习惯帮我发现了很多隐藏问题，比如某个页面的内容过时了、某个链接指向了错误的页面、某个搜索关键词的召回率特别低。抽检不用多，但要定期做，形成习惯。