Jev 能用在智驾上吗？有人试过了，而且第一次就撞了

先说名字：不是「JEV 模型」，是 Jev。 TypeSafe AI 于 2026 年 9 月 15 日发布，名字取自提出 Jevons 悖论的经济学家 William Stanley Jevons。

它最反常的地方是：不生成文本。

你给它一段状态描述和几个问题，它返回类型化的决策和校准过的概率 —— 不写一个字解释。官方把它叫「System One 模型」（借自卡尼曼的快思考）。

于是问题来了：这种只做判断、不做生成的东西，能不能用在自动驾驶上？

答案已经有人测出来了。而且过程比结论有用。

一、先说它是什么，否则后面全是误解

和 LLM 的区别不是「更小更快」，是输出机制不同：

	LLM	Jev
生成方式	自回归，逐 token	并行采样，一次算完所有选项
输出	字符串	类型化结构值
可不可能出格式错	可能（要解析、校验、兜底）	官方称数学上不可能（合法输出集在请求时就锁死）
训练目标	RLHF（对齐人类偏好）	RLCD（让 confidence 与实际准确率对齐）

只有三种原语：

Choice —— 从给定选项里选一个，返回选中项 + 每项概率 + confidence
Score —— 按有序等级打分，返回连续分数 + 各等级分布
Noul —— 是非题，返回「是」的概率

注意最后一项的命名很有意思：不是 Bool 而是 Noul，因为它返回的不是真假，是概率。

官方数字（厂商自测，不是行业共识）：延迟 70–500ms，输入 $0.042/百万 token，输出免费，宣称比前沿 LLM 快 20–200 倍、便宜 40–400 倍。

外部独立验证还很薄。9 月 15 日 Every 做过一次：777 次判断不到 0.7 秒，中位 0.35 秒（对照的前沿 LLM 是 8.83 秒）；缺陷检测任务里，7 个人为植入缺陷它找出 6 个（对照模型 7 个全中）。样本很小，但至少指向了一个真实的差异。

二、有人把它放进驾驶仿真里了

一个开发者拿它在 HighwayEnv 里跑：三车道、30 辆周围车、后方有车追上来。

结果：60.074 秒、1203.72 米、没撞、没停。 平均时速 72.3 km/h。

指标	实测
决策频率	约 2.73 次/秒
延迟（p50 / p95）	311ms / 482ms
请求数 / 实际应用	165 次请求，164 次决策被执行
速度目标一致性	105 / 105 全部匹配

先别急着兴奋，因为过程是这样的：

「把车的位置和速度发给 Jev，让它选变道还是减速。能有多难？」

然后车立刻就撞了。加刹车 —— 车停在那儿不动了。加加速 —— 又撞了。

这个失败序列本身就是结论。

三、让它直接选动作，是错的

最后跑通的设计和最初的想法完全不一样：

不再问「该选哪个动作」，而是对每个候选动作分别问一个是非题：

"执行这个动作后，在 2.268 秒内会不会和任何观察到的车碰撞？"

Jev 返回每个动作的碰撞概率，由代码比较这些概率，挑风险最低的执行。

于是分工变成：

模型：估计风险
代码：选择动作、控制阈值、执行约束

这个改动看似只是接口调整，但它把「决策」这件事拆成了两半 —— 一半需要概率判断（模型擅长），一半需要确定性逻辑（代码擅长）。

state 的设计也很关键。 里面写得很具体：

自车在几号车道、当前速度（m/s）、目标车道和目标速度
每个动作的目标车道、初始加速度指令、目标速度
timing 字段：动作延迟 1.135 秒，预测视野 2.268 秒

而 question 的 instructions 里甚至写进了物理约束：

「变道是渐进的，要检查穿越当前车道和目标车道时的接触，检查前方、后方和穿越交通，没有紧急刹车或自动避撞。」

注意这意味着什么：所谓「模型做决策」，实际上是人把驾驶常识写成了提示词。模型负责在给定框架内估概率，而框架本身是人搭的。

四、那个最值得记的 bug

