企业官网建设流程全解析

简介：一套基于扣子COZE平台构建企业官网多轮对话智能客服的资料包，面向有编程基础的开发者与企业技术人员，解决用户问题自动应答、服务推荐、信息查询等客服自动化需求。资料仅含1个docx文档，大小14KB，内容紧凑，已有1468人学习。文档围绕完整项目案例，依次讲解对话流程设计、意图识别与多轮问答配置、插件与API集成、对话个性化与场景扩展、发布与测试，包含意图关键词触发、上下文跟踪、变量提取、HTTP接口调用示例（如订单核验）等可操作细节。针对企业常用场景，还涉及产品推荐、FAQ导航、服务状态查询与用户数据收集；借助COZE的低门槛能力，可直接参考文中方案将客服Bot接入企业现有系统，并通过多轮交互、上下文管理与数据分析持续优化对话效率。文档中的变量提取JSON配置和订单核验请求参数示例，便于读者直接复用。

1. 官网客服“秒回”背后的多轮对话，为什么常用扣子COZE来搭

官网挂着在线客服，用户点开就问“你们那个能定时的小家电还有货吗”，客服回“请稍等，我查一下”，十分钟过去没下文。这种场景我在多家企业官网见过，用户流失就发生在那段等待里。这里要讲的“人工智能客服”，是指基于扣子COZE平台搭建的多轮对话智能客服助手，用来完成企业官网客户服务自动化。它能在多轮对话里记住用户上一句说过什么、把零散信息拼成完整需求，遇到答不了的主动转人工。适合正在选型，或者已经在用扣子COZE、但觉得机器人答得生硬的人。

2. 搭多轮对话客服前先拆能力：意图识别、状态记忆和转人工开关在哪

2.1 用户在一场多轮对话里到底在测什么

单轮FAQ的模式是“问一句答一句”，用户发“怎么退货”，机器人从知识库翻出退货流程，完了。多轮对话不一样，用户开头说“我想买个挂烫机”，中间插一句“之前你们推荐的那个会不会漏水”，结尾又说“算了还是选便宜的”。这里有三件事单轮模型做不到：一是记住“之前推荐的那个”到底指代什么；二是把三个零散信息拼成一个完整的购买需求；三是在用户变卦的时候及时修正意图。这就是多轮对话能力训练的重点，也是用户实际在测试机器人的地方。

我在扣子COZE平台配置这类助手时，习惯先把用户可能走的分支列出来，而不是直接开控制台。分支大致是这样几类：

• 意图没识别到时，要不要追问，追问几轮；
• 槽位没收集齐（型号、地址、数量），怎么二次确认；
• 知识库没有答案时，兜底话术说什么；
• 用户连续表达负面情绪，是否提前转人工。

把这些先写在纸上，再去工作流里配置，比建好机器人再慢慢补要省事得多。很多翻车案例并不是模型不行，而是没定义“当用户没说清楚时，系统下一步干什么”。

2.2 把会话状态挂进工作流：把“聊天”变成“办事”

扣子COZE平台里没有一个叫“状态机”的节点，但它把状态机的逻辑拆成了“节点 + 变量”。常见的做法是先声明一批会话变量，比如 intent_name 存当前意图、slot_json 存已收集到的参数、turn_count 存对话轮数、handover_flag 存是否转人工。然后每轮对话都从消息事件进入工作流，节点依次读变量、判断条件、改写变量、把结果拼回答案。

举个例子。第一轮用户说“我要买挂烫机”，intent_name 被设为 product_intent，同时把“挂烫机”写进 slot_json。第二轮用户说“有没有便宜点的”，工作流看到 intent_name 已经是 product_intent，就不会重新去猜这是不是售后问题，而是直接进入价格话术分支。第三轮用户说“那算了不买了”，intent_name 被改成 abandon_intent，流程可以往挽回话术或结束语走。这个转发过程，本质上是把“聊天”变成了“办事”，每轮都不是独立事件，而是对上一轮状态的增量更新。

有一点要提醒：别在 prompts 里靠“请记住用户刚才说的话”来长期依赖大模型的上下文，上下文窗口再大也是有边界的。扣子COZE工作流里的变量是显式状态，比让模型自己记要可靠。模型负责理解和生成，变量负责记账，各干各的，才能把多轮对话做稳。

2.3 会话落库：先把转人工开关设计在字段里

