企业官网建设流程全解析

做对话式AI系统这件事，我前后折腾了快三年，从最初的规则模板到现在的混合架构，踩过的坑比很多人见过的方案还多。上一篇聊了整体项目规划和技术选型，这篇直接进入实操层面，把从零搭建一套对话系统的完整流程拆开讲，重点放在那些文档里不会写的细节上：意图识别到底怎么设计才不翻车、对话状态管理什么时候该用缓存什么时候该入库、Prompt该怎么写才能让大模型稳定输出、以及上线之后最常出现的那几个鬼问题怎么排查。

如果你正准备自己搭一套对话式AI，或者已经在路上但被各种怪问题卡住，这篇文章应该能帮你省下至少两周的试错时间。

1. 整体架构怎么定：对话式AI系统的四种姿势

先泼一盆冷水：不是所有对话系统都需要大模型。我见过太多人一上来就接GPT，结果成本高、响应慢、还控制不住输出。对话式AI的架构选择，本质上是你在"效果上限"和"可控成本"之间做权衡。

1.1 规则模板流：最朴素但最稳

规则模板就是写if-else，用正则表达式或者简单的关键词匹配来识别用户意图。比如用户说"我要退款"，你就匹配"退款"这个词，然后走退款流程。

这套方案的优点很直接：完全可控、零成本、响应速度毫秒级。缺点是脆弱得要命，用户换个说法就失灵了。"我想把钱拿回来""订单不要了"这种表达，规则根本接不住。

但别急着否定它。我现在做的系统里，仍然保留了一层规则兜底。原因很简单：对于高频的固定场景，比如"人工客服""转人工""退出"，规则比任何模型都可靠。大模型再强，在这几个词上也可能理解偏。

1.2 检索式对话：给知识库加上对话外壳

检索式的核心是：提前把问答对或者文档片段存好，用户提问时用相似度匹配找到最合适的答案返回。这就像你拿着地图找路，地图里有的地方你都能到，地图里没有的你肯定去不了。

这套方案适合知识密集型的场景，比如企业内部的FAQ、产品使用手册、政策查询。优点是答案可控、更新方便——知识库内容变了，改文档就行，不用重新训练模型。缺点是只能回答库里有的东西，遇到没收录的问题就抓瞎。

做检索式对话，关键在两点：一是文档切分要合理，别把一个完整流程切成七零八落的小段；二是检索的召回策略，不能只依赖向量相似度，关键词权重、标题匹配这些都得考虑进去。

1.3 生成式对话：大模型时代的默认选项

现在聊对话式AI，大部分人默认就是生成式。用户输入进大模型，模型直接生成回复。好处是理解能力强、表达自然、能处理各种没见过的问法。坏处是容易一本正经地胡说八道，而且费钱。

用大模型做对话系统，真正的学问不在模型本身，而在你怎么约束它。这就要用到系统提示词、少样本示例、输出格式约束这些手段。因为我需要反复强调：大模型是一匹好马，但你不给它套上缰绳，它就到处乱跑。

1.4 混合架构：我现在的主力方案

我的主力方案是"规则 + 检索 + 生成"三层混合：

• 第一层：规则拦截高频固定指令（转人工、退出、骂人等）
• 第二层：检索召回知识库中的标准答案（有标准答案的先给标准答案）
• 第三层：前两层都没命中，才交给大模型生成

这套架构的好处是，80%的常规问题用便宜、快速、可控的方式解决，只有20%的开放性问题才动用大模型。成本大概能省一半以上，响应速度和稳定性却好了不止一个档次。

注意：混合架构最大的坑是层级之间的"竞争"。比如用户问了一个知识库里有标准答案的问题，但检索没召回，结果落到了大模型那里，生成了一个和标准答案不一致的回复。解决方法是给每一层都加上"置信度门槛"，检索结果低于某个阈值才允许下放到生成层。

2. 核心模块拆解：从意图识别到回复生成

不管架构怎么选，对话系统的基本模块是固定的。这四个模块我逐个拆开讲，每个都说清楚"为什么这么做"而不是只讲"怎么做"。

