客服场景比普通知识问答多了一层要求：不同问题要走不同处理路径。物流咨询可以自动回答，退款争议需要核对规则，账号安全和投诉则应该尽快交给人工。把所有问题都交给同一个提示词，往往会得到看似完整、实际越权的答案。

把问题分成少数几类

第一版不要设计几十个意图。可以先从四类开始：

  • 售前与产品咨询；
  • 订单、物流等售后查询；
  • 退款、投诉和账号安全；
  • 无法识别的问题。

对应的 Chatflow 可以这样组织：

用户输入
  → 问题分类器
    → 产品咨询：知识检索 → LLM → 回答
    → 订单查询：参数提取 → 业务接口 → LLM → 回答
    → 高风险问题：收集必要信息 → 创建工单 → 告知用户
    → 其他问题：澄清问题或转人工

问题分类器负责判断路线，不负责生成最终答案。订单号、手机号后四位等结构化信息，可以由参数提取节点从自然语言中整理出来；真正的订单状态必须从业务系统读取，不能让模型推测。

自动回答与业务动作要分开

“解释退款规则”和“执行退款”不是一回事。前者可以基于知识库回答，后者会改变真实业务状态，应该经过身份校验、明确确认和服务端权限控制。初学阶段可以只创建工单，不直接执行退款、取消订单或修改账号。

调用外部接口时，只把完成任务所需的最少字段传出去。API 密钥应配置在凭据或服务端环境中，不要写进提示词，也不要回显给用户。接口失败时应走清晰的失败分支，例如告知用户稍后重试并提供人工渠道，而不是生成一个“成功”结果。

设计一段可控的对话

客服助手需要处理信息不完整的情况。用户只说“我的东西怎么还没到”，助手应先询问订单标识，而不是马上调用接口。拿到标识后，再确认它是否符合格式，并在查询成功后只返回必要信息。

你还可以保存会话变量，例如当前问题类别和已经确认的订单号，减少重复询问。但不要把长期身份和权限只建立在对话记忆上，敏感操作仍需由外部系统验证。

验收重点

用真实表达方式测试，而不是只用标准问句：错别字、口语、省略信息、连续追问和情绪化表达都应该覆盖。尤其要检查三件事：高风险问题是否稳定转人工，接口失败是否会被误报为成功，用户能否从任意分支回到可继续对话的状态。

好的客服助手不是把人工全部移走，而是让重复问题快速解决，让需要判断和承担责任的问题更早到达合适的人。