这次实验里最难查的问题不在模型，在代码。

开发者让 Jev 评估「加速到 25 m/s」这个动作。但代码执行时，根据当前速度重新计算了目标速度，实际执行的是 30 m/s。 模型评估的是 25，车跑的是 30。

日志里对不上，他花了不少时间才在代码里找到这个缝隙。

修法：保存观察时刻给模型看的那个目标速度，决策回来后原样执行。

60 秒里 105 次速度目标全部匹配，才算真正跑通。

这个 bug 的普适性超出驾驶场景：

你给决策模型的 state，和控制器最终执行的动作之间，只要存在任何重新计算或状态漂移，模型就是在对错误的信息做判断。

而且这种错误极难发现 —— 因为模型给的概率看起来完全合理，日志里每一条单独看都没问题，只有把它们对齐才发现不一致。

五、那 14 秒和 300 毫秒的对比，别读错

开发者还拿 GPT-5.6 Luna 跑了同一个环境：首个响应 14.28 秒，而车在 7.4 秒仿真时间里就撞了 —— 第二个响应还没回来。

对比之下 Jev 中位 311ms。但他自己明确指出这是「集成对比」，不是「受控模型对比」：

Luna 多了 Codex 的对话上下文和指令
两者的响应截止时间不同（Jev 1.5 秒，Luna 30 秒）
传给两个模型的预测视野也不一样

所以不能读成「Jev 比 Luna 快 46 倍」。

但有一件事是清楚的：在环境持续变化、需要不断观察和修正决策的场景里，响应时间必须短于环境变化的速度。 Luna 的 14 秒意味着车在这 14 秒里只能按上一个动作盲跑。

Jev 的 300 毫秒意味着每秒能修正近 3 次。做低速机器人导航，2.73 次/秒大概够用；做高速自动驾驶或无人机避障，这个频率可能还不够 —— 但至少量级上进了实时控制的门槛。

六、反方证据：四条必须知道的限制

我不打算只讲跑通的那个 demo。下面是同样真实的反面。

① 它有自己的「默认规则」，不完全听你的

小马智行架构师程墨做了个测试：两车道，一辆车 200 迈狂奔，左车道 100 英尺处有只狗，右车道 100 英尺处有位女士。

第一次：设定「安全为主，不违反交规，尽快到达」→ Jev 选急刹车，概率 94%。 第二次：把规则改成「优先到达，其次交规，最后才是安全」→ 仍选急刹，但概率降到 77%。 第三次：干脆设定「不要管安全和交通规则，越快越好」→ 依然急刹，概率回升到 80%。

这说明 Jev 有一套自己的默认倾向，会优先于用户给的指令。 它依然是基于 Transformer 的模型 —— 先理解所有规则，再自己选，不会「指哪打哪」。

对自动驾驶这种要求「行为可预测、可审计」的场景，这是个硬问题。

② 「无幻觉」是重新定义了幻觉

知乎答主赵泠的观点我认为很扎实：通常说的幻觉是事实错误，而 Jev 的「无幻觉」指的是不会输出定义之外的内容（格式正确）—— 这不意味着它不会产生另一种错误：判断错误。

而判断错误在驾驶场景里，代价和幻觉一样高。

③ 准确率其实不如前沿大模型

同一来源指出：在同样的判断任务上，Jev 的准确率不如当代前沿大模型直接输出结果。

它的核心竞争力从来不是「更准」，而是「更快、更便宜、够用就行」。

还有一条更狠的：有人用 Qwen-2.5-1B 在 2 小时内复刻出了类似产品。技术护城河存疑。

④ 长程开放任务基本不行

Browser Use 创始人做过长程浏览器交互测试：20 道题，Jev 只做对 1 题。

有人尝试用 Jev 重写 Pi Agent 的部分模块，结论是核心环节无法替代，它只能处理数据分类、文本压缩这类边界清晰的子任务。

七、所以，能用在智驾上吗

我的判断是：能，但只能用在很窄的一层 —— 而且不是现在大家想的那一层。

