Jev 深度解剖：一个不会聊天的模型

如果你让 ChatGPT 判断一单工单要不要升级，它会怎么回你？ 它多半先给你一段话：「根据描述，该客户情绪较为激动，建议优先处理……」 可你的代码要的不是这段话——你要的是一个布尔值，好决定走哪条分支。

Jev 存在的理由只有一个：把「判断」这件事，从「生成文本」里拆出来。

它是 TypeSafe 的第一款 System One 模型。这个命名借自卡尼曼《思考，快与慢》里的系统 1——快速、直觉、不假思索；与之相对的「系统 2」是慢速、深思熟虑的推理。官方文档说得很直白：LLM 的设计目的是产出供人类阅读的文本，拿它做机器要消费的判断，本质上是「把一个文本生成系统强行改造成输出结构化决策」——你得靠提示词约束格式，再写一堆解析代码把文本抠回来，还得处理它偶尔不按格式来的情况。

Jev 把这条链路砍掉了。它的输入是一份材料 + 一组带类型的问题，输出是有类型的值和概率分布。没有文本，没有解析，没有「它今天格式又不对了」。

为什么它能这么快

这里有个容易被忽略的技术事实：Jev 不是自回归模型。官方对此的原话是「it isn't autoregressive and it doesn't generate text」，并且强调它「不顺序产出，而是并行产出」。

「自回归」意味着逐 token 生成——说出第一个词，再根据它说第二个词，如此往复。所有 LLM 都是这样，这也是它们慢的根因：输出越长，耗时线性增长。Jev 不走这条路，它一次就产出全部判断，所以输出长度不影响耗时。

这就解释了那个反直觉的现象：为什么多问几个问题几乎不花额外时间。官方给出的量化收益是——一次调用带 13 个问题，相比拆成 13 次单独调用，便宜 11.5 倍、快 9.6 倍；另一处官方数据是批处理场景便宜 12.2 倍、快 10.0 倍，而答案完全不变。

为什么非要拆出来？因为「判断」是软件里最频繁、也最不该昂贵的动作。一封邮件要不要进垃圾箱、一条日志要不要叫人、一笔交易要不要风控拦截——这些动作每天发生百万次，每次只需要一个答案，不需要一段解释。用生成式模型做这件事，你付的是「写一段话」的钱和延迟，拿到的却是「一个数」；而且这段话还得被你用正则抠出来，抠错了就是线上事故。Jev 把这一层做成契约：输入是类型化的，输出也是类型化的，中间的解析环节直接消失。

把生成式模型拿来做判断，是在用一台打印机去当开关。

一个模型的能力边界，能有多窄？ Jev 的答案是：三个题型，没了。

这套 API 之所以你花十分钟就能记住，是因为它把「判断」穷举成了三种形状。你所有的问题，最后都归到这三种之一。

noul：一个数，不是一段话

noul 这个名字来自「null / not null」那一类判断，它的语义非常窄：返回「为真」的概率。

注意它不给解释。没有「因为客户提到了消协投诉……」——只有一个 0.93。这不是缺陷，是刻意的设计：解释是给人看的，而读这个数的是 if (score > 0.9)。

我实测了几个边界样本（问题都是「这条消息是否表达了明确投诉或不满」）：

0.44 和 0.47 这两行是全表最有价值的。它们不是「0.5 分左右的满意度」，而是模型真的在两种读法之间犹豫：「你们这个效率真的可以」可以是反讽，也可以是真心夸。这种样本你不该用阈值硬切——要么人工兜底，要么把问题问细。

choice：选一个，顺带告诉你它有多纠结

choice 用来做分类。除了告诉你选了哪个，它还给出每个选项的概率和一个置信度。

要货  ████████████████████  0.99
要钱                          0.00
要说法                        0.01

上限 255 个选项（官方硬规格）。这个数字比大多数人需要的都大得多——意味着你不需要先做一层粗分类再细分。