2.1 意图识别：别一上来就上大模型

意图识别的本质，是把用户的自然语言映射到一个预定义的目标集合上。比如"查询订单""修改地址""投诉建议"就是三个不同的意图。

很多新手喜欢直接用大模型做意图分类，prompt写一大段让模型判断。但实测下来，如果你只有十几个意图，传统的文本分类方案——比如微调一个BERT模型，或者甚至用TF-IDF加SVM——效果并不比大模型差，而且延迟低、成本低、完全可控。

我现在的做法是分两级：

第一级用规则和轻量分类器处理高频意图。比如"查订单""物流""快递什么时候到"这些，直接用关键词和短句匹配就能覆盖90%。

第二级才把复杂意图交给大模型。比如用户说"我上周买的东西现在还没到，而且那个优惠券好像也没用上"，这种信息密集、意图混合的句子，规则和分类器都搞不定，只能靠大模型理解。

设计意图体系的时候，有两条铁律：

• 意图粒度要"够用就好"，不要拆得太细。"查询订单"和"查询订单详情"在业务上往往是同一个流程，拆成两个意图只会让你多写两倍的训练数据和多处理两倍的边界情况。
• 一定要留一个"fallback意图"或者叫"未知意图"。没有这个兜底，所有识别不出来的话术都会强行走某个最近的意图，那才是灾难。

2.2 实体抽取与槽位填充：对话系统的"填空游戏"

如果说意图是"用户想干什么"，实体就是"用户想干这件事需要哪些信息"。拿订机票举例，"帮我订一张明天去北京的机票"——意图是订机票，实体是"明天"（时间）和"北京"（目的地）。

实体抽取看似简单，实际坑特别多。最大的坑是实体值的泛化问题。比如你只收录了"北京""上海"这些城市名，用户说"我想去趟西安"，你的实体列表里没有西安，系统就识别不出来。

解决思路有两个：

一是做"开放实体"识别，不依赖预定义的实体列表，而是靠模型理解上下文来抽取。比如用大模型抽取出"目的地：西安"，即使西安不在你的预设列表里，也能通过上下文确认它是一个城市名。

二是做"实体归一化"。比如用户说"明儿""明天""明日"，这三个词要归一化成同一个日期值。"后天下午三点"要归一化成具体的时间戳。这一步不做，后面的对话状态管理根本没法玩。

槽位填充的意思，是系统要主动向用户询问缺失的信息。用户说"帮我订机票"，你至少要问清楚"去哪里""哪天走""几个人"。这里有一个我之前经常犯的错误：一次问太多。用户只说了"订机票"，你一口气问五个问题，用户大概率直接流失。正确做法是一次问一个最关键的问题，拿到答案之后再追问下一个。

2.3 对话状态管理：记住用户说了什么

对话状态管理是整个系统里最容易被忽视、但崩起来最要命的模块。它的职责是：记住用户在这场对话里已经提供了哪些信息，还需要哪些信息，以及当前进行到流程的哪一步。

最简单的实现方式就是用一个本地字典存槽位，比如：

state = { "intent": "book_flight", "slots": {"destination": "北京", "date": "2025-06-15"}, "current_step": "ask_passenger_count" }

每次用户说话，系统更新这个字典，然后根据当前步骤决定下一步问什么。

但真实场景远比这复杂。用户可能在多轮对话之间插一句"等等，我改一下时间"，这时候你要能定位到之前的槽位并更新它。用户还可能在一轮对话里同时提供多个槽位的信息，比如"明天去北京，后天回来"，你要能一次性抽取并填入多个槽位。

多轮对话的上下文窗口管理，是状态管理的一个难点。我的经验是：对话状态和模型上下文要分开管。对话状态用结构化的数据结构存（比如上面的dict），模型上下文只保留最近几轮的对话内容。不要把整个对话历史都塞进状态里，更不要把状态数据直接拼进Prompt给模型看——两件事混在一起，迟早出问题。

2.4 回复生成与兜底策略：AI也会无话可说

回复生成在生成式方案里就是调用大模型，在检索式方案里就是返回标准答案。这里重点聊几个生成时的细节。

