Jev 深度解读与实测：只做判断的 AI，究竟快在哪里

假设你正在做一个客服系统，用户发来一句话：

我被扣了两次钱，请今天退回多扣的一笔。

人看到这句话，很快就知道它和退款有关，而且用户希望尽快处理。但程序还需要把这份理解变成具体动作：分给哪个队列、要不要提高优先级、是不是明确提出了退款要求。

现在很常见的做法，是把消息交给大模型，让它返回一段解释，或者直接生成符合约定的 JSON。这个方案能工作，不过等请求量变大，模型的等待时间、输出长度和调用费用就开始变得明显。

最近看 TypeSafe AI 发布的 Jev，我觉得它最值得讨论的地方就在这里：如果程序只需要几个判断，模型能不能直接把这些判断交出来？

这篇是前面 Jev 视频的文字展开版。我们继续用这张工单，把它的接口、速度来源、适用场景和限制串起来，再用六条中英文样本调用真实 API。文中会区分本机拿到的结果与官方性能数字；官方工作流评测没有在本地独立复现。

Jev 到底接收什么，又返回什么

TypeSafe AI 在 2026 年 9 月 15 日发布 Jev，并把它归到自己提出的 System One 模型类别中。这个名字借用了“快速、直觉式判断”的说法；对开发者而言，理解它的输入输出比理解这个名字更有用。官方发布文章

一次请求主要包含两部分：一份待判断的 state，以及一组预先定义好的 questions。

state 可以是用户的自然语言消息，也可以是包含订单、工单和规则的结构化数据。questions 写明要问什么、答案可以有哪些。Jev 返回对应的选项、分值或概率，业务代码再根据这些结果继续执行。官方介绍

拿退款工单来说，我们可以一次问三个问题：

这里有个容易混淆的地方：“用户希望退款”只是在识别意图。“这笔订单应该退款”还要核对支付记录、身份、金额和业务规则。前一个问题适合交给模型理解语言，后面的确定性检查仍然应由系统完成。

所以我更愿意把 Jev 理解成程序里的一组判断函数。函数内部处理那些很难用关键词写完整的语义，函数外部的代码负责流程和实际操作。

三种原语，分别解决三种问题

Choice 最接近选择题。你给它一个没有先后高低关系的选项集合，它返回选中的选项，以及全部选项的概率分布。例如把消息分到 refund_request、billing_question 或 other。Choice 文档

选项的描述很重要。“退款申请”和“账单问题”如果写得含糊，重复扣费就可能同时符合两类。实际接入时，我会把前者写成“用户要求返还已支付金额”，把后者写成“用户询问收费情况，但没有提出退款请求”。这相当于先把团队自己的分类标准整理清楚。

Score 适合有顺序的等级。比如时间紧迫程度可以定义为：没有时间要求、希望近期处理、明确要求今天或立即处理。它返回的 score 是等级编号的概率加权平均，因此可以落在两个等级之间。Score 文档

举一个纯粹用于解释计算方式的例子，并非 API 实测：假设三个等级编号为 0、1、2，概率分别是 0.1、0.3、0.6，那么：

1

score = 0 × 0.1 + 1 × 0.3 + 2 × 0.6 = 1.5

这里的 1.5 表示模型的判断偏向高等级。它不表示“客户有 75% 的紧急程度”，也不是客观测量出的时间压力。等级的含义是我们自己定义的，分数的意义来自这套定义。

Noul 则回答一个明确的是非问题，返回“是”的概率，字段名就是 noul。例如：“用户是否明确要求退款？”数值接近 1 倾向于“是”，接近 0 倾向于“否”，靠近 0.5 表示两边概率接近。Noul 没有额外的 confidence 字段。Noul 文档

尤其要避免把 Noul 当程度评分。如果问“用户是否着急”，0.5 不代表“中等着急”；它表示模型对这个命题拿不准。想区分不着急、比较着急、非常着急，应该先把等级写清楚，再使用 Score。

为什么多个问题可以更快

这三个问题都能直接根据原始消息作答，并不需要先知道其中某个答案。因此，可以把它们放在同一个请求里。

按照官方接口的设计，同次请求中的问题共享同一份 state，各自独立求值，并行返回结果。每个问题不会把另一个问题的答案当作自己的上下文。Primitives 文档

