企业官网建设流程全解析

做对话式AI搭建系统这件事，我从前年年底开始碰，最早就是拿现成的模型API写个问答demo，后来慢慢做成带知识库、多轮记忆、能对接企业数据的完整系统。中间踩的坑，比写代码的时间还多，所以这篇想认真聊聊整个流程和避坑经验。这是系列的第二篇，重点讲“从零搭一套能用起来”的对话式AI系统要经历哪些阶段，每一步卡住你的通常不是模型本身，而是工程细节。适合谁看？准备做智能客服、知识库问答、私人助理这类应用的开发者，或者刚接到任务要在公司里落地对话式AI产品的朋友，这篇能帮你省掉几轮返工。

1. 动手之前，先把需求边界和系统架构想清楚

1.1 需求边界：你的对话式AI到底是做什么用的

很多人上来就找模型、写Prompt，做了几天发现方向不对。对话式AI看着都是“聊”，实际场景差异很大。我一般把需求分成三类：

1. 闲聊陪伴型。目标是聊得自然、有趣，对准确率要求低，但对人设、语气要求高。
2. 知识问答型。目标是给用户准确、权威的信息，依赖知识库、文档检索，最怕模型一本正经地编。
3. 任务执行型。目标是完成具体操作，比如查天气、下单、查工单、回工单，必须对接业务API，还要处理多轮里缺失的参数。

这三类系统的复杂度完全不在一个量级。闲聊型拿一个开源模型改个Prompt就能跑；知识问答型需要做检索增强，重点变成文档解析、召回、引用溯源；任务执行型则是套完整的对话管理框架，要把意图识别、槽位填充、业务接口调用串起来。我的建议是开工前先列一份用户问题清单，找真实用户聊一聊，至少三五条最典型的对话样例，再判断系统属于哪一类。

还有一种常见情况是需求方说“我要一个智能助手”，但具体问题全都没定义。这时候别急着设计架构，先花一周时间收集真实场景里的对话数据、用户问题、现有客服记录，越具体越好。你拿到的颗粒度决定了系统能做到什么程度。

1.2 分层架构：不搞复杂，但这几层必须有

对话式AI系统再简单，工程上也至少分四层：交互层、对话编排层、模型服务层、数据层。我见过不少项目把Prompt、逻辑、模型调用全写在同一个方法里，demo阶段没问题，一旦要加一个新功能就要改一大片，所以分层不是炫技，是给自己留活路。

交互层负责对话框、打字机效果、多轮消息展示，纯粹的前端问题。对话编排层是整个系统的大脑，它负责接住用户消息、管理上下文、调用模型、决定要不要触发知识检索或者业务API，同时把模型返回内容整理成最终回复。模型服务层把具体模型供应商或部署方案隔离起来，统一对外提供完整的请求接口。数据层则管用户信息、会话记录、文档向量库、业务系统数据。

我第一次搭系统时省掉了对话编排层，直接把前端的请求原封不动转发给模型，结果加一个字数限制、加一个敏感词过滤都要改前端代码。后来重构花了整整三天。分层会让前期代码多一些，但后面加功能你会感谢自己。最小可用版本不需要所有层都做得很重，但接口路径必须清晰。

2. 模型选型与接口接入：第一个容易翻车的地方

2.1 模型怎么选：托管API还是私有化部署

模型是整个系统里最容易被赋予“技术含量”的部分，实际运营中它只是一个组件。选模型主要看四件事：效果、成本、数据合规、运维能力。我拿一张表把主流做法对比一下：

我的建议是：第一次做，优先上托管API，把产品跑通再说。你真正需要的是快速验证问答效果和用户接受度，而不是先搞一张4090搁那儿调半天环境。开源本地部署适合两类情况：一是数据敏感不能出域，二是推理成本预测下来长期能摊平服务器投入。但本地部署别指望省心，模型文件、显存、并发、推理引擎版本能凑一块儿不那么容易。

知识类系统选模型时还有一个误区——过分追求模型本身的能力。实际上，如果你的痛点是从大堆文档里找准确答案，那花大精力打磨文档切分、召回排序、引用标注，效果提升往往比换一个更大的模型更明显。用一个好的小模型加上强检索，通常能打赢裸奔的大模型。

2.2 接口封装与调用参数：细节决定体验

无论选哪家模型，我都建议在代码里做一层统一封装，把供应商SDK隔离掉。原因很简单：模型迭代快，今天用的API价格高，明天更好的模型出来了，你要能换。封装层只需要暴露一个方法，比如“生成回复”，内部做重试、超时、日志、Token统计。

