Jev / System One Model 实测：把语言模型变成软件可直接调用的决策函数

大语言模型最擅长的事情是生成文字，但软件系统经常只需要一个决定：这条工单应该进哪个队列？这段内容是否需要人工复核？下一步该调用哪个模型？一条回复能不能发给用户？

如果为了得到一个 true / false，先让模型生成一段解释，再从文本中解析 JSON，整个链路就会承担不必要的生成、解析和格式校验成本。TypeSafe AI 的 Jev 试图把这类任务反过来设计：输入一段状态和一组预先声明的问题，直接返回带类型、概率和置信度的答案。

本文整理 01Coder 发布的视频《Jev 实测：这款爆火的极速决策模型的基本玩法》。视频时长约 16 分 54 秒，内容覆盖 Jev 的背景、三种问题原语、官方数字与独立实测、社区案例、AI SDK 7 Playground、coding-agent skill，以及“什么时候用、什么时候不用”的判断。文中也结合 TypeSafe 的官方介绍和 Vercel AI Gateway 的接入信息，补充工程实现边界。

先说明来源边界：视频转写稿和章节可以直接核对视频内容；官方价格、接口名和性能数字则来自 TypeSafe 与 Vercel 的公开页面。官方评测、视频中的单次体验和本文的工程建议不是同一种证据，不能把宣传数字直接当成所有业务场景的性能保证。

一张图看懂 Jev 的位置

Jev 不负责写最终答案，也不替代通用语言模型。它更像一个位于“状态”和“业务代码”之间的快速决策层：把同一份上下文同时交给多个独立问题，再让代码根据答案和概率继续执行。

状态 state
  → 一次声明多个问题
  → Jev 并行评估
  → Choice / Score / Boolean + 概率
  → 代码执行、路由或人工复核

视频内容索引

时间	主题	重点
00:00	开场与背景	TypeSafe AI、Hacker News 热度、Vercel AI Gateway 接入
01:57	Jev 是什么	System One Model 与“决策而不是文本生成”
04:09	官方数字 vs 独立实测	速度、成本、准确率、类型安全和校准置信度
06:09	社区案例与上手	typesafe-mario、browser-use/jev-ultrafast 与 AI SDK 7
08:18	Playground 五个场景	布尔判断、工单分诊、模型路由、内容审核、输出校验
13:15	官方 skill	让 coding agent 按需读取文档并设计决策工作流
15:26	用还是不用	适合分类、路由、打分、验证；不适合解释和开放式生成

一、Jev 解决的不是“模型不会聊天”

视频借用了丹尼尔·卡尼曼《思考，快与慢》的系统一与系统二：传统语言模型通常逐个 Token 生成文本，更像需要较长推理过程的系统二；Jev 则面向大量软件内部的快速判断。

这不是说 Jev 更像人类直觉，也不是说它可以替代通用模型。更准确的说法是：它把输出空间限制在软件预先声明的类型里，让模型只回答代码真正需要的问题。

例如下面这些任务通常不需要一段长文本：

• 工单应该进入 billing、technical 还是 account 队列；
• 用户情绪属于平静、焦虑还是愤怒；
• 一条评论是否为垃圾广告；
• 当前请求该交给便宜模型还是强模型；
• LLM 生成的回复是否泄露了内部政策。

传统做法是提示模型输出 JSON，再解析、校验和处理异常。Jev 的思路是把“允许出现哪些答案”直接放在问题定义里，模型返回的结构由问题类型约束。

二、三种原语：Choice、Score 与 Boolean

Vercel AI Gateway 的公开说明把 Jev 的三类输出称为 Choice、Score 和 Boolean；视频中把第三类称作 Noul，并解释为判断一个命题真假的概率。为了兼容两种表述，本文统一写成 Boolean（视频称 Noul）。

Choice：从有限选项中选择

当答案空间是有限集合时使用 Choice，例如：

问题：这条工单应该进入哪个队列？
选项：account / billing / technical / other
输出：billing
附带：各选项的概率分布

Choice 的关键不是“让模型猜一个标签”，而是让应用明确告诉模型有哪些合法选项。代码可以使用选中的 key，也可以根据概率和业务阈值决定是否转人工。

Score：在有序量表上评分

Score 适合有明确顺序的等级，例如故障严重程度、用户情绪或风险等级：

问题：这条工单的紧急程度如何？
等级：low / medium / high / critical
输出：high
附带：各等级的概率分布与分数

它不是要求模型自由生成一个任意数字，而是先定义量表，再在量表上评估。这样既能保留离散等级，也能利用概率判断结果是否接近边界。

Boolean：判断命题是否成立

Boolean 用于“是或否”的问题，例如“客服是否已经完成退款？”它的结果不是一段解释，而是 true / false 及其概率。

