发表技术19 分钟读完 (大约2913个字)0次访问

Jev：不聊天，只决策的 AI 模型

Jev 不负责和你聊天，它只负责在软件最犹豫的那一秒，给出一个能被代码直接执行的判断

TypeSafe AI 官网 本身就做得很有趣，像一份带着技术脾气的产品宣言，值得先点进去逛一圈

最近爆火的 Jev，到底是什么

如果你最近刷到「一个 AI 在一周内通关《宝可梦 红》」的消息，主角大概率就是 Jev

它没有看屏幕，也不会写攻略，更不会在遇到岔路口时洋洋洒洒地分析一千字

它面对的是程序整理好的状态和一组合法选项，然后只做一件事

1
该往左走、往右走，还是先去补血

Jev 从中选出最合适的一项，并交出它对此有多大把握

这听起来不像那个无所不能的 AI，却恰恰击中了许多软件系统最缺的一环

大模型很会说，但程序真正想问的往往是

1
2
3
4
这张工单该交给谁
这个操作是否需要人工确认
这个用户现在流失的风险高不高
这一步该继续执行，还是立刻刹车

Jev 是 TypeSafe AI 在 2026 年 9 月发布的 System One 决策模型，官方对它的定义很干脆

非结构化状态输入，类型化的概率决策输出

它不生成自由文本，而是把「该怎么选」变成软件可以接住的 choice、score 或 noul

先用人脑理解 System One 和 System Two

这个名字来自丹尼尔·卡尼曼提出的两种思考方式

思考方式 像什么 擅长做什么
System One 看到红灯就停下来的直觉 快速识别、分类、判断、打分
System Two 坐下来写一篇分析报告 推理、创作、规划、解释复杂问题

GPT、Claude、Gemini 更接近 System Two

它们会一个 Token 一个 Token 地生成内容，所以擅长解释、写作、写代码和长链路推理

但如果你只是想知道「这是不是垃圾邮件」，让一个大模型先想一会儿、写一段解释、再输出 JSON，就有点像请论文导师帮你判断今天要不要带伞

Jev 想做的是 System One

它放弃了自由写作，换来更快的响应、更固定的输出，以及能用于程序分支的概率和置信度

1
2
3
4
5
LLM
输入 -> 逐字生成推理与答案 -> 程序解析文本 -> 决定下一步

Jev
状态 + 预设选项 -> 直接评估决策空间 -> 程序执行下一步

不是谁取代谁，而是一个负责想办法，一个负责在高频路口迅速拍板

它和“让 LLM 返回 JSON”有什么区别

乍一看，这两件事很像

你也可以让 GPT 返回下面这样的 JSON

1
2
3
4
5
{
  "category": "billing",
  "urgency": "high",
  "needs_human": false
}

区别在于，大模型本质上仍在生成文字

即使外面套了 JSON Schema，它也还是在一个个 Token 地写出 JSON，应用仍要处理截断、格式失败、工具调用和模型偶尔不按剧本演的情况

Jev 则要求你在请求前定义好答案空间

它可以判断错，但不能凭空造出一个你没有定义过的类别

这点很重要

1
2
Jev 的“不会幻觉”指不会产生类型或 Schema 之外的结果
不代表它永远不会判断错

如果你给它的类别只有「技术问题」和「账单问题」，一张物流投诉工单仍可能被它硬塞进其中一个

因此真正可靠的设计不是相信模型绝不会错，而是永远给它留一个 other 或「转人工」的出口

Jev 的三种问题

Jev 不是让你写开放式 Prompt，而是让你把问题声明成三种原语

类型 它回答什么 适合场景 例子
choice 在固定选项里选一个 分类、路由、下一步动作 工单该去账单组还是技术组
score 按有序标准打分 风险、紧急程度、优先级 这次事故有多紧急
noul 一个命题为真的概率 是非判断、护栏、审核 这次删除操作是否需要人工确认

noul 这个名字很陌生，可以先把它理解成「不直接回答是或否，而是给出“是”的概率」

例如 0.93 表示模型认为这个命题成立的概率很高，0.50 则代表它也拿不准

一次请求长什么样

下面是一个客服工单分流的示例

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
31
32
33
34
35
36
37
{
  "model": "jev-latest",
  "state": {
    "subject": "信用卡被重复扣款",
    "message": "昨天订阅扣了一次，今天又扣了一次，请尽快处理",
    "customer_tier": "pro"
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "这张工单应该路由到哪个团队",
      "criteria": {
        "billing": "扣费、退款、订阅和发票问题",
        "technical": "产品故障、错误和功能异常",
        "account": "登录、权限和账号资料问题",
        "other": "无法归入以上类别"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "评估处理紧急程度",
      "criteria": [
        "可以在三个工作日内处理",
        "应在一个工作日内处理",
        "需要当天优先处理"
      ]
    },
    "needs_human_review": {
      "type": "noul",
      "instructions": "这张工单是否需要人工优先介入",
      "criteria": {
        "true": "涉及重复扣款、高价值客户或可能造成资金损失",
        "false": "可以由自动化流程安全处理"
      }
    }
  }
}