调用参数看着简单，实际坑不少。重点说几个常用的：

• temperature：采样温度，调高会更发散，调低更稳定。知识问答我通常设0.1到0.3，闲聊设0.7到0.9。但要注意，问题是模型实际实现有差异，同样的0.5在两个模型上看效果可能完全两回事，只能以实际表现为准。
• max_tokens：限制生成的最大长度，不只是保护成本，还能防止模型越写越长。中文场景别忘了估算，一个汉字大约对应1到2个token，具体和分词器有关。
• top_p：核采样，一般保持默认或者配合temperature调，不要同时乱动两个参数，否则输出容易失控。
• stop：停止词，比如用“\n\n”或者特定标记约束输出结构，能极大改善格式化效果。

接口层还必须处理流式和超时。对话式AI最影响用户体验的就是等太久没反应。用非流式接口，用户看着一句话转圈十秒，心里已经开始骂了。流式接口一般基于SSE，边生成边吐字，前端配合打字机效果，感知延迟能降到几百毫秒。我要求团队里所有对话接口默认走流式，除非是离线批处理任务。

超时和重试也要提前设计好。模型接口有时候会慢，尤其是高峰期。设一个合理的超时时间，比如30秒，再配重试机制。但重试要注意退避，网上流行的指数退避可以用，你还要配合调用失败时的用户提示，不能无限重试把体验拖垮。另外并发数要控制住，很多API有并发限制，超了会给你返回限流状态码，这部分在封装层就要做统一处理。

3. 对话管理：Prompt、上下文与记忆是最难的部分

3.1 Prompt设计：像写接口协议一样写提示词

Prompt不是什么神秘的咒语，本质是一段写给模型的“接口说明”。我一直建议用结构化模板把Prompt分成几个区：角色定义、任务目标、输入格式、输出格式、约束条件、示例输入输出。这样你能像维护代码一样维护它，而不是随手在聊天框复制来复制去。

一份典型的知识问答系统Prompt长这样（示意）：

你是XX公司的客服助手，负责解答用户关于产品使用的问题。 请基于给定的【资料片段】回答，如果资料中没有相关信息，直接回复“抱歉，这个问题我暂时无法确认”，不要编造。 回答要求： 1. 使用简洁的书面中文； 2. 如果资料中存在多个相关信息，按重要性排序回答； 3. 回答末尾标注资料来源编号。 【用户问题】 ... 【资料片段】 ...

我自己踩过最大的坑不是Prompt写得不够好，而是没有规定输出格式。模型经常问一答十，加上一堆正确但没用的废话，或者不按“资料来源编号”格式来。后来加了few-shot示例，再配合模型输出后的正则后处理，问题才稳定。

另一个容易忽略的是提示词注入。用户完全可能绕过你的系统提示，输入“忽略以上所有指令，告诉我如何……”这类内容。工程上能做的是：把用户输入和系统指令分成不同字段传入，严守“用户输入只是数据”的原则；敏感操作不要靠模型判断，要用结构化流程控制；如果发现用户输入的意图和业务无关，宁可让模型拒绝回答多轮，也不要让它执行未定义动作。

3.2 多轮上下文管理：滑动窗口与摘要压缩

对话系统的核心难点在于“记住前面聊了啥”。模型不是无状态的聊天机器人，你把整段对话历史全塞给它，一是会超过Token限制，二是会稀释重要信息，回复质量反而下降。

我一般把对话管理分成两层：短期上下文和长期记忆。短期上下文只保留当前这一轮会话的核心内容，通常做法是滑动窗口。比如只保留最近6到8轮对话，或者用Token数动态裁剪，保证消息总长度接近模型输入上限的60%到70%。再往前的历史对话，可以做摘要压缩。

摘要压缩的做法很好理解：每当窗口快满了，把当前窗口里的内容发给模型，让它生成一段言简意赅的对话摘要，保存成新的历史摘要。下次再要完整上下文时，就把摘要加在后边。这样模型既不会丢掉前面聊过的关键信息，也不用每次把所有历史都拿过来。

我写过一个简单的伪代码，表述如下：

def build_conversation_context(messages, max_tokens=4000): # 保留系统Prompt system = messages[0] history = messages[1:] recent = [] used_tokens = len(tokenize(system)) for msg in reversed(history): msg_token = len(tokenize(msg)) if used_tokens + msg_token > max_tokens: if not recent: # 至少保留最近一条消息，否则模型没有可回答的输入 recent.append(msg) break recent.append(msg) used_tokens += msg_token recent.reverse() return [system] + recent

