对话设计框架

对话设计要解决的具体问题

把客服机器人接上大模型之后，最常见的翻车现场往往不在模型能力，而在对话结构：机器人只会单轮问答，用户一旦跑题、用口语化表达（比如「那个大号的」）或中途改变意图，对话就陷入死循环；像订单追踪这类多步任务，常在槽位收集到一半时不知如何继续；出错时只会重复一句「我不明白」，用户别无出路。这个技能要解决的是：如何让多轮对话自然容错，同时把用户稳定引导到目标结果。

技能的核心能力与关键步骤

技能提供一套覆盖完整设计生命周期的六步工作流：

• 定义人设与边界：明确性格特征、用词偏好、emoji 使用规则和升级触发条件，写成风格指南。能做好五件事的机器人，胜过什么都会一点的五十件事机器人。
• 映射意图与实体：区分主任务意图（如 order.place）与元意图（如 help、cancel），为每个意图列出必需槽位，用有向图描述 happy path、分支点与退出条件。
• 设计槽位填充与消歧：安排槽位收集顺序，为「the large one」这类模糊输入设计候选选项；支付、取消等高风险操作强制二次确认。
• 构建错误恢复：三级 fallback——低置信度时引导用户换说法，两次失败后给出受限选项，再失败则携带完整上下文转人工，绝不留死路。
• 状态管理与上下文继承：区分跨会话持久槽位（如用户姓名）与任务级重置槽位，用上下文栈支持中途切话题并可回到原流程。
• 原型与迭代：用对话脚本或 Botmock、Voiceflow 搭建低保真原型，以任务完成率、fallback 触发率等指标定位最弱流程优先改进。

适用边界与注意点

• 这是一套设计框架而非运行时组件，槽位收集和状态持久化需在你选择的平台上实现，Web widget、Slack、WhatsApp 或语音助手各有约束。
• 官方建议优先设计「不开心路径」（unhappy path）：错误恢复和边界情况的投入应大于 happy path。
• 机器人单次回复控制在三句以内，复杂信息拆成多轮或用列表、卡片呈现；不可逆操作前必须确认。
• 还需处理多意图输入、矛盾信息、用户情绪、平台限制等边界场景。