很多团队把机器人跑起来之后，才发现没有会话数据可回溯，用户投诉了都没法对线。我一般会在第一版就建一张会话表，字段按下面的结构来：

CREATE TABLE customer_session ( session_id VARCHAR(64) PRIMARY KEY, user_id VARCHAR(64) NOT NULL, intent_name VARCHAR(64) DEFAULT '', slot_json TEXT, turn_count INT DEFAULT 0, handover_flag TINYINT DEFAULT 0, created_at DATETIME, updated_at DATETIME, KEY idx_user (user_id), KEY idx_updated (updated_at) );

字段的逻辑说明：session_id 是扣子COZE会话的唯一标识，user_id 从网页端埋点或登录态拿；intent_name 存最后一轮识别到的意图；slot_json 存整场对话收齐的参数，格式可以是 JSON；turn_count 记录轮数，超过阈值却没完成目标时直接置为待转人工；handover_flag 是人工坐席系统要轮询的字段，机器人一闭环不了就把这个字段置 1。这张表同时解决了三件事：给人工坐席提供上下文、给多轮对话能力训练提供样本、给弃单分析提供事实依据。没有这张表，后面所有评测和优化都是空谈。

3. 扣子COZE平台实操：知识库、会话流和代码节点把官网客服跑起来

3.1 把FAQ和产品手册送进知识库：两种灌法，一道门槛

在扣子COZE平台创建机器人之后，第一步是把企业官网的FAQ、产品手册、售后政策灌进知识库。常见做法有两种：一是直接上传 Markdown/PDF/Word 文档，二是填官网 URL 让平台自动抓取页面内容。两种都可行，但我更推荐第一种，因为文档可以提前清洗，URL 抓回来的内容常带导航、页脚和推荐位，噪音多，灌进去反而影响检索命中。

灌知识库有一道门槛必须过：分块。默认按字数切块常常把“产品型号”和“保修政策”切到两块里去，用户问“这台 X1 保修几年”时，检索返回的可能是半句话。我一般把分块大小控制在 200～500 字，每块只讲一件事，产品型号和保修期限放进同一块，不跨主题。文档开头写清楚适用对象，比如“X1 电熨斗常见问题”，后续检索的命中率会明显高。

知识库节点还有几个参数值得调：相似度阈值我习惯设在 0.7 左右，低于这个值的检索结果直接丢弃；返回条数设 3 条，给大模型足够信息但不让它同时看到五六个互相矛盾的片段。阈值设太低会出现“任意问题都从知识库拉一段出来”的幻觉，这是最常见的翻车源。

3.2 编排多轮对话主流程：让机器人记住上一步说的话

知识库灌完，接下来是工作流编排。扣子COZE的工作流绘制区会让你先放一个开始节点和一个结束节点，中间按业务需要添加大模型节点、知识库检索节点、条件分支节点和代码节点。

多轮对话回路是这样串的：开始节点接收用户消息后，先走大模型节点做意图判断，把结果写进 intent_name 变量；再走条件分支，看 intent_name 是 product_intent 还是 after_sale_intent，走不同分支；每个分支里再接知识库检索节点或代码节点，最后把答案拼成文案回到结束节点。第二轮用户再发消息时，工作流重新从开始节点进入，但变量里已经有上一轮的 intent_name 和 slot_json，条件分支就能走到“追问缺哪个参数”而不是重头再猜。

这里要特别处理轮次限制。常见做法是加一个计数节点，当 turn_count 大于等于 3 且槽位还没收齐时，不再继续追问，而是主动转人工。用户可以接受机器人多问一两轮细节，但连续三轮都在问同一个问题，用户就会开始烦躁。这个阈值我一般写死在配置里，改起来也容易。

3.3 用代码节点接真实“查订单”接口，别让大模型猜业务数据

多轮对话里用户常问“我的订单什么时候到”“能不能改地址”，这类数据大模型不知道，必须实时调业务接口。在扣子COZE工作流里可以插入代码节点来干这件事，下面是一个查订单状态的示例：

