Jev 是什么?TypeSafe AI 的 System One 模型:和 GPT/Claude 的区别、价格算例与国内付款(2026)
Jev 不写文字、不聊天,只对你预先定义好的问题返回带概率的结构化答案。它适合做什么、不适合做什么、按官方单价怎么算钱、从哪注册,以及国内开发者付款卡在哪。
1. Jev 是什么:一句话说清
Jev 是 TypeSafe AI 在 2026 年 9 月 15 日发布的第一个公开 System One 模型。官方发布文章把它比作「前沿智能的一次函数调用」:非结构化的状态进去,带概率的类型化决策出来。它不生成文本——你在请求里给出一段状态(一封工单、一条消息、一份记录,文本或 JSON 都可以),再列出若干个问题,并提前把每个问题允许的答案定义好;Jev 对每个问题返回一个落在你定义范围内的答案,外加概率:Choice 和 Score 返回每个选项(档位)的概率和一个置信度,Noul 返回一个 0 到 1 之间的概率。发布文章的作者是 TypeSafe 创始人 Diogo Almeida,他在文中自述在 OpenAI 时参与过让语言模型学会听从指令、与人对话的方法研究。名字的来历官方也写了:System One 取自卡尼曼《思考,快与慢》里「快思考」的说法,Jev 取自经济学家 William Stanley Jevons。
2. 和 GPT、Claude 这类聊天模型差在哪
差别不在「更聪明还是更笨」,而在训练目标和输出形态完全不同。聊天模型用 RLHF 一类的方法优化「人更喜欢的回答」,输出是逐个 token 顺序生成的字符串,程序要用还得先解析、校验,而且总有输出跑偏的可能。Jev 用 TypeSafe 自己的训练方法 RLCD(Reinforcement Learning for Calibrated Decisions,面向校准决策的强化学习),目标是让给出的概率「说实话」——官方的说法是置信度越高、准确率越高;采样是并行的,一次请求同时给出所有问题的全部概率,而不是一个字一个字地吐。由此带来三个差异:① 输出类型由 schema 保证,官方称不会出现类型错误;② 每个答案都带概率(Choice、Score 另带置信度),代码可以按阈值决定自动执行还是转人工;③ 同一次请求里多加几个问题,响应时间几乎不变。反过来,它也做不了聊天模型能做的事:官方文档明确写着 Jev 不是 Claude Code、Cursor 这类编程工具背后大模型的替代品,它不写代码、不对话、不调用工具。正确的组合是:编程助手照常用大模型,你写出来的程序在需要做判断的地方调用 Jev。
3. 三种问题类型,一次请求全部问完
Jev 的接口只有三种问题(官方文档称为 primitives):Choice 从你给的选项里选一个,返回所选项、每个选项的概率和置信度;Score 按你写好的有序档位打分,返回分数、每档概率和置信度;Noul 判断一句陈述是否成立,返回 0 到 1 之间的概率。三种可以混在同一次调用里,每个问题对同一份状态独立、并行地评估。官方建议把问题拆到最小:与其问「这份商业计划好不好」,不如分别问市场规模、技术可行性、差异化,再在代码里按你自己的权重合成——权重变了改代码里的系数,而不是重写提示词。下面是按官方快速入门的请求格式写的最小示例,接口地址和字段名以官方 API 文档为准。
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "jev-latest",
"state": "Order #1042 arrived damaged. I need a refund before Friday.",
"questions": {
"team": {
"type": "choice",
"instructions": "Which team should handle this message",
"criteria": {
"refund": "Refund or return requests",
"shipping": "Delivery problems without a refund request",
"other": "Anything else"
}
},
"is_urgent": {
"type": "noul",
"instructions": "The message conveys urgency or time-sensitivity"
}
}
}'4. 适合做什么
官方给出的定位是「AI 驱动的工作流 / 智能 if 语句」:在手写规则太脆、又不值得调用一次大模型去生成文字的地方,让 Jev 给出一个结构化判断,由周围的代码负责约束和组合。官方博客和文档列出的典型场景包括:工单和请求的意图分类与路由(按置信度决定交给规则、交给专门的大模型还是交给人);按你定义的档位给内容打分(紧急程度、质量、风险);RAG 检索结果先逐段打分再决定哪些进入回答模型;核对引用是否被原文支持;在大模型应用的输入、输出两侧做安全护栏和越狱检测(官方同时提醒,刻意写来带偏模型的内容可能改变答案,见下一节第 ⑤ 条);以及对海量数据做批量特征提取。官方还演示过用它实时玩 Doom(输入是文本化的游戏状态数据,不是画面):每秒 10 次查询,博客里给出的成本约每小时 7 美元。高频、低延迟、每次只要一个判断的负载,是它和聊天模型拉开差距的地方。
5. 不适合做什么:官方自己列的短板
TypeSafe 在文档里专门有一页写 jev-1.13 的已知短板(标注 2026-09-17 复核),接入前值得读完。要点:① 数学和计数——别让它做算术、数个数、比较两个十六进制颜色,这些放在代码里做;② 日期时间比较——它把日期当文本读,应先抽取年月日,再在代码里比较;③ 字面理解——它回答你写下的问题,而不是你心里想问的问题,边界条件要写进选项说明;④ 多跳间接推理和塞满无关细节的超长状态都会拉低准确率,先过滤再发送;⑤ 对抗内容——官方写明 jev-1.13 默认把状态当数据、不当作恶意输入,注入的指令、刻意误导的措辞、替自己争取某个分类的文本都可能带偏答案,官方预计以后改进;判定标准要写清楚,上线前充分测试边界情况;⑥ 生成——要写文字、写代码,请用生成式模型。另外三条硬限制:输入只支持文本(字符串、JSON 对象或文本数组),图片、音频、视频要先转成文本;单次请求上下文 64k token(其中状态加最长的一个问题不超过 32k);官方写明英文是主要训练语言,中日韩等语言能处理但效果不完全一样——中文业务上线前务必用自己的数据测一遍,并认真看置信度。
6. 价格怎么算:按官方单价的一个算例
官方单价:输入 $0.042 / 百万 token(即 $42 / 十亿 token),输出不计费。官方快速入门里那次示例请求(一条客服工单加三个问题)返回的用量是 392 个输入 token。按这个量级粗算:单次约 392 × 0.042 ÷ 1,000,000 ≈ $0.0000165;同样大小的请求跑 100 万次,输入合计约 3.92 亿 token,费用约 $16.5。你的真实成本取决于状态有多长、问题写得多详细,上线前用自己的请求看返回里的 usage 字段即可。有两点要一起读:其一,官网首页的「193.6x Faster, 444.6x Cheaper」来自他们自己的 System One 任务工作流评测,官方在博客里也说明这些数字预计处在真实场景收益的偏高端,不要直接拿来做预算;其二,关于价格能否持续,9 月 15 日的发布文章里官方说目前无法证明价格没有补贴,需要时间来证明,并预期以后会降价而不是涨价;官网首页 FAQ「Are these prices temporary or subsidized?」现在的回答是:按现价可以盈利地提供 Jev,目标是随着技术改进让智能逐步更便宜。
7. 速度:70ms–500ms 的前提
官方给出的端到端响应时间是 70ms–500ms,同时说明公开评测一般是在美国西海岸跑的,服务目前也部署在美国西海岸。从国内或亚洲其他地区调用,要在这个数字上再加跨境网络往返,实际延迟以你自己测到的为准。限流方面,官方文档列出的是每秒 10 万 token、每秒 40 次请求,并注明需求很大、限额会动态调整,更高额度要联系官方的企业方案。批量任务要做退避重试——官方 Python SDK 默认会对 429 退避重试,自己直接调 HTTP 接口时要自己处理。
8. 怎么注册开始用
9 月 15 日发布时,Jev 以 early access(抢先体验) 开放,官方在发布文章里说会尽快把候补名单上的开发者放进来;官网首页 FAQ 现在写的是 Jev 已向所有人开放,在 console.typesafe.ai 创建账号即可。能从官方页面核实到的入口是这些:控制台 console.typesafe.ai(登录后有 Playground,不写代码也能直接粘一段文本、加几个问题试);API Key 在控制台里创建;接口是 POST https://api.typesafe.ai/v1/systemone;Python SDK 用 pip install typesafe-sdk 安装,默认调用 jev-latest。注册时要填哪些信息,官方没有公开写明,以控制台实际显示为准。计费规则可以在官方主服务协议(typesafe.ai/legal/mca)第 8.2 节核实:使用服务要先有 Credits,每次提交输入时扣减;Credits 不可兑现、不可退款、不可转让;购买的 Credits 若订单没有另行约定,在购买满 12 个月或合同期结束时过期(以先到者为准);赠送的 Promotional Credits 由官方自行决定,官方没有义务发放——所以别默认会有免费额度,按预估用量购买即可。另外,官方使用条款写明网站不保证适用于美国以外的地区,注册前请自行确认你的使用方式符合官方条款和所在地的法律法规。
9. 国内开发者注册和付款的常见卡点
按出现的先后:① 付款卡被拒——海外 SaaS 和 API 平台普遍走海外收单,收单方按卡号前几位(BIN)判断发卡地区,国内发行的卡即使印着 Visa 或 Mastercard,跨境扣款也可能被风控拒掉,这是常见原因之一。② 账单地址对不上——随手编的地址容易导致扣款失败,邮编和州都可能参与校验。③ 卡内余额不足——虚拟卡是先充值后消费,余额不够扣款就会失败。④ 拿中文 demo 下结论——这不是付款问题,但很常见:Jev 的主要训练语言是英文,评估时建议准备一份英文样本和中文样本对照着测。
10. 用美国卡段虚拟卡付款的流程
全程在官方页面自己操作,不把账号交给任何人:① 注册 cocodot,用支付宝充值到钱包;② 在控制台开一张美国卡段的 Visa 或 Mastercard 虚拟卡,再把钱从钱包转进卡——钱包余额和卡内余额是两回事,没转进卡的钱扣不走;③ 在 TypeSafe 控制台的付款页面填卡号、有效期、CVV,账单地址填你本人真实使用的完整地址(这张卡没有绑定个人地址,卡页上也没有需要照抄的地址),同一个商户账号始终用同一个,不要用网上找来的、他人的或编造的地址;④ 卡账单上的商户名显示为 TYPESAFE AI, INC.,对账时按这个名字加金额、日期核对。cocodot 的美国卡段虚拟卡在这个商户有过成功扣款;但发卡侧和商户侧的风控都会变化,任何卡都不能保证每一笔都通过。扣款连续失败两次就先停下排查余额、地址和卡状态,别在短时间内反复重试,以免卡和账号一起被标记风险。付款方式和计费周期以 TypeSafe 控制台实际显示为准。
11. 说清楚两件事
第一,cocodot 的 API 中转目前不包含 Jev——要用 Jev,请直接在 TypeSafe 官方控制台注册和调用,cocodot 在这件事上提供的是付款用的美国卡段虚拟卡。第二,Jev 发布后网上流传着不少关于估值、播放量、开源星数的说法,我们在官方渠道找不到出处,本文一概不引用。本文关于 Jev 的事实全部来自 typesafe.ai 的发布文章、官网首页、docs.typesafe.ai 文档以及官方法律文件(主服务协议与使用条款),写于 2026 年 10 月初,价格、限额和模型版本以官方最新页面为准。
一张表看懂 Jev 和聊天模型的分工(Jev 一列全部来自 TypeSafe 官方页面)
| Jev(System One 模型) | 聊天 / 生成式大模型 | |
|---|---|---|
| 输出 | 预先定义类型的结构化答案 + 概率(Choice / Score 另带每个选项的概率和置信度) | 自由文本,程序使用前要解析和校验 |
| 采样方式 | 并行:一次请求给出所有问题的全部概率 | 逐 token 顺序生成 |
| 训练目标 | RLCD:校准过的决策 | RLHF / RLVR:人类偏好、可验证奖励 |
| 计费 | 输入 $0.042 / 百万 token,输出不计费 | 输入、输出分别计费,各家价目不同 |
| 延迟 | 端到端 70ms–500ms | 官方博客引用的前沿模型数据为 3–329 秒 |
| 适合 | 分类、路由、打分、抽取、是非判断、护栏 | 写作、编程、对话、Agent |
| 不适合 | 生成文字、算术与计数、日期比较 | 嵌进代码做大量判断(官方观点:容易过度自信、前后不一致,集成进代码时是瓶颈) |
| 输入 | 仅文本(字符串 / JSON / 文本数组),单次 64k token,其中状态加最长一个问题 ≤32k | 视模型而定 |