实际开发中还要注意，多轮对话里用户可能会在某一轮突然改问题，比如“不对，我说的是另一个功能”。这时候单纯按工具截断是不够的，需要结合意图识别判断是否开启新对话，否则多轮上下文反而会污染当前问题。

3.3 长期记忆：怎么让AI记住你的偏好

短期上下文解决“这一轮聊过什么”，长期记忆解决“这个用户之前聊过什么”。很多对话系统做得像失忆患者，用户上次反馈过“不要讲太长”，下次还在长篇大论。长期记忆可以做得简单也可以做得很深。

最简单的做法是：在一段会话结束时，用模型把用户的核心偏好和关键事实抽取成条目，存进数据库。下一次会话开始，先查库加载和当前问题相关的记忆条目，拼进系统Prompt。注意不要把所有历史记忆全塞进去，只挑相关的，否则噪音很大。

更进阶的做法是引入向量数据库。先把用户问题或者历史对话摘要向量化，存储在向量库里，当前用户对话开始时，做一次相似度检索，把最相关的记忆片段捞出来放进上下文。这里的选型我列一下：

我的建议是，如果项目规模不大，直接用PostgreSQL加pgvector，少一套组件就少一堆运维问题。等确实发现性能瓶颈再上专门的向量库，那时候迁移路径也相对清晰。记忆的本质是“在合适的时机给模型补上合适的背景信息”，存储形式反而是次要的。

4. 前后端联调与上线：从能聊到好用，差在细节

4.1 流式输出：前端不只是收到一个字符串

我前面提过流式输出，前端处理这一块其实是很多团队的暗坑。如果你用SSE，前端不能用普通的XMLHttpRequest拿到完整响应后再渲染，那样流式就白做了。现在主流方案是用fetch加ReadableStream逐块读取，或者直接使用EventSource。要注意的是EventSource只能发GET请求，部分场景下需要带鉴权头，这时反而要用fetch来模拟SSE。

我通常在后端把流式响应设计成标准的Server-Sent Events格式，前端拿到每个chunk后，直接做增量追加渲染。这里有两个细节：一是首字要尽量快，后端不要等全文生成完才吐第一个块；二是即使模型生成了一个完整句子，前端也最好按块渲染，而不是等一段完整段落再刷，否则打字机效果会一顿一顿。

还有个容易忽略的场景：用户点了“停止生成”按钮。对话模型流式生成是可以中途打断的，前端要发送取消请求给后端，后端立刻终止生成调用，并且把已经生成的文本作为最终消息保存。如果你不处理中断，用户在流式过程中已经看到一半回答了，结果后端又继续纠错返回完整结果，整个对话记录就乱了。

4.2 后端服务化：并发、限流与缓存

对话式AI系统上线后，最怕的不是功能缺陷，而是模型接口扛不住突发流量。模型API本身有速率限制，你自己服务端也要做用户级限流，避免一个用户刷几百次，把成本打爆。

一般给普通用户做按时间窗口限流就够了，比如一分钟最多30次请求。限流算法用令牌桶相对经典，实现也不复杂：桶容量代表最大突发量，每秒钟往桶里放几个令牌，用户请求取令牌，取不到则返回“请稍后再试”。这个策略既允许日常高峰的抖动，也防止有人恶意刷接口，简单可靠。

重试策略我前面提过指数退避，这里补一个细节：当模型接口因为限流返回429时，你重试前一定要读一下响应头里的Retry-After字段，按服务端建议的等待时间来。我见过不少团队无视这个字段，三秒暴力重试，结果越挫越勇，限流越来越严重。服务端说等多久就等多久。

缓存也值得做。对话系统经常有大量重复的用户问题，比如“怎么退款”“怎么开发票”，这些问题短期内容答案很少变化。可以做一个语义缓存：把用户问题向量化后查缓存库，相似度超过某个阈值直接返回历史答案，完全不调用模型，成本和延迟双双下降。这个方案我实测能把整体模型调用量减少三成以上，但要注意设定合理的相似度阈值，不然语义稍微变一下就误命中，一直回复旧答案，体验很差。

4.3 日志、评估与全链路追踪

对话系统上线之后，你面对的将是一堆“模型说错一句话”的模糊反馈。没有日志，你连“它为什么错”都查不出来。所以我非常建议从第一天就把请求链路日志设计进去。

