最近很火的 Jev，到底是什么？

前言

这几天 AI 圈突然冒出来一个新贵：Jev，官网地址：

它不是 OpenAI、Google 或 Anthropic 发布的新模型，而是来自一家叫 TypeSafe AI 的创业公司。2026 年 9 月 15 日，TypeSafe AI 正式发布 Jev，并把它称为自己的第一个 System One Model。

这家公司之前已经低调研发了大约两年，而它的创始人 Diogo Almeida，来头不小。

在创办 TypeSafe AI 之前，Diogo Almeida 曾在 OpenAI 工作，参与过 InstructGPT、RLHF 相关的重要研究。按照他自己在 Jev 发布文章里的说法，这些工作后来成为 ChatGPT 背后的重要研究基础。

后来 Diogo Almeida 离开 OpenAI，创办 TypeSafe AI。相比继续做“更会生成”的大模型，他开始把注意力放到另一类问题上：如果一个任务本来只需要快速判断，为什么一定要让模型生成一大段答案？

Jev 就是在这个背景下出现的。

所以我们第一次接触 Jev，不用急着研究 System One、RLCD 这些技术名词，先记住它和我们熟悉的 ChatGPT 有一个很大的不同：

ChatGPT 擅长生成答案，而 Jev 更专注于做判断。

Jev 到底是什么？

如果非要找一个最简单的比喻，我觉得可以把 Jev 理解成：一个专门做“选择题”的 AI。

比如我平时做数据库监控，Oracle 突然出现下面这些指标：

CPU：95%
持续时间：10 分钟
Active Session：180
平时 CPU：30%

如果把这些信息交给 ChatGPT，它可以分析 CPU、活跃会话、等待事件、Top SQL，再结合上下文给出一大段原因和排查建议。对于 DBA 来说，这种能力当然很有价值，因为很多故障本来就需要分析和解释。

但如果面对这些数据的不是 DBA，而是一套监控程序，情况就不一样了。程序可能根本不需要 AI 写几百字分析，它只想快速知道一件事情：这个告警现在到底严不严重？

于是我们可以提前把答案范围定义好：

LOW
MEDIUM
HIGH
CRITICAL

Jev 要做的，就是根据当前信息，在这些候选答案中做出判断。

比如可能得到类似这样的结果：

程序看到 CRITICAL 的概率已经达到 75%，就可以根据提前设置好的规则决定是否发送告警、升级事件或者触发下一步处理。

这就是 Jev 和我们熟悉的大语言模型一个非常直观的区别。ChatGPT、Claude 更像是在做一道问答题，需要理解问题、分析信息，然后组织出一个完整答案；Jev 更像是在做选择题，答案范围已经给定，它需要解决的是“到底选哪个”。

当然，这不是严格的技术定义，但如果只是想快速搞懂 Jev 是干什么的，这样理解已经足够了。

更有意思的是，大家已经开始拿 Jev 玩游戏了

如果只是看上面的介绍，可能还是会觉得 Jev 有点抽象。好在 Jev 发布以后，官方和社区很快就做出了一堆非常有意思的 Demo，我觉得看这些 Demo，反而比研究一堆技术参数更容易理解 Jev。

TypeSafe 官方自己就拿 Jev 玩起了经典 FPS 游戏 Doom。

Jev 并不是像人一样盯着游戏画面操作，而是不断读取当前的游戏状态，然后判断下一步应该做什么。游戏程序还是正常运行，Jev 只负责根据当前情况不断做决定，这正好把它“快速判断”的特点展示了出来。

接下来社区开始玩得越来越花，其中一个我觉得特别直观的项目叫 Jev Pong。

它让 Jev 和其他聊天模型一起打 Pong，也就是我们熟悉的乒乓球小游戏。这个实验有意思的地方并不是比较谁更聪明，而是规定模型完成一次判断，球才往前移动一步，于是模型的响应速度会直接反映到游戏画面上。

项目记录的一组测试中，Jev 平均一次判断大约需要 227ms，每秒可以完成约 4.4 次判断；同场的几个聊天模型则需要几秒钟。更重要的是，作者明确表示，其他模型在同样问题上的正确率也很高，所以这个 Demo 想展示的并不是 Jev 更聪明，而是 Jev 更快。

作者自己总结得很好：

This is a latency demo, not an intelligence demo.

换句话说，大家都会做这道选择题，只不过一个两百多毫秒就交卷了，另一个可能还要等几秒钟。放到实时游戏里，这个差距一下就看出来了。

这个项目也已经开源：

再往后，还有人让 Jev 玩起了 Subway Surfers，也就是地铁跑酷。

这个 Demo 的视觉效果就更夸张了。开发者 Max Blade 不但让 Jev 玩地铁跑酷，还同时跑了 50 局游戏。按照作者公布的数据，这次运行的模型调用成本不到 1 美分。当然，这个成本数字来自 Demo 作者本人，并不是独立 Benchmark。

