应用场景
退款政策核查
询问是否请求了退款，以及书面政策是否支持这次退款。
问题
客服对每一张重复扣款工单都要重读一遍同一份政策。
代码拿到答案后怎么做
只有两个 noul 答案都高时才自动批准。其余一律进复核。
用两个 yes/no 问题替代人工判断
请求把工单、结构化订单（同一订单号上的两笔扣款）与退款政策文本一起作为 state。两个 noul 问题：消息是否请求退款，以及结合扣款情况政策是否支持。两者都返回概率。对一份写清重复扣款的政策，政策问题会返回接近 0.98 — 模型读的是你随 state 送达的真实政策文本，这正是用心措辞的政策页在此产生回报的地方。
政策机器
只有两个概率在同一调用里都过线才自动批准 — 不少团队定在 0.9。一高一低不等于批准一半：它带着分布进复核，而这正是客服一早就最想先看的东西。这里没有任何投机取巧的成分：模型回答的是你写下的政策是否覆盖这张工单，所以被政策排除的模式会正确落进复核。
政策核查专属的坑
失败模式是写给律师看的政策文本：“合理使用退款窗口”什么都解析不出来，而“自购买之日起 30 天内”则解析得干干净净。把决策严格限定在书面政策之内 — 如果政策自相矛盾（一处写 30 天，另一处写终身保修），先改写政策，因为对着矛盾文本给出的类型化答案不叫解决。另外，当订单数据在你的数据库里时，把相关字段显式放进 state，而不是让模型从散文里推断扣款。
请求结构
这是 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": {
"ticket": {
"subject": "Duplicate charge",
"message": "I was charged twice for order A-104. Please refund the duplicate."
},
"order": {
"id": "A-104",
"charges": [
{
"amount_usd": 49,
"status": "captured"
},
{
"amount_usd": 49,
"status": "captured"
}
]
},
"refund_policy": "Duplicate charges are eligible for a full refund of the duplicate amount."
},
"questions": {
"refund_requested": {
"type": "noul",
"instructions": "Does `ticket.message` request a refund?"
},
"policy_supports_refund": {
"type": "noul",
"instructions": "Does `refund_policy` support the refund requested in `ticket.message`, given `order.charges`?"
}
}
}'关于此用例的常见问题
- 可以附截图或 PDF 吗？
- 这个调用不行 — Jev 读文本，请把相关对话或订单要点以文本或 JSON 贴进 state。100,000 字符的上限足以容纳一段很长的对话。
- 这和聊天模型做决策有什么不同？
- 它的答案空间是有界的：两个问题都返回在你对政策的既定解读之上的概率，而不是需要你解析并信任的生成式散文 — 且整次核查只要 1 积分。
- 我们经常改政策 — 会坏吗？
- 不涉及任何重新训练：政策就是 state，发布新文本就改变模型看到的内容。但每当政策出现实质变化，把你的十个验证工单重跑一遍。