第一，回复长度要控制。用户问"你们几点上班"，答案是"9点到18点"，就七个字。有些模型会给出"您好，感谢您的咨询，我们的营业时间为工作日的上午9点至下午18点，周末及法定节假日休息，请您合理安排时间"这种废话。解决方法是明确写出"回复不超过20个字，直接回答问题，不要寒暄"。

第二，回复格式要约束。比如你要返回结构化数据给前端渲染，就得让模型输出JSON。最稳妥的做法是像下面这样在Prompt里给一个明确的示例，并要求"只输出JSON，不要有任何其他内容"。

第三，也是最容易翻车的：生成内容的安全兜底。如果模型生成的内容包含不当信息，或者模型拒绝回答（比如用户骂人、问敏感问题），你要有预案。我的做法是定义几个固定的兜底回复："这个问题我还在学习中，建议转人工客服处理。"

这里涉及一个我强烈建议所有做对话系统的人都做的设计：可降级性。大模型挂了怎么办？网络超时怎么办？API返回乱码怎么办？你的系统必须能在模型不可用的状态下，自动降级到规则回答或者检索回答，而不是直接报错给用户看。

3. Prompt工程与知识库接入：对话质量的真正分水岭

同样的模型，不同人写Prompt，效果可能天差地别。Prompt工程不是玄学，它有一套方法论。

3.1 系统提示词的写法：让模型知道它是谁、该干嘛

系统提示词（System Prompt）是你在对话开始前给模型设定的"角色和规则"。一套高质量的提示词至少包含四个部分：

• 角色定义：你是谁、服务对象是谁。比如"你是一家电商平台的智能客服，负责解答用户的订单、物流、售后问题。"
• 任务边界：你能做什么、不能做什么。"你只能回答与平台业务相关的问题。超出范围的问题，统一回复'该问题不在我的服务范围内'。"
• 输出格式：回答的结构要求。"优先给出结论，再补充说明。不要使用'首先''其次'这类词。如果信息不足，先提问。"
• 安全约束：绝对不能做的事。"不要编造订单信息，不要承诺赔偿金额，遇到投诉类内容转人工。"

有一个词我特别提醒："不要"比"要"更好用。模型对"不要做什么"的遵从度往往高于"要做什么"。我在提示词里写了"不要编造"之后，编造率明显下降。

3.2 上下文管理：别把上下文塞爆

大模型的上下文窗口有限，你不可能把整段对话历史都塞进去。上下文管理的核心策略是"裁剪 + 摘要"。

裁剪是说，只保留最近N轮对话。我的经验值是：业务类对话保留最近5到8轮就够了，超过这个范围的对话内容，用户自己都说不清，模型更不用参考。

摘要是说，对早期对话的核心信息做结构化提取后保存。比如用户在20轮之前说过"我的订单号是ABC123"，你不需要把原话留在上下文里，只要把{"order_id": "ABC123"}存进状态，在需要的时候拼进Prompt即可。

还有一个细节：用户的问题和AI的回答，在上下文里的"权重"是不一样的。用户刚说的这句话权重最高，AI自己之前给出的回答，反而可以适当压缩——因为模型回答的内容本来就源自上下文，重复引用意义不大，还白白占token。

3.3 知识库检索：让AI"有据可查"

对话式AI系统里，知识库的质量基本决定了系统的天花板。模型再聪明，知识库里没有的内容它也不可能凭空知道。所以知识库的建设和检索，值得投入大量精力。

文档切分是第一道坎。我之前把一份操作手册按固定字数切成片段，结果一个完整的操作流程被劈成两半，检索时只召回一半，生成的回答自然缺胳膊少腿。后来改成按"语义完整性"切分：每个片段尽量是一个完整的主题单元，比如一个操作步骤或一个概念解释。

检索增强生成的流程，我建议按这个顺序：

