Jev 最近很受关注，但它和常见聊天模型的工作方式不一样。它不负责写一段客服回复，而是把一条非结构化消息转换成程序可以直接使用的判断：语言、分类、分数、概率。
我用同一套请求测试了中文、英文、德语、法语和西班牙语客服消息。五条请求全部返回成功，耗时 804～900 ms。下面记录测试方法、结果和一个可以直接改造的 Python 接入版本。
Jev 适合做哪一层
普通聊天模型适合生成回复。Jev 更像一个判断组件：输入一条工单，输出固定选项和概率。
这次请求同时问了四个问题：
- 消息是什么语言；
- 应该分给哪个客服部门；
- 紧急程度是多少；
- 是否需要人工复核。
这种拆法比让模型一次性“理解工单并写出完整结论”更容易接进业务代码。分类结果可以路由，分数可以做阈值判断，人工复核概率可以决定是否进入人工队列。
官方文档把这三种问题叫作 Choice、Score 和 Noul。Choice 选一个固定选项，Score 在一组等级上打分，Noul 返回 0 到 1 之间的概率。三种问题可以放在同一次请求里。官方 Quick start
这次测试测了什么
样例很小，目标是验证接口和基本的跨语言理解，不是做模型排行榜。每条消息都带有明确的客服意图，结果也用固定字段输出。
| 语言 | 客服分流结果 | 紧急程度 | 人工复核概率 | 耗时 | 输入 / 输出 tokens |
|---|---|---|---|---|---|
| 中文 | shipping | 1.32 | 0.49 | 900 ms | 602 / 151 |
| English | billing_refund | 0.67 | 0.50 | 874 ms | 586 / 152 |
| Deutsch | technical | 2.00 | 0.48 | 858 ms | 589 / 152 |
| Français | order_account | 0.01 | 0.42 | 875 ms | 586 / 152 |
| Español | technical | 1.46 | 0.37 | 804 ms | 596 / 151 |
五条消息都被识别成了对应语言。中文订单延迟被分到 shipping，英文重复扣款被分到 billing_refund，德语登录失败和西班牙语上传崩溃都进入 technical。这些结果符合样例的业务意图，但样本量太小，不能推导出准确率或稳定性结论。
返回的模型版本是 jev-1.13.0。我们请求的是 jev-latest，服务端把它解析成了当前版本。一次请求的输入和输出合计约 740 tokens，五次请求合计 3717 tokens。
图 1：API key 页面。账号、创建者和 secret 字段已经替换为演示值，只保留 Active 状态和页面结构。
图 2：本次五条请求的用量记录。控制台显示 5 次请求、3717 tokens，Spend 约为 $0.0001。价格和额度以你的控制台为准。
最小 Python 请求
这个版本只用 Python 标准库，不依赖 SDK。它读取 .env 中的 TYPESAFE_API_KEY，把 key 放在服务端环境里，不写进代码，也不放到浏览器。
python3 -m venv .venv
.venv/bin/python -m pip install --upgrade pip
.env 只需要这一行：
TYPESAFE_API_KEY=your_typesafe_key_here
真实代码可以保持很小：
import json
import os
from urllib.request import Request, urlopen
payload = {
"model": "jev-latest",
"state": "我的订单已经付款三天了，但还没有发货，请尽快帮我查一下。",
"questions": {
"language": {
"type": "choice",
"instructions": "Which language is the customer message written in?",
"criteria": {
"chinese": "Chinese",
"english": "English",
"german": "German",
"french": "French",
"spanish": "Spanish",
"other": "Another language or unclear",
},
},
"department": {
"type": "choice",
"instructions": "Which customer-service team should handle this request?",
"criteria": {
"billing_refund": "Payment, duplicate charge, invoice, or refund issue",
"technical": "Bug, login failure, crash, or integration problem",
"order_account": "Order change, delivery address, or account information",
"shipping": "Shipment tracking, delivery delay, or logistics issue",
"other": "Anything else",
},
},
"urgency": {
"type": "score",
"instructions": "How urgent does the customer sound?",
"criteria": [
"Routine; no time pressure",
"Needs attention soon",
"Urgent; asks for immediate help",
],
},
"needs_human_review": {
"type": "noul",
"instructions": "Would a human agent need to review this request before an automated reply?",
},
},
}
request = Request(
"https://api.typesafe.ai/v1/systemone",
data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
headers={
"Authorization": "Bearer " + os.environ["TYPESAFE_API_KEY"],
"Content-Type": "application/json",
},
method="POST",
)
with urlopen(request, timeout=15) as response:
result = json.loads(response.read().decode("utf-8"))
print(result["answers"]["department"]["choice"])
print(result["answers"]["urgency"]["score"])
官方接口是 POST https://api.typesafe.ai/v1/systemone，认证头是 Authorization: Bearer <API_KEY>。不要把 OpenRouter、Vercel AI Gateway 或其他服务的 key 填到这个地址上。不同渠道的 endpoint、模型名和认证方式不一定相同。
把测试脚本接进自己的项目
这次测试用的脚本还做了几件适合保留在项目里的小事：
- 把样例消息集中在
SAMPLES表里，增加语言时不用改请求逻辑。 - 把四个判断放在一个请求中，减少重复的网络往返。
- 401 时立即停止，不用拿同一个错误 key 重试五次。
- 输出模型版本、延迟和 tokens，便于后续比较版本变化。
- dry-run 模式只检查 payload，不消耗 API 用量。
项目里的运行命令是：
./.venv/bin/python run_jev_customer_test.py --dry-run
./.venv/bin/python run_jev_customer_test.py
如果返回 401，先检查 key 是否来自 TypeSafe 控制台、是否复制了完整 secret，以及 .env 里是否混入了引号或空格。401 是认证失败，不是客服问题格式错误。
这次实测后的判断
Jev 值得放在客服系统的“判断层”里试用。它能把多语言消息转成稳定的选项和分数，接入路由、优先级和人工复核都比较直接。
它不能替代客服回复生成，也不能用五条样例证明生产准确率。正式接入前，还需要用真实历史工单做一批标注集，观察每种语言、每个部门和每个阈值下的误分情况。对于低置信度结果，保留人工复核入口会更稳妥。
相关资料：TypeSafe Jev 官方文档、Jev 发布说明。
