USE CASE / Choice
客服工单分流
从物流、账单、技术、其他中选一个负责团队
一条代表性的输入(state)
客户消息、订单状态和已知问题类型
问题类型
Choice
问题说明(建议用英文写给模型)
从物流、账单、技术、其他中选一个负责团队
低于阈值时
程序分配队列;低置信度转人工
把“分流”缩到一个可撤销动作
先由代码确认工单所属账户、订单和配送记录。Choice 只建议首接团队;若同一消息还要求退款,单一首接标签不能覆盖退款诉求。先为每个诉求建可追踪的记录,再由规则或人工决定动作。
三个必须测的边界样本
- 没有订单号:请求补充信息
- 配送投诉同时提到重复扣款:拆单或人工
- 客服改派三次:检查候选定义与人工标签
示例请求
这是设计草案,不是 Jev 的实际回答或准确率测试。
{
"state": "My parcel says delivered, but nothing arrived.",
"model": "jev-latest",
"questions": {
"decision": {
"type": "choice",
"instructions": "Which team should handle this customer request?",
"criteria": {
"shipping": "Delivery, tracking, or missing package",
"billing": "Payment, charge, or subscription",
"technical": "Product bug or integration failure",
"other": "None of the above"
}
}
}
}边界与回退
先核对订单事实;不要凭分类结果直接退款。
先看原始任务:客服真正需要什么?
从客户原话、核实订单、设计三道问题,到阅读示意结果、处理边界案例和上线评估,完整走一遍 Jev 工作流。
完整实战:一条“显示送达却没收到”的工单,如何设计 Jev 决策流程