可以想象有三位同事同时读这张工单：一位负责分类，一位看时间要求，一位确认退款意图。最后程序把三份结果汇总。如果让一个人先写完分类，再写紧迫程度，最后写退款判断，后两个答案就要排在前面的文字之后。

这个类比对应的是输出方式的差异。典型的自回归语言模型逐个生成输出 token；哪怕返回的是一个 JSON 对象，字段名、数字、标点也要经过输出过程。Jev 放弃自由文本生成，针对预定义问题直接返回类型化结果。官方把并行采样列为它的重要设计。官方发布文章

不过，“并行”也有明确边界。假设第一步要识别订单编号，第二步必须拿这个编号查数据库，第三步才能判断支付情况，那么后一步需要的信息还不存在，自然无法全部塞进第一次请求。你仍然需要在代码里分阶段调用。

反过来，如果只是想“确认属于退款后，再看看用户着不着急”，第二个问题其实早就能根据原文作答。提前一起问，随后由代码决定是否采用这个答案，就能省掉一次往返。这是工作流设计上的收益，不必等到某种特殊模型才开始思考。

至于底层用了多少参数、具体网络怎样安排、硬件算子怎样实现，仅凭目前这些公开接口和发布说明，还不足以精确复原。把速度归因于“它就是一个很小的模型”，缺少证据。我们能确认的是任务范围收窄、输出方式不同；每项因素分别贡献了多少，还需要更多技术披露和对照实验。

普通大模型已经能输出 JSON，Jev 的差别还剩什么

这个问题比“Jev 会不会写错括号”更值得问。

现在已有大模型提供 Structured Outputs，通过约束解码让返回结果符合指定 schema。比如 Claude 的官方文档就明确提供 JSON 输出和严格工具调用。因此，不能把普通大模型一概描述成“只能自由写一段话，然后碰运气解析”。Claude Structured Outputs 文档

更合理的比较是：

也就是说，Jev 的卖点并不只剩下“格式合法”。它试图把判断、概率和多问题并行做成更专门的模型接口，从这类任务里争取更低延迟和成本。

但通用性确实有价值。处理完工单后，如果还要写一封措辞得体、能够解释账单情况的回复，仍需要模板或文本生成模型。一个合理的系统完全可以先用 Jev 做分类和筛选，再把少量需要生成或复杂分析的情况交给其他模型。

有了概率，怎样才能真正用起来

概率最有用的地方，是让代码有机会表达“这次先别自动处理”。

例如，一个消息被分到退款队列，但分布里“账单咨询”也占了很大比例。系统可以先询问用户希望核查收费，还是申请退回款项。分类结果十分明确时，再走对应流程。业务上能接受多大误判、人工复核成本是多少，决定了阈值应该放在哪里。

Choice 和 Score 的 confidence 是从概率分布归纳出的统计量，描述结果有多集中。它不是独立核验后的正确率，更不能把 confidence = 0.9 直接读成“这一单一定有 90% 的把握做对”。需要更细的处理时，可以直接使用完整的 probabilities。Confidence 文档

TypeSafe 把自己的训练方法称为 RLCD，也就是面向校准决策的强化学习。这里“校准”的理想含义是：收集很多被模型赋予约 0.8 概率的同类事件，它们最终发生的比例也应接近 80%。这描述的是一批预测的统计关系，不是单个答案的保证。AI Primer

要在自己的业务里验证这一点，我会保留一批人工判断过的历史工单，先看误判集中在哪里，再比较不同概率区间的实际表现。退款意图识别、工单排序和自动退款的后果差别很大，不能共用一个随手选出的阈值。

还有一种错误很容易被“类型安全”遮住：答案永远在菜单里，不代表菜单本身合理。如果只给“退款”和“投诉”两个选项，普通咨询也会被迫落入其中之一。补上 other、改善分类边界，比盯着输出是不是合法 JSON 更接近实际质量问题。

怎样看待“快 193.6 倍、便宜 444.6 倍”

这些数字来自 TypeSafe 自己发布的工作流评测，不是所有任务、所有模型之间都成立的固定倍率。发布文章还给出约 70–500 毫秒的单次端到端延迟，并说明公开评测通常从美国西海岸的笔记本发起，服务也位于那里；对于工作流的巨大收益，官方自己认为可能处在真实收益的高端。官方发布文章的评测说明

