Jev：不会说话的 AI，为什么让整个硅谷沉默了

Decisions, not strings. —— TypeSafe 给 Jev 的官方定义：要决策，不要文本。

一句话读懂 Jev

Jev 不是用来聊天、写文章或写代码的"小 LLM"，而是一个嵌进程序决策点的低延迟概率判断器：它不生成任何自由文本，只在开发者预先定义的答案空间里做选择、打分或判断真假。

给它一段信息（state）和几个提前定义好的问题（questions），它直接返回带校准概率的结构化结果。你的代码拿着这些数字去做分支、路由、升级人工——全程不需要把任何一句话"翻译"回程序能懂的结构。发布后发布帖获得约 420 万次浏览、近 2 万次点赞，长时间盘踞 Hacker News 前列。

它到底"反常"在哪

我们对"AI 模型"的直觉几乎被自回归 LLM 塑造了：一个 token 一个 token 地续写，应用层再用提示词、JSON Schema、重试和校验，把字符串"翻译"成结构。Jev 把这个流程整个倒过来：

传统 LLM：   输入 → Token1 → Token2 → Token3 → …… → 文本/JSON → 解析 → 结构
Jev：        state + questions ──────────────→ 类型化决策 + 概率分布（无文本）

TypeSafe 称之为第一个公开的 System One Model——借卡尼曼《思考，快与慢》的框架：LLM 是缓慢深思的 System 2，Jev 是快速直觉的 System 1。二者不是替代，而是分层协作：Jev 负责海量高频的"模糊 if"，LLM 负责少数真正需要开放推理的环节。

命名彩蛋：Jev 来自 19 世纪经济学家 William Stanley Jevons——提出"杰文斯悖论"的人：效率提升未必减少消耗，反而可能因为足够便宜而引爆总需求。潜台词：当单次判断便宜到可忽略，开发者会在过去"根本不值得调模型"的每个细小节点上都加上判断。

一次调用是怎么工作的

请求体非常小：一个 state（要判断的事实现场：文本 / 嵌套 JSON / 文本数组，所有问题共享）+ 一组 questions。官方服务对同一 state 上的所有问题并行评估，而不是让第二个问题等待第一个问题的输出。

{
  "model": "jev-latest",
  "state": "客户说发票被重复扣款，要求立即退款，否则将向监管机构投诉……",
  "questions": {
    "is_refund": { "type": "noul", "instructions": "客户是否明确提出退款？" },
    "team":      { "type": "choice", "instructions": "该由哪个团队处理？",
                   "options": ["billing", "support", "security", "other"] },
    "urgency":   { "type": "score", "instructions": "紧急程度？", "min": 0, "max": 10 }
  }
}

返回的不是解释，而是程序可直接消费的结构：

{
  "model": "jev-1.13.0",
  "answers": {
    "is_refund": { "type": "noul", "noul": 0.95 },
    "team":      { "type": "choice", "choice": "billing", "confidence": 0.91 },
    "urgency":   { "type": "score", "score": 8.7, "confidence": 0.88 }
  }
}

if answers["is_refund"]["noul"] >= 0.9 and answers["team"]["choice"] == "billing":
    auto_process_refund()
elif answers["urgency"]["score"] >= 7:
    page_on_call_engineer()
else:
    normal_queue()

核心思想：模型负责模糊语义判断，代码负责精确规则、权限和动作。

三种原语：Choice / Score / Noul

• 一个 Choice 最多 255 个选项；Score 可定义 2–10 个带描述的等级。
• Score 是各等级概率的加权值，可能落在两档之间（如 8.7/10）。
• 多问题并行且相互独立——问题 B 若依赖问题 A，依赖关系必须显式写在代码里。

"没有幻觉"的确切含义：不会输出你没定义过的选项。但这不等于判断不会错——"严格在界内"和"界内选得对"是两回事。

Jev vs LLM vs 传统分类器

关键区分：JSON Mode ≠ Jev。JSON Mode 约束生成文本的语法，模型仍在"写"字符串；Jev 约束的是答案空间本身，模型不进入字符串生成，直接输出决策与完整概率分布。

训练方法 RLCD：校准比聪明更重要

TypeSafe 将训练方法称为 RLCD（Reinforcement Learning for Calibrated Decisions）：不只优化"选对"，还让概率在一组相似预测上反映真实正确率——给出 0.8 置信度的一批判断，应约有 80% 真的正确。

与 RLHF 的对比是 TypeSafe 的核心论点：RLHF 把 LLM 优化成"讨好人类偏好的聊天机器"，带来模式坍缩与过度自信；而机器之间的通信本来就不需要自然语言。已知的架构信息（均为官方口径，无论文）：transformer 架构、完全在合成数据上训练、外界猜测可能基于某个开源权重 LLM（未经证实）。

数字背后的真相（性能与成本）

厂商 benchmark：特定工作流中最高比对照大模型快 193.6 倍、便宜 444.6 倍（约 $0.000081/0.114s vs LLM 的 $0.01388/8.566s）。

