企业官网建设流程全解析

大促刚结束，客服后台的消息列表红点一直跳，运营同事在群里发了一句：客服真的不够用了。那段时间我一直在想，如果把大模型接进来做电商客服，能不能顶一阵子？但真去试了才发现，直接丢一个通用模型当客服，大概率会被用户怼回来，甚至把店铺投诉量拉高。我们后来花了大约两个月时间，把一个电商客服+导购智能体完整做了出来，这篇文章准备把整个设计思路和落地过程摊开来讲，包括怎么拆架构、怎么建知识库、怎么定义意图和工具、上线后怎么评测、踩了哪些坑。如果你也在考虑用大模型做类似的客服、导购或私域助手，这篇文章应该能帮你少走不少弯路。

1. 为什么客服智能体不能直接拿通用大模型顶上

1.1 客服表面是对话，本质是“业务操作+体验承诺”

刚立项那天，我们几个人的想法很简单：接一个大模型，给一段系统提示词，再丢一堆商品说明，它不就能回消息了吗？结果第一次内测就翻车了。有用户问“我的订单到哪了”，模型回了一长段“您的订单正在运输中，请耐心等待”，问题是那笔订单在系统里压根没有付款记录。这不能怪大模型，它在聊天里表现得像一个“客服”，但它没有权限查订单，也没有接入业务系统，所有回答都只能靠猜。

电商客服和普通闲聊机器人最大的区别在于：客服的大多数动作不只是说话，而是要落到业务系统里。用户说“我要改地址”，你得真的去订单系统里调出这笔订单，确认收货地址能不能修改，再执行修改；用户说“我要退货”，你得查商品是否在可退周期内、有没有运费补贴，然后生成售后单。这些动作只要有一个环节出错，就不是“回复质量不高”的问题，而是实实在在的客诉和资损。

所以第一步想清楚的事是：智能体不能只做一个会聊天的语言模型，它必须是一个能编排工具、能查数据、能按照规则办事的系统。语言生成只是最外层的壳，真正的核心是业务动作。

1.2 客服和导购是两套人设、两套目标，别混在一个prompt里

再往深看一层，电商场景里的“客服”和“导购”其实是两种能力，甚至可以说两种人格。客服的核心目标是“不出错”：准确解释规则、如实告知物流、不轻易承诺赔偿、不跟用户起冲突。它的语气是克制的、被动的，用户问什么答什么，绝不画蛇添足。

导购就不一样了。导购的目标是“多卖货”：用户说“随便看看”，你得从对话里挖出送人还是自用、预算多少、偏好什么颜色，然后主动推荐商品，把“随便看看”聊成“我想买这个”。它的姿态是主动的、热情的，需要会用利益点打动用户。

把这两个目标塞到同一个提示词里，模型很容易“人格分裂”。比如用户说“这个外套多少钱”，客服线应该直接报价格；导购线想的是“要不要顺便告诉他搭配裤装更划算”。第一次上线测试时我们就观察到，智能体有时候过度热情，用户明明是在问退货流程，它却在推荐“如果不喜欢可以换季新品”，用户直接说“你是机器人吧”。

后面我们把架构改成了“一个入口、两条工作流”——先用意图识别把用户分流到客服线或导购线，每条线用自己的提示词、工具和知识库。这个拆法的好处是：客服线可以严格卡规则，导购线可以放开话术；客服线出错了能追踪到规则哪里不严，导购线效果不好也能单独调参，不会互相污染。

1.3 现实约束：时延、成本、红线，一个都不能放松

抛开原理讲现实。我们上线前排了一组硬性约束，全部来自业务侧的反馈：

• 首屏响应时间不能超过3秒。用户可没有耐心等一个“正在思考”的转圈动画，超过3秒就会连续追问或者直接关掉窗口。
• 单人单轮对话成本要压到可控范围。一通咨询往往要来回七八轮，如果每一轮都调用一次高配大模型，大促当天账单会非常难看。
• 平台上有一批“红线词”属于绝对不能乱说的，比如“保证赔付”“无条件免单”“绝对正品”这类确定性承诺，模型一旦自由发挥说出了口，店铺就要背锅。

我把这些约束写在项目第一页文档里，时刻提醒自己：这是一个工程系统，不是一次大模型调用。

2. 整体设计：一个入口分发，两条工作流各干各的

