完整实战：一条“显示送达却没收到”的工单，如何设计 Jev 决策流程

先看原始任务：客服真正需要什么？

1. 客户原话：“订单显示昨天已送达，但门口没有包裹。我今天就要用，能不能直接退款？”
2. 业务目标是决定谁先处理：物流、账单、技术，还是人工复核。退款并不是这次模型调用的输出，也不能因为用户提到了退款就立即执行。
3. 系统另外查到：订单属于该账户；承运商状态为 delivered；签收信息缺失；退款政策由另一个确定性流程管理。模型看不到系统没有提供的事实。

01 · 确定动作边界

把最终动作写成可检查的规则：只有资料齐全、分类明确且达到自有验证阈值时，才自动分配一个可撤销的队列。信息不足、多个诉求冲突、低置信度或接口失败，全部进入人工复核。任何退款申请都要走身份、订单和政策检查。

02 · 把原话变成 state

不要把整个账户历史丢进去。保留本次消息、经系统核实的配送状态、签收人是否已知；标清“客户称未收到”与“承运商显示送达”来自不同来源。删除姓名、地址、电话、卡号。若订单记录查不到，先补信息，不让模型猜。

03 · 拆成三个原子问题

Choice 回答“首先由哪个团队处理”；Noul 回答“这条消息是否表达时间紧迫”；Score 依预先定义的低、中、高尺度评估客户情绪。三个答案互相独立；代码可以让高紧迫度工单优先排队，但不会把情绪评分当成退款权限。

04 · 读取示意结果并执行

假设 Choice 选 shipping，示意 confidence 为 0.84；Noul 为 0.91；Score 为中等级。只有在自己标注的数据上验证过适用阈值后，代码才能决定是否自动分配物流队列。若阈值设为 0.88，这条工单仍要人工复核。0.84、0.91 和 0.88 都是教学假设，不是官方实测或推荐值。

05 · 用反例找出设计漏洞

如果客户只说“我要退款”，物流仍是唯一选项，就说明候选集设计错了；如果承运商状态缺失，先查记录；如果同一句同时有物流和扣款争议，转人工或拆成两个工单；如果“我不着急”被判紧急，就把否定句加入回归集。

可复制的最小 state：标清事实来源

customer_claim: 包裹显示送达但未收到；today_needed: true
verified_order_owner: true；carrier_status: delivered
signature: unknown；refund_authorized: not_checked

把问题写成请求：三个判断共享同一份 state

以下 JSON 展示官方文档的请求形状，字段值是本站编写的合成样本。发送前仍要按实际 SDK/API 版本核对约束和权限。

{
  "state": "customer_claim: 包裹显示送达但未收到；today_needed: true\nverified_order_owner: true；carrier_status: delivered\nsignature: unknown；refund_authorized: not_checked",
  "model": "jev-latest",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this ticket first?",
      "criteria": {
        "shipping": "Delivery, tracking, missing parcel",
        "billing": "Charges, payment, subscription",
        "technical": "Product bug or integration",
        "review": "More than one intent or insufficient information"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "This message expresses time sensitivity."
    },
    "tone": {
      "type": "score",
      "instructions": "How distressed does the customer appear?",
      "criteria": [
        "Calm, factual",
        "Concerned but civil",
        "Strong distress or anger"
      ]
    }
  }
}

不要把示意输出误当实测

下面数值是为讲解决策路径手工编写的示意数据。Choice/Score 的 confidence 与 probabilities 是不同字段；Noul 只有 noul 值。应用应先检查 answers 的问题 ID、type 和必需字段，再决定下一步。

{
  "answers": {
    "team": {
      "type": "choice",
      "choice": "shipping",
      "confidence": 0.84,
      "probabilities": {
        "shipping": 0.81,
        "billing": 0.1,
        "technical": 0.02,
        "review": 0.07
      }
    },
    "urgent": {
      "type": "noul",
      "noul": 0.91
    },
    "tone": {
      "type": "score",
      "score": 1.0,
      "confidence": 0.78,
      "probabilities": {
        "0": 0.08,
        "1": 0.82,
        "2": 0.1
      }
    }
  }
}

六条回归样本：先写预期动作，再看模型

怎样判断这个方案值得上线？

1. 从目标业务抽取脱敏样本，先让人工标注“首接团队”和“是否允许自动分流”。把常见样本与高代价长尾样本分开统计。
2. 在一组样本上调阈值，在未参与调参的样本上验证；报告误分到高风险队列的次数、转人工率、p50/p95 端到端延迟、每千单成本。
3. 小流量、可撤销地试运行，记录模型版本、请求 ID、问题定义版本和人工改派原因。模型或候选集更新后重新回归。