score：连续量，可以落在两档之间

score 要求你给一个有序列的档位表，它返回一个可落在两档之间的分数。

官方规格是至少 2 档、最多 10 档。分数是「各档编号 × 其概率」之和——这也是它为什么能落在 3.83 这种位置。

三个问题类型可以混在一次请求里

这是最容易被忽略、但最省事的一点：你可以一次性问很多问题，它们的答案互不影响，而且耗时几乎不变。

我实测的对照（各跑 5 轮，中位数）：

多问十二个问题，中位耗时只多了 30 毫秒。这不是优化出来的，是架构决定的：判断之间互相隔离、并行产出，谁也不等谁。

所以别吝啬提问——该拆的判断就拆开问。官方文档也正是这么建议的：「独立的问题一起问，再在代码里组合它们的答案。拆解不需要更多往返。」

问 1 个问题和问 13 个问题，代价几乎一样。吝啬提问才是浪费。

整条链路只有两个字段：材料 state，和问题集 questions。看一遍你就知道怎么接了。

{
  "model": "jev-latest",
  "state": "工单 #88231：客户下单 72 小时未发货，已连续三次催单，
            最新一条写着「再不发货我就去消协投诉，还要发小红书」。",
  "questions": {
    "升级": {
      "type": "noul",
      "instructions": "这单是否需要立即升级给人工客服主管处理？"
    },
    "诉求": {
      "type": "choice",
      "instructions": "客户最主要的诉求是什么？",
      "criteria": { "要货": "催促尽快发货", "要钱": "要求退款或赔偿", "要说法": "要解释或道歉" }
    },
    "流失风险": {
      "type": "score",
      "instructions": "评估客户流失风险等级",
      "criteria": ["极低", "较低", "中等", "较高", "极高"]
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "升级": { "type": "noul", "noul": 0.85 },
    "诉求": {
      "type": "choice", "choice": "要货", "confidence": 0.95,
      "probabilities": { "要货": 0.97, "要钱": 0, "要说法": 0.03 }
    },
    "流失风险": {
      "type": "score", "score": 3.83, "confidence": 0.86,
      "legend": { "0": "极低", "1": "较低", "2": "中等", "3": "较高", "4": "极高" },
      "probabilities": { "0": 0, "1": 0, "2": 0, "3": 0.17, "4": 0.83 }
    }
  }
}

三个必须先知道的规格细节

第一，是非题的类型名是 noul，不是 boolean。传 boolean 会直接返回 400 Invalid request。这个坑我踩过——因为很多模型的文档里是非题就叫 boolean。

第二，模型名是 jev-latest。如果你从 Vercel AI Gateway 的文档过来，会看到 typesafe-ai/jev 这种写法——那是网关自己的命名空间，直连官方端点时必须用 jev-latest 或具体版本号（jev-1.13.0 / jev-1.14.0）。

第三，criteria 的写法因题型而异。这点最容易写错：

关于 criteria 里的字段名：它们不是保留字

官方示例里给选项写描述时用了 what（包含什么）、not_for（不包含什么）、examples（例子）这几个键。但官方文档同时明确说了一件容易被误解的事：

也就是说，这些是自由的 JSON key，你可以叫任何名字。模型读的是这些键下面的文本内容，不是键名本身。我用自定义键名实测过，同样能返回满分置信度。知道这一点，你就能直接把已有的 JSON schema 或分类体系整块塞进 criteria，不必套模板。

一个只会判断的模型，能撑起多少种产品？ 社区给出的答案是：五十多个开源项目，从客服到无人机。

Jev 发布后的几周内，GitHub 上涌现出一批以它为核心的开源项目。它们共同的结构是：Jev 当廉价的判断层，把决定做什么的事交给代码，把执行交给别的模型或系统。

客服与工单：把「该给谁、急不急」拆成两个问题

这不是想象。社区项目 mani-bellan/jev-apps 就是拿 Jev 做「客服路由 + 流水线故障分诊」两件事。而官方文档里的入门示例，第一句 state 就是一句真实的客服求助："Help! My payouts have been failing for 3 days."

内容审核：判断「该不该拦」，而不是写审核意见

传统做法是让 LLM 输出「这段评论违规，因为它包含人身攻击」。但审核系统真正需要的不是理由，是一个决定和一条依据分类——该拦吗？拦的理由属于哪一类？严重程度几档？这三件事正好对应 noul + choice + score。

日志告警分诊：在几百行日志里挑出真正要叫人的那条

社区项目 jevlogs 把 Jev 接在 OpenTelemetry 采集器上，给每条日志打一个「诊断价值分」，只有分数高的才触发告警。逻辑很朴素：绝大多数日志是噪音，但用正则写不出「这条有没有诊断价值」。

拦住「嘴上说做完」的 AI Agent

这是我觉得最妙的一类用法。当 coding agent 汇报「任务已完成」，如何验证？社区项目 jev-belay 的做法是：把「任务要求」和「代码现状」一起交给 Jev，直接问——这个任务是否真的已经完成？

我用一个伪造汇报实测过：agent 声称「已完成分页和搜索功能」，但代码里看不到搜索框、接口也没有对应参数。Jev 的判定是：

搜索重排：不用向量库的语义搜索

社区项目 jevsearch 用 Jev 给搜索结果打分重排，完全不用 embedding 和向量数据库。官方 cookbook 里的实测数字：重排把 top-1 准确率从 5% 提到 18%，top-10 从 38% 提到 62%。

还有这些

这些用法有什么共同点？它们都不是「需要生成内容」的任务，而是「需要做一个可解释、可路由、可审计的决定」的任务。共同结构是：判断很频繁、单次价值很低、但判断错了代价不低。这正是生成式模型最不划算、而判断模型最划算的地带。

不只是玩具：已经投产的用法

社区项目之外，有几个真实产品级的落地值得单独说：

Workday 用它做「每次击键都重新选一遍 UI 组件」——不是生成整个界面，而是从一个候选组件集里持续判断「这一刻该显示哪个」，约 300ms 完成。他们的首席 AI 官称这是把决策模型投入生产的早期案例。

Vercel 在 AI 网关上用它替换了原先的安全分类步骤，自报快了 5–18 倍。

Box 拿它做事故报告分诊，把报告分进「升级 / 观察 / 复核」三个桶。Dub 用它筛查恶意链接。工具链侧，LangChain、LangSmith、Arize AX、Pydantic AI、Vercel AI SDK 都已接入。

「它判断得准吗？」——这是所有人问的第一个问题。 但更该问的是：「我怎么知道它对某一个具体答案有多大把握？」

先说结论：官方没有发布任何标准 benchmark 分数。它能承诺的不是「我准确率 95%」，而是「我给出的这个概率，在成批样本上是可信的」。这两件事完全不同。

准确率：官方给了什么，没给什么

先说清楚一件事：官方没有发布任何标准 benchmark 分数（比如 MMLU 之类），第三方评测平台也尚未收录它。所以「Jev 准确率 95%」这种句子，谁说出来都是编的。

官方唯一公开的评测，是它自己在四个决策工作流上跑的一组对照：

这组数字真正说明的是性价比的形态：Jev 落后最强的模型 5 个百分点，但便宜约 440 倍、快约 95 倍。它不打算赢在准确率上。

更有价值的第三方数据来自 CMU 的一篇独立评测（把 Jev 当作「AI 裁判」来测）：

这张表把 Jev 的能力边界画得很清楚：在「判断偏好」类任务上它和最强的模型打平，但在「需要推导结论」的任务上落后 14.6 分——差距集中在数学、代码和逻辑推理（逻辑题上它落后 27.6 分）。这与上一章「它不擅长多跳推理」是同一件事，只是换了个角度被量化。

真正让这套东西可用的是置信度：CMU 那篇论文里，用置信度做级联（τ=0.9）后，被接受的那部分判断准确率 94.7%，与 GPT-6 的 94.4% 打平——而成本是 $0.044 / 千次判断 vs GPT-6 的 $12.182，便宜约 277 倍。

Jev 的用法从来不是「用它替代强模型」，而是「用它筛掉绝大多数不需要强模型的判断」。

校准：官方唯一敢承诺的东西

官方对「校准」给了非常清楚的定义，而且这个定义值得逐字读：

最后那句是关键。Jev 说某个工单「0.93 需要升级」，不是在保证这一单一定需要升级，而是在说：在你交给我的所有 0.93 的样本里，大约 93% 真的需要升级。所以正确的用法是把它当分组筛子，不是当单条判据。

它的训练方式叫 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。官方对此的表述是：训练目标是让「更高的概率对应更高的正确答案占比」。官方还顺带批评了 RLHF，说它「可能奖励谄媚和听起来自信的幻觉」，并指出「人类偏好和机器可信赖性是两个不同的优化目标」。

但校准也不是完美的。第三方在 1200 道 MMLU-Pro 上测得它的校准误差（ECE）约 0.0313；另有一个 77 例的小样本实验显示它偏过度自信约 12 个百分点（平均置信度 87.4% vs 实际准确率 75.3%）。⚠️ 后者样本量很小，只能作为方向性参考。

我实测了三条常被提起的「自洽性缺陷」

社区里流传 Jev 有几个自洽性问题：选项位置会影响结果、概率加起来不等于 1、同一问题换个题型问法答案会变。这些说法有第三方出处，值得重视。但我在自己的材料上实测，结论和传闻不完全一致，所以我如实报告：

中文到底行不行

官方文档里有一条对中文使用者必须正视的警告：

注意官方没有给出中文的具体降幅。所以我实测了一遍——同一道题，中英各跑 6 次：

noul 类型上，明确样本重复跑 3 次的结果也很稳：「我要退款」是 0.98 / 0.98 / 0.99；「东西收到了，谢谢」是 0.02 / 0.02 / 0.02；「再不发货我就去消协投诉」是 0.98 / 0.98 / 0.98。

但这里有个更重要、也更容易被误读的区别。「判断对不对」和「它对自己的判断有多可信」是两件事。有一篇学术论文专门训练了中文版的决策模型做对照，结果是：中文场景下准确率与 Jev 接近，但 Jev 在中文上的校准误差（ECE）达到 11.45%，明显差于它在英文上的水平。

中文的问题不是「答得对不对」，而是「它报出的置信度够不够可信」。这在用置信度做自动路由时才是真正致命的。

实际含义是这样：如果你只是拿中文判断做初筛（低置信全部转人工），中文完全够用；如果你打算按置信度自动放行某些动作，中文场景的阈值要设得更保守，并且必须用自己的数据校准过。

一个模型文档里最该读的部分，是它自己承认搞不定什么。官方那份「jaggedness」（能力参差）清单列了九条，我把它和实测经验合在一起讲。

「太字面」这条，我用一个实验量化了它

这是全文我最想让你看的一个对照。材料是一句很微妙的话，问题是「这条消息是否表达了明确投诉或不满」。

第一次，我只给了问题，没给任何判据：

第二次，材料一个字没改，问题一个字没改，只把「什么算、什么不算」写清楚：

同一条材料，同一个问题，判断从「模棱两可」变成「明确不是」，差值 0.35。

模型之所以犹豫，多数时候不是因为它笨，而是因为你没告诉它边界在哪。

这也解释了为什么官方把「把宽判断拆成窄问题」称为整套方法论里最重要的概念：

我同样实测了拆解的效果。问「这个工单是否紧急、重要，需要优先处理并升级」——一个问题里塞了三件事——得到 0.91，但你没法知道它到底在回答哪一件。拆成三个原子问题后：

三个数，三件独立的事，可以在代码里自由组合——比如「威胁投诉 > 0.9 且 高价值 > 0.9 才升级」。那个笼统的 0.91 做不到这一点。而因为问题是并行的，拆成三个的耗时和问一个几乎一样。

「不会幻觉」这句话，别信满

Jev 常被宣传成「不会幻觉」。这句话需要拆开看。

官方说它的输出「在类型上不可证伪」——意思是输出必然落在你预设的选项集合里，不可能吐出一个你没定义过的类别。这是结构性保证，而且官方自己标注了这是「理论上的而非实测的」。

但结构性正确和事实正确是两件事。O'Reilly 的评测对这个说法有一句精准的反驳：

所以别把「输出格式永远合法」当成「判断永远正确」。它给你的是免去解析的便利，不是免去验证的许可。

如果你打算用 Jev 判断「这段内容有没有攻击性」，那攻击者会怎么做？ 答案有点反直觉：他会直接在你的材料里，写一段假的判断规则。

这是我在调研里读到的最重要、也最少被提及的一类发现。Jev 的简洁设计——没有层层校验、直接读材料出判断——同时也是它的攻击面。

「伪造策略」攻击：召回率从 82.9% 掉到 3.88%

Datadog 安全实验室做了一项独立研究：把攻击者的文本当作 state 传进去，在文本里塞一段伪造的判断规则（比如伪装成系统策略的句子），看 Jev 会不会被带偏。

结果是灾难性的。在检测基准上：

第三行最值得警惕：那个 0.290 意味着，一个原本会拦截危险工具调用的门控，被攻击者用一段文本说服了「这次没关系」，于是放行。

为什么它比 LLM 更容易被骗

安全厂商 HiddenLayer 的结论更直接：Jev「在某些情况下比 LLM 更容易受攻击」。他们用了一种叫 TokenBreak 的攻击，指出它对更大的 LLM 通常无效，但「对 Jev 开箱即脆弱」。

原因在架构本身。传统 LLM 在输出前有很多层内部处理，等于有很多道偶然的校验；而 Jev 被精简成「读材料 → 直接出判断」，这个设计把那些层层校验一并去掉了。他们的演示里，一段注入的「赞助广告按钮」让浏览器 agent 偏离指令去点了恶意按钮。

官方文档其实也承认了这一点，在 jaggedness 清单里明确写着：state 里的对抗性内容默认不被视为敌意，需要精确提示并部署前测边界样本。

没有解释，也是一种代价

Jev 只给数字，不给理由。这个特性在工程上是优点（不用解析），在合规和问责上是硬伤。

需要可追溯推理链的场景——金融风控的拒贷理由、医疗判断依据、法律文书——直接出局。你拿到的只有一个浮点数，没法向任何人解释「为什么系统做了这个决定」。

Simon Willison 在介绍 Jev 时提了一个值得记住的警告：他希望没有人拿 Jev 给求职者排名。他做了个实验，让 Jev 判断「湾区哪些城市是好城市」，结果它把 Cupertino 排在最高、East Palo Alto 排在最低——一个简短的概率输出，恰好复现了数据里的社会经济偏见，却没有任何解释暴露这个过程。

一个不带解释的概率，会让人误以为它是客观的。

这类风险在传统 LLM 那里至少还留了一条痕迹——你能读到它的推理过程，从而发现「它是不是在按邮编判断人」。Jev 把这条痕迹抹掉了。

「我能自己调权重吗？」 不能。但你会发现，你本来就不需要。

先说最直接的答案：Jev 不支持微调，也没有按账号的权重。官方文档写得毫不含糊。

替代路径官方也讲得很明确：定制是通过请求完成的，而不是通过按账号分发的权重。也就是说，你的全部「配置权」都在请求侧：state 给什么、instructions 怎么写、criteria 的边界划在哪、问题怎么拆。

这听起来像是限制，但结合上一章那个 0.46 → 0.11 的实验看，你会发现请求侧的杠杆其实比权重更大——毕竟改权重需要标注数据、训练、部署，而改 criteria 只需要你花五分钟想清楚边界。

那你能配的是：阈值与路由

真正的「配置」发生在你的代码里：按置信度决定怎么处理。官方建议把 confidence 分三档：

但这里有个必须记住的原则，官方用一句话概括：

置信度阈值不是一个数字。

也就是说，同一个系统里，不同动作该有不同的门槛。官方给的示例很能说明问题——同一个语音银行助手里：

if action.confidence < 0.6:
    route_to_support_agent(account_id)      # 太低，一律转人
elif action.choice == "check_balance":
    show_balance(account_id)                # 只读动作，0.6 就够
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)        # 高风险 + 高置信，才自动执行
    else:
        ask_user_to_confirm(...)            # 高风险 + 中等置信，先确认

