7秒订完机票、70毫秒打毁灭战士：不会说话的AI被网友玩坏了

素材说明：本文基于 TypeSafe AI 官方发布与演示、Simon Willison 的实测与整理、
 Hacker News 主帖及社区讨论、browser-use/jev-ultrafast 仓库 README 与第三方实测、
 Firecrawl、Octomind、Made with Jev 目录站等公开来源交叉整理。
 各项目的性能数字均为作者自述，除特别说明外未经独立复现，文中已逐处标明。

---

01 先说清楚，它是个什么东西

Jev 是 TypeSafe AI 在 9 月 15 日发布的模型，创始人 Diogo Almeida 是前 OpenAI 研究员、RLHF 的共同发明人，公司拿了 4000 万美元种子轮。

它跟我们熟悉的所有 AI 有一个根本区别：它不会说话。

你给它一段文字或一份数据（官方叫 state），再给它一组"类型化问题"，它返回的是数字，不是一个字。问题只有三种：

• 
  
• Choice
  ——从你给的选项里挑一个，附带每个选项的概率
• 
  
• Score
  ——按你定义的量表打个分
• 
  
• Noul
  ——是或否，返回一个 0 到 1 之间的概率（名字取自伯努利分布的 Bernoulli）
• 
  

一次请求里可以并行塞几十个问题，耗时跟问一个差不多。延迟 70 到 500 毫秒，价格是每百万输入 token 0.042 美元，输出免费。

用开发者 lubujackson 在 Hacker News 上的话说，过去两年大家一直在干的事是"逼大模型吐 JSON，再写脆弱的正则表达式提心吊胆地防崩溃"，而 Jev 就是为了消灭这件事而生的。

但有意思的部分不在官方通稿里。

Jev 发布不到一周，社区做了一大堆项目。Made with Jev 这个目录站上线 26 小时就收录了 239 个作品，其中光 GitHub 仓库就有 143 个。

我翻完了能找到的公开记录，挑出最有趣的五个。判断标准不是有用——这五个里有两个是纯粹的玩笑，而恰恰是那两个说清楚了 Jev 到底是什么。

---

02 No.5 pi-warden：给 AI 编程智能体装一个刹车

唯一进榜的"正经工具"，因为它所在的位置最微妙。

现在所有人都在用 AI 写代码。但凡用过的人都知道真正的风险不是它写错，是它自作主张——擅自执行一条删库命令，或者信心十足地宣布"做完了"而实际上测试一次都没跑。

pi-warden 的做法是：在编码智能体的每一步动作前，让 Jev 先做一次判断。它不只拦破坏性调用，还会干这几件事：

• 
  
• 把写出来的代码拿去跟项目的规则文件比对
• 
  
• 标记出桩代码（stub）和那些"可能"、"一般来说"式的含糊措辞
• 
  
• 检测卡死循环——同一个动作反复失败还在重试
• 
  
• 抓"声称完成但没跑过测试"
• 
  

最后这条最狠。它治的不是代码能力问题，是 AI 的态度问题。

同在 r/PiCodingAgent 上，另一位开发者 u/peepo_comfy 做了个更激进的版本：给每一次工具调用打安全分，然后计划做一个路由器——根据提示词难度和代码库复杂度自动选模型。

他留下了一句使用心得，我认为是理解这类模型的关键：你必须把问题措辞写得非常明确，而且分层提问的效果远好于一个笼统的大问题。

这句话后面还会出现。

---

03 No.4 用 Jev 打《毁灭战士》

这条是 TypeSafe 官方自己放出来的演示，但我把它放进榜是因为它最有画面感。

演示的逻辑是把游戏的实时状态——生命值、弹药量、周围恶魔的距离和坐标——全部编码成纯文本，喂给 Jev，让它通过 Choice 原语决定下一步动作。

结果：单次延迟 80 到 100 毫秒，约 10 QPS。

这个数字要放在对比里才有意义。过去想让大模型玩实时动作游戏基本是场灾难——模型还在逐字往外蹦"好的，我现在决定向左后方走位并换喷子"这句话的时候，游戏里的角色早就被恶魔打死几十次了。

而 70 到 100 毫秒是什么概念？人类视觉反应时间的下限大约是 100 毫秒。

也就是说，这个不会说话的模型，在游戏里反应得比人快。它输出的不是一段描述，是一个可以直接挂进主事件循环的开关量。有人把它形容为"毫秒级的机器直觉神经元"——这个比喻我觉得是准确的。

它证明的不是 Jev 会打游戏，而是：当卸下"生成文字"这个包袱，模型可以直接坐进系统的决策回路里，而不再只是坐在旁边给建议。

---

04 No.3 jev-ultrafast：7.073 秒订完一张机票

