对话流程

设计目标

AI 客服的难点不是单轮回答，而是每一轮都要判断「现在该继续自动处理，还是该交给人工」。外卖客户的情绪变化很快，尤其是订单延迟、食品质量、漏餐错餐和退款场景。如果系统只按 FAQ 方式回答，很容易在投诉场景里显得机械；如果系统过早转人工，又会牺牲自动解决率。对话流程必须把意图、风险、工具、知识库和状态管理结合起来。

系统的流程目标是：客户提出问题后，先识别意图和风险，再选择知识库回答、工具调用、追问补充信息或转人工。每次回答都留下可复盘数据，包括意图、引用文章、工具调用、转人工原因、成本和延迟，供看板和质检使用。

总流程

flowchart TD
  A[客户发送消息] --> B{识别意图与风险}
  B -->|FAQ/营业/活动| C[检索知识库]
  C --> D[生成带引用回答]
  B -->|订单状态| E{是否有订单号}
  E -->|有| F[调用订单查询工具]
  E -->|无| G[追问订单号或手机号后四位]
  F --> D
  B -->|售后投诉| H{是否命中高风险}
  H -->|过敏/食品安全/强烈负面| I[转人工并创建工单]
  H -->|一般漏餐错餐| J[收集信息并建工单]
  J --> K{是否可自动解释}
  K -->|可解释| D
  K -->|不可解释| I
  B -->|骚扰/非业务| L[短回复引导回业务]
  D --> M{客户是否继续追问}
  M -->|同类重复| N[降低置信度并考虑转人工]
  M -->|新问题| B
  I --> O[后台接管并展示等待提示]

阶段拆解

第一阶段：上下文组装。系统装配商家信息、客户信息、会话状态、最近若干轮消息和可用工具。客户消息可能来自 Widget 或嵌入式 SDK，但都收敛到同一套 chat API。上下文窗口控制在最近 10 条加会话摘要以内，避免无效成本与噪声。

第二阶段：意图与风险判断。系统先跑关键词规则（订单号、退款、过敏、转人工、老板、少送、送错、异味等），规则无法确定时调用 LLM 辅助判断。高风险规则优先级高于普通 FAQ：客户一句话同时问「招牌菜」和「过敏能不能吃」时，系统会先处理健康风险。

第三阶段：动作选择。FAQ、营业和活动类问题进入知识库检索；订单类问题进入订单工具；售后类问题进入工单或转人工分支；非业务问题进入短回复。动作选择决定后续数据记录，因此必须稳定。订单查询工具返回结构化数据，AI 只负责自然语言表达；工单创建返回 ticketId，客户侧展示「已记录」而非空泛安慰。

第四阶段：生成回答。回答根据风险等级调整语气。普通 FAQ 直接、简短、有引用；订单问题说明状态、预计时间和下一步；投诉问题先共情，再说明已记录和人工处理；健康风险明确建议谨慎并转人工。Prompt 不只要求「礼貌」，还要写清楚哪些话不能说，例如不能承诺退款金额、不能保证过敏者安全食用。

第五阶段：后续判断。客户继续追问时，系统区分新问题和同类重复。同类重复说明前一轮没有解决，需要降低置信度，必要时转人工。客户说「不用了」「谢谢」不一定代表解决，最终判定要结合意图、质检和后续 7 天内重复咨询情况。这个设计直接服务有效解决率反作弊。

会话状态

会话状态分为 ai、pending_human、human、closed 四种：

状态切换必须写入数据库并通过 Redis Pub/Sub 推送，否则客户侧和后台会出现不一致。除了状态本身，系统还记录 intent_category、ai_resolved、satisfaction、assigned_to、prompt_id、summary：意图分类用于看板和质检，解决率字段用于反作弊判定，prompt 编号用于版本对比，摘要用于人工接管时快速理解上下文。

客户体验细节

客户侧不暴露内部规则，但要让下一步明确。知识库回答展示引用来源，让客户知道答案不是瞎编；订单工具回答展示预计到达时间和骑手信息，但不展示内部字段；转人工时告诉客户「我已记录，并把情况转给人工处理」，避免重复描述。工单场景尽量收集订单号、问题类型和补充描述，但不在强情绪下反复追问。

流式回复也分节奏。普通问题边生成边展示；工具调用先展示「正在查询订单」再输出结果；转人工不长篇解释，重点是承认问题、说明已转交、显示等待提示。

商家后台联动

流程触发转人工或工单时，后台出现待处理提醒。后台列表显示客户最近消息、意图、优先级、转人工原因和摘要。人工接管后客户侧状态同步为 human，AI 不再继续回答——避免人工和 AI 同时回复的混乱体验。

看板层面，流程中的每个事件都成为指标：总咨询量、FAQ 自动回答量、订单工具调用量、转人工量、工单量、平均响应、成本、引用命中、质检分数。运营复盘从对话链路自然沉淀，不需要手工统计。

设计权衡