评测覆盖客服、安全事件、发票处理和 Agent 运行轨迹审查四类工作流。模型回答拆解后的问题，再由程序规则产生结果；总览图对四类工作流等权平均。参考标签来自 GPT-6 Astra 和 Claude Fable 5.1 在高推理设置下回答的平均值，其他参评配置使用供应商默认推理设置。官方 Workflow Evals

这套评测有参考价值：它把具体流程、问题以及模型之间的分歧摆出来，比只展示一条最快响应更容易分析。但“接近两个强模型的共识”和“在真实业务里判断正确”仍然是两个问题。若参考模型一起误解某条规则，接近它们不一定代表更接近业务事实。

另外，TypeSafe 给通用大模型使用了兼容其决策接口的包装，要求返回相应概率；官方也指出，这通常比只输出一个决定更慢、更贵。发布文章中的比较口径

因此，实际选型应该拿自己的目标做比较。如果系统只需要一个分类标签，就比较分类标签；如果需要十几个问题的完整概率分布，就两边都要求同等信息。再把模型版本、输入长度、问题数量、客户端所在地区、并发数、错误率和延迟分位数一起记录下来。

从国内网络调用服务，还会多出网络路径这项变量。看到官方的 70 毫秒，不能据此推导出自己部署环境里也能稳定得到同样结果。

装上 skill，就算把 Jev 安装到电脑里了吗

官方给 Coding Agent 提供的安装方式是：

1

npx skills add typesafe-ai/skills --skill typesafe-ai

运行时选择自己使用的 Agent。默认安装范围是当前项目，加 -g 才是全局安装。TypeSafe Agent Skill 文档

这次安装遇到了 Git HTTP/2 错误和拉取超时，最后下载官方仓库在提交 65a39f393687675ce170e6094757de20370365b9 的归档，再用 npx skills add 对本地归档目录安装，指定 --skill typesafe-ai --agent codex --yes。技能已安装到项目的 .agents/skills/typesafe-ai，内容仍来自官方仓库。

这条命令安装的是一套接入知识，包括如何组织问题、调用 API、读取返回值和拆分工作流。它帮助 Coding Agent 正确使用 TypeSafe，并不会把 Jev 的模型权重下载到电脑上，也不意味着获得了离线推理能力。

真正运行判断，需要通过 TypeSafe 账户获得 API 访问权限，并配置 TYPESAFE_API_KEY。接口是 POST https://api.typesafe.ai/v1/systemone。Quick Start

下面先给一个沿用本文工单的教学版请求：问题说明使用中文，紧迫程度分成 0–2 三级。它用于解释字段结构；后面的实际实验采用更详细的英文问题说明和 0–3 四级标准，两者不是同一份请求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "model": "jev-latest",
  "state": {
    "message": "我被扣了两次钱，请今天退回多扣的一笔。"
  },
  "questions": {
    "request_type": {
      "type": "choice",
      "instructions": "message 中用户主要希望获得哪一种处理？",
      "criteria": {
        "refund_request": "要求返还已支付的金额。",
        "billing_question": "询问收费情况，但没有要求返还款项。",
        "other": "不属于上述两种需求。"
      }
    },
    "time_pressure": {
      "type": "score",
      "instructions": "message 中表达的时间要求有多紧迫？",
      "criteria": [
        "没有表达处理时限或催促。",
        "希望尽快处理，但没有明确要求当天完成。",
        "明确要求今天完成或立即处理。"
      ]
    },
    "explicit_refund": {
      "type": "noul",
      "instructions": "message 中用户是否明确提出返还款项的要求？"
    }
  }
}

问题的 ID 只是程序匹配请求和回答的键，模型并不读取这个 ID 来理解问题，所以完整含义要写在 instructions 和 criteria 中。API Reference

中文读者还需要特别留意语言条件。官方 Models 文档说明，英语是主要训练语言，目前表现最好；中文等其他语言可以处理，但能力并不等同，应该用自己的材料验证。当前 jev-latest 指向 jev-1.13.0，别名会随版本更新变化；如果已经根据某个版本调过阈值，应该记录或固定实际模型版本。Models 文档

