最近我试用了 TypeSafe 的 Jev 模型，以及配套的 typesafe-ai agent skill。我的问题很简单：它能不能把一段自然语言，变成程序可以直接使用的判断？
先说我的结论：这次基础测试跑通了，而且结果符合直觉。 Jev 适合给应用提供有类型的语义判断；skill 则帮助开发者把问题拆成合适的判断，并接上当前 API。但测试只有两条清晰的样本，远远不足以证明它在真实业务中的准确率。
我测试了什么
我通过官方 POST /v1/systemone 接口，分别提交两条中文客服消息。每次请求同时问三个问题：
- Noul：消息是否要求尽快处理？返回“是”的概率。
- Choice：消息主要该交给技术、账单，还是其他团队？返回选项及概率分布。
- Score：处理紧迫程度是多少？我定义了 0、1、2 三档，从“不着急”到“要求马上处理或有紧迫业务影响”。
两条输入分别是：
支付接口连续报错三小时，客户无法下单，今天必须恢复，请马上处理！
你好，我想了解上个月账单里的一笔费用。方便时回复即可，不着急。
实际返回的摘要如下；两次均使用 jev-latest，响应中的具体版本为 jev-1.13.0：
| 输入 | 尽快处理的概率（Noul） | 分配团队（Choice） | 紧迫程度（Score） |
|---|---|---|---|
| 支付接口故障 | 0.99 | technical |
2.0 |
| 普通账单咨询 | 0.05 | billing |
0.0 |
两次请求都成功返回了结构化结果。第一条消息的故障、客户下单受阻和“马上处理”被识别为技术问题与高紧迫度；第二条消息则被分配到账单团队，并因“不着急”得到很低的紧急概率。这至少说明：中文输入、三个基础问题类型，以及一个请求中同时提问，在这组样本上都工作正常。
我觉得 Jev 好在哪里
最有价值的地方是输出形状。普通文本生成还需要再解析、约束和校验；这次得到的是可以直接交给代码处理的选项、分数与概率。比如工单系统可以先用 Choice 选择队列，再根据 Noul 的结果决定是否进入人工优先处理列表。
另一个优点是问题可以一起提交。上面的三个判断基于同一段消息，在一次 API 请求中拿到结果，业务代码再决定如何组合它们。模型负责理解语言，真正的分配规则和后续动作仍由程序控制。
不过，概率不能直接当成业务承诺。0.99 表示模型在这次提问下给出的“是”的概率，不代表工单路由在生产环境有 99% 的正确率。Choice 的置信度也描述选项分布的集中程度，不能替代人工标注的评估。
typesafe-ai skill 帮了什么
这里要区分两样东西：Jev 是接受请求并返回判断的模型；typesafe-ai skill 是给编程助手看的开发说明。 安装 skill 不等于安装模型，也不会自动提供 API 密钥。
这次 skill 的实际帮助是明确的：它要求先看实时文档，再按判断的含义选 Noul、Choice 或 Score；它还提醒我把判断写在问题说明里、给选项写清标准，并检查概率和置信度的使用边界。照着这个流程，我很快构造了一个包含三种问题的最小请求，随后对照官方快速入门和API 文档确认请求格式。
我喜欢它把“接入接口”和“设计判断”放在一起讲。后者往往才是成败所在：如果团队选项定义含糊，或者问题没有提供必要上下文，结构化返回也可能只是结构化的错误。
这次测试还不能说明什么
两条消息都很直白，并且仅运行了一次。我没有测试模棱两可的描述、多个团队都合理的情况、长对话、领域术语、对抗性输入或结果在多次调用中的稳定性；也没有测量延迟、价格和生产环境下的总体准确率。因此，我现在会把 Jev 看作值得进入原型验证的判断组件，而不是已经通过业务验收的自动决策系统。
如果要放进真实工单流程，我下一步会收集一批带人工标签的历史消息，分别统计路由正确率和漏掉紧急工单的比例，再根据误判代价设置阈值。无法确定的工单应进入人工复核。API 密钥则应保存在服务端环境变量中。
对开发者来说，这次体验给出的最清楚信号是：当产品需要的是“选哪个、是否符合、程度多高”，而非一段自由生成的文字，Jev 的接口形状很顺手；typesafe-ai skill 能帮助把这个需求写成清晰、可验证的提问。真正决定能否上线的，仍是用自己的数据检验它。
参考资料：TypeSafe 文档索引 · 三种问题类型 · API 文档