Jev 上手实战：不写一个字的「System One 决策模型」，70ms 返回带概率的确定答案，分类路由从此便宜两个数量级

9 月 15 日，一家叫 TypeSafe AI 的旧金山创业公司结束了两年隐身，发布了一个不太像"大模型"的模型：Jev。它的创始人 Diogo Almeida 是 OpenAI 前研究员——InstructGPT 和 RLHF（人类反馈强化学习）方法的发明人之一，这套方法正是 ChatGPT 的技术底座。这一次他的赌注是：软件里大多数 AI 调用根本不需要一段文字作为答案，只需要一个带概率的、类型安全的决定。

一、Jev 到底是个什么东西

官方给它的品类名是 System One 模型——借用了卡尼曼《思考，快与慢》里"系统 1"（快速、直觉的判断）的概念。和现有大语言模型逐项对比就明白了：

维度	现有大语言模型	System One（Jev）
优化目标	人类偏好（RLHF）/可验证奖励（RLVR）	校准决策（RLCD，校准强化学习）
输入	强调对话式的顺序消息	强调结构化的程序状态
输出	字符串（需解析校验，可能跑题）	预先定义好的类型化值 + 概率 + 置信度
采样	逐个 token 串行生成	一次查询内并行算出全部答案
输入价格	$0.20–$10 / 百万 Token	$0.042 / 百万 Token
输出价格	约为输入的 5 倍	免费
端到端延迟	3–329 秒	70–500 毫秒

注意两个关键性质：一是输出结构在提问时就已经定义死，模型在数学上不可能产生类型错误（官方声称零幻觉，严谨说法是"不可能返回超出 schema 的值，但仍可能返回错误的合法值"）；二是每个答案都带校准过的概率分布和置信度——置信度高真的意味着准确率高，这让"按置信度分流"成为可能。

二、整个 API 只有三种提问原语

Jev 的接口非常克制：你把一段"状态"（state，可以是字符串、JSON 对象或对话数组）连同若干"问题"一起发给 POST /v1/systemone，它一次性并行回答所有问题。

1. Choice：从选项里挑一个

最多支持 255 个选项，每个选项只花几个 Token，所以应该把完整候选列表都传进去，而不是先粗筛一遍。返回选中项、每个选项的概率和置信度。

2. Score：在刻度上打分

2–10 个有序等级（用文字描述），返回的位置可以落在等级之间（比如 1.035），适合"有多生气""有多紧急"这类连续判断。

3. Noul：是非题的概率

返回 0 到 1 的一个数——"是"的概率本身。名字来自 "no/yes" 的拼合。

用官方 JavaScript SDK 看一个完整的客服工单分诊例子：

npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY="sk-..."