跑酷游戏其实也很适合 Jev，因为游戏一直在产生新的状态，而模型需要不断判断下一步应该往左、往右、跳还是蹲。一次判断结束以后，马上又进入下一次判断。

除此之外，社区里很快又出现了贪吃蛇、迷宫、ViZDoom 等各种实验，甚至已经有人开始自己复刻类似 Jev 的小型决策模型。比如开源项目 NanoJev，作者就把模型、代码、数据集和游戏回放一起放了出来。

开源地址：

看了几个 Demo 以后，我大概明白为什么大家都喜欢拿游戏来演示 Jev 了。

不管是 Doom、Pong 还是贪吃蛇，游戏本身都还是正常运行，Jev 只在需要做决定的时候参与一下。球拍往上还是往下，蛇下一步往哪个方向走，碰到敌人以后采取什么动作，这些事情刚好都是 Jev 擅长的。

而且游戏对速度特别敏感。一次判断慢两三秒，放在普通聊天里可能只是多等一会儿，但放进 Pong 或者跑酷游戏里，画面马上就卡住了。所以这些 Demo 展示的与其说是 Jev 会玩游戏，不如说是它能不能连续、快速地做判断。

换到实际的软件里其实也一样。监控平台判断告警等级、风控系统决定通过还是转人工、Agent 决定下一步调用哪个工具，这些任务很多时候都不需要模型写一大段话，只要尽快给出一个明确结果就够了。

为什么 Jev 最近这么火？

除了上面这些好玩的 Demo，Jev 这几天能迅速引起关注，还有一个很现实的原因：快，而且便宜。

TypeSafe 官方公布的测试中，Jev 在部分工作流上的数据非常夸张，最高给出了约 193.6 倍的速度提升和 444.6 倍的成本下降。

当然，这些主要还是 TypeSafe 自己公布的数据。Jev 才刚刚发布，现在就拿这些数字证明它全面碾压传统大模型还太早，真实效果还需要更多第三方测试和实际业务去验证。

这些数字先不用太当真，Jev 才刚发布，真实效果还得看更多第三方测试。真正值得看的，是如果 AI 判断真的可以做到足够快、足够便宜，那很多以前根本不会考虑使用 AI 的地方，是不是也可以开始用了？

这也正好解释了为什么它叫 Jev。

Jev 这个名字来自英国经济学家 William Stanley Jevons（威廉·斯坦利·杰文斯），他提出过著名的 杰文斯悖论（Jevons Paradox）。

简单来说就是：

一个东西变得越来越高效、越来越便宜以后，人们反而可能用得越来越多。

以前一次 AI 调用又慢又贵，我们会先想：“这种地方真的有必要用 AI 吗？”

但如果未来一次判断足够快，成本低到几乎不用考虑，这个问题可能就会变成：“既然这么便宜，那为什么不用？”

一天调用十几次可能感觉不到区别，但如果以后一个系统每天需要做几十万、几百万次这样的判断，速度和成本就完全是另一回事了。

Jev 会取代 ChatGPT 吗？

至少从现在来看，没必要这么理解。

像分析 Oracle AWR、写代码、总结文档这些需要大量理解、推理和生成的任务，还是 GPT、Claude 这类大语言模型更擅长；而告警分级、风险判断、Agent 路由这类需要快速做选择的任务，Jev 可能更合适。

所以它们并不是简单的替代关系。一个擅长复杂的理解和生成，一个专门解决大量、快速、明确的判断。

这也是 Jev 给我的一个提醒：

AI 不一定非得会写东西。

过去几年，我们已经习惯了 AI 就是一个聊天框，输入一个问题，然后等它生成一段答案。但未来大量 AI 可能根本不会和人聊天，而是藏在软件后面，不断帮程序完成一次又一次判断。

其实仔细想想，这种 AI 可能比聊天机器人更容易真正进入业务系统。用户甚至不需要知道背后有一个模型，它只需要在合适的时候给程序一个足够快、足够可靠的结果。

最后

Jev 在 2026 年 9 月 15 日才刚刚公开发布，它最终能不能成为一种主流模型，现在下结论还太早。

官方公布的速度和成本优势能不能在更多真实场景里复现，判断准确率到底怎么样，哪些场景适合 Jev、哪些场景还是应该交给传统大模型，这些问题目前都还需要更多测试。

但至少从这几天出现的 Doom、Pong、地铁跑酷、贪吃蛇这些 Demo 来看，Jev 确实展示了一种和传统聊天模型不太一样的玩法。

当然，看别人玩游戏终究只是看热闹。Jev 到底怎么调用，API 好不好用，速度是不是真有这么快，实际判断效果怎么样，还是得自己跑一遍才知道。

所以下一篇，我准备从零开始上手 Jev。

从注册、申请 API Key、第一次调用，到 Choice、Score、Noul 怎么用，再拿几个真实场景跑一遍。尽量不讲复杂原理，先把它真正用起来。

下一篇：《小白如何零基础上手 Jev？》