把一封客诉交给普通大模型，它会给你一段话；交给 Jev，它只回答应该分给哪个部门、有多紧急，并给出概率。对 Codex / computer use，它可作为操作判断层：先把页面转成文本或结构化状态，再在候选动作里做 Choice，减少大模型反复处理封闭判断的延迟和 token。
这是 TypeSafe AI 在 2026 年 9 月推出的第一个 System One Model。官方用一句话概括 Jev：「非结构化状态输入，类型化概率决策输出」。它不是另一个聊天或编程模型，而是给软件工作流用的「判断原语」。
Jev 与普通 LLM 差在哪
普通 LLM 默认输出字符串。即使开启 JSON mode 或 structured output，本质上仍是「先生成，再约束格式」。Jev 则要求开发者在请求里预先定义问题和可能的输出，模型只能在这些类型内做决定。
这就是官方所说的「零幻觉」应该被如何严谨理解：Jev 不会返回预定义类型之外的值，但它仍可能在合法选项中判错。类型安全不等于事实正确，概率和置信度正是留给程序的风险信号。
图1：TypeSafe 官方评测中的结构化输出与工具调用错误率。这是厂商自报数据，不是独立基准。
三个原语，对应三类判断
- Choice
：从给定候选中选一个，返回选中项、完整概率分布和置信度。例如把工单路由到账单、技术或销售团队。
- Noul
：判断命题是否成立，返回 0–1 之间的「是」概率。例如「这封邮件是否需要立即处理」。
- Score
：按自定义的有序量表评分，例如从「平静」到「非常愤怒」评估客户情绪。
多个问题可以共享同一份 state，一次并行完成。这对路由、分类、筛选、质量检查、RAG 片段选择很有吸引力。配合 Codex 时，可把页面状态和候选操作交给 Choice，由 Jev 判断该点哪个按钮、走哪个分支或调哪个工具；主模型保留规划、生成和操作校验。速度提升来自这种分工，而不是一个对所有任务都成立的「快 10 倍」承诺。
但 Jev 不生成文本，目前只接受文本或文本化的 JSON，也不擅长精确数学、计数、日期比较和多跳推理。官方还提醒，中文等 CJK 语言的准确率可能低于英语，上线前必须用自己的数据评测。
一个实用判断方法是：如果结果必须预先列举、可以用标注数据验证，而且会在工作流里高频重复，Jev 值得测试；如果任务要写作、解释或开放推理，就应继续交给生成式模型。
图2：官方「工作流智能与成本」图。其参考答案来自外部模型的平均预测，应视为厂商评估而非人类标注真值。
如何用上 Jev
第一步：申请 early access
访问 typesafe.ai 加入 waitlist。早期用户有人反馈当天或一两天收到邀请，但这是社区经验，不是官方 SLA。
第二步：给 Codex 安装官方 Skill
在项目终端执行：
npx skills add typesafe-ai/skills --skill typesafe-ai按提示选择 Codex。默认是项目级安装；需要全局安装时再加 -g。Skill 只是给 Codex 增加 Jev 的 API 说明和设计方法，不会把 Codex 的主模型替换成 Jev。
第三步：创建 API Key
回到 TypeSafe Console 创建 key，并在本机设置环境变量 TYPESAFE_API_KEY。不要把密钥粘贴到 prompt、代码或 Git 历史中。同时记得审查隐私条款和 DPA，因为输入会发送给 TypeSafe API。
第四步：让 Codex 使用 Skill
新开一个会话，直接输入：
use the TypeSafe skill. Build a minimal Python demo that routes a customer-support ticket with Choice, checks urgency with Noul, and scores frustration with Score. Read TYPESAFE_API_KEY from the environment, print all answers and confidence values, and add a fallback for low-confidence results.Codex 会依照 Skill 生成基于 typesafe-sdk 和 TypeSafeClient 的最小示例。别急着让低置信度结果直接执行：高置信度可自动处理，中间区间要补充信息或二次确认，低置信度转人工或更强的推理模型。阈值不应拍脑袋，必须用真实业务数据标定。
图3：TypeSafe AI 官方发布视觉。
值得现在就用吗
按 2026 年 9 月 19 日的官方文档，jev-latest 指向 Jev 1.13，输入价格为每百万 token 0.042 美元，输出不计费；上下文上限 64k，官方直连限额为每秒 25 万 token、每分钟 1200 次请求。这些数字变化很快，生产使用前要重新查官方页面，经过阈值标定的工作流最好锁定具体模型版本。
至于这种用法能省多少，"10 倍"这样的数字请谨慎看待。一条热门帖子来自一个单一样本的手感，没有给出对照设置、样本量、统计方法或可复现代码，不应被当作普遍性基准。官方宣称在自己 System One 工作流中最高约 193.6 倍更快、444.6 倍更便宜，但官方自己也明确说这些数字位于实际收益的高端，且其参考答案来自外部模型的平均预测而非人类标注。
真正值得关注的不是倍数，而是让主模型负责规划与生成，让 Jev 承担封闭、可评估的快速判断。是否真的更适合你，请用自己工作流的延迟、token 占用和私有测试集来回答。