真正调用六次，得到了什么

接下来我在 tools/jev-lab/ 写了一个小实验。index.mjs 定义问题和结果处理逻辑，cases.mjs 放六条人工编写的合成输入：中英文重复扣费退款、中英文明确不退款、信息模糊，以及完全无关的内容。

配套的可运行示例包包含代码、锁定的依赖版本和这次实验的 JSON 快照。使用 Node.js 20 或更新版本，解压后在目录里执行：

1
2

npm ci --ignore-scripts --no-audit --no-fund --registry=https://registry.npmjs.org
node index.mjs --dry-run

这一步不读取密钥、不联网。配置自己的 TYPESAFE_API_KEY 后，再执行六条样本：

1

node index.mjs --suite

也可以用 --key-file /你的本地密钥文件路径，从文件读取密钥。示例只向 TypeSafe 官方端点发请求，不会把密钥写进结果。博客源码仓库里的同一份脚本位于 tools/jev-lab/index.mjs。

本次运行时间为 2026 年 9 月 20 日，环境是 Node.js v22.21.1、@typesafe-ai/sdk@0.6.0。一个本机进程顺序发送六次请求，每次把三个问题放在一起；超时设为 15 秒，重试次数为 0，没有做预热。请求选择 jev-latest，六次响应实际都返回 jev-1.13.0。

为了把判定边界写得更清楚，实测的 instructions 和 criteria 都使用英文，state 中分别放中文或英文工单。Choice 的选项是 refund / support / other；Noul 明确区分“要求退钱”和“只是提到或否定退款”。Score 判断的是需要客服介入的紧迫程度，四级标准大意如下：

下面是实际响应中的数值，按请求发送顺序排列。explicit_refund 是明确退款请求的 Noul 概率，urgency 是上面四级标准的加权分值：

比起看第一条命中了 refund，我更关心后面的边界输入。例如“我不是来申请退款的，不要退款。我只是想知道发票在哪里下载”，虽然出现了多次“退款”，返回的明确退款概率仍然只有 0.03，路由为 support。至少在这条样本上，它区分了提到某个词和表达某种意图。

模糊工单也很有意思。它返回 other 的概率为 0.70、support 为 0.30，而 route confidence 是 0.54。这正好说明，选中类别的概率和 confidence 并不是同一个数值。

示例代码把 route confidence < 0.8 的结果显示为 human_review，所以这条没有直接采用 other 路由建议。这里的 0.8 只是便于展示分支的阈值，没有用真实客服数据校准；程序也只输出建议，不会创建工单或执行退款。Score 的返回值保留供查看，没有接入自动行动。

延迟则需要单独解释：第一条为 1962.02 毫秒，后五条在 744.75–823.44 毫秒之间。计时包住一次 SDK 调用，包括网络往返和响应解析，并非模型纯推理时间。由于没有预热、重复运行和顺序对照，不能把首条较慢直接归因于服务冷启动，也不能据此认为中文比英文慢。

这六条只能说明本次请求跑通了，并让我们看到某些具体边界上的行为。它们没有组成足够的带标签评测集，不能用来估计生产准确率或证明概率已经校准；本次也没有通用大模型对照，不能验证官方宣传的加速和成本倍率。本次完整实验快照保留了问题定义、输入、返回版本、概率分布和客户端计时；读者自己运行时，新记录会写入示例的 results/ 目录，方便沿着相同口径扩充样本。

我会先把它用在哪

我比较想先试的是工单分流、检索结果重排、文章分类，以及给已有 AI 输出加一层多维检查。这些地方通常已经有明确的候选项，判断会高频发生，而且容易把结果接到现有代码里。

我不会一开始就把“理解用户意图”和“批准具体交易”合在一个问题里。回到那张重复扣费工单，比较容易验证的第一步是让 Jev 判断用户希望做什么，再由系统读取真实订单和支付记录。模型负责理解那句话，业务代码负责确认发生了什么。

Jev 让我感兴趣的是这种工作方式：把一个含糊的大任务拆成可以逐项检查的小判断，得到概率后，再把它们写进清楚的程序逻辑。对于已经在搭建 AI 工作流的开发者，是否采用 Jev 可以通过实验决定；先把问题边界和比较口径写清楚，这件事现在就能做。