Jev 是 TypeSafe AI 推出的首个 System One（系统一）模型。它面向机器和软件工作流，而不是为人写一段可阅读的回复：程序把当前状态交给它，Jev 快速返回可供代码直接处理的结构化判断。总部位于旧金山的 TypeSafe AI 由前 OpenAI 研究员 Diogo Almeida 与 Erik Gafni、Sasha Sheng 联合创立；Jev 于 2026 年 9 月 15 日进入早期访问阶段。216

核心差异：不是“生成文字”，而是“给出决策”

大语言模型（LLM）通常逐个预测并生成文本 token，因此能写作、解释、规划、编程和回答开放式问题。但在软件系统中，开发者往往还要解析模型回复，或验证其生成的 JSON，才能把结果安全地交给后续代码。

Jev 面向的是更收敛的任务。应用提交一份 state（状态）——可以是文本字符串、JSON 对象或文本数组——再附上带类型的问题；模型会为每个问题返回一项结构化答案。TypeSafe 的 API 文档将其描述为：针对一组带类型的问题评估状态，并逐题返回结构化回答。17

目前主要支持三种决策形式：

• Boolean（布尔判断）：估计某个命题为真的概率，例如“这条命令是否可以安全执行”。
• Choice（选择）：从开发者预先提供的选项中选出一个。
• Score（评分）：按照有序量表或数值尺度进行评级。

因此，TypeSafe 将 Jev 定位为软件流程中的“决策原语”，适用于模型路由、分类、检索过滤、风险评分和 AI Agent 护栏，而不是聊天助手。官方文档列出的用例还包括语义检索、Agent 轨迹分类，以及核查其他 AI 的输出。18

“系统一”是什么意思？

这个名称借用了心理学家丹尼尔·卡尼曼提出的区分：快速、直觉式的“系统 1”，以及较慢、更审慎的“系统 2”。TypeSafe 用“System One”描述专注于快速、边界明确判断的模型，而非开放式推理或内容创作。16

这并不意味着 Jev 解决了通用推理问题。它的重点是另一种接口：提供相关状态和明确的决策问题，得到的是一个受限结果及其概率分布，而不是一段解释性文字。

为什么受限输出更适合自动化？

使用 Jev 时，应用在请求前就定义好输出形态；对于 Choice 问题，也要给出所有允许的答案。这样能减少生成式系统集成中的常见麻烦：模型不会凭空增加字段、杜撰工具名称，或在程序只需要固定值时返回一大段自由文本。

但这是一种结构层面的保证，不是“答案必然为真”的保证。受限决策模型仍可能误读上下文、在允许选项中选错，或者给出在真实业务中校准不佳的置信度。Vercel 也明确区分了两者：符合 schema 只保证回答结构，语义正确性仍需单独评估。

在生产环境中，团队应把置信度阈值视为需要测试的业务策略，而非可靠性的自动证明。较实用的做法是：对高置信度、低风险的判断自动执行；对模糊或高影响的情况，转交 LLM、规则引擎或人工审核。

训练与校准：TypeSafe 的说法是什么？

TypeSafe 表示，Jev 完全使用合成数据训练，并采用 Reinforcement Learning for Calibrated Decisions（RLCD，面向校准决策的强化学习）。其目标是让模型报告的概率更接近实际观察到的正确率，而不是优化出更讨人喜欢的文字回复。

若校准确实可靠，对自动化很有价值：例如 0.9 的概率，理论上可帮助开发者设置更有意义的人工复核阈值。不过，RLCD 尚未经过广泛公开的独立测试验证；现有材料也没有提供针对 Jev 校准能力、对抗鲁棒性或跨领域准确率的全面第三方审计。因此，企业仍应使用自身业务数据和实际决策策略进行评估。

价格、上下文与速度

TypeSafe 列出的 Jev 1.13 价格为：每百万输入 token 0.042 美元，即每十亿 token 42 美元；输出 token 免费。按该标价计算，5 美元约可购买 1.19 亿输入 token，未计税费或账户的特殊条款。文档还显示，单次请求上下文为 64,000 token，其中 state 加上最长问题最多可占 32,000 token。

该公司及早期报道提到，Jev 的延迟约为 70 至 500 毫秒，具体取决于工作负载。这些数字可作为测试起点，但实际延迟还会受到请求大小、问题设计、部署地区和服务状态影响。

Vercel 的早期接入与使用热度

Vercel 已将 Jev 接入 AI Gateway，开发者可通过实验性的评估 API，以 typesafe-ai/jev 调用该模型。