1. 用户问题进来，先做改写。比如"那个东西咋退"改写成"如何申请退货"，改写后的query去检索，效果比直接用原话好很多。
2. 用混合检索策略。向量相似度 + 关键词权重 + 标题匹配，三个结果做加权融合，而不是只信向量检索。
3. 检索到的片段要经过"相关性过滤"。有时候向量相似度高，但语义上根本答非所问，这一步需要用更精细的阈值或者二次重排来把关。
4. 最后把筛选后的片段拼进Prompt，并要求模型"严格基于以下资料回答，资料中没有的信息不得编造"。

注意：知识库检索最隐蔽的坑是"检索命中但不相关"。向量检索经常会把形式相似但内容无关的段落捞上来，如果你不做相关性过滤，模型就会拿着不相关的资料一本正经地乱答。实测下来，加上一个简单的相关性重排（哪怕只是用模型打分），回答准确率能从60%提到85%以上。

4. 测试与评估：上线前你必须做的三件事

对话系统不像传统软件，你有没有bug，不是"能不能跑"的问题，而是"答得对不对"的问题。所以测试和评估的方法论完全不同。

4.1 测试数据集：没有基准，一切优化都是自我安慰

我见过太多团队用肉眼测几个例子就宣布"效果挺好啊"。等你把系统交给用户，立刻被各种稀奇古怪的问法打脸。

正确的做法是从一开始就维护一套测试集。测试集分两类：

• 标准测试集：覆盖每个意图和每个关键槽位的典型问法，用于验证核心流程。每种意图至少20条，每个槽位至少10条。
• 对抗测试集：专门收集那些容易让系统翻车的说法。比如带错别字的、口语化的、中英文混杂的、指代不清的。这类数据不用多，但每条都是宝。

我自己的习惯是，每次用户实际对话里出现了系统答错的案例，就把它加入对抗测试集，并且写明"期望行为"。这套数据的价值会随着时间积累越来越大——你后续做的任何优化，都要用这套数据回归验证。

4.2 评估指标：别只盯着"正确率"

对话系统的评估，最少要看三个维度：

• 意图识别准确率：用户表达了意图之后，系统能不能识别对。这个用准确率（Accuracy）就够了。
• 槽位填充完整率：完成一次任务式对话，系统是否收集齐了所有必要信息。用"任务完成率"来衡量。
• 回答质量满意度：生成式回答是否准确、完整、得礼貌。这块比较主观，建议用"规则检查 + 人工抽样"结合。规则检查可以设定几条红线：回答中是否出现"我不知道"、是否编造了具体数字、是否超过指定字数。

还有一个我强烈推荐的指标：转人工率。如果用户频繁要求转人工，说明系统在大量场景下解决不了问题。这个指标越高，越说明你的对话流程设计有问题，而不是模型效果有问题。

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

最后这部分，把我实际运营中遇到的几个高频问题整理出来。这些问题你在任何官方文档里都找不到答案，但几乎每个做对话系统的人都会遇到。

5.1 高频问题速查表

5.2 几个值得写进代码里的经验

先说状态日志。对话系统的线上问题，90%靠日志排查。每轮对话我都强制记录三个东西：用户输入的原始文本、当前系统状态、最终输出。这三样一拼，出问题的时候能快速定位是哪一环坏了。

再说效果优化的节奏。不要指望一步到位。我建议的节奏是：先跑通流程，用测试集验证主流程能走通；然后灰度上线，收集真实用户的失败案例；每个迭代只解决一类问题，比如这周只优化意图识别，下周只处理检索召回。贪多嚼不烂，一次动太多地方，出了问题你连因果链都理不清。

最后说一个很多人忽略的点：对话系统的"体验"问题，很多时候不是AI的问题，是产品设计的问题。比如用户不知道该问什么，这其实是"引导话术"设计的问题。在开场白里告诉用户"你可以问我：怎么退款、物流到哪里了、优惠券怎么用"，比任何模型优化都更能提升实际使用率。

做对话式AI系统，真正难的不是用上大模型，而是让用户在有需求的时候，恰好能得到他想要的答案。这套系统打磨到最后，你会发现最值钱的不是模型权重，而是你手里那套持续迭代的测试集、那把定义清晰的意图体系，和那些踩过的坑换来的日志排查经验。