一、先从一个工程问题说起：代码什么时候该信模型
前段时间我在商城客服场景里做过一次六分类对比，用的是开源社区的 Jev-Style-Qwen3.5-2B（一个仿照 Jev 接口思路训练的开源模型，和 TypeSafe 没有任何关系），对照组是 laya-multilingual。结果 Jev-Style 20 条全对，laya 错了 5 条。
但让我真正停下来想的不是准确率，而是两组概率。Jev-Style 有三条题的最高概率只有 0.47 到 0.54，正好卡在「退换售后」和「价格优惠」之间。laya 把「这款桌子还有货没」判成了退换售后，给的概率却是 0.91，和它判对时一样自信。
20 条全对说明不了什么，下一批数据换个说法就可能错。工程上真正要回答的问题是：模型给出一个答案时，代码凭什么决定直接执行，还是交给人？ 如果概率本身不可信，阈值就只是摆设。
这正是 TypeSafe 做 Jev 时想回答的问题。2026 年 9 月 15 日，前 OpenAI 研究员、RLHF 共同发明人 Diogo Almeida 带着 TypeSafe AI 结束隐身，发布了 Jev，并把它称为第一个「System One 模型」。到我写这篇文章的 10 月 8 日，官方仍然只有 jev-1.13.0 一个版本，jev-latest 和 jev-preview 两个别名都指向它。
接口层面的东西我在之前介绍 NeoHorse-Jev-4B 的文章里讲过，这里不再重复。这篇只讲一件事：Jev 为什么这样设计。它押注了什么，放弃了什么，又把哪些活儿交回给了工程师。下文的事实都来自 TypeSafe 的官方博客、宣言和文档；第三方观点会单独标明出处；官方没公开的东西，我会直说没公开。
二、思想一：放弃字符串，把输出契约写进请求
先看我们最熟悉的做法。用通用大模型做分类或路由，一般是在提示词里写「请输出 JSON」，模型逐个 token 生成一段字符串，代码解析、校验字段，不合法就重试或走兜底。这条链路能跑，但每一环都可能出问题：多写了一句解释、少了一个字段、枚举值拼错了，都得在代码里防着。
Jev 的第一个设计决定是直接放弃生成字符串。官方博客里有一张对比表说得很直白：LLM 输出的是字符串，「要被软件使用，就得先解析、再校验」；Jev 输出的是类型安全的结构化值，「可能的输出和结构都提前定义好，模型不会犯类型错误，每个答案都带校准过的概率和置信度」。
调用方在请求里放一段 state（要判断的上下文），再附上一组带类型的问题：从几个选项里挑一个，在有序等级上打分，或者判断一句话是真是假。答案的形状由请求决定，模型只能在这个范围里作答。官方的说法是：把 Jev 想成一次「前沿智能的函数调用」，输入非结构化的状态，输出类型化的概率决策。博客里还有一句我很认同：「放弃字符串，反而让我们获得了很多超能力」。后面几节讲的并行、校准、可组合，都是从这个取舍里长出来的。
但这里必须把边界说清楚：类型安全不等于判断正确。官方说「不会出类型错误」在数学上就不可能被推翻，这没错，因为 schema 匹配是结构上保证的。可 InfoQ 在 10 月 1 日的报道里引用了一条 Hacker News 评论：它确实不会输出非法类型，但完全可能输出一个合法但错误的值。Armin Ronacher 对 TechCrunch 的评价更尖锐，说这种设计「把幻觉问题部分转交给了用户」，用户得自己决定一个 50% 的概率值不值得执行。
我认为这两种说法并不矛盾。Jev 消灭的是格式层面的错误，语义层面的错误它只能用概率告诉你，最后拍板的还是你的代码。所以第二个设计决定就格外关键：这个概率得是可信的。
三、思想二：训练目标从「人喜欢」换成「概率诚实」
TypeSafe 在文档的 AI primer 里，把大模型的后训练分成三条路线：
| 路线 | 优化的是什么 | 典型产物 |
|---|---|---|
| RLHF（人类反馈强化学习） | 人类评分员更喜欢的回答 | 聊天助手 |
| RLVR（可验证奖励强化学习） | 能被程序自动验证的结果 | 推理模型，强但慢、贵 |
| RLCD（校准决策强化学习） | 概率和实际命中率一致 | 决策模型，不生成文本 |
这张表背后是 TypeSafe 对主流路线的一个判断。官方认为 RLHF 教模型说「人爱听的话」，这对聊天产品是对的，但会奖励谄媚和「听起来很自信的幻觉」，还会造成 mode dropping：模型偏向某一种风格，其他可能输出的概率被压低。文档里有一句话我很认同：对人有说服力的输出，不一定可靠到能无人值守地自动化。RLVR 则只适合能用程序简单验证的任务，官方博客的 FAQ 说，大部分真实世界的判断不是这种形状，硬套会得到「尖刺状、不鲁棒的智能」。
RLCD 的目标是校准：模型给出 0.8 的那一类答案，长期看大约 80% 应该是对的。官方反复强调，这是一组预测的统计性质，不保证某个单独的答案正确。理解这一点很重要，因为它决定了阈值怎么用：阈值是在一批流量上做取舍，不是给某一条结论背书。
说完思路，得老实交代空白。RLCD 公开的只有名字和目标：奖励函数、训练流程、校准方法都没有公开。第三方站点 Agentic Ready 在 9 月 20 日专门列过一份清单，指出这些问题官方都还没回答。社区里有人用 Brier 分数当奖励去复刻，也有人把它解读成某种多选偏好学习，这些都是猜测，我不当事实写。同样没公开的还有模型架构、参数量和训练数据。官方 FAQ 只说「数据全部是我们自己造的，不会用客户数据训练」；被问到「Jev 是不是一个更小的 LLM」，官方的回答是「它既不小，也不是 LLM」。所以如果把它理解成「蒸馏出来的小模型」，目前并没有官方依据。
四、思想三：state 只读一次，问题彼此独立、并行评估
自回归模型是一个 token 接一个 token 地往下写，后面的输出依赖前面的输出。官方博客说，Jev 的采样是并行的，「一次查询生成所有输出」。文档讲得更具体：Jev 只读一次 state，然后把每个问题都拿来和它并行对照评估。
这个设计带来两个工程上的好处。
第一，多问几个问题几乎不加钱，也不加时间。 官方因此推荐一种叫 speculative fan-out 的用法：把系统可能用到的问题一次全发出去，由代码事后决定用哪些。比如一条客服工单，同时问类别、bug 严重程度、有没有复现步骤、是否要求退款、用户情绪五个问题；如果最后判定不是 bug，严重程度那一问直接忽略就行。
官方 cookbook 里有一个可以量化的例子：对 GDPR 的维基百科条目问 13 个监管相关的问题，打包成一次调用比拆成 13 次调用便宜 12.2 倍、快 10.0 倍，答案没有变化。原因不复杂：那篇约 5.4 万字符的文章才是每次请求的大头，读一次和读 13 次的差别，就是账单的差别。真正贵的是读输入，不是回答问题。
第二，问题之间互不影响。 文档里的原话是：一个问题的结果不会变成隐藏上下文，去改变另一个问题的结果。这一点比快更重要。用大模型在一次生成里连问几个问题，前面的回答会影响后面的回答，排查错误时很难说清是哪一步带偏的。Jev 把每个问题隔离开，每个答案都可以单独测试、单独调阈值。
至于内部到底怎么实现，官方只说用了「新的模型架构和并行采样器」。有第三方做了上万次 API 调用来逆向分析，推断它只做 prefill、复用共享前缀、没有自回归解码。这个推断听起来合理，但 TypeSafe 没有证实，我只把它当成一种可能的解释。
五、思想四：代码掌舵，模型只做原子判断
如果只看前三点，Jev 像一个更好用的分类 API。真正让我觉得它是在提出一种架构主张的，是 TypeSafe 的宣言，标题就叫「Composable AI: Build Prod, Not God」。
宣言里有一个比喻：早期的汽车被设计成「没有马的马车」，保留了高座位、弹簧，有的甚至还留着插马鞭的孔。官方认为今天的 AI 也是这样：它被训练成一个善于表达、讨人喜欢的助手，结果就是必须有人在回路里看着。而软件从来不是这么构建的。再复杂的软件也是由简单逻辑一层层搭起来的，每个分支都可以审计。所以他们希望 AI 成为程序员可以随时调用的语义判断原语，精确计算仍然交给代码。宣言的脚注把这条思路归到神经-符号 AI，并且给了一个俗称：「smart if-statements」，也就是更聪明的 if 语句。
文档把这个主张落成了三种架构的对比：
传统代码是一棵由确定性规则组成的决策树，可靠但处理不了模糊输入。Agent 让大模型自己决定下一步，适合有人盯着的场景，但官方的说法是「每多一轮循环，就多一次跑偏的机会」。TypeSafe 推的是第三种：代码掌控流程、规则和副作用，模型只在需要常识判断的地方出场，而且每次只回答一个窄问题。 文档写得毫不含糊：System One 是用来构建 AI 驱动的软件的，「不是用来做 agent 的」；它不生成代码，也不自己选择下一步动作。
要让这种架构成立，问题必须拆得足够细。文档把这一条称为「大概是本指南里最重要的概念」，并给了一个钓鱼邮件的例子。不要问「这封邮件是不是垃圾邮件」，而是拆成六个是非题：
requests_credentials 正文是否索要密码或登录凭证？
offers_unexpected_reward 是否声称收件人获得了意外奖励？
creates_time_pressure 是否催促收件人尽快行动？
sender_identity_mismatch 发件人显示名和邮箱域名是否矛盾？
link_domain_mismatch 链接域名和发件机构是否矛盾？
disguises_link_destination 链接文字是否掩盖了真实地址？
risk = 代码里按权重组合这六个概率 → 阈值 → 放行 / 隔离 / 人工复核
一个笼统的问题背后其实藏着好几个判断，拆开以后，每个判断都能单独检查、单独调优，组合方式和权重留在代码里，随时可以改。官方把这叫做 composite scoring（组合打分）。同样的思路还有两条：state 里只放这个问题需要的内容，多余的上下文会让准确率下降；能从自己的知识库里查到的事实，不要指望模型权重里记得。
这一点和我自己做推荐链路时的体会是一致的：召回、过滤、打分规则交给程序，大模型只拿到一份候选清单去写回复。问题越窄，越容易测；边界越清楚，出了问题越容易定位。Jev 只是把这套分工推到了模型这一层，连模型本身都只允许做窄判断。
官方还特意写了一页说明：Jev 不能拿来替代编码 agent 背后的大模型。它不写代码，不聊天，不调用工具。正确的用法是让编码 agent 写出调用 Jev 的代码，而不是让 Jev 当 agent。
六、思想五：置信度是第二条轴
有了校准过的概率，下一步就是把它变成代码里的分支。TypeSafe 文档里有一句话概括得很好：答案告诉你是什么，置信度告诉你要不要行动。
官方 10 月 3 日在 X 上专门发了一条：「我们公开了置信度的计算方式」。三种问题的置信度都是从概率分布算出来的，公式写在文档里，用伪代码表示是这样：
# Choice：n 个选项，p_max 是被选中选项的概率
confidence = (p_max - 1/n) / (1 - 1/n) # 均匀分布时为 0，完全确定时为 1
# Score：有序等级，m 是概率最大的等级
spread = Σ p_i × |i - m| # 概率离峰值平均有多远
confidence = max(0, 1 - spread / 均匀分布下的平均距离)
# Noul：不单独返回 confidence，p 本身就是不确定性
如需和 Choice 统一口径：confidence = |2p - 1|
Score 的公式值得多看一眼。它考虑了等级之间的距离：模型在相邻两级之间犹豫，比在两端之间犹豫扣分更少。例如三个等级时，(0, 0.5, 0.5) 的置信度是 0.25，(0.5, 0, 0.5) 是 0。官方也提醒，这只是一种合理的汇总方式，不是唯一正确的；完整的概率分布都会返回，你可以自己算 top 概率，或者第一名和第二名的概率比，后者往往更贴近「到底在两个候选之间纠结多少」。
怎么用这个数，文档给了一个三段式：高置信自动执行；中置信谨慎执行（让用户确认，或者进复核）；低置信不执行（转人工、请求澄清，或者换别的系统）。更关键的一句是：阈值不是一个数，而是随动作的风险分级。
官方举的例子是银行场景：置信度低于 0.5 一律转人工；查余额这种看错了也能补救的操作，过了这条线就直接执行；转账这种高风险操作，要高于 0.9 才进入确认后执行，否则先让用户确认意图。这些数字只是示例，官方也说正确的阈值取决于你的领域和模型在你数据上的表现，应该从保守的值开始，用自己的数据调。
还有一个容易被忽略的细节：阈值要和版本绑定。 官方文档明确写着，别名会随新版本移动，同一个请求背后的答案可能就变了；如果你按某个版本调过阈值，就应该在生产里写死 jev-1.13.0 这样的版本号，按自己的节奏迁移。概率的含义一变，阈值就得重调，这和数据库升级要回归测试是一回事。
阈值到底能换来什么，可以参考第三方 DecisionEval 在 9 月 20 日对 jev-1.13.0 的一次评测：400 个用例、2,000 个决策，整体准确率 0.740，ECE（期望校准误差）0.045。只保留置信度 ≥ 0.7 的答案时，覆盖率 57.6%，准确率升到 0.864；只保留 ≥ 0.9 的，覆盖率 24.5%，准确率 0.937。这张「用覆盖率换准确率」的表，比单一的准确率更能回答「这条队列能自动化多少」。需要注意的是，这个数据集的标准答案来自一组教师模型的概率分布，不是人工标注；在教师模型意见一致的子集上，Jev 的准确率是 0.841，意见不一致的子集上只有 0.591。换句话说，模型的表现和题目本身有没有确定答案高度相关，这也是为什么一定要用自己的数据重测。
七、代价：官方自己承认的 9 个毛刺
放弃生成、只做窄判断，是有代价的。值得称道的是，TypeSafe 在文档里专门写了一页「Jev 1.13 jaggedness」，把已知的短板列了出来，最近一次复核是 10 月 2 日。我把这 9 条按「怎么应对」分成三类：
| 应对方式 | 短板 | 官方建议 |
|---|---|---|
| 交还给代码 | 数学和数字：不是计算器；计数靠不住；hex、RGB 这类数值表示不如语义名称；不要拿 Score 的期望值去插值算具体数值 | 计算放在代码里；计数拆成逐项是非题，由代码累加 |
| 日期和时间比较：把日期当文本读，先后、间隔、是否落在某个窗口里都不可靠 | 日期抽取交给模型（年、月、日都是有限集合，可以用单选），比较和计算交给代码 | |
| 靠写法规避 | 理解偏字面：你写什么它答什么，不会揣摩你的本意 | 把精确条件写进 instructions，把边界情况写进 criteria |
| 多跳、间接、双重否定 | 减少跳数，直接点名 state 里的字段 | |
| state 里无关内容太多，准确率下降 | 先在代码里检索、过滤，只送问题需要的字段 | |
| instructions 和 criteria 互相矛盾 | 让两者用一致、清楚的语言表达 | |
| 靠测试兜住 | 对抗内容：注入的指令、误导性的表述可能改变答案（官方说以后会改进） | 把 criteria 写明确，上线前充分测试边界用例 |
| 单选题的选项顺序：有时会偏向排在第一个的选项 | 调换选项顺序，看答案是否一致 | |
| 不会生成文本 | 生成交给生成式模型；抽取任务先用正则或大模型列出候选，再让 Jev 挑 |
这张表其实是在说同一件事：模型只负责判断，凡是能精确计算、能用规则表达的东西，都应该留在代码里。 这和上一节讲的架构主张是自洽的。
给中文读者提一句：官方在模型页写明，英文是主要训练语言，效果最好；中日韩文字「能处理，但没那么好」，建议非英文任务先在自己的数据上测，并特别留意置信度。我目前没有找到公开的、系统的中文评测。
另外，官方对公共 benchmark 的态度也值得记下。FAQ 里说他们不打算在公共榜单上发成绩，建议「不要给公共 benchmark 任何权重，用自己的用例建评测」。官方博客里自己的评测也附带了一长串说明：延迟是在美国西海岸的笔记本上测的；工作流评测用两个大模型的平均答案作为参考；首页上「快 193.6 倍、便宜 444.6 倍」的数字，他们自己也说「可能处于真实收益的偏高一端」。第三方的数据更保守一些：InfoQ 引用的一份对 12,759 条发布期推文的分析显示，用户自述的提速中位数约 7 倍，成本节省中位数约 30 倍。差距很大，这再一次说明：数字要在自己的流量上测出来。
八、适用与不适用
把前面的内容收拢，我会用下面这张表来判断一个场景该不该用这类决策模型：
| 适合 | 不适合 |
|---|---|
| 请求路由、工单分流、意图识别 | 写回复、写文案、写代码 |
| 闸门和护栏：是否放行、是否越权、是否含敏感内容 | 开放式推理、多步规划 |
| 打分和排序：紧急度、质量、风险，以及检索结果重排 | 精确计算、日期运算、计数 |
| 抽取后的二次选择：先列候选，再挑正确的那个 | 依赖模型自身知识的事实问答 |
| 对延迟敏感的实时交互 | 图片、音频输入（目前只支持文本） |
一句话：生成交给大模型，判断交给决策模型，规则和算术留在代码里。 三者叠加，而不是互相替代。官方文档里的意图路由模式也是这个意思：先用决策模型判断请求该去哪，再把它交给确定性逻辑、专门的大模型或者人工。
九、10 月的信号：决策模型成了一个品类
Jev 发布后的三周里，有几件事值得记下来。
第一，大厂跟进了。OpenAI 在 10 月 6 日开放了 Decisions API 公测，模型是 gpt-6-luna，三类输出分别叫 Predicate（判断一个陈述为真的概率）、Choice（从固定选项里选一个并给置信度）、Score（按区间打分），支持文本和图片输入，每百万输入 token 0.10 美元，不收输出费。接口思路和 Jev 几乎一致，而且已经补上了 Jev 还不支持的图像输入。
第二，流量平台单独开了榜。OpenRouter 上线了「决策模型排行榜」，截至 10 月 7 日的一周，Jev 1.13 的请求量是 9.81 亿次，第二名 Span-01 Lite 是 951 万次；榜上还有 OpenAI、Cloudflare、Perplexity、Upstage 等多家的决策模型。这个榜只统计请求量，不代表准确率，但它说明「决策模型」已经被当成一个独立的模型类别来看待了。
第三，开源侧有了复刻。除了我之前写过的 NeoHorse-Jev-4B，Jev-Style 也在 9 月 27 日发布了 2B 的 v3 版本。它们都不是 TypeSafe 的产品（Jev-Style 在模型卡里明确声明与 TypeSafe 无关），接口相似，但训练方法、校准方式和效果各不相同，不能拿来互相推断。
热闹之外，社区的质疑同样值得听。在 OpenAI Decisions API 的发布帖下，有用户做了一个「偏硬币」实验：硬币 70% 的概率正面朝上，用是非题问，模型给出的结果符合预期；换成单选题问，正面的概率却被推到了 98%；调换选项顺序，概率也跟着变。他的结论是这样不可靠，并补了一句「Jev 也好不到哪去」。这只是一个用户的小实验，不能当评测结论，但它提醒我们：校准是一个需要持续验证的性质，不是厂商写在文档里就自动成立的承诺。 这也和 Jev 官方自己列出的「选项顺序偏差」对得上。