需要特别注意：概率高不等于业务事实已经被证明。它表示模型对这个判断的估计；最终是否允许退款、删除、发送或切换权限，仍然应该由代码规则、数据源和审批边界决定。

三、真正的变化：多个问题一次并行评估

视频里的工单场景同时询问了五个问题：工单类别、故障程度、是否有复现步骤、是否要求退款、用户情绪。传统的串行流程可能是：先判断类别，再根据类别继续追问，等待多次模型调用。

Jev 的建议是把相互独立的问题一次性声明：

同一份 state
  ├─ category: Choice
  ├─ severity: Score
  ├─ reproducible: Boolean
  ├─ refund_requested: Boolean
  └─ sentiment: Score

返回后，业务代码只消费与当前类别相关的答案。例如 category=technical 时读取 severity 和 reproducible；如果类别是 billing，则读取 refund_requested。没有关系的问题可以被忽略，而不必为它们额外发起请求。

这种模式的工程价值在于：把模型负责的语义判断和代码负责的业务依赖分开。模型一次给出候选事实，代码再决定哪些字段在当前状态下有效、是否触发下一步以及何时需要人工接管。

四、视频里的五个 Playground 场景

1. 一句话得到一个概率

第一个场景把客服记录作为 state，询问“是否已经完成退款”。视频还替换成“我们会在三个工作日内答复”和与问题无关的天气句子，观察概率如何变化。

这个实验说明了两点：Jev 可以快速回答一个原子问题；概率可以作为不确定性的信号。但它也提醒我们，单个概率不能代替数据核验，更不能直接变成财务动作。

2. 工单分诊：五问并发

一个工单同时包含“登录不上”“多扣钱”“要求退款”和“语气很急”等信息。五个问题一起评估后，代码可以按类别取相关字段，把低置信度或矛盾状态送入人工队列。

视频还测试了相互矛盾的工单和乱码输入。模型仍会在预设选项中做选择，因此概率分布非常重要：类型安全保证的是接口形状，不保证答案一定正确。

3. 模型路由

根据最近几轮对话，选择便宜模型还是强模型，是 Jev 很自然的用法。比如改错别字可以交给轻量模型；写带 LRU、TTL 和测试的缓存，或者优化大表查询，则可以路由到能力更强的模型。

路由模型的调用时间必须放在完整生成链路里衡量。如果一次路由本身比后续模型调用还慢，优化就失去了意义。视频中的判断是，在它展示的场景里路由耗时相对后续生成可以忽略；实际系统仍应以自己的 P50/P95 测量为准。

4. 内容审核

视频把作者、时间、评论正文、历史和举报次数组成 JSON state，然后同时询问：是否为垃圾广告、冒犯程度如何、应该放行、人工复核还是删除。

这里的关键是可以直接传结构化对象，不必先把所有字段拼成一段自然语言。更重要的是，删除属于外部副作用，模型的分类结果最多是决策输入，最终动作仍应经过明确的策略、审计和权限检查。

5. 给 LLM 输出加一道校验

视频最后把 Jev 放在语言模型后面：LLM 负责生成客服回复，Jev 负责判断回复质量、是否泄露内部政策，以及语气是道歉、中性还是推诿。

这是一个非常实用的分工：

用户问题 → LLM 生成草稿 → Jev 并行校验 → 发送 / 重写 / 人工复核

Jev 不是生成模型的替代品，而是“生成之后的结构化审查器”。它可以让每次输出都经过固定的检查，但不意味着一次校验就足以证明回复安全。安全规则、敏感字段检测和人工升级仍然需要独立存在。

五、官方数字应该怎样读

视频中记录了官方给出的价格、延迟、速度和准确率，并对比了独立测量结果。这里最重要的不是记住某个倍数，而是理解比较条件。

TypeSafe 官方页面把 Jev 定义为 System One Model，并公开声称其针对结构化决策、并行采样和校准概率进行了优化；Vercel 的接入公告则列出了 typesafe-ai/jev、AI SDK 7 的 experimental_evaluate 以及 Choice、Score、Boolean 三种类型。Vercel 同时转述了 TypeSafe 在自有 workflow evaluation 中的速度和成本数字。

这些数字必须带着上下文阅读：

• 评测的是否是 System One 形状的任务，而不是开放式写作；
• state 长度、问题数量和问题是否独立；
• 计算的是接口时间，还是包含网络、网关、浏览器和重试的端到端时间；
• 准确率的参考答案由谁提供，是否存在工作流和样本选择偏差；
• 置信度是否在自己的标注数据上做过校准。

官方博客也明确建议对自己的 workflow 做校准。更稳妥的做法是先拿几十到几百条有标注的真实样本，记录预测、概率、正确性和人工接管结果，再决定阈值和上线范围。