2.1 入口层：先决定“该聊商品还是该办业务”

整个智能体最前面是一个轻量入口层，它不直接跟大模型对话，而是先把用户消息分门别类。这个入口我们同时用了规则和模型：规则负责处理确定性信号——用户消息里出现“退”“换”“投诉”“人工”等词，基本可以直接判断为售后或客诉；模型负责处理模糊信号——用户说“你们家有没有适合送妈妈的包”，这类话没有售后词，但明显是导购需求。

入口层把用户请求打成四类标签：售前咨询、售后服务、导购推荐、其他对话（包括闲聊和脏话等）。前两类走客服工作流，第三类走导购工作流，最后一类直接用固定话术处理，不占用大模型推理资源。

为什么要单独做这层分发？因为如果不做分流，让一个模型同时处理售后、销售、闲聊，最后每个任务都做不精，还会出现“用户问退货，模型推荐新品”这种尴尬情况。入口层把复杂问题先拆开，每条下游链路只需要面对自己那类问题，提示词可以写得更窄、更准、更容易维护。

2.2 客服工作流：查得准、答得稳、不越权

客服线内部是一条标准的“感知-决策-执行”链路，拆成四步：

1. 意图识别和槽位抽取：识别用户要查物流、查订单、申请退款还是开发票，顺带抽取出订单号、商品名、退款原因这些关键信息。
2. 工具调用：根据意图去调用订单查询、物流查询等接口，拿到真实数据。
3. 知识检索：从售后规则库里召回对应的政策片段，比如退款时效、运费承担方、发票开具流程。
4. 回复生成和安全校验：把工具数据和规则片段拼进提示词，让模型生成一段人话，生成后再过一道敏感词校验，确认没有越过红线。

伪代码大概是这样的：

def handle_service(user_msg, session): intent, slots = parse_intent(user_msg, session) if intent == "logistics_query": trace = call_logistics_api(slots["order_id"]) policy = retrieve_policy("logistics_status", trace["status"]) reply = generate_reply(intent, trace, policy) reply = safety_check(reply) return reply elif intent == "refund_request": # 退款这种破坏性动作，先确认，不直接执行 return ask_confirm(slots)

每个环节都做成独立接口，而不是让大模型一把抓。这样做的最大好处是可观测：哪里出问题，直接定位到具体环节，不用猜模型到底“理解错了什么”。

2.3 导购工作流：把“随便看看”聊成“我要买这个”

导购线和客服线完全不同，它不查订单，不做售后，它只做一件事：从用户的模糊语句里挖需求，然后给出有说服力的商品推荐。

用户的原话往往非常短，比如“想给爸爸买个保温杯，不要太贵的”。这句话信息量很少，但我们能抽取出的槽位有：使用场景是礼物、目标人群是中年男性、价格意向是“不要太贵”。有了这些槽位之后，导购线开始干活：

1. 召回候选商品：从商品库里按品类、价格带、标签召回8到10个候选。
2. 生成对比信息：把每个候选的参数整理成几句话，比如容量、材质、保温时长、重量。
3. 生成推荐话术：根据用户的场景选择最重要的一到两个卖点，而不是把所有参数都堆给用户。

我们当时给导购线定了一条原则：推荐必须有依据，任何结论都要落到具体参数上。同一款保温杯，对“送爸爸”的用户，理由可以落在“500ml大容量适合喝水多的人”；对“送女朋友”的用户，落在“轻量设计携带方便”。模型不能只会说“这款很棒”，要能解释清楚棒在哪里。

2.4 两条工作流怎么切换，逻辑要钉死

系统里经常出现的情况是：用户本来在问商品，聊着聊着突然说“那我先退了，你们这个也不便宜”。这时候智能体必须立刻从导购线切回客服线，不能再补一句“那您可以看看另一款更实惠的”，那只会火上浇油。

我们定义了几条切换规则，全部写死在入口层：

切换规则是血的教训总结出来的。一开始我们没有做强制切换，结果模型在用户生气的时候还在推商品，体验非常差。把逻辑钉死、用规则兜底之后，哪怕模型再傻，也不会在错误时间干错误的事。

3. 冷启动知识库：把卖点和售后规则变成可检索的上下文

3.1 冷启动数据从哪来：翻聊天记录、啃商品详情页、逼运营交底