# 扣子COZE 工作流里的代码节点：查订单状态 import requests def main(params: dict) -> dict: order_id = params.get("order_id") user_id = params.get("user_id") if not order_id: return {"hit": False, "result": "没拿到订单号，向用户追问"} # 替换成企业自己的订单系统地址，注意超时设置 api = "https://api.example.com/orders/query" try: resp = requests.post( api, json={"order_id": order_id, "user_id": user_id}, timeout=5 ) data = resp.json() except Exception: return {"hit": False, "result": "订单系统暂时开小差，给用户一个低姿态话术"} items = data.get("items", []) info = ", ".join([f"{i.get('name')} x{i.get('qty')}" for i in items]) return { "hit": True, "result": f"订单{order_id}当前状态是{data.get('status')}，" f"含{info}，预计{data.get('eta', '待更新')}送达" }

参数说明：params 里的 order_id 和 user_id 是从会话变量 slot_json 里解析出来的，所以用户在上一轮说了“订单号是 12345”，这一轮代码节点就能直接用。timeout 设 5 秒，业务系统慢也不能拖垮对话响应。异常分支返回的是“低姿态话术”而不是让大模型自己编一个订单状态，这个原则要守住，AI 客服可以答不到，但不能谎报物流。

3.4 一组能直接上线的对话参数：模型、温度和记忆窗口

在扣子COZE平台的模型配置里，有几个参数直接决定多轮对话体验，我的参考取值如下：

记忆窗口需要多说一句。不是窗口越大越好，客服场景里用户经常在一个问题上纠缠，超过 15 轮还没解决就该转人工了，硬要模型记住前面 30 轮的内容，反而会把最后几轮的关键信息冲淡。温度设 0.3 是我个人实践下来的平衡点，话术稳定又不至于完全像复读机。“多轮对话能力训练”这类需求，很多时候不是换模型，而是这些参数先用对。

4. 多轮对话能力训练与评测：用回归用例集而不是感觉调机器人

4.1 从日志里捞出那些“被用户放弃”的会话

多轮对话做得好不好，不能靠点几轮测试就下结论。我每月会从扣子COZE平台导出一次会话日志，筛出那些“用户聊到一半就不理人”的记录。这些会话是优化方向的金矿，它们代表了模型没接住用户的地方。筛选可以写一段简单的脚本：

# 从导出日志里筛“被用户放弃”的会话 import pandas as pd df = pd.read_csv("coze_session_log.csv") abandoned = df[ df["is_last_msg"].eq(1) & df["user_content"].str.contains("在吗|人呢|算了|没听懂|气死|再见", na=False) ] stats = ( abandoned.groupby("intent_name")["session_id"] .count() .sort_values(ascending=False) ) print(stats.head(20))

逻辑说明：is_last_msg 标记每个会话的最后一条消息，user_content 里出现“算了”“人呢”这类词，说明用户在等待或放弃边缘。按 intent_name 分组统计后，能看到哪个意图分支放弃率最高，是售后流程太长，还是机器人追问次数太多。参数说明：关键词列表要定期补充，早期只有“算了”“没听懂”，后来加了“服了”“再见”这类词，覆盖更全。

4.2 搭一套回归用例集：覆盖意图、槽位、兜底和转人工四类分支

优化对话时最怕改了一个分支，另一个分支悄悄坏了。我维护了一张回归用例表，每次调整知识库或工作流后，把用例逐条跑一遍再上线。用例集至少覆盖四类分支：

每条用例跑完，记录“通过/不通过/不确定”三档。不确定的用例最值得处理，说明模型输出不稳定，大概率是知识库片段冲突或 prompt 里没定义边界。回归集不用多，50 条左右就能覆盖一个中等规模官网客服的主要分支，每周增补几条新出现的高频问法就够了。

4.3 负样本库与话术修正：多轮对话能力训练的边界在哪

很多人问“能不能微调模型”，在扣子COZE这类平台上，底层模型权重通常是不开放的，真正能做的多轮对话能力训练集中在三层：提示词、知识库、工作流。最常见做法是把用户问了但机器人答错的句子收集成负样本库，比如用户问“你们有没有那种不用插电的熨斗”，知识库没命中，机器人回“对不起，我不明白”。这时不用急着加知识库，先看是“产品确实不存在”还是“需求没归纳对”。前者直接加一条标准问答；后者要修正用户话术到知识库表达之间的检索映射，比如把“不用插电”纳入“无线熨斗”的同义词。

负样本库的积累是个长期活。我每周固定花半小时，把上一周日志里的未命中案例过一遍，标记成三类：知识库缺内容、意图判断错、话术表达差。标记结果分别对应三个动作：补内容、调分支、改提示词。这样多轮对话能力才会稳定上升，而不是靠玄学调热度。

5. 上线前必看的避坑清单：客服机器人翻车多发生在这四处