import { choice, score, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient(); // 默认模型 jev-latest

const r = await client.systemOne({
  state: {
    ticket: {
      subject: "Duplicate charge",
      messages: [
        { from: "customer", text: "I was charged twice for order A-104. Please refund the duplicate." },
      ],
    },
    order: { id: "A-104", charges: [
      { amount_usd: 49, status: "captured" },
      { amount_usd: 49, status: "captured" },
    ]},
  },
  questions: {
    department:  choice("Which team should handle this", {
      billing: "Payment or subscription issues",
      technical: "Bugs or integration problems",
      other: "Anything else",          // 永远留一个 other 出口
    }),
    frustration: score("How frustrated is the customer", [
      "Calm", "Frustrated but civil", "Very angry",
    ]),
    refundWanted: noul("The customer explicitly asks for a refund"),
  },
});

console.log(r.answers.department.choice, r.answers.department.confidence);
console.log(r.answers.frustration.score);
console.log(r.answers.refundWanted.noul);

几个问题在同一次请求里并行回答——这是它成本结构的根基：加一个问题几乎只加 Token 费、不加时间。官方 cookbook 里把一个 13 问的监管简报批量塞进一次调用，比逐问调用便宜 12.2 倍、快 10 倍，答案还一致。

三、最值得偷的架构模式：The Cascade

Jev 不是来取代 GPT-6 或 Claude 的，它是来决定"哪些请求配得上调用它们"的。典型的级联结构分三层：

async function handle(message) {
  const r = await client.systemOne({
    state: message,
    questions: {
      intent: choice("Primary intent of this message", {
        order_status: "Asking about an existing order",
        product_question: "Asking about a product",
        complaint: "Unhappy, wants resolution",
      }),
      complexity: score("How complex is this to resolve", [
        "Simple lookup", "Requires judgment", "Edge case, escalate",
      ]),
    },
  });
  const { intent, complexity } = r.answers;

  if (intent.confidence < 0.5) return routeToHuman(message); // 兜底：真没把握

  if (intent.choice === "order_status") return lookupOrder(message); // 纯代码，零模型成本
  if (intent.choice === "product_question") return llmHandle(message, PRODUCT_SPECIALIST);
  if (intent.choice === "complaint") {
    if (complexity.score > 1 || complexity.confidence < 0.5) return routeToHuman(message);
    return llmHandle(message, COMPLAINT_RESOLUTION);
  }
}

按官方给出的单例成本估算，100 万张工单上这套结构大约花 6,480 美元，而全量用大模型处理约 30,400 美元；其中约 80 万单在 0.5 秒内就被纯代码或 Jev 消化掉了。另一个配套技巧是按动作的成本设不同置信度阈值：只读查询 0.6 就放行，涉及转账的操作要 0.85 以上、否则转人工确认——因为置信度是校准过的，这套阈值才有意义。

四、发布 48 小时内社区做出的东西

1kpapers.com：DeepSeek V4 Flash 摘要 1,018 篇论文花 $3.99，交给 Jev 用一次 Choice 分类只花 $0.08，每篇中位延迟 256ms。
browser-use/jev-ultrafast：浏览器 Agent 把页面转成编号元素表，一次 Jev 调用同时决定操作类型和目标元素，真实 Google Flights 订票 7.1 秒、$0.0039。
awlevin/typesafe-computer-use：Mac 电脑操作 Agent，OCR 读屏 + Jev 决策，单步 $0.0002，比直接喂截图给旗舰模型便宜约 160 倍；作者也诚实指出：旗舰模型"顺手做了"的那些推理，在这里都要你用确定性代码重建。
jev-trader：在 Monad 链上每约 300ms 一个区块做一次买/卖决策的做市机器人，模型延迟约 81ms。

共同点很清晰：循环、安全判断、算术都留在普通代码里，只把代码难以表达的"那个狭窄判断"交给 Jev。

五、注意事项：官方自己列出的"锯齿"（jaggedness）

TypeSafe 发布了一份少见的诚实文档，列出 Jev 明确做不好的事，上线前必读：

逐字理解：它回答你写出来的问题，不是你心里想的问题。否定词、范围限定都会按字面执行——看到错误答案时你下意识解释"我其实是想问……"，那段解释就是缺失的指令。
不是计算器：数数和计算不可靠，且误差随计数对象增多而变大。要计数就逐条问 Noul，求和在代码里做。
日期只是文本：比较先后、算间隔都不靠谱；日期解析和排序必须放在代码里。
上下文腐烂（context rot）：状态里塞的无关材料越多，准确率越低。先用代码检索和过滤，只传问题需要的字段。
状态不防注入：用户可控内容进了 state，就可能被"游说"影响答案——这是你的威胁模型，要自己测。
锁定版本：jev-latest 当前解析到 jev-1.13.0，升级后同样输入的答案可能漂移；调过阈值就钉死版本号，并记录响应里的 model 字段。
速率限制：当前 250,000 Token/秒、1,200 次请求/分钟，超限返回 429，且官方明确说限额会随 GPU 到货随时调整。

另外还有一句值得抄下来的元规则：不要问模型代码能精确计算的问题，也不要在一个问题里藏多个判断。

六、小结

Jev 代表的不是"又一个更便宜的 LLM"，而是一个新原语：一次碰巧具备智能的函数调用——返回类型化结果，并告诉你该信它多少。 它适合路由分诊、审核过滤、在昂贵上下文之前做相关性筛选、给 LLM 输出打分做护栏、以及一切需要塞进请求处理链路里、对延迟敏感的批量判断；不适合生成任何文本、计数、日期运算，以及需要给审计人员一份书面理由的决策。

目前 Jev 处于早访问阶段（typesafe.ai 申请候补名单，密钥在 console.typesafe.ai 签发），官方基准是自测且尚无第三方复现，所有性能数字都应在自己的真实流量上验证后再押注。但如果这个品类成立——而"用对工具做对的决策"这个方向几乎必然成立——未来系统架构里会多出一层永远存在的便宜判断层：代码做确定的，Jev 做模糊的，旗舰模型只做最难的那一小撮。