智能客服对话流程与异常兜底设计

对话流为什么总是崩

客服机器人上线前，团队通常把注意力放在主流程上：识别意图、填充槽位、返回结果。但真实用户不会照着脚本说话。一句 asdfghjkl、一个订单号和退款意图混在一起的请求、或是中途突然切换话题，都可能让对话卡死或误执行操作。多数上线后的事故不是主流程写错了，而是异常路径没有设计过。这个技能就是为解决这个问题而生的。

技能如何工作

• 角色与边界先行：先定义机器人的语气、用词偏好、emoji 规则与升级触发条件，明确 bot 能做什么、不能做什么。能稳定处理五件事的 bot，胜过声称能做五十件事的 bot。
• 意图与实体建模：区分主任务意图（如 order.track、account.reset_password）与元意图（help、cancel、speak_to_human），为每个意图列出所需槽位，把对话画成有向图，标注 happy path、分支与出口条件。
• 槽位填充与消歧：定义槽位收集顺序、必填与可选槽位；当用户输入歧义（如“the large one”）时，给出有限选项而非开放式追问；对支付、取消等高风险操作强制确认。
• 三级兜底机制：置信度低时先让用户换个说法；两次仍不明确时切换为受限选项列表；仍失败则携带完整上下文转人工，并给出参考编号。任何错误状态都不允许死路。
• 上下文与状态管理：明确哪些槽位跨轮次保留（如用户名）、哪些任务间重置；支持中途插话（“先帮我查下余额”）后回到原流程。
• 原型与度量迭代：用 Botmock、Voiceflow 或 Dialogflow CX 做低保真原型，跟踪任务完成率、平均解决轮次、兜底触发率与转人工率，优先修补最弱流程。

适用边界与注意点

• 该技能只负责对话设计层，不涉及 NLU 模型训练或后端接口实现，落地时仍需与具体平台能力配合。
• 平台限制要单独处理：WhatsApp 的消息长度与按钮数不同于 web widget，不要套用同一套话术。
• 遇到用户情绪波动时，先共情再解决，避免机械式积极回复。
• 用户给出矛盾信息（如同会话中两个邮箱）时应主动澄清，而不是静默取最后值。