知识库是整个智能体的记忆。没有知识库，模型就像一个口才很好但什么都不懂的新员工。我们冷启动的时候没有花哨的办法，就是老老实实做了两周的“知识整理”：

第一，翻历史聊天记录。把所有能导出的客服会话导出来，筛出高频问题。常见的是“什么时候发货”“运费怎么算”“尺码偏不偏”“有没有赠品”，这些直接整理成一对一的Q&A条目。

第二，啃商品详情页。每个商品页的规格参数、卖点文案、常见疑问，我们抽成了结构化字段。比如一款杯子，参数表里有“容量500ml”，卖点文案里有“食品级不锈钢”，常见疑问里有“能不能放微波炉”。这些内容分开存，类型不同，后面检索策略也不一样。

第三，逼运营团队把售后规则以书面形式写出来。退换货周期、运费补贴上限、发票开具流程、赠品缺失的处理方式……这些规则过去散落在各个人脑子里，不写出来，模型根本无从学起。我们用了一周时间让运营一条一条填表，这一步虽然枯燥，却是后面所有准确性的地基。

3.2 分库：售前、售后、话术各管各的

一开始我们把所有知识都塞进一个向量库里，结果发现一个严重问题：用户问“退货运费谁出”，向量检索经常会召回一堆商品介绍，比如“运费说明：偏远地区不包邮”，跟售后政策混在一条上下文里，模型生成回复时就容易张冠李戴。

后来我们把知识库拆成了三个子库：

分库的价值是避免“上下文污染”。售前库管商品、售后库管政策，各自独立检索、独立过滤。模型生成回复时只拼接对应库的内容，规则就清晰多了。特别是售后规则这种强逻辑内容，更适合用规则匹配去精确命中，而不是靠向量相似度去“猜”。

3.3 混合检索，而不是只靠向量召回

只做向量检索的另一个坑，是对数字和型号不敏感。我们实测过，向量检索对语义相近的句子召回效果好，但到了精确数值就时常漂移：用户问“500ml的保温杯有吗”，向量检索可能召回“550ml”的产品，因为语义相似度太高了。

所以后来我们做的是混合检索：

• 关键词精确匹配管型号、规格、数字类查询，比如“500ml”“316不锈钢”“订单号”。
• 向量召回管口语化表达，比如“这衣服掉色吗”对应到洗涤说明。
• 规则匹配管政策类问题，比如“退货地址是多少”直接从售后规则库精确拉取。

三类结果会合并排序，取分数最高的前几段作为上下文。排序时有个小技巧：关键词精确命中的结果权重最高，因为数值和型号类的错误是不能容忍的；向量召回的结果降一档，因为它更多是扩展语义，不是精确事实。

3.4 可刷新的“事实池”，防止参数过期

知识库还有一个绕不开的问题：商品数据会变。价格会变、库存会变、上下架状态会变。如果这些动态数据写进长期知识库里，模型拿到的永远是旧数据。我们曾经出过一个事故：智能体推荐了一款已经下架的连衣裙，用户高高兴兴地点进去，发现链接404，转头就是一个投诉。

后来我们把知识库分成两层：静态知识和动态事实池。动态事实池专门存状态变化频繁的字段——商品当前是否在售、实时库存、当前价格、优惠活动标识。这些数据不放进长期知识库，而是定时从商品系统同步到内存表中。生成回复前，先查事实池拿到最新状态，再结合知识库里的静态卖点描述，最后才让模型开口说话。

这个改动之后，“商品已下架但还在被推荐”的坑基本被填平了。事实池刷新频率不用太高，我们设置的是五分钟同步一次，大促期间会缩短到一分钟一次，够用且不至于压垮商品接口。

4. 意图识别与状态机，决定智能体“什么时候该闭嘴”

4.1 意图标签体系不是拍脑袋，是从真实会话里长出来的

意图识别是智能体的大脑，它必须知道用户这段话说的是“想买东西”还是“想退东西”，之后所有动作都建立在这个判断上。我们最初照着网上常见的对话系统标签表套了一版，结果发现根本不好用，因为电商场景的意图颗粒度太细。

后来我们老老实实把历史会话按频次做了个统计，最后沉淀出十几个高频意图，比如：

有了这版标签之后，我们再去让模型做意图分类，准确率明显提升，因为标签本身更贴合真实业务。这个梳理过程很耗时，但是必须做。标签体系是后面所有评价指标的地基，如果标签本身混乱，再准的分类器也没有意义。