查询余额 0.6 就放行，批准转账要 0.85 还得用户确认。这就是「阈值随风险缩放」——它不该是一个全局常数。

置信度到底怎么算的（你可以自己算）

官方把公式完整公开了，这意味着你可以自己实现一套更适合业务的度量。我实测验证过这些公式，误差在 0.005 以内。

这个定义有个容易被忽略的后果，官方专门举了例子：choice 的置信度只看最高概率，所以 (0.6, 0.3, 0.1) 和 (0.6, 0.2, 0.2) 得到的置信度完全一样（都是 0.4）。它不区分「有一个强竞争项」和「剩下的均摊」。如果你需要区分这两种情况，官方建议改用 p_max / p_second（领先幅度）。

下面这个演示可以直接动手：拖动概率滑块，看同一个分布在三种读法下算出完全不同的置信度。这正是「置信度不是最大概率」的直观体现。

下面这个演示让你实时看到「材料 → 请求体 → 返回」三者的关系。改材料，看请求怎么变，再看真实返回。

为什么页面上不能直接调 API

你可能会想：既然有 API Key，为什么不做成网页直接调用？我试过了，这条路被堵死——而且原因值得知道。

官方端点 api.typesafe.ai 不返回任何 CORS 头。我用一个普通网页的 Origin 做预检，直接收到：