Vercel 表示，Jev 上线后 24 小时内，近 13% 的付费 AI Gateway 团队已开始使用；同期触达的付费团队数量超过此前任何一次模型发布的两倍。 这说明开发者对这一类工具有很强的早期尝试意愿，但不能单凭这一数据推导出长期留存、生产级可靠性，或其在所有任务上优于其他模型。

早期报道也提到命令安全分类和邮件分类等实验。这些案例有助于理解 Jev 的目标任务类型，但不能替代独立、受控的基准测试。团队若要比较 Jev 与 LLM，应以自身代表性数据衡量准确率、概率校准、错误严重程度、延迟和整个工作流的总成本。

Jev 适合做什么，不适合做什么？

当应用已经清楚自己需要作出什么判断，并且能明确规定答案空间时，Jev 可能是合适的选择，例如：

• 决定 Agent 是继续、重试、请求澄清还是停止；
• 对命令或工具调用进行安全分类；
• 对紧急程度、相关性或风险进行评分；
• 先由确定性代码抽取候选值，再从中选择正确项；
• 在调用更昂贵的模型前，批量过滤或标注文本。

但如果产品需要开放式写作、解释、头脑风暴、代码生成、广泛规划，或者答案无法写进预先声明的 schema，Jev 不能替代 LLM。Jev 的效果同样取决于问题表述、输入筛选、候选选项、阈值和测试策略。TypeSafe 建议开发者明确写出判断条件，尽可能先过滤上下文，并充分测试集成效果。

模态支持与后续计划

Jev 目前只接受文本型 state，包括字符串、JSON 对象和文本数组；暂不支持图片、音频和视频。TypeSafe 将这些模态标为“尚不支持”，但现有文档未给出多模态模型的公开发布时间表。

实际应如何看待 Jev？

Jev 的主张并不是“所有 AI 都不该再生成语言”，而是指出许多软件工作流本来就不需要生成语言。对于边界明确的分类、路由或策略判断，带类型的概率化结果可能比聊天式回复更易接入、更便宜，也更快落地执行。

不过，结构化输出减少的是输出格式出错，不是决策本身出错。Jev 的实际价值，仍取决于其准确率和置信度是否能在独立测试、特定领域的数据与真实工作流中经受检验。在此之前，更适合把它视为面向明确软件决策的一种有潜力的专用工具，而非 LLM 的通用替代品。

Jev 是 TypeSafe AI 推出的首个 System One（系统一）模型。它面向机器和软件工作流，而不是为人写一段可阅读的回复：程序把当前状态交给它，Jev 快速返回可供代码直接处理的结构化判断。总部位于旧金山的 TypeSafe AI 由前 OpenAI 研究员 Diogo Almeida 与 Erik Gafni、Sasha Sheng 联合创立；Jev 于 2026 年 9 月 15 日进入早期访问阶段。216

核心差异：不是“生成文字”，而是“给出决策”

大语言模型（LLM）通常逐个预测并生成文本 token，因此能写作、解释、规划、编程和回答开放式问题。但在软件系统中，开发者往往还要解析模型回复，或验证其生成的 JSON，才能把结果安全地交给后续代码。

Jev 面向的是更收敛的任务。应用提交一份 state（状态）——可以是文本字符串、JSON 对象或文本数组——再附上带类型的问题；模型会为每个问题返回一项结构化答案。TypeSafe 的 API 文档将其描述为：针对一组带类型的问题评估状态，并逐题返回结构化回答。17

目前主要支持三种决策形式：

• Boolean（布尔判断）：估计某个命题为真的概率，例如“这条命令是否可以安全执行”。
• Choice（选择）：从开发者预先提供的选项中选出一个。
• Score（评分）：按照有序量表或数值尺度进行评级。

因此，TypeSafe 将 Jev 定位为软件流程中的“决策原语”，适用于模型路由、分类、检索过滤、风险评分和 AI Agent 护栏，而不是聊天助手。官方文档列出的用例还包括语义检索、Agent 轨迹分类，以及核查其他 AI 的输出。18

“系统一”是什么意思？

这个名称借用了心理学家丹尼尔·卡尼曼提出的区分：快速、直觉式的“系统 1”，以及较慢、更审慎的“系统 2”。TypeSafe 用“System One”描述专注于快速、边界明确判断的模型，而非开放式推理或内容创作。16

这并不意味着 Jev 解决了通用推理问题。它的重点是另一种接口：提供相关状态和明确的决策问题，得到的是一个受限结果及其概率分布，而不是一段解释性文字。

为什么受限输出更适合自动化？