4.2 多轮状态机：追问到槽位齐了再执行，别让用户重复填

客服场景里，用户的第一句话往往信息不全。比如用户说“我要退货”，缺了订单号，这就要靠多轮对话把缺的槽位问出来。我们把这类流程做成状态机，每个意图对应一组必填槽位，当前缺哪个就问哪个，一次只问一个，不打扰用户。

举个例子，“退货申请”这个流程的状态序列是：

1. 用户说“我要退货”，系统发现缺订单号。
2. 系统问：“方便提供一下订单号吗？”
3. 用户发来订单号，系统查单确认商品信息。
4. 系统继续问退款原因，用户选择“尺码不合适”。
5. 所有槽位齐了，生成退货指引（包括地址、退回要求、注意事项）。

状态机里最重要的一条经验是：该闭嘴的时候必须闭嘴。槽位齐了、该落地执行了，就不要再追问“还有其他需要帮忙的吗”——这句话在真人客服嘴里叫服务周到，在智能体嘴里就是机器人味拉满。用户体验的一大来源就是节奏感：系统知道什么时候该问、什么时候该停。

4.3 一个让我印象深刻的误判：把“催发货”听成了“要退货”

这个坑必须放在前面说，因为它太典型了。有一次内测，用户发来一句：“你们到底什么时候发货啊，再不发我就退了。”意图识别模型把它识别成了“退货申请”，于是智能体回复：“好的，您是想要申请退货吗？”用户当场炸了：我不是要退，我是在催发货！

我们复盘原因，发现两个问题叠加在一起：第一，这句话里同时出现“发货”和“退”，模型对“退”字的敏感度过高，直接归到了退款类；第二，我们没有做“破坏性动作确认”，退货这种高影响操作，系统直接就准备接单了。

修正方案是双管齐下：在意图识别层增加一个“催发货-潜在退货”的边界意图，用模板去匹配“再不发我就退了”这类句式；在动作层规定，所有退款、索赔、投诉类动作必须先发一句确认句——“您是希望申请退货，还是查询发货时间呢？”一句话确认，成本极低，却能避免最严重的用户情绪恶化。

5. 工具调用与系统联动：让智能体真正能“办事”

5.1 需要定义的几类核心工具：查询、修改、创建，一个都不能少

智能体要“办事”，就必须能把自然语言翻译成对系统的调用。我们把工具分成几类，每一类都采用统一的函数描述：

• 查询类：查询订单详情、查询物流轨迹、查询优惠券。
• 操作类：修改收货地址、申请退货、重新发起配送。
• 计算类：计算预计退货金额、计算满减差价。

每个工具的定义我都会写成统一格式，方便模型理解参数和约束：

{ "name": "query_logistics", "description": "根据订单号查询包裹物流轨迹", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "用户提供的订单号" } }, "required": ["order_id"] } }

这里有个容易被忽视的点：工具描述要写得足够具体，尤其要说清楚“什么时候用、什么时候不用”。比如查询物流的工具描述如果只写“查询物流”，模型很容易在用户问“发货了吗”时顺手调用；实际上这个动作完全可以等一版再说，减少一次接口调用就降低一次出错概率。描述越精确，模型越不容易误调用。

5.2 从工具返回数据到“人话”的翻译：别把JSON丢给用户

工具返回的数据是机器语言，不能直接拼到回复里。我们内部定了一个规矩：系统返回的数据永远先经过一层“话术模板”，把状态码翻译成用户能看懂的表达。

光有模板还不够，还要加一层校验逻辑。工具返回的数据如果显示订单不存在，就绝不能生成“您的订单正在运输中”，哪怕模型再想顺嘴编，校验层也会把它拦下来。这种“生成前校验”是减少错误承诺的核心手段。

5.3 转人工兜底，别让用户陷在死循环里

不管智能体做得再好，总会有它搞不定的事。我们把“转人工”当成系统的安全阀，而不是失败。触发转人工的条件我们设置了四条：

1. 用户主动要求人工客服。
2. 进入投诉、赔付、高阶纠纷场景。
3. 连续两轮意图确认失败，模型始终不确定用户要干什么。
4. 命中红线词，系统判定不能继续对话。