这里最值得注意的是 state 和 questions

  • state 是所有判断共享的事实，可以是文本、JSON 对象或文本数组
  • questions 是你希望软件得到的几个明确答案，键名由你决定
  • 多个互不依赖的问题可以在同一次请求中被并行评估

这比让模型读完一段 Prompt 后「顺便帮我判断一下」更像在给软件写一组有语义的智能 if

返回结果为什么好用

上面的请求会得到类似这样的响应

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
31
32
33
34
35
{
  "model": "jev-latest",
  "answers": {
    "team": {
      "type": "choice",
      "choice": "billing",
      "confidence": 0.97,
      "probabilities": {
        "billing": 0.97,
        "technical": 0.01,
        "account": 0.01,
        "other": 0.01
      }
    },
    "urgency": {
      "type": "score",
      "score": 1.86,
      "confidence": 0.91,
      "legend": {
        "0": "可以在三个工作日内处理",
        "1": "应在一个工作日内处理",
        "2": "需要当天优先处理"
      },
      "probabilities": {
        "0": 0.03,
        "1": 0.08,
        "2": 0.89
      }
    },
    "needs_human_review": {
      "type": "noul",
      "noul": 0.94
    }
  }
}

程序不用猜模型在说什么，可以直接写出很朴素的业务逻辑

1
2
3
4
5
6
7
8
如果 needs_human_review >= 0.8
  -> 进入人工优先队列

否则如果 team = billing 且 urgency >= 1.5
  -> 路由到账单团队的高优先级队列

否则
  -> 走普通自动化流程

概率和置信度不是一回事

这也是 Jev 最容易让人产生兴趣的地方

probabilities 表示各个选项本身有多大可能性

1
2
3
billing 0.51
technical 0.47
other 0.02

这说明工单很难分，两个选项正在打架

confidence 则表示模型对自己做出这项判断的把握

如果一个模型的置信度经过校准，那么它说 80% 有把握的那批案例，理论上就应该大约有 80% 是真的

这就是官方所谓的 RLCD，也就是 Reinforcement Learning for Calibrated Decisions

它追求的不是「看起来特别自信」，而是「知道自己什么时候不太懂」

不过要把这句话划重点

校准是模型声称和需要持续验证的能力，不是拿到一个 0.9 就可以放心自动扣款

数据分布变了、问题描述变了、选项写得模糊了，原本好用的阈值都会失效

Jev 最适合放在 Agent 的哪里

我觉得最有意思的用法，不是把 Jev 当成更便宜的 ChatGPT，而是把它放进 Agent 的每个岔路口

1
2
3
4
5
6
用户请求
  -> LLM 理解需求并制订计划
  -> Jev 判断这一步是否安全、是否值得调用昂贵工具
  -> 工具执行
  -> Jev 判断结果是否可信、是否需要继续
  -> LLM 负责向用户解释最终结果

可以把 LLM 想成一个会做方案的聪明同事，把 Jev 想成一个反应快、从不离题的流程调度员

场景 让 Jev 做什么 让 LLM 做什么
客服系统 分类、打优先级、判断是否转人工 撰写回复、处理例外情况
Coding Agent 判断检索结果是否相关、改动是否需要复核 阅读代码、规划和写补丁
内容审核 初筛风险等级、判断是否进入人工队列 解释上下文、处理边缘案例
模型路由 判断问题难度和是否需要升级模型 回答复杂问题
工具调用 判断操作是否高风险 选择工具、组织参数、解释结果

这也是它在《宝可梦》演示里看起来很强的原因

Jev 负责在明确候选动作中不断选择，Claude Opus 则在它陷入死循环时阅读日志、改写状态和选项

一个负责踩油门和刹车，一个负责看地图和想策略

什么时候别用 Jev

Jev 的边界反而很清楚

  • 不要让它写文章、写邮件、写代码或做开放式创作
  • 不要把数学计算、日期比较、权限校验这类确定性问题交给它，普通代码更快也更可靠
  • 不要把超大段杂乱上下文直接丢进去，先用规则或 LLM 整理为会影响判断的事实
  • 不要省略 other、未知状态和人工兜底，否则模型只是在被迫猜答案
  • 不要把单次高置信度当成生产真相，仍要使用真实业务样本评估准确率和校准情况

它不是一个更小的通用模型，而是一把很锋利的专用刀

这波热度真正有意思的地方

Jev 最值得关注的，不只是「某次调用有多快、多便宜」

它把 AI 应用里一个常被忽略的问题摆到了台面上

软件不总是需要一段漂亮的回答，更多时候它只需要一个能审计、能分支、能兜底的决定

过去我们习惯让 LLM 先生成一堆文字，再从文字里找一个可以执行的结论

Jev 的思路则是反过来

1
2
3
先定义系统允许做什么
再让模型在边界里判断
最后由代码执行结果

这条路线能否成为下一种主流模型形态还很早，但它给 Agent 的一个提醒很实在

真正可靠的智能，不是每一步都表现得无所不能，而是在该自由发挥时创作，在该做选择时老老实实地选择

参考资料

#

喜欢这篇文章？打赏一下作者吧

×