5.1 答非所问，且第二句话就忘了上一轮说的什么

现象是我测试时连续输入“我想买挂烫机”“刚才那个贵不贵”，第二句直接被当成新问题，回了一段产品百科。原因多半是工作流里没有把第一轮的 intent_name 和商品名写进变量，或者大模型节点没有引用会话变量作为上下文。解决方法是检查工作流：把上一轮识别到的 intent_name、关键实体和已填槽位在节点输入里显式传给下一轮，不要依赖模型的隐式记忆。改完再测同一段对话，看第二轮是否走价格分支。

5.2 两个长得像的产品在知识库里互相打架

用户问“A 款和 B 款有什么区别”，结果机器人把 A 的功率和 B 的重量拼在一起回答，数据完全串了。原因是知识库里两个产品的文档分块重叠，检索返回的 3 条里既有 A 又有 B，模型不知道该信哪个。解决方法是给每款产品的文档加清晰的标题前缀，比如“【产品A-操作指南】”“【产品B-常见问题】”，并且在提示词里写明：当知识库片段涉及多款产品时，必须在答案开头标注产品名称，只陈述对应产品的内容。另一个补救办法是把相似度阈值从 0.7 提到 0.75，减少模糊命中的概率。

5.3 “转人工”明明触发了，人工客服却收不到任何通知

用户说“转人工”，机器人也回了“正在为您转接”，但人工坐席后台空空如也。原因是转人工动作只停留在对话层，没有通过代码节点调用工单系统接口把 handover_flag 写进数据库，更没有通知坐席。解决方法是检查工作流：条件分支命中 handover 后，接一个代码节点，把 session_id、user_id、slot_json、对话摘要一并 POST 到工单系统，再在工单系统里配上企微/短信/webhook 通知。转人工不能只靠机器人嘴上说说，消息链路必须打通到人的终端。

5.4 并发一上来响应时间翻倍，先查这几个地方

上线预热后流量一大，机器人从 1 秒响应变成 4 秒。常见原因有三个：一是知识库索引没预热，首次查询走了慢路径；二是代码节点里的业务 API 响应慢，每次对话都实时调用；三是大模型节点 prompt 太长，每轮都把全部历史塞进去。解决方法是按顺序排查：先看知识库节点是否需要预加载，再看业务 API 是否加了缓存层，最后压缩 prompt 里的历史轮数，超过 10 轮就滚动丢弃旧内容。代码节点里的外部请求如果非实时不可，就加一层 Redis 缓存，把高频查询结果缓存 30 秒。

6. 上线一个月后的进阶玩法：会话摘要、情绪标签和坐席协同

6.1 用会话摘要把长对话压成一张工单传给人工

转人工时直接把完整对话列表丢给坐席，坐席要翻半天才知道用户在干嘛。我一般会在转人工节点前置一个大模型节点，把当前会话内容压缩成 100 字以内的摘要，包含用户姓名或 ID、咨询意图、已收齐的槽位、是否表达过负面情绪、机器人已给出的回复。摘要写进工单的 first_message，坐席一眼就知道从哪接起。这个节点的 temperature 我会调到 0.2，摘要不需要创造性，稳定最重要。

6.2 给对话打情绪标签，命中“投诉/退款”直接置顶提醒

在代码节点里加一组关键词检测，命中“投诉”“退款”“12315”“差评”等词时，给会话打上 emotional_flag=1，同时把该会话在工单系统里的优先级字段置为最高。这个动作不用大模型参与，关键词匹配就够，快且可解释。上线后用了一个月，坐席处理投诉的平均耗时降了不少，因为高危会话不会沉底了。

6.3 每周看一次“未命中对话”，把机器人的黑匣子拆开看

我给自己定的规矩是每周一上午拉一次未命中对话列表，逐条标记是知识库缺内容、意图判断错还是话术表达差。这三类分别对应补文档、调分支、改提示词三个动作。有一次我把知识库相似度阈值从 0.7 调低到 0.65，当周退货咨询的答错率直接翻倍，后来才明白阈值不是越高越好也不是越低越好，而是必须和文档分块质量配合着调。从那以后我再也不乱动阈值，每次只改一个参数，改完跑一遍回归用例集再上线。这些小事不如新功能显眼，但多轮对话的质量就是靠一轮一轮补出来的。希望帮到你。

本文还有配套的精品资源，点击获取