Diogo Almeida 在发布博客的第一句话里问：模型在聊天上超越人类已经好几年了，那自动化在哪里？他说这是自己过去四年反复在想的问题。
问这句话的人有资格问。他在 OpenAI 参与了 InstructGPT 与人类反馈强化学习（RLHF）的核心研发，是 ChatGPT 与 GPT-4 论文的共同作者之一。按他自己的说法，他当时以为聊天模型会通向 AGI，但热闹归热闹，他越来越确定这条路上缺了很大一块。两年前他离开 OpenAI，在旧金山和 Erik Gafni、Sasha Sheng 一起创办了 TypeSafe AI。2026 年 9 月 15 日，公司结束隐身，带着 4000 万美元种子轮融资发布第一个公开模型 Jev，目前只开放早期访问。
Jev 反直觉的地方在于，它是一个刻意不会生成文字的 AI。它不写回复、不写代码、不解释自己。你给它一段内容和几个问题，每个问题的答案范围由你事先定死，它返回的是带概率的结构化判断。TypeSafe 说这是一个新的模型类别，叫 System One 模型。
两个名字都有来头。System One 出自丹尼尔·卡尼曼的《思考，快与慢》：系统一是那种快速、直觉、不费力的判断，系统二则是缓慢、刻意的推演。在 TypeSafe 的框架里，Jev 负责前一类，推理模型负责后一类。这里他们自己留了个没填的坑——官方承认在认知科学的语境里，「系统一思维」恰恰意味着容易出错，并说日后再解释为什么他们认为这类模型可以做得比替代方案更可靠。到目前为止，这个解释还没有出现。
Jev 取自 19 世纪经济学家威廉·斯坦利·杰文斯。杰文斯悖论说的是，蒸汽机效率提高之后，煤炭的总消耗量不降反增，因为便宜的动力创造出了原本不存在的用途。TypeSafe 的赌注是智能也走这条曲线：一次决策的成本每掉一个数量级，就会有高一个数量级的场景值得动用它。这不只是个典故，它就是这家公司的商业模型。
一个会判断但不会说话的函数
官方给 Jev 的定义是一句话：非结构化的状态进去，类型安全的概率决策出来。可以把它想成一次前沿智能的函数调用。
你要给它两样东西。一样是 state，也就是要判断的内容，可以是一段文本，也可以是一个带字段的对象或者一个数组。另一样是 questions，也就是你要问的问题——而每个问题的答案形状，必须事先声明。
问题只有三种类型。Noul 是是非题，返回一个 0 到 1 的概率，表示「是」的可能性有多大；它没有单独的置信度字段，那个概率本身就是唯一的不确定性信号。Choice 是在你给的一组选项里挑一个，返回选中的那项、所有选项上的完整概率分布，外加一个置信度；置信度由分布的形状算出来，概率集中在一项上就高，摊得很开就低。Score 是在你描述的档位上打分，分数是各档位序号按概率加权的均值——比如 0 档 0.0、1 档 0.7、2 档 0.3，分数就是 1.3——同时返回档位说明、完整分布和置信度。
关键在于，它选不出你没给它的东西。如果产品类别这个问题只有三个候选值，它造不出第四个。这是架构层面决定的，不是靠提示词约束出来的。
速度的来源是采样方式。大语言模型要吐出 `{“category”: “billing”}` 这样一个对象，得一个 token 一个 token 地生成，每一个都以前一个为条件，计算在时间上高度串行。Jev 的输出空间在推理之前就由预定义的模式完全限定，模型在一次前向传播里并行算出全部数值输出。Almeida 自己给了个类比：用并行取代串行，和当年 Transformer 取代 RNN 是同一个思路。
TypeSafe 给这个定位起了个通俗名字，叫「聪明的 if 语句」。普通的 if 只能对算得出来的条件分支，比如订单金额大于一百。它对付不了需要判断的条件：这条投诉是不是在生气？这封邮件是不是在问账单？结账流程里这十二个按钮该点哪一个？传统分类器能处理这类窄判断，但你得先有标注数据、走一遍训练，而且一个任务一个模型。通用大模型不需要这些，代价是它本质上仍然是生成模型，哪怕你把输出约束成 JSON 也一样。Jev 的位置在中间：像大模型一样吃自由文本、问题在运行时定义，像分类器一样返回受约束的概率分布。
训练方式也是重造的。眼下业界主要有两条路线。一条是 RLHF，优化的是人类评审员偏好的自然语言输出，好处是模型学会了取悦人，副作用是它在自动化场景里倾向于表现得过度自信。另一条是面向可验证奖励的 RLVR，依赖能被代码低成本验证的目标，比如数学证明或者代码能不能编译，但真实业务里很少有这种现成的判定。TypeSafe 走的是第三条，他们管它叫 RLCD，面向校准决策的强化学习。它不考察文字表达，优化目标是「校准的决策」：输出的概率要诚实地反映把握程度，用官方的说法，更高的置信度应该对应更高的准确率。这个目标是理解后面所有争议的前提。
代码管流程，模型管语义
把这套东西放进真实系统，方式和用大模型很不一样。
拿员工报销审核举例。大模型的常规做法是把全部业务规范塞进一段长提示词：每笔报销需附发票凭证，凭证无法辨认则打回，判断属于餐饮、差旅还是设备采购，餐饮超过 75 美元且明细与说明不符时需经理审批，其余直接通过。这段提示词要求模型在一条思维链里从头推到最终动作，多步逻辑混在一起，很容易在中途漂掉。
System One 的做法是把它拆成一张计算图，由确定性代码和语义原语共同构成。先用一个 Noul 问票据图像或文字是否清晰可读，不清晰就打回重传。清晰的用一个 Choice 判断支出类型。落到餐饮这一支时，金额是否超过 75 美元交还给 Python 原生代码去算——这一步绝不交给模型，因为它根本不该有看错数字的机会。超过的再用一个 Noul 问发票明细与申报描述是否吻合，吻合就自动核准，不符就触发经理二审。
这就是核心理念：确定性逻辑交给代码，语义理解交给模型。
置信度在这套结构里变成了代码里的阈值。有个例子很说明问题：给编码 agent 做安全闸，在它执行 shell 命令之前先问 Jev 这条命令是只读、可逆还是不可逆。一条有歧义的 `rm -rf` 回来的结果是「不可逆」概率 0.56、置信度 0.33。真正起作用的是那个 0.33——它告诉外层代码「我拿不准」，于是命令转给人确认，而不是按 0.56 这个勉强过半的判断放行。这是大模型给不了的东西：就算你明确要求它给出把握程度，那个数字也不保证可靠。
官方文档建议把置信度切成三段：高就自动执行；中等先确认、先复核，或者再取些数据；低就别动，转人工或者转给更慢的系统。分界线放在哪，取决于一次错判的代价。文档拿 0.5 当复核下限、0.9 当破坏性操作的门槛，但明说这是举例，不是默认值。要紧的是这些阈值躺在你自己的代码里，是能读、能改、能在代码评审里被人看见的数字。
还有一个习惯值得单说，因为它和用大模型的直觉正好相反。用大模型时一次调用又慢又贵，所以流程通常是先问一个问题，拿到答案再决定下一个问什么。Jev 不是这样。每个问题都独立针对同一份 state 求值，互相之间不作为对方的上下文，所以多问一个问题几乎不增加响应时间，只多花它自己那点 token。官方把这叫 speculative fan-out：把你可能用得上的独立问题一次全问了，包括那些只在某些分支才有意义的，然后让代码去挑该用哪些答案。官方 cookbook 里量过一次，13 个问题合并成一次调用，比拆成 13 次串行便宜 12.2 倍、快 10 倍。测试用的是 jev-1.12 和一份 53,777 字符的文档，官方也说明了，大部分节省来自那份长 state 只发送了一次。
数字：官方口径与可复算的口径
先说能直接对照的。官方公布的端到端延迟是 70 到 500 毫秒，称多数查询落在 100 毫秒上下，对照的是前沿大模型的 3 到 329 秒。价格是每百万输入 token 0.042 美元，也就是每十亿 token 42 美元，输出免费，官方的措辞是「便宜到不值得计量」。作为对比，大模型的输入价在每百万 0.20 到 10 美元之间，输出大约是输入的五倍。
倍数就比较复杂了，因为同一家公司给了四个口径。发布推文说快 20 到 200 倍、便宜 40 到 400 倍；博客正文写的是快 40 到 200 倍；官网首页挂的是 193.6 倍更快、444.6 倍更便宜。官方自己在博客里注明，首页那组数字处在现实收益的高端。
真正能自己复算的，是官方公布的四工作流等权平均表：
| 模型 | 平均准确率 | 每次成本 | 每次耗时 |
|—|—|—|—|
| Jev | 67.8% | $0.0004 | 0.4 秒 |
| Terra | 67.9% | $0.0304 | 10.1 秒 |
| Sol | 74.1% | $0.0836 | 23.3 秒 |
| Opus 5 | 73.1% | $0.1761 | 37.8 秒 |
表里准确率和 Jev 最接近的是 Terra，67.9% 对 67.8%。在这一对比较上，Terra 慢约 25 倍、贵约 76 倍——两个可以用表中数字直接除出来的倍数，比首页那组大得多的数字扎实。但同一张表也说明，Jev 明显低于 Sol 的 74.1% 和 Opus 5 的 73.1%。
更值得看的是等权平均掩盖掉的东西。官方评测页面按四个工作流分列了全部数据，把它们摊开来，「与前沿模型相当」这句话在四个任务上的含义完全不同。
在客户服务动态路由上，Jev 拿到 76.0%，高于 Terra 的 72.7%、Opus 5 的 72.4% 和 Sonnet 5 的 69.3%，只低于 Sol 的 78.3%、DeepSeek v4 Flash 的 76.8% 和 DeepSeek v4 Pro 的 76.1%，而成本是 0.0001 美元、耗时 0.4 秒。这一项上它确实站得住。
供应商发票核验上，情况反过来。Jev 是 61.8%，而 Sol 79.1%、Opus 5 78.4%、Terra 74.7%、DeepSeek v4 Pro 72.7%——除了 42.9% 的 Haiku 4.5，参测模型里没有一个比它差。与此同时，它的成本是 0.0011 美元对 Sol 的 0.2152 美元，耗时 0.5 秒对 34.3 秒。便宜和快是真的，准确率的差距也是真的。
另外两项落在中间。安全事件告警分流上 Jev 是 61.7%，低于 Opus 5 的 66.2% 和 Sol 的 62.5%，但高于 Terra 的 51.2%。Agent 轨迹可观测性上 Jev 是 71.6%，低于 Sol 的 76.6%、Luna 的 76.1%、Opus 5 的 75.2%，以及同为 73.0% 的 Terra 和 DeepSeek v4 Flash。
这些数字怎么来的，必须交代清楚，因为它决定了它们能支撑多少结论。评测的参照标签不是人工标注的真值，而是 GPT-6 Astra 与 Claude Fable 5.1 在深度推理模式下判定结果的平均值，其余参测模型用各自提供商的默认推理设置。四个工作流由 TypeSafe 自己的模型能力团队设计，官方承认可能存在偏差，同时也指出这个口径偏向 OpenAI 和 Anthropic 的模型，可能低估了自家和 DeepSeek 的模型。参测的大模型通过 TypeSafe 开源的适配器接入，被约束为输出结构化决策。速度测试一般在美国西海岸的自家笔记本上运行，服务也部署在那里。到目前为止，没有第三方独立复现。
官方不公布 MMLU 这类公开学术榜单的成绩，理由是公开榜单容易诱发针对测试集的优化，也反映不出模型作为函数组件嵌进生产代码时的真实表现；他们主张用户针对自己的业务工作流自建评测。
这套评测里还有一个和 Jev 无关的发现值得记下来：每个参测模型被拆成结构化工作流之后，都比让同一个模型用一段单体提示词跑完全程更准确、更便宜、更快。这个结论只覆盖这套 harness 和这四个样例任务，不能直接外推，但它指向的东西比 Jev 本身更普遍。
「不会幻觉」到底保证了什么
这是整件事里最容易被读错的一句话，得拆成三层来看。
第一层是类型与格式安全，这一层是机制保证的。Jev 的输出空间在推理之前就被预定义的模式完全限定，输出端直接映射为离散类别或者标尺上的数值概率，所以结构和类型的匹配由接口本身保证，不存在 JSON 损坏、多余前缀或者意外拒答导致下游解析崩溃的情况。官方的对比图里 Jev 标的是 0%，但他们自己写明了：这个数字不是实测出来的，而是由模式匹配的保证直接填进去的。同一张图里其他模型的数据来自 OpenRouter，官方也说那边几乎肯定存在偏差，因为更复杂的查询可能被路由到更好的模型。
第二层是概率校准，这一层是训练目标和厂商主张。RLCD 优化的就是「更高的置信度对应更高的准确率」。但校准是一个统计性质：在它给出 90% 概率的那一大批答案里，大约九成是对的——这句话对其中任何一个单独的答案都不成立。而且到目前为止，官方没有公开训练实现细节，也没有公开独立的校准曲线。
第三层是业务语义正确性，这一层完全不保证。不管格式多安全、置信度标得多准，模型的推断本质上仍然是统计的。一个 Choice 永远能返回一个合法的目的地，也照样可以把请求发到错的地方去。
维基竞速那个演示正好卡在第一层和第三层的缝上。游戏规则是从一个维基百科词条出发，只靠页面内的链接跳到指定词条，每一步往往要在成百上千个候选里选。因为候选集受类型约束，Jev 不可能点一个页面上根本不存在的链接——这是第一层的结构保证。但它完全可能在几百个真实存在的链接里挑错那一个——这是第三层的问题，结构管不着。顺带一提，官方自己注明了这个演示的几处水分：为了让视频不那么难熬，对照的大模型跑的是非推理或者最低推理档，所以这里的加速比明显小于其他演示；另外 Jev 的 Choice 最多支持 255 个候选，超过时要走先独立评分再显式选择的两阶段方案，所以偶尔会慢下来。
所以「不会幻觉」准确的说法是：它不会编造你没给它的东西，但它照样会选错你给它的东西。这两件事的工程含义完全不同。前者意味着你的解析代码可以少写一整套防御，后者意味着你仍然得自建业务评测、配置阈值、留好人工兜底。
它做不好的事
TypeSafe 为每个模型版本发布一个叫「jaggedness」的页面，专门列这一版做得差的地方。厂商主动公布缺陷清单不是常见做法，这件事本身值得注意，也让下面这些内容大部分可以直接引自官方。
它按字面读指令，不读意图。限定词、否定和隐含条件都被逐字理解。这里有一条挺好用的判断标准：当你看着一个错答案、开始向别人解释「我其实是想问……」，那段解释就是你指令里缺掉的那一半。
它不是计算器。字符数、出现次数、列表项数，它都数不准。给它十六进制颜色值，它判断不出哪两个接近——问颜色名字可以，问 `#FF4B0A` 不行。算数应该留在代码里。如果你要数的是「符合某个语义条件的有几项」，正确做法是每一项问一个 Noul，然后在代码里求和。
日期同理，它把日期当文本读。谁先谁后、相隔多久、是否落在某个时间窗内，全都不可靠，遇上混杂格式或者「上周」这类相对表述更糟。抽取本身是判断，可以交给模型——年、月、日各做一个 Choice，带上「未说明」这个选项——但拼出真正的日期再做比较，是代码的活。
Score 不是测量。别拿 1.4 去反推「这个客户从不满走到愤怒完成了四成」，档位之间的数值校准很弱。Score 用来过阈值或者排序，不用来插值出一个量级。
间接指代会掉准确率，双重否定、一个属性的属性、任何需要多跳的东西都是。指着 state 里相关的那部分直接问。state 里塞进去的无关内容越多，准确率也越低——官方说这个模型和其他模型一样有 context rot，而修复的责任在调用方：先在代码里过滤，实在没法确定性过滤的，就用一个 Noul 逐块问「这块和当前问题相关吗」，把不相关的丢掉再问正题。
对抗性内容目前没有防护。写进 state 的文字是可以影响答案的，官方说预期会改进，但眼下的建议是把 criteria 写精确，并且在放到公开入口之前拿恶意输入测一遍。指令和档位说明互相打架同样会让答案变差，两者得说同一件事。
档位要描述情境，不要描述程度。「功能坏了但有绕过办法」给了模型可以比对的东西，「比较严重」没有。官方在一个 Safari 导出缺陷上量过这个差别：档位只用纯文字描述时，得分 1.30、置信度 0.54；同样的档位每档补一个贴近真实输入的例子，变成 1.07、置信度 0.90。补无关的例子几乎没有变化——例子只有长得像你的真实输入时才有用。
最后，它不能写字。技术上你可以用逐字符的 Choice 硬凑出文本，官方直说这么做又慢又差。控制台的欢迎页也自陈了三类不擅长的任务：系统二任务、专业垂直领域，以及任何生成类任务。
这些限制归拢起来是一句心法：从牌堆里挑一张，而不是让它报一张牌。凡是你想说「抽取 X」的地方，都改写成「这是 X 的候选，哪一个是？」
该把它放在哪
分工其实挺清楚。决策重复、高频、答案集合事先已知，交给 Jev。需要文字、代码、一段书面理由，或者一次性的复杂推演，还是归大模型。而已经被确定性代码正确处理的判断，就让它留在代码里——一个不花钱的 if 仍然好过一次可能出错的模型调用。
所以落地形态几乎总是组合，不是替代。一个反复出现的搭配是「大模型写，Jev 查」：播客网站用大模型生成分集摘要，再用 Noul 逐条比对原始转录，把概率低的标出来送复核。另一个是路由：订单查询直接查库，根本不碰大模型；产品问题送大模型并带上相应上下文；投诉再用第二个 Score 决定给大模型还是给人。贵的资源只在真正需要时才启动。
上线路径也有比较稳妥的做法。保持现有行为不变，让 Jev 在旁边跑并记录完整答案；累积一批之后标注哪些判对了、哪些判错了；用这批数据去调问题写法和阈值；先自动化风险最低的那一条分支；不确定的继续留给人或者更强的模型。
成本要按「每个被解决的任务」算，不是按每 token 算。有个早期实验把 1018 篇论文摘要分到 24 个主题里，Jev 这部分只花了 0.08 美元，单篇中位延迟 256 毫秒——但生成那批摘要用掉了另外 3.99 美元。便宜的那一段只占全流程的一小块。同理，如果省下来的钱被重试和人工复核吃掉，工作流层面的节省就缩水了。有个粗略的算式：总节省等于分类类调用在账单里的占比，乘以这些调用上的节省幅度。一个月花一万美元，其中六千花在分类、路由、评分、核验上，新路径只要原来的百分之五，那么省下五千七，占总账单的 57%；但如果分类只占一成，就算把这部分做到免费，最多也只能省一成。
最后要记住现在是什么阶段。Jev 发布才几天，处在早期访问，前面提到的那些用例绝大多数是实验，不是生产案例。当前版本是 jev-1.13.0，限流为每秒 25 万 token、每分钟 1200 次请求，官方说会在把人从候补名单放进来的过程中动态调整。定价能否长期维持，官方自己也说还需要时间检验。
但这套东西真正改变的，可能是加 AI 的方式。产品不必变成聊天机器人，流程也不必整个变成 agent。你可以保留手上已有的应用，只在普通 if 看不懂输入的那一个点上，加一次模型调用。
参考资料：
https://typesafe.ai/blog/introducing-system-one-models-and-jev