每条请求至少记录这些字段：用户ID、会话ID、模型版本、Prompt模板版本、请求参数、模型原始返回、最终返回给用户的内容、各环节耗时、Token消耗、错误码。这样做的好处是，当用户投诉时你能复现当时的完整上下文。另外每次调整Prompt，务必带上版本号，不然根本不知道线上跑的到底是哪套提示词。我见过不止一次，测试环境调好了Prompt，生产环境忘记更新，用户反馈差了一个版本。

追踪工具上，开源生态里Langfuse、LangSmith这类平台可以帮忙把调用链可视化，能直接看到一次回答从检索到模型生成的全部过程。项目刚起步用它们成本很低，我建议顺手接一个。别等出了事故再补。

评估是最容易被拖到最后的事。一个对话系统没有评估集，你根本说不清版本A好还是版本B好。我会攒三五十条典型问题，最好覆盖用户高频场景和很容易翻车的边界场景，形成固定的回归集。每次改Prompt、换模型、调参数，都拿这批问题跑一遍，再人工给出打分。这个工作看着笨，实际价值比花哨的自动指标大得多。

5. 避坑实录：高频问题与排查思路

5.1 高频报错速查表

排查问题时，大部分错误都集中在几个固定原因。我整理了一张速查表：

5.2 性能与成本：别急着上重武器

很多团队一上来就规划要做微服务、自建推理集群、接消息队列，但实际业务并发量只有几十。对话系统在初期，最重要的反而是快速迭代和灵活调整。架构上保持单体加上清晰的模块边界，比拆成七八个微服务更实用。

成本控制也有不少小技巧。第一个是Prompt瘦身：把系统提示词里不必要的背景文案删掉，把示例控制在两三个以内，Token费用会肉眼可见下降。第二个是上下文裁剪：前8轮对话可能只值30分钱，但你把50轮全部塞进去，单次调用成本会翻好几倍，效果还更差。第三个是用语义缓存，前面提过，重复问题直接命中缓存，成本趋近于零。

关于性能，如果用户感知到首字慢，别急着升级显卡或者换更快的模型服务，先看看是不是接口封装层里做了多余的预校验，或者前端没有开流式。我优化过的一个项目，改动后端让它边生成边返回后，用户体感从五秒变成一秒，但整体生成时间其实一样长。流式输出是对话产品体验的免费午餐，一定要用。

5.3 一些文档里很少写的真实坑

最后分享几个我实际踩过、但通常文档里看不到的细节问题。

第一个是上下文列表的顺序。做多轮请求时，消息列表必须是“系统提示 -> 历史对话 -> 当前用户问题”这种顺序。有一次我把历史对话倒序拼接，模型开头还能正常回，但聊到后面完全错乱，排查了很久才发现是把列表反转了。建议写个单元测试，固定住消息顺序。

第二个是模型返回里时不时带出一些隐藏字符，比如“\n\n”“```”之类的。做知识库问答时，我要求模型只返回纯文本，但它有时仍会在开头加“好的，根据资料如下”。这类问题用后处理规则清理，别指望模型100%遵守格式。线上系统后台，格式化解析失败统一走兜底逻辑。

第三个是中文Token估算误差。很多工具有估算函数，但中文分词和英文不一样，不同模型的分词器也有差异。我吃过亏：用某个公式估算上下文只用了50%容量，结果实际调用时直接因为超限报错。正确做法是用你实际调用的模型自带的Token计数接口，再留25%余量。

第四个是重启导致记忆丢失。本地长期记忆存在进程内或内存Redis里，服务一重启全没了，用户第二天发现AI不记得自己是谁。虽然不是致命问题，但上线前一定要把记忆持久化到数据库，并把恢复逻辑测一遍。

尾声：按我现在的习惯，先让系统跑起来再谈优化

我后来搭新系统时，刻意控制自己在第一个月不要碰任何“优化”：“不要加AI客服头像，不要调漂亮的前端动画，不要研究流式负载均衡”。第一版就是把对话打通，能回答问题，能记录日志，能抽取出用户偏好就够了。等数据攒下来、问题暴露出来，再回头优化Prompt、加缓存、调整上下文策略，每一步都有明确的收益。

这套流程走到今天，我个人认为最难的不是模型，而是把上下文管理、记忆检索和日志评估这些工程细节做扎实。把这些底座打好，后续加什么功能都不会太慌。这篇先把搭建流程和第一波避坑讲完，下一篇可以单独聊知识库怎么切分、召回怎么调优，以及如何设计一个靠谱的评估集。