这是整个生态里最火的项目，没有之一。

仓库 9 月 16 日创建，也就是 Jev 发布第二天。到 9 月 22 日，17,202 星、1,091 fork，MIT 协议。作者是 browser-use 团队。

它的做法很聪明，聪明在减法。

大多数 AI 浏览器智能体是这么工作的：截图 → 丢给大模型 → 模型看图思考 → 写一段 JSON 动作 → 解析 → 执行。每一步三到八秒，十步就是一分钟。

jev-ultrafast 换了个思路。它每次观察页面时，读取可见 HTML 和 ARIA 控件，把页面上所有可交互元素整理成一张带编号的表：

button     Change ticket type · Round trip combobox   Where from?        · San Francisco combobox   Where to?          · empty 

模型只能在"已观察到的元素"和"受支持的动作"里做选择——它不能凭空编造 CSS 选择器、坐标或 JavaScript。支持的操作只有 CLICK、TYPE_TEXT、SELECT、SCROLL、WAIT、DONE、BLOCKED 七个。

关键一步在这里："下一步做什么"和"做在哪个元素上"，在同一次请求里并行回答。 如果答案是 CLICK，代码只读 click_target 这一个字段，其余推测结果直接丢弃。两次判断被压进一次网络往返——这就是 TypeSafe 说的 speculative fan-out。

只有真正需要打字时，才调用一个小模型。演示里小模型一共只被调用了两次：生成"Zürich"用了 581 毫秒，生成"London"用了 346 毫秒。

最终成绩：从自然语言目标到 Google Flights 出结果，7.073 秒，录屏 1× 速度，经独立校验。

对照实验也做了：任务中位时间从 9.450 秒降到 7.092 秒（快 25%），浏览器协议调用从中位 1,092 次降到 101 次。

但我得把话说完整。这个 7.073 秒是一个任务、一个网站、三组重复，作者自己在 README 里写了"这不是通用可靠性基准"。那个流传很广的"单次成本 0.0039 美元"，仓库里能核对的只有两次文本模型调用合计的 0.00006272 美元。

还有个更有意思的后续：有开发者把它接到 OpenRouter，拿去跑 12306——查北京南到上海虹桥的余票。原版连撞三个坑：12306 的车站联想依赖逐键事件、候选项是没有标准 ARIA 角色的自定义 div、点"查询"会开新标签页。模型一度在错误的页面上宣布完成。

补了三项通用能力后跑通了，7 次操作 20.391 秒，四项独立校验全过。这个结果比"又跑通一个网站"有价值得多——Jev 的有限选择确实快，真正拖住它的是网页工程细节：键盘事件、非标准控件、多标签页。

它的边界不在模型，在 DOM 之外。

---

05 No.2 jevchat：把哑巴逼成话痨

现在开始进入玩笑区。但这两个玩笑，我认为比上面三个正经项目更有信息量。

jevchat 是开发者 Kyle Pena 做的。它的目标荒诞到近乎挑衅：把一个根本不会生成文字的模型，变成一个聊天模型。

做法是这样的——每一步，它向 Jev 提一个问题：

"给定用户的问题和目前已经写出的回复，下一个符号是什么？"

然后 Jev 从候选符号里挑一个。挑完拼上去，再问下一个。一个字一个字地往外蹦。

可以想象那个画面：你问它一句话，它像某种极其缓慢的通灵仪式，逐字符地把回答挤出来。

Hacker News 上用户 ericpruitt 给了一句我认为是全网最好的点评：

"这是 Morty 拿着死亡水晶说话的数字等价物。"

（《瑞克和莫蒂》里那块能看到所有可能结局、让持有者说出宿命台词的水晶。）

这句话精准在哪？它说出了 Jev 的本质——它不是在"思考该说什么"，它是在每一步对所有可能性做一次概率抽样。 普通聊天模型的逐字生成是自回归的副产品；jevchat 把它还原成了本来面目，于是所有人都看清了：所谓"说话"，拆到底就是一连串的选择。

这个项目毫无用处。但它是一个教科书级别的反向工程——用最蠢的方式证明了这个模型的工作原理。

---

06 No.1 jev-leftpad：用 AI 重写了那个让半个互联网瘫痪的 11 行代码

第一名给一个只有十几行的 npm 包。理由是它把整个 2026 年的 AI 荒诞感压缩进了一个函数里。

先补个背景。2016 年，一个叫 left-pad 的 npm 包被作者从仓库里删除，导致成千上万的 JavaScript 项目构建失败——它的全部功能是在字符串左边补空格，实现不到 11 行。这件事后来成了软件史上关于供应链依赖最著名的教训。

十年后，开发者 Fatih Kadir Akın 用 Jev 把它重写了一遍。

用法长这样：