转人工时，系统会把完整会话记录、识别到的槽位、当前走到哪个状态、工具调用结果，全部打包给坐席后台。人工客服接过来时已经能看到用户的完整上下文，不需要用户再复述一遍。刚开始我们没做上下文传递，转人工之后用户要重新解释半天，体验比没有智能体还差。补上之后，这个环节才算真正闭环。

转人工的另一个小细节：如果用户情绪已经非常激动，智能体转人工之后就不要再多话了，直接发“我帮您安排人工客服，请稍等”。不要在结尾画蛇添足加一句“祝您生活愉快”，那只会让用户更冒火。

6. 上线后的评测与踩坑：从“能用”到“好用”不是一回事

6.1 客服线看什么数据：准确率只是底线，红线违规才是高压线

智能体上线之后，评测不能只看“回答得像不像人话”。我们客服线的指标体系分三层：

准确率、一次解决率都只能说明系统“大多数时候好用”。真正要盯死的是红线违规率，因为这是一个“一次事故就可能抹掉一百次好评”的领域。我们每周会抽100条会话人工复核，凡是红线违规样本，会立刻回溯到提示词、知识库、校验层，定位是哪个环节漏的。

还有一类指标不能只看平均数：夜间与大促期间的响应情况。白天流量小，高配模型慢慢推理也没关系；夜间凌晨流量几乎为零，但恰恰是用户最容易急躁的时候。我们后来专门为夜间启用了降级策略，模板能答的问题绝不让大模型回答，保证弱算力环境下也不会“卡死”。

6.2 导购线看什么数据：盯着转化率，但不做“硬推荐”

导购线的评测和客服线完全不同，它关心的不是“有没有犯错”，而是“有没有卖出东西”。我们看的主要指标是：

• 商品卡片点击率：智能体推荐的商品，用户有没有点进详情页。
• 推荐咨询转购率：聊完推荐后，用户有没有真正下单。
• 平均客单价：导购对话带来的成交金额是否高于自然流量。

不过这里有一个反直觉的提醒：导购线最怕的不是推荐效果差，而是“硬推荐”。用户明明没有购买意向，智能体还在反复推商品，这会让用户产生强烈抵触，甚至演变成投诉。所以我们同时监控一个反向指标——推荐引发的投诉率，只要这个指标上升，立刻收紧推荐触发条件。

导购线的调优我们还发现，把主推商品和活动信息在话术里“软性植入”比直接说“现在买可以减30元”效果更好。比如推荐一款保温杯时顺带说“这款正好参与店铺满减活动”，用户会觉得自己在做选择，而不是被推销。

6.3 踩坑记录：参数过期、提示注入、串单、回复过长

上线这几个月，我们踩了不少坑，很多都很有共性，整理成了一张表：

这里最值得展开的是“提示注入”。我们第一次做智能体时完全没想过这个点，直到有一天某用户在对话框里输入了一串奇怪指令，模型开始用一本正经的语气承认“我是AI助手，不是店铺客服”，运营当时冷汗就下来了。后来我们把所有用户输入先过一遍风险词过滤，发现类似“ignore previous instructions”的模式直接替换成普通客服模板。这类安全机制不用做得特别聪明，能挡住大多数试探就够了。

6.4 成本控制：模型分级与模板兜底

最后说一个所有做智能体的人都躲不开的话题：成本。我们的做法是模型分级，不同任务用不同规格的模型，而不是所有对话都走最强配置。

实测下来，80%的会话用“小模型+工具+模板”就能解决，高配模型只用在真正需要推理的场景。这个比例带来的成本收益非常明显，大促期间服务器负载也没有失控。

模板兜底是最后一道防线：如果大模型接口超时、返回失败，或者识别结果置信度过低，系统直接走预设模板回复。模板内容宁可保守，也绝不胡编。用户最反感的是“客服消失”和“客服乱说”，模板兜底至少保证了两个都不会发生。

回头看整个项目，我最大的感受是：做一个电商客服+导购智能体，模型能力只是地基，真正决定上限的是数据新鲜度、工具调用严谨度和转人工兜底的完整性。这三样任何一样掉了链子，模型跑得再快也白搭。如果让我重新做一遍，我一定把商品事实池的定时刷新放在第一天去做，而不是上线两周后才补上；我也一定会在第一天就让“确认后执行”成为所有破坏性动作的默认规则，而不是等误判事故发生了再改。这些细节不是大模型能教你的，是用户一条一条消息把你教会的东西。