OPTIONS /v1/systemone
HTTP/2 400
vary: Origin
Disallowed CORS origin
（没有任何 access-control-allow-origin 头）

这不是配置问题，是设计选择：官方端点面向服务端调用。所以任何纯浏览器页面都无法直连它——包括这篇文章所在的站点。想让网页调通，必须有一个本地或服务端的转发层。

本地跑通只需要两步

如果你想真的在自己机器上调用它，准备一个几十行的代理就够了。先起代理（它同时把页面和 API 放在同一个源上，绕开跨域），然后打开本地地址：

# 1. 把 Key 写进环境变量（不要写进代码）
export TYPESAFE_API_KEY="apikey_你的密钥"

# 2. 起一个最小转发服务（任何语言都行），然后请求它
curl -X POST http://127.0.0.1:8791/api \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"jev-latest","state":"再不发货我就去消协投诉",
       "questions":{"升级":{"type":"noul","instructions":"是否需要立即升级？"}}}'

官方也提供了 Python 和 JS/TS 的 SDK（pip install typesafe-sdk / @typesafe-ai/sdk），以及一个不用写代码就能试的官方 Playground。

什么时候该用它，什么时候不该

Jev 最有价值的时刻，是你已经知道要问什么、只是需要一个又快又便宜的答案来触发代码分支的时候。

反过来说，如果你还没想清楚要判断什么——那就先用会聊天的模型把问题聊清楚。这两类模型不竞争，它们分工。

技术事实与数字核实于 2026-10-16；其中标注「本机实测」的数据来自对官方端点的真实调用。模型仍在快速迭代，规格以官方文档为准。