六、什么时候适合用，什么时候不要用

适合的场景

• 答案空间可以事先定义；
• 任务是分类、路由、打分、验证或分支；
• 一次请求里有多个相互独立的问题；
• 对低延迟、低成本或高频决策有要求；
• 不确定的结果可以转人工，而不是强行自动执行；
• 最终动作由确定性代码和权限系统控制。

不适合直接使用的场景

• 需要向用户解释理由、写长文本或生成代码；
• 选项设计不完整，正确答案可能根本不在选项里；
• 对隐私敏感，但托管 API、数据保留和训练政策尚未核清；
• 业务无法接受概率错误，却没有人工复核或回滚路径；
• 把 confidence 误当成整个流程的正确率；
• 需要开放式探索，而不是在固定问题中做判断。

视频里有一个特别值得保留的提醒：如果只给模型一个不包含真实答案的选项集合，它仍然必须从这些选项中选一个。问题设计本身就是系统的一部分，不是调用 API 之后才考虑的细节。

七、接入 AI SDK 时的最小结构

Vercel 的公开示例使用 AI SDK 7 的实验性 evaluate 接口。下面只展示调用结构，不包含任何密钥，也不表示当前所有项目都应直接复制上线：

import { experimental_evaluate as evaluate } from 'ai'

const result = await evaluate({
  model: 'typesafe-ai/jev',
  state: {
    message: 'The support agent issued a full refund to the customer.',
    channel: 'email',
  },
  questions: {
    refunded: {
      type: 'boolean',
      instructions: 'Was a refund issued?',
    },
    queue: {
      type: 'choice',
      options: ['account', 'billing', 'technical'],
      instructions: 'Which support queue should receive this case?',
    },
  },
})

console.log(result.answers)

生产接入时至少要补上：请求超时、重试上限、概率与置信度的记录、标注样本回放、敏感数据策略、人工升级、模型版本和成本追踪。对于删除、付款、发送消息、修改权限等动作，还要在模型判断之外保留硬编码的权限与确认门禁。

八、对 Agent 工程的启发

TypeSafe 准备的 coding-agent skill 并不是把整套 API 文档塞进上下文，而是引导 Agent 按需读取在线文档，并先从应用需求倒推需要哪些判断。这个工作方式本身很值得借鉴：

应用要展示或改变什么？
  → 哪些判断确实需要语义理解？
  → 哪些规则、计算和查表应该留在代码里？
  → 哪些问题可以并行评估？
  → 哪些低概率结果必须人工接管？

在 GPT88 或其他统一模型网关中，可以把 Jev 这一类模型放在显式的“快速决策路由”层，而不是让 Agent 自己随意切换：

decision_layer:
  state_source: structured_event
  questions: versioned-in-code
  fast_decision_model: typesafe-ai/jev
  low_confidence: human_review
  external_side_effects: require_policy_check
  audit: model_id_probability_latency_cost

这样做的重点不是绑定某一个供应商，而是保留能力边界：语言模型生成文字，决策模型回答有限问题，业务代码执行规则，权限系统控制副作用。

九、落地前检查清单

• 每个问题的合法答案空间已经定义，而且包含 unknown 或人工复核路径。
• Choice、Score、Boolean 的语义和量表已经写入版本化代码。
• 相互独立的问题合并评估，存在依赖的问题由代码处理顺序。
• 置信度和概率与真实标注数据做过校准，未把高置信度当成事实证明。
• 记录模型 ID、延迟、token、费用、答案、概率和人工接管结果。
• 路由、审核、重试和停止规则不依赖模型自由生成的解释文本。
• 删除、支付、发送、权限修改等动作有独立的策略和确认门禁。
• 对乱码、矛盾输入、选项缺失、网络超时和服务不可用做过测试。
• 先在真实的几十条标注任务上验证，再扩大自动化范围。

来源与边界

原始视频：01Coder｜Jev 实测：这款爆火的极速决策模型的基本玩法。视频章节包括“Jev 是什么”“官方数字 vs 独立实测”“Playground 五个场景实测”和“用还是不用”。

官方资料：TypeSafe AI｜Introducing System One Models & Jev、TypeSafe AI 文档、Vercel｜TypeSafe AI's Jev now available on AI Gateway、Vercel｜Jev API、Pricing & Playground。

本文保留了视频的主要技术脉络，并把官方定义和工程建议分开书写。官方速度、成本、准确率和置信度属于其公开评测或产品说明；视频中的 Playground 结果属于作者的体验；本文的架构、代码边界和检查清单是面向读者的工程化整理，不构成 Jev 或 GPT88 在所有任务上的性能、正确率或安全保证。