Jev 是什么：把「生成一段话」换成「返回一个决策」

2026 年 9 月 15 日，TypeSafe 发布了它的首个公开模型 Jev。社交媒体上它被简写成「快 200 倍的 AI」「不要钱的大模型」，这类标题既对又错：对在数量级确实来自官方发布文，错在它根本不是又一个聊天模型。这篇文章用官方文档的口径讲清楚：Jev 到底是什么、不是什么、什么场合值得进你的架构。

一句话定义

Jev 是一个 System One 决策模型：输入一段状态（state）加一组事先定义好的封闭问题，输出的是带概率与置信度的结构化决策，而不是一段自由文本。

把它放进你已经熟悉的坐标系里：

• 它不是 LLM 替代品：官方发布文明确「Jev gives up string generation」——它放弃了字符串生成能力，写不了回答、代码或邮件。
• 它不是 传统分类器的替代品：不需要标注数据训练，靠自然语言描述选项与标准就能工作。
• 它更像一个可编程的判断函数：你定义问题的动作空间和量表，它返回分布，你的代码拿分布去路由。

System One：软件工程里缺的第三种角色

官方把模型分成两类心智：「System Two」是慢速、生成式的 LLM（链式思考、写长文），「System One」是快速、封闭式的判断。Jev 的架构要点（均为官方口径）：

• 并行采样：模型对状态一次性并行评估所有问题，而不是逐 token 生成——这是低延迟的来源。
• RLCD 训练（Reinforcement Learning for Calibrated Decisions）：训练目标是「校准过的概率」，即置信度更高时准确率确实更高。
• 类型安全输出：可能的输出结构在请求里预先定义，模型「不会犯类型错误」——注意，类型正确不等于语义正确，它依然可能把投诉归错类。

工程上的位置可以概括成：LLM 负责「生成」，规则引擎负责「确定」，Jev 负责中间那层「快速、模糊但封闭的判断」——判断该走哪条分支、优先级多高、要不要拦下来。

三种决策原语

所有请求发往同一个端点 POST /v1/systemone，问题分三种类型（详细写法见决策原语怎么选）：

一个请求可以带多个问题并行求值，官方建议把代码可能需要的所有问题一次问完——加问题的边际延迟很小，代码用不到的答案直接忽略即可。

官方宣称的性能与价格，怎么读

以下全部是厂商口径（2026-09-20 抓取自官方文档），本站尚未独立复现，生产决策前请用自己的数据实测：

• 延迟：System One 形态任务端到端约 70–500ms；发布文中的工作流对比声称「同智能水平下快 40–200 倍」。实测取决于网络、状态长度与问题数量。
• 价格：jev-1.13.0 输入 $0.042/百万 token，输出不计费。
• 上下文：单请求 64k token 总预算；其中状态加最长问题占 32k。
• 限流：250,000 tokens/s、1,200 requests/min，官方注明「动态调整中」，超限返回 429。
• 中文：英语是主训练语言、准确率最好；中日韩「可处理但不均等」，官方明确建议用自己的内容先测。

读这些数字的正确姿势：把它们当作待验证的架构假设，而不是采购依据。中文效果尤其如此——这正是本站存在的理由，见客服分流实战里的中文验证方法。

它明确不做什么

1. 不生成文本：没有自由文本输出，需要填理由、写回复的场景要配合小模型或 LLM。
2. 不处理图像/音频：只接受文本输入（字符串、JSON 对象或文本数组）。
3. 不替代规则引擎：高副作用的动作（退款、删数据、支付）该有的确认与审计一步都不能少。
4. 不承诺语义正确：schema 正确只是「输出不会是乱格式」，分类错误、评分偏差依然存在，靠置信度门控兜底。

什么时候适合用 Jev

满足这三个条件的问题值得考虑：答案是封闭的（能枚举选项或描述出有序量表）、需要低延迟/低成本（在高频或前置位置）、需要可审计的概率（你要据此设计阈值与人工升级）。典型场景：客服分流、Agent 工具路由、RAG 相关性过滤、内容审核预筛。

反例：开放式写作、多轮复杂推理、需要最新信息的问答——这些留在 LLM。两者的组合架构见 Jev vs LLM：组合架构选型；想直接上手跑第一个请求，看中文上手教程。