不写一个字的模型:Jev 把「判断」做成了一次函数调用
9 月 15 日发布,10 天刷屏。它不聊天不写代码,只回「哪一个」「多少分」「是不是」——并且每个答案都带一个可以拿来当闸门用的概率

文章目录
共 7 节先说清楚一件事:如果你打算把 Jev 换到 Claude Code 或者 Cursor 底下去写代码,那是白折腾。TypeSafe 自己的文档专门开了一页讲这个,标题就叫「Jev with coding agents」,第一句话是「Jev 不是那些工具背后 LLM 的替代品」。
它连一个字都不生成。
那为什么 9 月中旬发布之后,这东西在十天里被 Forbes、The Register、InfoWorld、TechCrunch 轮番写了一遍,Vercel 的 CEO 亲自发帖跑分,一堆人用它去玩 Doom、搜机票、给辩论逐句打分?
因为它解决的是另一个问题。
一、它只回三种答案
Jev 的接口简单到有点反常:一个 HTTP 端点,POST https://api.typesafe.ai/v1/systemone,请求体里三样东西——state(要判断的那堆材料)、model(模型名)、questions(一组你自己命名的问题)。
问题只有三种类型,官方叫「原语」(primitives):
- →Choice:从你给的选项里挑一个。返回选中的那个、每个选项的概率、以及一个 confidence。一个 Choice 最多 255 个选项。
- →Score:按你写的分级量表打分。返回一个概率加权的分值(可以落在两级之间)、每一级的概率、confidence。最多 10 级。
- →Noul:一句陈述是不是成立。返回一个 0 到 1 的数,就是「是」的概率。没有 confidence——这是故意的,后面会讲为什么。
没有第四种。你不能让它写摘要,不能让它返回一段 JSON 里嵌一段自由文本,不能让它解释理由。文档里那句话很直接:「如果你真的需要生成文本……有别的模型干这个。」
代价换来的是一条硬保证:它不会出类型错误。因为可能的输出在请求发出去的那一刻就已经被你枚举完了,模型做的是在这个封闭集合上分配概率,不是在一个几万词的词表上自回归采样。
二、和 LLM 到底差在哪
TypeSafe 在发布博客里列了一张对照表,我把里面能核对的部分摘出来。
训练目标不同。现在的 LLM 走 RLHF(对齐人类偏好)或者 RLVR(对齐可程序化验证的奖励)。Jev 走的是他们自己造的一套,叫 RLCD——Reinforcement Learning for Calibrated Decisions,对齐的是「概率要诚实」。这个词组的重点在 calibrated:说 80% 的那一批里,最后大约有 80% 是对的。
采样方式不同。LLM 是顺序的,一个 token 接一个 token,每个都以前面的为条件。Jev 是并行的,一次请求里所有问题同时出答案。所以官方说「多问几个问题几乎不影响响应时间」——这不是营销,这是架构决定的。
计价方式不同。Jev 只按输入 token 收钱,输出 token 免费。文档原话是「too cheap to meter」。
不确定性的处理方式不同。你让 GPT 自己报一个置信度,它会给你一个数,但那个数跟实际准确率的关系很松。Jev 的 Choice 和 Score 每次都带一个 0 到 1 的 confidence,而且它是从概率分布的形状算出来的——分布越集中越高,越平越低。
一个能做对 95% 的模型,如果它不肯说清楚自己什么时候在那 5% 里,那它就没法自动化这件事。
这句话是 TypeSafe 发布博客里的原话(我译得直白了些)。它其实是整个产品的立论。
三、「把智能当编程原语」是什么意思
这是官方文档反复在讲、但很容易被读成口号的一句话。落到代码上,它的意思是这样的。
你原来会这么干:把一堆上下文塞进 prompt,让 LLM「返回一个 JSON,字段是 category、severity、需要人工吗」,然后写一段解析 + 校验 + 重试的代码去接。这段代码你写过,你知道它有多脏。
Jev 的写法是把这一件事拆成三个独立的问题,一次发过去:
"state": "单号 98423,上周四下单,被扣了两次款。
站点更新之后还登不上。",
"model": "jev-latest",
"questions": {
"category": {
"type": "choice",
"instructions": "这条工单属于哪一类",
"criteria": {
"bug_report": "用户在报告坏掉或报错的东西",
"billing": "扣费、发票、退款、订阅",
"feature_request": "用户在要新功能",
"account": "登录、权限、资料、安全"
}
},
"refund_requested": {
"type": "noul",
"instructions": "用户在明确要求退款或补偿"
},
"frustration": {
"type": "score",
"instructions": "用户表现出的不满程度",
"criteria": ["平静陈述事实", "不满但克制", "非常愤怒"]
}
}
}
回来的东西长这样(这是官方文档里的响应形状):
"model": "jev-1.13.0",
"answers": {
"category": {
"type": "choice",
"choice": "billing",
"probabilities": {
"billing": 0.88, "technical": 0.12, "sales": 0.0
},
"confidence": 0.81
}
},
"usage": { "input_tokens": 318, "output_tokens": 34 }
}
关键差别在最后那一段代码上。决策权没有交给模型,还在你手里。路由用哪条分支、阈值定在多少、三个维度怎么加权——全是你 if-else 里的常数。哪天业务变了,你改的是一个系数,不是重写一段 prompt 再祈祷它别退化。
文档里有个例子我觉得特别说明问题:与其问「给这份创业 BP 打个分」,不如分开问市场规模、技术可行性、差异化三件事,再用你自己的公式合成。优先级一变,改的是系数。
四、为什么是 9 月火的
时间线摆一下。
- →2026-09-15:TypeSafe 发布博客《Introducing System One Models & Jev》上线,作者 Diogo Almeida,公司创始人。他在 OpenAI 期间参与过让语言模型学会跟随指令的那套方法——也就是 ChatGPT 背后的研究。公司隐身了两年。
- →2026-09-16 起:The Register 写了「给机器造的模型,顺便会玩 Doom」;InfoWorld、Forbes、TechCrunch、The Economic Times 陆续跟进。
- →发布后数天内:Vercel、Cloudflare 被报道快速接入;ZenMux 9 月 23 日宣布上架 jev-1.13。
开发者侧的动静比媒体更实在。Vercel CEO Guillermo Rauch 发帖说在他们的命令安全审查场景里,Jev 的 p95 延迟最高比 GPT Luna 快 18 倍,而且更准;但他同一条帖子里说,fx reviewer 那条链路仍然跑在 Luna 上——这个细节比跑分重要。Bryo AI 的 CTO 试了邮件分流,结论是 Gemini 略准一点,但贵 10 到 20 倍。
还有一批纯粹是「原来还能这么用」的:Browser Use 拿 jev-ultrafast 跑了一次苏黎世到伦敦的 Google Flights 搜索,7.1 秒;jevmeter 给一场辩论逐句打分,一场约 0.05 美元;jev-guard 把 Agent 的每一次工具调用判成 deny / ask / allow。
把这些串起来看,火的原因其实很朴素:有一大类活儿,以前必须请一个会写作文的模型来干,现在有了一个专门干这个的,快两个数量级,便宜两个数量级。
五、官方自己承认的那些数字水分
这一节是我写这篇的主要理由。TypeSafe 首页挂着「193.6 倍快、444.6 倍便宜」,很多中文转述会把这两个数直接抄走。原文在「Nuance」小节里自己写了四条限定:
- →这两个数来自他们自己设计的 workflow evals,工作流是他们模型能力团队自己写的,可能有偏向。
- →参考答案取的是 GPT-6 Astra 与 Fable 5.1 的平均值——也就是说基准锚在 OpenAI 和 Anthropic 的模型上。
- →他们明说「我们预期这些数字处在真实收益的高端」。
- →关于价格:「我们无法证明它没有被补贴」。
还有一条更该被转述的:「零幻觉」指的是 schema 一定匹配,不是答案一定对。那个 0% 不是实测出来的,是数学上不可能违反的结构保证。答案照样可能是错的。
录制 demo 里的具体数字是:Jev 0.114 秒、0.000081 美元;GPT-5.6 Terra 8.566 秒、0.013880 美元。
六、它做不好的九件事
官方有一页叫《Jev 1.13 jaggedness》(最后复核日期 2026-09-17),列了九个已知的毛病。这一页比首页的跑分有价值得多,挑五条最容易踩的:
- →字面理解。它回答你写的那个问题,不是你想问的那个。限定词、否定、隐含条件都按字面吃。官方给的判断方法很妙:当你看着一个错答案、开始在心里解释「我其实是想问……」的时候,那段解释就是你漏掉的那半条指令。
- →数数和算术不行。字符数、出现次数、列表长度都不可靠,而且错误随规模变大。要计数就在代码里循环,每项问一个 Noul,自己加。
- →日期比较不行。它把日期当文本读,不当有序量。「哪个更早」「差几天」「在不在窗口内」都不靠谱。正确姿势是让它用 Choice 把年月日各挑出来(每一项都是封闭集合,还能留一个「未提及」),比较交给代码。
- →state 越大越差。塞了跟问题无关的内容会掉准确率。先在代码里检索过滤,只发这个问题要用的字段。
- →对抗内容会被带跑。state 被当数据处理,但它默认不把 state 当敌意输入。注入的指令、刻意误导的措辞、为自己分类辩护的文本,都可能挪动答案。官方说「我们预期未来会改善」——这句话的意思是现在没改善。
另外有一条很容易在生产里翻车:结构不变式不成立。同一个问题写成 Noul 和写成二选一的 Choice,数字可能对不上;一个问题和它的否命题,两个 Noul 加起来不等于 1。官方给的例子里,一个工单上 refund=0.72、not_refund=0.47,加起来 1.19。所以在 Noul 上调好的阈值,不要搬到 Choice 上去用。
七、什么时候用它,什么时候别用
该用的信号很明确:你的代码里有一个 if 判断不出来的分支,而这个分支需要的是常识而不是规则;或者你现在有一段「让 LLM 返回 JSON」的 prompt,正在被解析失败和格式漂移折磨。
别用的信号也明确:
- →需要生成任何文本——摘要、回复、代码、文案。换模型。
- →代码能精确算出来的——金额、天数、计数、去重。别问模型。
- →要做多跳推理、要它权衡好几个独立因素还给你一个综合结论。拆开问,或者换推理模型。
- →你的输入主要是中文,而且没条件先测一轮。官方 Models 页写得很直白:英文是主训练语言,准确率目前最好;包括 CJK 在内的其它语言「能处理,但没有同等水平」,用于非英文任务前请在自己的数据上先测。
最后一条对国内团队尤其要紧。它不是「不能用中文」,是「你得自己验一遍,而且要盯着 confidence 路由」。这件事和成本、和怎么绕开付款与网络,下一篇和第三篇会分别讲。
