应用场景
客服工单路由
在每张进线工单进入队列之前，分类紧急度、归属团队与语气。
问题
路由规则识别不出反讽、多重意图的工单和默默存在的 VIP 账号。
代码拿到答案后怎么做
当紧急度高而置信度低时，呼叫人工。否则排入所选团队的队列。
决策如何返回
三个问题搭着工单文本进入同一个请求：is_urgent（yes/no）、department（billing、technical、sales 三选一）与 frustration（三级 score）。每个答案各带概率，所以一张同时读作两种意图的工单 — 退款投诉里藏着 bug 报告 — 也会落到某个去处，分布会显示这次判断有多纠结。下面的 curl 示例就是完整请求；你的服务器带 Bearer key 发送同样的 JSON。
生产代码拿它做什么
按 department 路由。当 is_urgent 高于 0.8 且 frustration 在最高级时，呼叫人工而不是排队。当 is_urgent 高但 department 的概率在 0.6 以内分裂时，分布是在告诉你意图混杂 — 把它连同两个候选团队一起送到资深队列。阈值数字由你定；让它靠得住的是这个形状：按级行事，有分歧就复核。
分诊专属的坑
经典失败是 criteria 写给人类而不是写给模型：“billing stuff”会让发票与退款的路由前后不一 — 请在每个选项的描述里写出具体例子。其次：不要把紧急度埋进与路由同一个问题里；当一个问题同时背两件事时，混合意图的工单会被读成低紧急度。第三：把商业上下文（带营收字段的账号）放进 state，让紧急度能对其加权，而不是硬编码一个 VIP 层。
请求结构
这是 playground 为该预设发送的完整请求 — 与你的服务器带 Bearer key 发往 /v1/systemone 的 JSON 相同。
curl
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Help! My payouts have been failing for 3 days and my customers are asking where their money is.",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "Does this convey urgency?",
"criteria": {
"true": "Explicitly time-sensitive or business-critical",
"false": "No urgency expressed"
}
},
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, payouts, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": [
"Calm",
"Frustrated",
"Very angry"
]
}
}
}'关于此用例的常见问题
- 每张工单需要一次 Jev 请求吗？
- 不需要 — 每个路由信号都是同一请求里的一个问题。每次调用最多 8 个问题：足够一次带上紧急度、部门、情绪、VIP 状态和语言。典型的分诊调用是 400–600 token，花 1 积分。
- 其他语言的工单怎么办？
- instructions 与 criteria 用你的处理路径所用的语言来写；state 可以保留客户的语言。反正 Jev 的答案空间是类型化的 — 每种语言先拿五张近期工单测一测再上线。
- 队列分错了但置信度很高，怎么办？
- 高置信地分错是 criteria 措辞问题，不是阈值问题。拉出三张误路由工单，用具体例子（payments、invoicing — 不是“钱的事”）重写 department 的 criteria，并在动生产之前到 playground 免费重跑。