但必须降温：评测工作流由 TypeSafe 自己的团队设计，参考基线也是其 wrapper 跑出来的；官方技术备注坦承存在偏差、真实收益"可能处于高端区间"。结论应理解为：在可拆成结构化小判断的工作流里有数量级优势——不是所有任务都快几百倍。相信方向，审慎引用绝对倍数。

五个真实落地场景

1、客服工单路由 —— 消息+订单+政策进 state，一次请求并行问"是否退款/归谁/多紧急/情绪等级"，按阈值三级分流。原型价值：每天数十万次的判断，不该每次花 $0.014 等 8 秒。

2、Agent 的"前置反射弧" —— Agent 循环里每个微决策（选工具/结果是否相关/是否继续）都交给 Jev，前沿大模型调用量可压缩 90% 以上。LangChain 已发布 langchain-typesafe 集成包。

3、浏览器/UI 自动化 —— 把可访问性树扁平化成元素列表做 Choice，单步决策压到 150ms 内，DOM 点击由自动化框架执行。已有语音→Jev→浏览器点击的公开演示。

4、模型路由 —— 开源项目 jev-model-router：一次 Choice 在 nano/fast/balanced/frontier 四档模型间路由（输入价 $0.05–$10/百万 token），让贵的模型只处理贵的问题。

5、安全与可观测性打标 —— 几十次工具调用的 Agent 轨迹，安全管道需要的是标签：是否越权？是否泄露敏感信息？失败来自计划、工具还是环境？Jev 的输出形态与告警系统天然对齐。

彩蛋：GitHub jev_fsd 让 Jev 在温哥华真实街道地图（OpenStreetMap）的模拟器里开车，面板实时显示它被问了什么、有多确定；无 API key 时降级为纯规则引擎作对照组。

十分钟接入指南

方式 A：OpenRouter（门槛最低）：模型 ID typesafe/jev-1.13，输入 $0.042/百万 token，输出免费。
方式 B：Cloudflare Workers AI：env.AI.run("typesafe/jev", {...})。
方式 C：LangChain：pip install langchain-typesafe。
方式 D：TypeSafe 直连（Early Access 需申请）：POST https://api.typesafe.ai/v1/systemone。

生产环境锁定 jev-1.13.0 而非别名 jev-latest，并在响应里记录实际 model 字段。

Python 完整示例：客服分流器

import requests

resp = requests.post(
    "https://api.typesafe.ai/v1/systemone",
    headers={"Authorization": "Bearer YOUR_TYPESAFE_API_KEY"},
    json={
        "model": "jev-1.13.0",
        "state": "客户：你们的系统重复扣了我两次款，我要求今天之内退款，否则我投诉到消协。",
        "questions": {
            "is_refund":   {"type": "noul", "instructions": "客户是否明确要求退款？"},
            "team":        {"type": "choice", "instructions": "该工单归属团队？",
                            "options": ["billing", "support", "security", "other"]},
            "frustration": {"type": "score", "instructions": "客户愤怒程度（0-10）？"},
        },
    },
    timeout=5,
)
a = resp.json()["answers"]

if a["is_refund"]["noul"] >= 0.9 and a["team"].get("confidence", 0) >= 0.85:
    route_to("billing", priority="auto")
elif a["frustration"]["score"] >= 7:
    route_to("billing", priority="human-now")
else:
    route_to("billing", priority="queue")

最佳实践与避坑

该做：事实进 state、判断给 questions；大问题拆小；一次请求塞多个问题；用概率设计"自动/复核/人工"三级分流；先用真实数据校准阈值再放开自动执行。

不该做：拿它聊天/写作/写代码（物理上做不到）；指望问题间自动串联；把厂商 benchmark 倍数当承诺；忽略非英语场景需自测（官方口径英语为主要训练语言）；生产环境用漂移别名。

冷静看待：争议与局限

完全闭源（无参数量、无论文）；自测基准偏高（官方自己承认）；能力边界硬（无开放推理、无多模态、仅文本）；生态尚早但替代品已涌现（classifier.dev、Hugging Face 上的同类开源模型，社区已有 Jev 类模型榜单）。即便折扣全部打完，方向依然成立：AI 落地的主要成本，正在从"生成能力"转向"高频决策的可靠性、延迟与价格"——这不是一个产品的故事，是一个品类的开端。

结语：杰文斯悖论的回响

160 年前 Jevons 观察到：蒸汽机效率越高，煤耗反而越多——因为当一吨煤能做的事变多，人们会在任何从前用不起蒸汽的地方装上蒸汽机。Jev 正在 AI 领域重演这一幕：邮件是否值得打扰用户、这条日志要不要升级给人看、检索结果是否真的相关——这些判断单个都不宏大，却构成了自动化系统绝大部分的日常工作。LLM 负责让世界理解语言，System One 模型负责让机器自己做决定。 当二者分层协作，AI 应用才算真正从"演示"走向"基础设施"。

参考资料：TypeSafe 官方博客与文档、LangChain 官方博客、GitHub（jev_fsd、jev-model-router）、Wikipedia: Jev (AI model)