import leftPad from 'jev-leftpad'; const result = await leftPad('jev', 8); // "     jev"（大概） 

内部逻辑：给 Jev 一个 Choice 问题，选项从 space_0 一直列到 space_10，问它"需要几个空格"。比如目标是 8、值是 'jev'，正确答案应该是 space_5。JavaScript 拿到这个数字，生成五个空格，拼上原值。

于是这个包就有了三个荒谬到完美的性质：

第一，它最多只能补 10 个空格。 需要超过 10 个时，"Jev 就没有正确选项了"——作者在 README 里就写的这句话，我觉得他写得很享受。

第二，它可能数错。 每次调用都可能选错选项。

第三，它比 native 的 padStart() 慢、贵、不可靠。 作者自己在文档里写："请别用在生产环境，或者任何重要场合。"

这个包在 Hacker News 上拿到 108 分、44 条评论。

评论区的焦点很有意思，大家讨论的不是这个包，是三件事：它复活了 left-pad 这个梗；它讽刺了当下"万物皆可 AI"的风气；以及一个严肃的技术问题——Jev 大约 90% 的准确率，让它当不了神谕（oracle），但如果放进一个能自纠错的大系统里，也许能当个不错的迭代器。

我把它排第一，是因为它和最尖锐的那条技术批评形成了闭环。

Jev 官方宣传"不会幻觉"（Cannot Hallucinate）。Hacker News 上评论者 jacobgold 拆穿了这个说法：

"它不会输出一个非法类型，但它完全可以输出一个错误的合法值。"

jev-leftpad 就是这句话的实体化。当 Jev 数错空格时，它返回的依然是一个完全合法、带着置信度的 space_4——它没在撒谎，它只是错了。 而一个连补几个空格都要联网问 AI 的包，把这层风险用最滑稽的方式摊在了所有人面前。

还有个细节我很喜欢：这个包的测试用 mock 模拟 Jev，不需要 API key，也不会烧掉任何额度。连讽刺都是认真做的。

---

07 提名但未入选

信息密度补几个，同样有趣但排不进前五：

• 
  
• jev-2048
  （Andy Gayton）——用 Jev 玩 2048 滑块游戏
• 
  
• AI Slop Detector
  ——Made with Jev 目录站自带的展示项目，把网页截图和视觉描述交给 Jev，对照 35 条"AI 味"特征判断这个页面是不是 AI 生成的。作者称 Jev 这一步耗时约 243 毫秒、成本 0.00015 美元。用 AI 检测 AI 生成的垃圾，这个自反性我很喜欢
• 
  
• fast-jev-compaction
  （约 2.8k 星）——给 Claude Code 的会话历史做剪枝，丢掉无用的工具调用和结果，保留的对话文本逐字不动
• 
  
• Kev
  （Jared Palmer）——95 美元 H100 租金微调 Qwen 3.5，训出 0.8B/4B/9B 三个决策模型，9B 版准确率 0.837 对 Jev 的 0.857
• 
  
• 以及目录站里那几个令人过目难忘的数字：40 秒拆解 724 条竞品广告，0.09 美元；1 秒内回答 61 个问题，0.0004 美元
• 
  

---

08 这五个作品拼出来的东西

一个只会输出数字的模型交到人类手里，第一反应不是拿它去做正经事，是先把它玩坏。

有人逼它聊天，有人让它补空格，有人让它打游戏，有人让它玩 2048。这些项目没有一个是有用的。

但恰恰是这些无用的东西，比任何官方 benchmark 都更清楚地说明了 Jev 是什么。

jevchat 说清了它的原理——说话拆到底就是一连串选择。

jev-leftpad 说清了它的风险——它不会输出非法类型，但会输出错误的合法值，而那个错误值带着同样真诚的置信度。

Doom 说清了它的位置——不是坐在旁边给建议，是坐进决策回路里。

jev-ultrafast 说清了它的工程价值——把网页变成一张编号表，把生成变成选择，1092 次协议调用压到 101 次。

pi-warden 说清了它最现实的用途——不是让 AI 更聪明，是给已经太聪明的 AI 装刹车。

最后回到那句使用心得：你必须把问题措辞写得非常明确，分层提问的效果远好于一个笼统的大问题。

这可能是关于 Jev 最实用的一句话。它把过去两年属于提示词工程的玄学，变成了一件更朴素的事——你得先想清楚自己到底要问什么，然后把它拆开。

一个不会说话的模型，最后逼着人把话说清楚。

---

本文所引性能数据除标注外均为项目作者自述，未经独立复现；Jev 官方"193.6 倍快、444.6 倍便宜"的说法来自其自建工作流评测，官方亦注明参考基准偏向 OpenAI 与 Anthropic 模型，实际增益"偏高端"。