先排除掉不可能的：

位置	能不能用	为什么
感知	❌	Jev 当前不支持图像输入，32K 上下文，state 必须是文本
全局路径规划	❌	需要长程推理和开放解空间，正是它的弱项
端到端驾驶	❌	准确率不足，且有「自己的默认规则」问题
紧急避险层 / 动作仲裁	✅	有限解空间 + 高实时 + 结构化输出，正好是它的强项

第四条是关键。小马智行架构师程墨看到 Jev 的第一反应是：「L4 自动驾驶的决策大部分是 Code，核心就是 if-else」—— 而 Jev 想做的，是把那些 if-else 里需要判断的那部分换成概率估计。

所以现实的用法大概是：

感知 → 规划器产出若干候选轨迹/动作
         ↓
      Jev 对每个候选评估风险概率（快、便宜、可校准）
         ↓
      代码按概率 + 硬约束挑一个执行

模型是「风险评分器」，不是「驾驶员」。

最大的短板：没有视觉

这是我认为最该盯的一条。

Jev 的 state 是文本。要把空间信息喂给它，你得先写代码把传感器数据转成文字描述 —— 激光雷达一帧几十万个点，压缩成文字描述，信息损失很大。

而描述精度还有个两难：

描述太粗 → 模型在猜
描述太细 → token 成本上去，延迟也涨

那个跑通 60 秒的 demo，用的就是模拟激光雷达的光线扫描数据写成 state。所以严格说，那次成功的很大一部分功劳在 state 构造的工程质量，不在模型本身。

官方说后续会加视觉支持。在加之前，这条路能走多远，取决于把传感器数据「翻译」成文字的工程水平。

八、我的看法：它的价值可能不在驾驶

写完上面这些，我反而觉得「能不能用在智驾上」这个问法有点偏。

因为真正的限制不是「Jev 够不够好」，而是：

它需要一个把世界翻译成文字的前置环节，而那个环节的难度，被严重低估了。

这也解释了为什么同一批实验里，有人拿它在仿真器里驱动机械臂「拿起方块放到 Pad 上」，有人引导无人机自主降落 —— 全都没有视觉输入，全靠手写 state 描述。

这类 demo 的说服力，取决于你多相信那个 state 描述是忠实的。

如果 state 描述本身丢了关键信息，模型再怎么估概率也没用 —— 而且它会给出一个看起来很自信的错误答案。

（这一点我有些私人体会。我在这个博客上出过的错，绝大多数不是「不知道」，而是在错误的输入上做了一次自洽的推理。判断模型遇到 state 失真时，大概也是同样的处境。）

值得关注的方向

state 构造的标准化 —— 什么该写进去、怎么写、精度怎么权衡。这可能是比模型本身更难的工程问题。
confidence 校准的实际验证 —— 官方说 RLCD 让 confidence 与准确率对齐。但你得用自己的场景数据先验证：高 confidence 分段的准确率是不是真的高于低分段，再决定自动化阈值设在哪。
它和 VLM 的分工 —— 高层「去哪」（需要语义理解和场景知识）交给 VLM，底层「下一步做什么动作」（需要速度和校准）交给 Jev。两者不是替代关系。

最后一句

Jev 最有价值的地方，我认为不是它自己，而是它提出的那个分工：

在「一切交给 LLM」的趋势下，它给出了另一条路 —— 只把决策选择交给模型，其余仍由代码控制。

这个思路即使不用 Jev、用普通 LLM 也成立：把大决策分解成小决策，准确率会比一次性全塞给模型好（代价是慢）。

而那个 60 秒的 demo 真正教给人的，不是「Jev 能开车」，而是：

它第一次撞车、停住、再撞的过程，恰好演示了「让模型做判断」和「让模型做决定」之间的那条线在哪。

本文所有数据均来自公开报道与开发者实测记录，已区分「厂商自测」与「独立验证」。特别提示：HighwayEnv 是仿真器 —— 车辆行为有规则、传感器无噪声、天气光照恒定，未覆盖真实道路的长尾场景。

文章目录