System One 模型与 Jev：把前沿智能做成一次函数调用——TypeSafe AI 的自动化新范式
本文是对 TypeSafe AI 博客 Introducing System One Models & Jev 的中文解读，图片引自原文。
模型在聊天上超越人类已经好几年了，那么承诺的自动化在哪里？
这是 TypeSafe AI 创始人 Diogo Almeida 过去四年的核心问题。他在 OpenAI 参与构建了让语言模型学会遵循指令、与人对话的方法——那项研究后来成了 ChatGPT 的基础。当时他以为聊天模型也许能通向 AGI，但渐渐地他确信：有什么非常重要的东西缺失了。
经过两年保密研发，TypeSafe AI 发布了他们的第一个 System One 模型：一类为自动化而生的新型前沿模型，专门做出软件可以直接使用的快速、结构化决策。第一个公开的模型叫 Jev，现已开放早期访问。
一、Jev 是什么：一次前沿智能的函数调用
先给一个最直观的类比：Jev 就像一个前沿智能的函数调用——非结构化状态进，带类型的概率决策出。
与现有 LLM 相比，Jev 在 System One 类任务上达到相近的智能水平，同时：
- 快两个数量级：端到端响应时间 70ms–500ms（前沿 LLM 为 3–329 秒）；
- 便宜两个数量级：输入 $0.042/百万 token（约 $42/十亿 token），输出免费（便宜到不值得计量）；
- 不会产生类型错误：可能输出和结构事先定义好，schema 匹配有数学保证；
- 放弃字符串生成：不生成文本，因此结构上不可能幻觉。
这套全新技术栈包括：新模型架构、面向最大效率的并行采样器，以及称为 RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习）的训练方法。
二、与 LLM 的七维正面对比
原文用一张大表把两类模型放在了一起，这是理解 System One 的关键：
| 维度 | 现有 LLM | System One + Jev |
|---|---|---|
| 训练方法 | RLHF（人类偏好）/ RLVR（可验证奖励） | RLCD：面向校准决策，输出附带认知上诚实的概率 |
| 优化目标 | 人类评分者喜欢的回答；可程序化验证的输出 | 校准的决策：置信度越高，准确率越高 |
| 输入 | 非结构化文本，强调串行消息 | 非结构化文本，强调结构化程序状态 |
| 输出 | 字符串：灵活但什么都可能是——聊天、代码、幻觉、拒绝；进软件前需要解析 + 校验，且始终有失控风险 | 类型安全的结构化值：输出结构事先定义，永不犯类型错误，所有答案附带校准概率与置信度 |
| 采样方式 | 串行：逐 token 生成，每个依赖上一个 | 并行：单次查询生成全部输出，高效且硬件感知 |
| 成本 | 输入 $0.20–$10/百万 token，输出约 5 倍于输入 | 输入 $0.042/百万 token，输出免费 |
| 速度 | 端到端 3–329 秒；人机交互够用，进代码就是瓶颈 | 端到端 70ms–500ms，同等智能下快 40–200 倍 |
| 置信度 | 即使被要求给置信度，也倾向于过度自信、不一致；不会说自己在那 5% 里，任务就无法自动化 | 每个输出都附带置信度与不确定性；校准、一致（相似输入得到相似答案） |
适用场景的分工也随之清晰：
- LLM 的主场：人在环任务（聊天机器人、副驾驶、编码 agent）——通用强大，但自由也意味着可能失控，需要人类监督；可验证问题（数学证明、内核优化）——正确性可以便宜地自动检验时，LLM 可以生成-测试-迭代；以及演示——字符串的灵活性让它擅长做“有时能跑通”的原型。
- Jev 的主场：智能 if 语句——结构化输出像模糊决策规则一样嵌入普通软件：分类、路由、打分、抽取、分支，用在手写规则太脆的地方，周围代码约束了它的自由度，反而更容易组合成可靠系统；大数据 map-reduce——把 PB 级数据变成特征和洞察；实时应用——100ms 级速度让 AI 能进 UX 敏感的关键路径；验证一切——给 LLM 的 prompt、推理链、输出打分、评判、守门、检测越狱。
三、证据：他们如何回应质疑
原文有一句很带感的话：“We love skeptics, and are skeptics ourselves（我们热爱怀疑者，我们自己就是怀疑者）。”他们把声明分成两类：
容易验证的：
- 速度：真的就这么快（评测从西海岸笔记本上跑出来的）；
- 成本：定价透明；是否补贴无法自证，长期可持续性需要时间证明（他们预期价格只会降不会涨）；
- 零类型错误：单个反例就能证伪，但这在数学上不可能。
Workflow evals：为“AI 进代码”设计的新评测
他们发明了一类新评测：不追求 ground-truth 分类，不允许通过 harness 工程来过拟合，而是假设存在一个正确的计算图（工作流），用最大、最聪明、最贵的外部模型（GPT-6 Astra 与 Fable 5.1）的预测均值作为参考概率。每个模型跑同一个工作流，看谁更接近“最聪明模型的平均值”：
结果：Jev 直接“爆表”，独占 Pareto 前沿近两个数量级。首页上“快 193.6 倍、便宜 444.6 倍”的数字就来自这里——他们自己也承认这属于真实收益中偏乐观的一端。作为对比，让 LLM 用提示词在思维链里做全部逻辑，效果显著差于直接使用工作流本身。
文中强调：真实可靠的业务工作流往往由大量独立、分解的问题组成，靠概率而非离散决策驱动细粒度行为——最终结果是离散分支，但通往结论的过程需要大量领域工程以高度一致的方式完成。
幻觉与类型安全：自动化的入场券
幻觉与类型安全本质上是一回事，而后者是自动化的入场券。agent 里幻觉一个工具调用只是麻烦；但在一个有延迟承诺的系统里、或埋在依赖链好几层深的地方，就是彻底的 deal-breaker。现有模型无论多聪明，仍然会幻觉、会犯类型错误。
他们的坦诚同样值得注意：LLM 的数字来自 OpenRouter（复杂查询可能被路由到更好的模型，存在偏差）；而自己的 0% 不是实证数字——schema 匹配是保证的，所以可以放心地写进图表。
Side-by-side 演示
并排演示展示了 Jev 与 LLM 的关键差异：Jev 并行输出全部概率，而不是自回归地逐 token 生成。字符串极其强大和通用，但很昂贵——“放弃”字符串反而带来了一堆超能力。录制的那次运行中，Jev 与 GPT-5.6 Terra 唯一的分歧在“流失可能性等级”——他们自己看，那个答案确实两可。
四、两个好玩的演示
玩 Doom。 用结构化游戏状态（含文本的数据结构，注意不是图像）驱动，每秒 10 次查询，成本约 $7/小时——团队本来担心太贵，结果大家一致觉得比想象中便宜。他们计划发布完整讲解并办 hack 活动。
Wikiracing。 从一个维基百科页面出发，只靠沿途链接到达指定页面。每一步要在成百上千个链接中选择——它是展示“每秒智能”和“高基数选择下不幻觉的复利效应”的绝佳 playground。一个冷知识：第 2 和第 3 个挑战恰好都从“Rubber Duck（橡皮鸭）”页面出发，纯属巧合，作者本人直到团队指出才发现。
五、命名由来：卡尼曼与杰文斯
System One 来自丹尼尔·卡尼曼的《思考，快与慢》：快速、直觉的 System 1 思维 vs 缓慢、深思的 System 2 推理。传统上“System 1 思维”也意味着易错——TypeSafe 认为System One 模型可以做得比替代方案更可靠，原因他们承诺未来展开。
Jev 纪念经济学家威廉·斯坦利·杰文斯（William Stanley Jevons）：蒸汽机效率提升后，煤炭需求不降反升——杰文斯悖论。他们预期机器智能会走上类似路径：智能成本每下降一个数量级，就会解锁数量级更多的新用例。
六、值得学习的“自我质疑”
这篇文章最难得的，是每个惊艳结论后面都跟着大段的 Nuance（细节与限定）：演示查询经过高度简化、问题键名为了可读性做了设计、较短的输入让自家模型占了便宜；评测由自家模型能力团队制作，可能存在偏差；参考答案偏向 OpenAI 和 Anthropic 的模型，很可能低估了自己和 DeepSeek 的相对表现；LLM 使用了他们自制的 System One 适配器（比无概率输出更慢更贵）……
这种“非常规的主张需要非常规的证据”的自我要求，比数字本身更有说服力。
七、接下来
Jev 还在早期。TypeSafe 正在开放早期访问，尽快把候补名单上的开发者放进来，想听大家：需要自动化什么决策、Jev 在哪里有效、在哪里失灵。
他们的出发点很简单：AI 需要一个软件可以依赖的接口。 当决策快到 70ms、便宜到输出免费、可靠到数学上不会出错，智能就可以像普通函数一样被“连续扩散”进社区和经济——正如杰文斯悖论所预言的那样。
八、落地可能性：先把“System One 层”这个抽象搬进来
先泼一盆冷水：Jev 目前是早期访问，而且是境外托管服务。在受监管行业，生产数据不可能送到境外 SaaS——这一条基本判死了直接使用。
但真正值得搬走的从来不是这个模型，而是这套抽象。
说明：以下场景均为通用化描述，不涉及任何具体企业、项目或内部数据。
1. 最值得抄的抽象：类型化决策单元
把它抽象成一个独立的工程概念，与具体模型解耦：
- 输入：非结构化状态（自然语言文本 + 结构化的程序上下文字段）；
- 输出：事先定义好 schema 的结构化值，每个字段附带校准过的概率；
- 约束：输出不可能违反类型；调用方拿到的是可以直接进
if的值，而不是一段需要解析的文本。
关键差异在于：现在大多数团队做的是“prompt 一段话 → 正则或人肉解析 → 出错重试”，脆弱、不可回归、无法承诺延迟。而这层抽象是“schema 先定义 → 输出被约束 → 概率被代码直接使用”。
2. 现有工程里可以立刻替换的五类点
| 场景 | 现状的典型做法 | 换成决策单元后 |
|---|---|---|
| 测试自动化 | LLM 生成失败分析文本，再靠正则/人工归类 | 失败原因分类、缺陷定级、报告字段抽取，输出即结构 |
| 研发效能度量 | 人工打标或关键词匹配，覆盖率与准确率都差 | commit/工单意图分类、变更风险打标、需求-代码映射批量跑 |
| 合规与文档处理 | 抽取靠模板 + 人工复核，规则命中靠字符串匹配 | 字段校验、要素抽取、规则命中判定，结论可审计 |
| 安全与网关 | 敏感信息识别靠正则，容易漏也容易误杀 | PII/凭据识别、请求意图路由、注入与越狱检测 |
| AI 编码助手的质量门禁 | 要么全量人工评审，要么完全不评审 | 判定 diff 是否触碰敏感目录、是注释变更还是逻辑变更 |
最后一行值得单独说一句：它和上一篇 Scion 解读里提到的语义化审批约束是同一件事——按风险分配评审注意力。两篇原文在这里正好接上了。
原文把这类用法叫“智能 if 语句”：结构化输出像模糊决策规则一样嵌进普通软件，用在手写规则太脆的地方；而周围代码约束了它的自由度，反而更容易组成可靠系统。这个描述比“用 AI 做分类”准确得多。
3. 不能用境外服务时的私有化替代路径
拿不到 Jev，不代表这层能力就建不起来。可行的替代组合：
- 内网可部署的中小模型 + 约束解码：JSON Schema 约束、function calling、或 grammar-constrained decoding，先把“不可能类型错误”这一条用工程手段兜住；
- 补齐三件套：schema 定义与前置校验、评测集、概率校准（最低要求是“置信度分桶后准确率单调递增”，否则置信度没有意义）；
- 把决策单元做成独立服务：输入输出都是 typed contract，底层模型可替换——今天用私有化小模型，将来换更大的本地模型或真正可用的 System One 模型时，调用方代码不用改。
这条路的速度和成本都到不了原文宣称的两个数量级，但类型安全与可审计这两条是可以拿到的，而这两条恰恰是受监管行业最看重的。
4. 顺手搬走 Workflow evals 这个评测方法
原文这套评测思路对内部落地特别实用，因为它不需要标注数据：
- 假设存在一个正确的计算图（工作流），用当前能拿到的最强模型在同一工作流上多次预测，取均值作为参考；
- 然后比较各实现方案与这个参考的接近程度。
它带来两个直接结论：一是能在没有 ground-truth 的情况下横向比较方案；二是原文明确指出——让 LLM 用提示词在思维链里硬做全部逻辑，效果显著差于把工作流拆开。
对内部最有价值的一句提炼就是：先拆工作流，再谈模型。 很多“AI 效果不好”的场景，问题出在没有拆解，而不是模型不够强。
5. 三阶段路线
| 阶段 | 目标 | 主要动作 | 度量 |
|---|---|---|---|
| 0–1 个月 | 跑通一个点 | 选 1 个高频判定（如测试失败原因归类）做成 typed API；建评测集 | schema 校验通过率、与人工判定的一致率 |
| 1–3 个月 | 形成一层 | 扩到 3–5 个判定点；接入质量门禁；做概率校准与阈值策略 | p50/p99 延迟、单次决策成本、置信度分桶准确率 |
| 3–6 个月 | 变成资产 | 决策单元抽成共享服务；纳入效能与质量看板；沉淀 schema 与提示词资产库 | 复用次数、新场景接入工时 |
6. 一把判断该用谁的尺子
- 用决策单元：高频、有延迟要求、需要可审计、结论形态是“分类 / 概率 / 抽取”；
- 继续用 LLM：需要生成（代码、文档、解释）、人在环、或者正确性可以自动验证。
两者不是替代关系，而是分层协作：LLM 负责探索与生成，决策单元负责判定与守门。 原文说 Jev 的用途之一是“验证一切”——给 LLM 的输出打分、评判、守门——这恰好是最容易切入、风险也最小的起点。
如果只能从这里带走一句话，那就是杰文斯悖论的工程版本：决策的成本每降一个数量级，值得自动化的判定点就会多出一个数量级。 现在被我们当作“不值得自动化”而交给人的那些模糊判断，绝大多数只是太贵了而已。
一句话总结：LLM 是为对话而生的通才，Jev 是为代码而生的专才——它放弃了生成字符串的自由，换来了两个数量级的速度与成本优势、数学保证的类型安全、以及每个决策都诚实的置信度。如果你的场景是“在代码里做模糊判断”，这可能是错过很久的那块拼图。原文见 typesafe.ai/blog。