用例

Jev 用例

八个完整请求体,可直接粘贴进试用台或在代码里改造。每个请求把一段状态加类型化问题发到 /api/v1/decisions,拿回可以分支的 Noul、Choice 或 Score——每次成功调用 1 积分。

更新于

空白结账页该给谁

用这样的 Choice 把每个进线工单分到你的某个队列。答案给出团队名和每个选项的概率,接近的判断可以回落到人工而不是错误的队列。

Choice 返回负责团队,以及每个团队的概率。

{
  "model": "jev-1.13",
  "state": "Checkout shows a blank page after Pay is clicked. The customer is on the live store, not a sandbox.",
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should own this ticket?",
      "criteria": {
        "payments": "Checkout, billing, or payment processing.",
        "frontend": "Rendering, layout, or browser behavior.",
        "account": "Login, permissions, or profile access."
      }
    }
  }
}
在试用台打开这个请求

这是在要退款吗

二元问题就该用 Noul——这条消息是否在要钱。把退款宏或复核队列挂在 noul 值上,而不是去解析生成的文本。

Noul 返回“是”的概率,而不是一段要解析的文字。

{
  "model": "jev-1.13",
  "state": "I was charged twice for the same annual plan this morning. Please send the extra charge back.",
  "questions": {
    "refund": {
      "type": "noul",
      "instructions": "Is the customer asking for money back?"
    }
  }
}
在试用台打开这个请求

打款失败有多急

Score 适合排序判断。自定义档位——这里是三级紧急度——用小数 score 来排积压工单,而不是人工读标签。

Score 把内容放在你定义的刻度上,并返回分布。

{
  "model": "jev-1.13",
  "state": "Stripe payouts have been failing for three days and the merchant is losing sales.",
  "questions": {
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this ticket?",
      "criteria": [
        "Can wait for the next release",
        "Should be handled this week",
        "Blocking revenue right now"
      ]
    }
  }
}
在试用台打开这个请求

消息里在要登录凭证

在人工复核队列前放一道 Noul 做预筛。索要凭证的消息按概率被标记;次高概率告诉你这道门有多可信。

Noul 概率是人工复核队列之前的门。

{
  "model": "jev-1.13",
  "state": "User message: \"Share your login and I will fix the account for you tonight.\"",
  "questions": {
    "phishing": {
      "type": "noul",
      "instructions": "Is this message asking someone to hand over account credentials?"
    }
  }
}
在试用台打开这个请求

给一条进线定性

Choice 把购买意向分进销售流程已有的桶——ready、nurture、ignore——路由规则可解释,且每个选项保留自己的概率。

Choice 把“有采购窗口”和“只是感兴趣”分开。

{
  "model": "jev-1.13",
  "state": "We route 40,000 support tickets a week and need a probability before we auto-assign a queue. Budget is approved this quarter.",
  "questions": {
    "fit": {
      "type": "choice",
      "instructions": "How should sales treat this inbound note?",
      "criteria": {
        "ready": "A real workflow, a volume, and a buying window.",
        "nurture": "Interest without a stated workflow or timeline.",
        "ignore": "No product fit."
      }
    }
  }
}
在试用台打开这个请求

承诺收益的上架文案

政策核查用 Noul,规则用大白话写。listing 要么承诺了保底收益要么没有——概率就是你的执行信号。

Noul 回答的是你写的政策问题,不是一篇泛泛的安全说明。

{
  "model": "jev-1.13",
  "state": "Listing text: \"Guaranteed 30% returns every month. Send crypto to this wallet to join.\"",
  "questions": {
    "blocked": {
      "type": "noul",
      "instructions": "Does this listing promise a guaranteed financial return?"
    }
  }
}
在试用台打开这个请求

续约备注里的流失风险

用你自己的阶梯给续约风险打分,而不是用供应商的情感分。档位是你定的,小数 score 直接对应你已有的处理动作。

Score 使用你写的三档:不太会离开,到很可能取消。

{
  "model": "jev-1.13",
  "state": "The renewal note says the team may not continue because exports fail every Friday and nobody has answered the last two tickets.",
  "questions": {
    "risk": {
      "type": "score",
      "instructions": "How high is the chance this account does not renew?",
      "criteria": [
        "Unlikely to leave",
        "Unhappy, still using the product",
        "Likely to cancel"
      ]
    }
  }
}
在试用台打开这个请求

这张发票是哪种异常

带「both」选项的 Choice 一次就能抓住复合异常,不用第二次调用。财务拿到异常类型和各选项概率来分派争议。

Choice 可以标出超采购单、未请购明细,或两者,并给出概率。

{
  "model": "jev-1.13",
  "state": "Vendor invoice 4481 is $18,400. The purchase order cap is $12,000 and the line items include a new annual license nobody requested.",
  "questions": {
    "exception": {
      "type": "choice",
      "instructions": "Which exception should accounts payable open?",
      "criteria": {
        "over_po": "The amount is above the purchase order.",
        "unexpected_item": "A line item was not requested.",
        "both": "The amount and a line item are both wrong."
      }
    }
  }
}
在试用台打开这个请求

可组合的模式

上面的例子都是单次调用。TypeSafe 文档还描述了几种组合它们的模式:

  • 置信度门控路由——只有 confidence 过线才自动执行,其余转人工。
  • 投机扇出——打乱 Choice 选项顺序或精简状态再问一次,比较答案的一致性。
  • 护栏——用户输入到达生成式模型或生产动作之前,先跑一道 Noul。
  • RAG 段落过滤——对每个候选段落跑 Noul 或 Score,生成前只保留相关上下文。

常见问题

跑一个示例要多少钱?

每个请求是对 /api/v1/decisions 的一次调用,成功一次扣 1 积分,与问题数量无关。校验错误和上游失败免费。

能一次问好几个问题吗?

可以——questions 是映射,路由 Choice、退款 Noul 和紧急度 Score 可以共用一段状态、一次调用,仍只扣 1 积分。

怎么在代码里跑这些而不是在试用台?

把同样的 JSON 请求体 POST 到 https://jev-api.org/api/v1/decisions 并带 Bearer 密钥,或用指向 https://jev-api.org 的 TypeSafe SDK 走 /v1/systemone。

答案里的 confidence 是什么?

Choice 和 Score 的答案带 confidence,由概率分布推出——confidence 低或两个选项接近说明判断很边缘,适合人工复核。

现在就跑一个

上面每个请求都会在试用台预填打开。在价格页充一个小额一次性积分包,登录后直接跑——失败的调用不扣积分。