先说清楚是哪个 Jev。2026 年 9 月刷屏的这个 Jev，不是游戏区那位做了很多年的 YouTuber，而是 TypeSafe AI 在 9 月 15 日发布的 System One 决策模型：不写字、不聊天，只做结构化判断。官方给的口径是比同类前沿模型快 20 到 200 倍、便宜 40 到 400 倍，输出 token 免费。
它的接口很短：你给它一段材料（TypeSafe 管它叫 state），再给它几个答案范围已经写好的问题，它返回每个选项的概率和一个置信度，整个过程不生成任何文字。
它要解决的问题很具体：大量 AI 调用其实只需要一个判断——这条工单归哪个部门、这封邮件是不是钓鱼、这句话里客户有多生气。用生成式模型做这类事，要等它把一段 JSON 写完，再写解析代码，还要处理它偶尔多写一个逗号、或者自信地编一个选项出来。
TypeSafe 把这类模型叫 System One 模型，名字借自卡尼曼《思考，快与慢》里的划分：推理模型像慢的 System 2，Jev 做的是快的 System 1。模型名取自杰文斯悖论——19 世纪经济学家威廉·斯坦利·杰文斯提出的观察：某种东西变便宜之后，用它的地方会变多，而不是变少。TypeSafe 的赌注是，推理变便宜之后，被塞进软件里的判断会变得更多，而不是更少。
创始人 Diogo Almeida 的发布帖写得很短：「在和别人共同发明 ChatGPT 之后，我一直在问自己：为什么超人水平的聊天模型没有通向 AGI？」他在 OpenAI 期间参与过 RLHF、InstructGPT、ChatGPT 和 GPT-4 的工作。公司 2024 年成立，2026 年 9 月 15 日带着 4,000 万美元种子轮走出隐身，DCVC 领投；联合创始人还有 COO Sasha Sheng（前 Meta／FAIR）和 CTO Erik Gafni。官网上的口号是「Build Prod, Not God」。
这篇讲五件事：Jev 输出什么、概率为什么值得信、怎么接进来用、发布后这一周发生了什么、以及哪些说法被夸大了。
图 1：上面是生成文本再解析，下面是在定义好的范围里选答案。自制示意图。
它输出的是答案，不是文字
先说输出。
普通语言模型一次只往前走一个 token，每个 token 都依赖前面生成的 token。所以它天生适合写东西，不适合做判断题。哪怕你用 JSON 模式约束它，本质仍是「先生成再解析」：它在写一个看起来像答案的字符串，格式对不对、选项是不是你给的，都要靠外部检查。
Jev 没有这一步。它同时看整段 state 和所有问题，直接吐出类型化的值：一个选项、一个分数，或者一个 0 到 1 的概率。TypeSafe 的说法是「不生成文本，不解析」。这个差别听起来小，落到工程上就是少了一层解析代码、少了一类格式失败、也少了「模型写了一个不存在的部门名」这种错误。
代价是答案空间必须提前写出来。你不能问它「这封邮件该怎么回」，只能问「这封邮件属于以下哪一类」。TypeSafe 自己的说明也很直接：Jev 不写回复、不写代码、不解释理由。
三种原语：choice、score、noul
模型支持三种问题类型，TypeSafe 叫它们原语（primitive）。每个问题都有一个你起的 ID、一个 type、一段 instructions；choice 和 score 还要给 criteria，把可能的答案写清楚。
图 2：三种原语。返回字段以官方文档为准。自制示意图。
choice 从一组命名选项里选一个，返回选中的选项、每个选项的概率，以及一个 confidence。适合部门路由、意图判断、主题分类。官方给的选项上限是 255 个。
score 在一组有序等级上打分，返回各等级的概率、用分布算出的期望等级（比如 0/1/2 上的概率是 0/0.96/0.04，期望分就是 1.04），以及 confidence。适合紧急程度、客户情绪、风险等级这类有大小关系的判断。
noul 回答一个命题是否成立，返回一个 0 到 1 的 P(true)。适合「是不是钓鱼邮件」「有没有要求退款」这种是非判断。它的返回值不带 confidence，因为那个数本身就是概率；0.5 附近意味着模型也拿不准。
下面是 Cloudflare Workers AI 文档里的一个完整返回，问题、选项和答案都是现成的：
{
"model": "jev-1.13.0",
"answers": {
"is_urgent": { "type": "noul", "noul": 0.95 },
"department": {
"type": "choice",
"choice": "billing",
"confidence": 0.8,
"probabilities": { "billing": 0.87, "sales": 0, "technical": 0.13 }
},
"frustration": {
"type": "score",
"score": 1.04,
"confidence": 0.94,
"legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
"probabilities": { "0": 0, "1": 0.96, "2": 0.04 }
}
}
}
值得留意的是这里没有自由文本。billing 是你给的选项之一，1.04 是你定义的等级上的位置，0.95 是一个概率。代码可以直接拿这些值做分支，不需要再判断格式。
一次请求可以问好几个问题
同一段材料上，你可以一次问多个互不依赖的问题。Jev 把它们放在同一次评估里并行算完，返回也按你给的 ID 组织。
官方的说法是：每个问题都看到同一份 state，独立评估，所以问题数量增加时响应时间几乎不变，也不会出现「前面问了后面就忘」的上下文退化。文档建议一个问题只问一件事——一个「有知识的人看一眼就能答上来」的判断。想评一篇创业计划书，不要问「给这篇项目打分」，而是分开问市场规模、技术可行性、差异化，再用代码按自己的权重合成。
有一个限制要注意：问题之间不能有依赖。如果第二个问题要用到第一个问题的答案，就得发两次请求，把第一个答案拼进 state 再问第二个。
图 3：三个独立问题共享同一份材料。数值为官方示例。自制示意图。
概率和置信度才是它和「让 LLM 输出 JSON」的分界
这是整套设计里最值得看的部分。
你可以让任何语言模型输出 {"confidence": 0.95}。但那个数字是它「预测出来的、听起来很有把握的文字」，不是从概率分布里算出来的量，也没有经过任何校准。它说 95%，在 95% 的情况下真的对吗？没有保证。
Jev 的返回里有两个东西：
probabilities：所有选项（或所有等级）上的完整概率分布；confidence：把分布形状压缩成 0 到 1 的一个数。分布集中在一个选项上就是高，摊平了就是低。
文档把话说明白了：这是给你用的默认度量，不是唯一正确的定义；不满意可以直接拿 probabilities 自己算。
拿到 confidence 之后，系统可以按它分档，而不是把所有模型的输出当成一样可信：
- 高：自动执行；
- 中：先让用户确认，或者补一次检查；
- 低：不动手，转人工或追问。
官方给的例子里，语音银行助手的阈值不是一个数，而是一组：低于 0.6 一律转人工；「查余额」这类低风险动作，0.6 就行；「确认转账」这种做错了要赔钱的，要 0.85 以上才自动执行。
图 4：三档置信度与两个不同风险的阈值。数值取自官方文档示例。自制示意图。
这里有一个容易混的地方，值得单独说：类型安全不等于决策正确。
「不会出现格式错误」和「不会答错」是两件事。第一个问题，Jev 用固定的输出空间解决了——它没法吐出一个你没定义的选项。第二个问题没有解决：模型仍然可能把该退款的判成不该退款，而这时候它给出的概率可能还挺高。
官方的说明是：校准是统计意义上的。模型说 90%，是指在大量同类问题上大约对 90%，不保证这一个是对的。要在自己的数据上验证置信度和真实准确率的对应关系，再定阈值。Earendil 的 CTO Armin Ronacher 把这件事说成「把幻觉的责任往用户这边挪了一点」：你得自己决定，50% 的概率可以忽略，95% 才敢用。
还有一层麻烦来自数值本身。品玩的实测里，有人工标注要求严重度下限是 2.00，模型给了 1.99；紧急度标注 0.75，模型在 0.71 到 0.72 之间。差距很小，但如果你的规则写的是「达到 2.00 才转人工」，1.99 和 2.00 在程序里就是两个不同的信号。他们重复跑 15 次，有 3 道题在通过和失分之间来回摆。数字很精确，不代表规则很稳。
训练方式：RLCD
TypeSafe 把它的训练方法叫 RLCD，Reinforcement Learning for Calibrated Decisions，用中文说大致是「面向校准决策的强化学习」。
文档把后训练路线分成三条：RLHF 用人类偏好当奖励，训练出会聊天的助手；RLVR 用可验证的奖励，训练出会推理的模型；RLCD 用评分规则当奖励，训练出会给概率的决策模型。第三条路是 TypeSafe 自己提出来的，也解释了他们为什么把产品放在「给软件用的模型」而不是「给人用的模型」这个位置上。
为什么不能直接拿分类任务常用的交叉熵去训？因为交叉熵的最优解是把正确选项的概率一路推向 1，模型会变得越来越过度自信；而「答对给 1 分、答错给 0 分」这种朴素强化学习更糟，最优策略同样是让概率非 0 即 1。结果是一个自信地答错的模型。
RLCD 的做法是用严格适当评分规则（strictly proper scoring rule）当奖励，再配合温度校准。这类评分规则的数学性质是：只有当模型报出的分布和真实分布一致时，期望奖励才最高。换句话说，诚实报概率是它的最优策略。这条思路和开源项目 Laya 用的是同一套工具，我在 Laya 那篇里展开过具体公式。
还有一点对使用者更实际：Jev 不针对单个客户做微调，所有人用的是同一份权重。想让它在你的业务里更准，靠的是三件事——把材料放进 state、把领域规则和边界情况写进 instructions、把判断拆细之后在代码里合成。
图 5：三条后训练路线的目标不同。自制示意图。
怎么接进来用
目前能调到 Jev 的入口有好几个。
Playground。 TypeSafe 控制台（console.typesafe.ai）里可以直接贴一段材料、加几个问题看结果，适合先感受输出形态。9 月 20 日之前要排队，现在已经全面开放，注册送 5 美元额度，按输入价折算大约是 1.2 亿 token。
TypeSafe API。 直接 POST https://api.typesafe.ai/v1/systemone，用 Bearer key 认证。官方提供 Python 和 JavaScript/TypeScript 两个客户端 SDK，会自带重试；Python 的包名是 typesafe-sdk。官方还提供了一个给编码智能体用的 skill，npx skills add typesafe-ai/skills --skill typesafe-ai，装上之后 Claude Code 这类工具会知道怎么写集成代码。model 字段可以写 jev-latest（当前指向 jev-1.13.0），也可以固定版本号。
Vercel AI Gateway。 Vercel 把它做成了 AI SDK 7 里的一个函数。这是 Vercel 官方文档里的最小例子：
import { experimental_evaluate as evaluate } from 'ai';
const { answers } = await evaluate({
model: 'typesafe-ai/jev',
state: 'Hello, world!',
questions: {
greeting: { type: 'boolean', instructions: 'Is this a greeting?' },
},
});
console.log(answers.greeting.probability);
注意这里写的是 boolean，TypeSafe 自己的叫法是 noul，指的是同一件事。返回值也只给概率，用不用、阈值定在哪，都是你自己代码的决定。
Cloudflare Workers AI。 模型 ID 是 typesafe/jev，用 env.AI.run() 调用，凭据由 Cloudflare 托管，不需要单独配 TypeSafe 的 key。OpenRouter 上也有同一个模型。
图 6：接入方式、价格和上下文。数字取自官方文档。自制示意图。
价格和额度按 官方文档：输入按 $42 / 十亿 token 计（即$0.042 / 百万 token），输出 token 免费。限速是每秒 25 万 token、每分钟 1200 个请求，文档明确说这个数会动态调整。上下文一次 64k token，其中 state 加最长的那一个问题不能超过 32k。输入只支持文本，图片、音频、视频要自己先转成文本或结构化字段。
如果只想知道要不要用，建议按下面这个顺序试：挑一个已经存在的分类或路由调用，把可能的答案提前写下来，然后拿同一批带标注的输入，把 Jev 和现在的做法放在一起比。比三件事——准确率（含模棱两可的样本）、端到端延迟、以及包含重试和降级的完整成本。
发布后一周：从刷屏到接入
这一周里发生的两件事，比模型本身更值得记录。
第一件是采用速度。9 月 17 日 Jev 上了 Vercel AI Gateway，Vercel 官方博客的标题直接写「这是 AI Gateway 历史上采用最快的模型」。他们给出的数据是：上线 24 小时内，近 13% 的付费团队已经用过它。9 月 20 日，TypeSafe 取消等待列表，全面开放。也就是说，从发布到不需要排队，只用了五天。
第二件是社区自己长出了一套用法。发布帖在 X 上有约 3,800 万次浏览，之后两三天里出现的项目几乎都围着同一件事转：把原本交给大模型的那些小判断挪出来。社区里能列出来的项目已经上百个（我看到的一份汇编说约 295 个，没有逐个核实）。
图 7：发布、接入平台、社区爆发、全面开放的时间线。自制示意图。
别人拿它做了什么
发布后一周出现的项目挺集中，基本都是「原本要靠 LLM 做的小判断」：
- Jev Ultrafast（Browser Use）：浏览器智能体把页面上可用的操作整理成带编号的列表，交给 Jev 选动作和落点；需要输入文字时再让一个小模型生成。公开演示里订机票的任务大约 7 秒完成，成本约 0.0039 美元。
- Fast Jev Compaction：一个 Claude Code 插件，给工具调用和结果打分，决定哪些原样保留、哪些丢弃、哪些截断，用选择代替摘要。
- pg-jev：PostgreSQL 扩展，用自然语言描述来过滤行、给相关性打分，Jev 判断内容，SQL 负责其余部分。
- Sponsor Skip：解析 YouTube 字幕，找出赞助片段对应的位置并在播放时跳过。
- 游戏和机器人：Ably Pong 的公开演示里，Jev 在 12 秒内做了 47 次操作决策，同期对比的几个前沿模型只做了两三次——它们大多数时候判得对，但来不及。还有人在 MuJoCo 里用 Jev 选方向和夹爪。
- 顺手做的小工具：给 X 时间线降噪的浏览器插件、给广告线索批量打分、给 Codex / Claude Code 做路由和审批、给内容做审核分流。
这些项目里能看到一个共同的分工：Jev 只负责从状态到标签的那一步，快的控制和文字生成都留在外面。更多项目汇总在 madewithjev.com；中文社区还做了一个聚合站 JEV HUB，按时间、语言和主题收集 X 上的长文与演示视频。
Jev Engineering：只在分叉处放一个模型
到发布后第三四天，X 上出现了「Jev Engineering」这个词，指的是一套改 Agent 结构的做法：把一件事拆成「LLM 写、Jev 判、代码做」三段。
道理不复杂。一个智能体干活时，真正消耗时间和钱的地方往往不是写内容，而是那些岔路口：下一步该谁做、这份结果够不够用、要不要继续。这些判断用大模型做，等于每次都等一段文字生成完，再读它说了什么。
按这套做法，一个最小的循环长这样：state 里放目标、已经完成的工作和可选的工具列表；Jev 回答「下一个该谁做」「这份材料相关吗」；代码拿到答案后按置信度决定放行还是拦下；高置信度交给工具或便宜的小模型执行，低置信度转人工或者交给更强的模型。
图 8：判断放在分叉处，执行和写作留在外面。自制示意图。
这套写法里有几个反直觉的细节，值得单独记：
- Jev 看不到你的问题 ID。 字段叫
safe_to_publish 不会给它任何提示，真正的规则必须写在 instructions 和每个选项的描述里。
- state 里要放证据，不要放结论。 「研究员已经做完了」提供的信息远少于实际的来源、发现和还没补上的缺口。
- 选项要跟着状态刷新。 浏览器里的可点元素每次点击后都变，所以 Browser Use 每次重新生成候选列表。如果你的选项是固定的，模型就是在从昨天的菜单里挑。
- 批量问比串行问划算。 同一份 state 上一次问五个问题，和分五次请求相比，响应时间差距不大，成本差距明显。
Jev、生成式 LLM 和 Laya，各自负责哪一段
一套完整的自动化流程通常分成三段。Jev 做判断，应用代码做把关，LLM 做表达。
以退款为例：Jev 回答「客户是否要求退款」「证据是否指向重复扣款」「政策是否支持退款」；代码检查金额、权限和置信度阈值，决定自动执行还是转人工；需要给客户写一段解释时，再交给语言模型去写。三段各自可以单独测试，也各自可以单独换掉。
这也是 TypeSafe 反复强调的一点：他们预期未来绝大多数 AI 调用是机器对机器的，所以接口要像软件，而不是像给人看的文字。这是一个立场，不是已经验证的事实，但它解释了这个模型为什么长成这样。
和同类的对比也值得说一句。开源项目 开源项目 Laya（作者 Nandakishor M）用的是同一类思路：双向编码器、对选项打分、RLCD 训练、温度校准，同样有 choice / score / noul 三种原语，只是权重开放、可以在自己机器上跑、也允许在自己的数据上继续微调。它的作者在 2026 年 9 月 18 日写过一篇文章，说他 2025 年 3 月和 9 月的两篇论文已经提出同类做法，并指出 Jev 发布时没有配套论文、权重和训练数据集；他也声称自己的模型在 GPU 上只要 33 到 38 毫秒。这是作者本人的说法，我没有独立核实这条时间线，这里只做转述。
还有一点：Jev 的具体架构没有公开。官方在发布材料里的说法是「新的模型架构 + 并行采样器」，但没有给细节；外界普遍猜测它是在某个开源大模型的基础上改的，TypeSafe 只说它是基于 Transformer 的模型，用 RLCD 训练。在此之前，已经有开发者用现成的 Qwen3-8B 加单 token 选择做出过类似的接口，这说明「不生成、只判断」本身不难，难的是把它做准、做便宜、做成能依赖的服务。
对使用者来说，实际差别就三点：Jev 是托管服务，省掉了部署和运维，代价是数据要出网、价格按 token 计；Laya 是本地权重，数据不出网，但需要自己有 GPU、有能力校准和微调；两者的定位都是「被特化的快速判断层」，都不是通用助手。
图 9：三段分工，每一段都可以单独测、单独换。自制示意图。
热度与质疑：那些倍数该怎么读
Jev 发布时最有传播力的数字是速度。官方对外给的是一个区间：快 20 到 200 倍、便宜 40 到 400 倍。TypeSafe 在峰值测试里报出的具体数字是快 193.6 倍、便宜 444.6 倍，单次决策成本约 0.0004 美元；端到端延迟 70 到 500 毫秒，对比对象是 3 到 329 秒。公司同时说明，这是它预期在真实负载里的高端值。
这些数字有几个已知的折扣：
第一，准确率基准是 67.8%，测的是和另外两个前沿模型（GPT-6 Astra 和 Claude Fable 5.1）的一致程度，不是独立的人工标注真值。跟别的模型一致不等于答对。网上有一篇专门拆解这个 193 倍的文章，英文标题是《Jev's 193x Number Went Viral. The Caveats Didn't.》，大意是「193 倍火了，前提条件没火」。
第二，第三方复测的范围窄，结论也不一致。Every 用同一个提取任务测出 Jev 比 Claude Fable 5.1 快约 25 倍、便宜约 580 倍，单段耗时 0.35 秒对 8.83 秒。Vercel 的一位工程师把命令安全分类器从另一个模型换成 Jev，速度提升 5 到 18 倍，准确率也更好；另一家公司的 CTO 用业务邮件分类做对比，结论是 Gemini 准确率略高，但成本贵 10 到 20 倍。方向一致，倍数和厂商口径差一个数量级。
第三，发布时公司还没有公布付费客户和收入。
中文媒体里最有参考价值的一组实测来自品玩：50 条中文客服消息，每条要做紧急度、售前概率、处理类别、严重度四项判断，四项全对才算这一题正确。结果是 Jev 的完整准确率约 64% 到 65%，在便宜小模型那组排第二，略低于 DeepSeek V4 Flash；放到更强的模型组里则排在最后，比 MiniMax M3 低约 11 个百分点。但延迟和成本它是最低的：平均每题 0.73 到 0.75 秒，50 题总成本约 0.002 美元，而 DeepSeek V4 Flash 每题要 5.58 秒、成本约为它的 2.5 倍。换句话说，它换来的不是更准，而是「同样的判断便宜得多、快得多」。这 50 条样本也只能说明这一组任务。
社区里最常见的批评是：这本质上是「2026 年智商的分类器」，一个聪明的 switch，不是架构上的新东西——同样的思路，开源项目 Laya 更早就做过，也有开发者用 Qwen3-8B 自己实现了类似的接口，差别在产品包装、速度和 API 设计。这个说法有道理的一部分是，它确实不新；不合理的一部分是，把它做得足够快、足够便宜、足够稳，本身就是难点。
还有一类提醒是关于姿势的：它不是万能模型，不适合数学、长文写作、需要多步推理或者不可逆的执行；问题写得太宽会明显变差。官方的做法是建议你把大问题拆成小问题，这既是用法，也是它的边界。
另外，社区汇编里提到团队自己承认现在的模型「还太慢、还太贵、还太笨」，并公开征集模型表现不稳的案例。这一条我没有找到原帖，只当参考。
中文圈的节奏基本同步：先问「Jev 是什么」，再转发几十秒的讲解视频和成本对比，然后把它接到 Codex / Claude Code 上做路由、压缩和审批。也很快出现了代注册、卖教程这类二次生意。
图 10：不同口径的数字不能混着用。数据来源见文末。自制示意图。
结论不是「这些数字是假的」，而是：这是一类便宜且快的模型，值不值得用，只能在自己的数据上量。厂商的倍数可以当上限看。
边界与局限
把话说清楚，下面这些是选型前要知道的。
只能文本输入。 图片、音频、视频都要先转成文本或结构化字段，转换质量直接决定它的判断质量。
不能生成。 不写回复、不写代码、不解释理由、不对话。它只回答你提前写下来的问题，答案空间也由你定。
问题之间有依赖就要多发一次请求。 一次请求里的问题必须互相独立。
英文最准。 官方文档说英文是主要训练语言，其他语言（包括中文）能处理但质量不等，用之前要在自己的内容上测，并且特别留意 confidence。
置信度要自己验证。 出厂的概率是校准过的，但校准是在它的训练分布和评测口径上成立的。在你自己的业务里，置信度和准确率的对应关系可能不一样。
别名会漂移。 jev-latest 会随新版本移动，答案也可能变。如果你把阈值调好了，要固定版本 ID（比如 jev-1.13.0）并记录每次返回里的 model 字段。
材料越长表现越不稳。 官方单独有一页讨论「模型锯齿」（model jaggedness），讲 state 变长之后准确率怎么变。别假设把整份文档塞进去效果最好，长材料要单独测。
官方文档和第三方页面的参数不完全一致。 例如 Cloudflare 的模型页面写上下文窗口 32k token，TypeSafe 文档写一次请求 64k（state 加最长问题 32k）。以官方文档为准，接入前自己确认一遍。
小结
Jev 做的事可以概括成一句：把「做一个判断」从「生成一段文字」里拆出来，变成软件可以直接消费的类型化输出。
具体来说，它用 choice / score / noul 三种原语把答案空间固定下来，一次并行评估多个独立问题，输出概率分布和一个置信度，让代码能按确定性阈值决定自动执行还是转人工。训练上用 RLCD，把「诚实报概率」写进奖励函数，而不是让它学会用听起来确定的语气说话。
它换来的代价也很明确：不能写任何东西，只能在提前写好的答案范围里选，还有个容易被忽略的前提——类型安全保证的是格式，不是正确。
这一周里社区做的事，某种意义上比模型本身更重要：他们把它放到 Agent 的每个岔路口，让判断、写作和执行各归各位。如果你的系统里也有一批高并发、答案有限的分类或路由调用，正在为延迟、成本和解析失败率付账，那它值得花半天做一次对比测试。如果要做的是写文案、写代码、回答问题，它帮不上忙，那是另一类模型的活。这类判断层与生成层分离的思路，在云栈社区里也有不少讨论。
参考来源
以下链接均于 2026-09-21 访问。
发表于 前天 02:19
|
查看: 6|
回复: 0