使用 Jev 时，应用在请求前就定义好输出形态；对于 Choice 问题，也要给出所有允许的答案。这样能减少生成式系统集成中的常见麻烦：模型不会凭空增加字段、杜撰工具名称，或在程序只需要固定值时返回一大段自由文本。

但这是一种结构层面的保证，不是“答案必然为真”的保证。受限决策模型仍可能误读上下文、在允许选项中选错，或者给出在真实业务中校准不佳的置信度。Vercel 也明确区分了两者：符合 schema 只保证回答结构，语义正确性仍需单独评估。

在生产环境中，团队应把置信度阈值视为需要测试的业务策略，而非可靠性的自动证明。较实用的做法是：对高置信度、低风险的判断自动执行；对模糊或高影响的情况，转交 LLM、规则引擎或人工审核。

训练与校准：TypeSafe 的说法是什么？

TypeSafe 表示，Jev 完全使用合成数据训练，并采用 Reinforcement Learning for Calibrated Decisions（RLCD，面向校准决策的强化学习）。其目标是让模型报告的概率更接近实际观察到的正确率，而不是优化出更讨人喜欢的文字回复。

若校准确实可靠，对自动化很有价值：例如 0.9 的概率，理论上可帮助开发者设置更有意义的人工复核阈值。不过，RLCD 尚未经过广泛公开的独立测试验证；现有材料也没有提供针对 Jev 校准能力、对抗鲁棒性或跨领域准确率的全面第三方审计。因此，企业仍应使用自身业务数据和实际决策策略进行评估。

价格、上下文与速度

TypeSafe 列出的 Jev 1.13 价格为：每百万输入 token 0.042 美元，即每十亿 token 42 美元；输出 token 免费。按该标价计算，5 美元约可购买 1.19 亿输入 token，未计税费或账户的特殊条款。文档还显示，单次请求上下文为 64,000 token，其中 state 加上最长问题最多可占 32,000 token。

该公司及早期报道提到，Jev 的延迟约为 70 至 500 毫秒，具体取决于工作负载。这些数字可作为测试起点，但实际延迟还会受到请求大小、问题设计、部署地区和服务状态影响。

Vercel 的早期接入与使用热度

Vercel 已将 Jev 接入 AI Gateway，开发者可通过实验性的评估 API，以 typesafe-ai/jev 调用该模型。

Vercel 表示，Jev 上线后 24 小时内，近 13% 的付费 AI Gateway 团队已开始使用；同期触达的付费团队数量超过此前任何一次模型发布的两倍。 这说明开发者对这一类工具有很强的早期尝试意愿，但不能单凭这一数据推导出长期留存、生产级可靠性，或其在所有任务上优于其他模型。

早期报道也提到命令安全分类和邮件分类等实验。这些案例有助于理解 Jev 的目标任务类型，但不能替代独立、受控的基准测试。团队若要比较 Jev 与 LLM，应以自身代表性数据衡量准确率、概率校准、错误严重程度、延迟和整个工作流的总成本。

Jev 适合做什么，不适合做什么？

当应用已经清楚自己需要作出什么判断，并且能明确规定答案空间时，Jev 可能是合适的选择，例如：

• 决定 Agent 是继续、重试、请求澄清还是停止；
• 对命令或工具调用进行安全分类；
• 对紧急程度、相关性或风险进行评分；
• 先由确定性代码抽取候选值，再从中选择正确项；
• 在调用更昂贵的模型前，批量过滤或标注文本。

但如果产品需要开放式写作、解释、头脑风暴、代码生成、广泛规划，或者答案无法写进预先声明的 schema，Jev 不能替代 LLM。Jev 的效果同样取决于问题表述、输入筛选、候选选项、阈值和测试策略。TypeSafe 建议开发者明确写出判断条件，尽可能先过滤上下文，并充分测试集成效果。

模态支持与后续计划

Jev 目前只接受文本型 state，包括字符串、JSON 对象和文本数组；暂不支持图片、音频和视频。TypeSafe 将这些模态标为“尚不支持”，但现有文档未给出多模态模型的公开发布时间表。

实际应如何看待 Jev？

Jev 的主张并不是“所有 AI 都不该再生成语言”，而是指出许多软件工作流本来就不需要生成语言。对于边界明确的分类、路由或策略判断，带类型的概率化结果可能比聊天式回复更易接入、更便宜，也更快落地执行。

不过，结构化输出减少的是输出格式出错，不是决策本身出错。Jev 的实际价值，仍取决于其准确率和置信度是否能在独立测试、特定领域的数据与真实工作流中经受检验。在此之前，更适合把它视为面向明确软件决策的一种有潜力的专用工具，而非 LLM 的通用替代品。