1.1 自动化的缺口：聊天很强，自动化在哪
1.1 自动化的缺口：聊天很强，自动化在哪
本节摘要：本节讲 Jev 的来历。TypeSafe AI 是旧金山的一家 AI 实验室，创始人 Diogo Almeida 曾在 OpenAI 参与 ChatGPT 背后的研究，公司隐身两年、拿了 4000 万美元种子轮，2026 年 9 月 15 日随 Jev 一起出隐身。他们的出发问题很尖锐："模型在聊天上超越人类已经很多年了，那么自动化在哪里？"答案：聊天模型缺了一样自动化的根基性东西——软件需要的是能直接用的决策（一个布尔、一个枚举、一个分数、一个概率），而不是一段话。Jev 的定义由此而来："一次前沿智能的函数调用：非结构化状态进，类型化概率决策出。"
学习目标
阅读完本节，你应当能够：
- 复述 TypeSafe AI 的出发问题。
- 解释"聊天输出"与"软件需要的决策"之间的鸿沟。
- 说出现有 LLM 结构化输出方案剩下的两个未解问题（概率、成本延迟）。
一、出发问题
TypeSafe AI 官方发布博文的开场白，是创始人 Diogo Almeida（前 OpenAI，参与 ChatGPT 背后的研究）的提问：
"模型在聊天上超越人类已经很多年了，那么自动化在哪里？"
"Models have been superhuman at chat for years, so where is all the automation?"
按理说，"能看懂人话的智力"进入软件，就应该带来大规模自动化：工单自动分类、内容自动审核、风险自动分级、Agent 自动判断每一步该不该做。但现实中，这些判断要么还是人在做，要么用得很节制。为什么？
二、鸿沟：一段话 ≠ 一个决策
让 GPT 级模型回答"这封工单紧急吗"，你会得到一段诚恳的分析，运气好结尾带一句"综上，我认为比较紧急"。但软件要的不是这个：
| 软件需要 | 聊天模型给的 |
|---|---|
| 一个布尔值 | 一段含"虽然…但是…"的论述 |
| 一个枚举值（billing/technical/sales） | 可能是 billing，也可能是 "billing（偏技术）" |
一个能进 if p > 0.9 的概率 |
"我觉得大概率是计费问题"——没有刻度，不可比 |
| 每次调用 100ms、近零成本 | 3 秒到 5 分钟，按 token 计费 |
结构化输出（JSON schema、function calling）解决了"形状"问题，但没解决两件事：
- 概率：LLM 的 logprob 难以获取且未经校准——说 80% 把握的预测，实际可能只有 60% 正确率。没有校准的概率，就不能作为阈值判断的依据。
- 成本与延迟：逐 token 串行生成，天生慢而贵。把一个每条日志都要跑的判断放进管线，账算不过来。
三、Jev 的定义
于是 TypeSafe 给出的答案是一个新模型类别——System One 模型，Jev 是第一个。官方对 Jev 的定义：
"一次前沿智能的函数调用：非结构化状态进，类型化概率决策出。"
"A frontier-intelligence function call: unstructured state in, typed probabilistic decisions out."
三个关键词拆开看：
- 函数调用：它是软件的一个组件，不是对话伙伴。无状态、可缓存、可重试，像个永不宕机的"人类直觉"函数。
- 类型化：答案空间（布尔/枚举/等级）在请求里预先声明，模型在结构上不可能产出声明之外的值。
- 概率：每个答案附带经 RLCD 训练校准的概率（第 5 章展开），概率第一次成为可以作为工程契约的量。
💡 类比：LLM 像一位顾问，你问他问题，他给你一篇分析；Jev 像装在你代码里的一位资深值班员，你递给他一张单子（state）和一组勾选框（questions），他直接打勾，还告诉你每个勾的把握有几成。
本节要点回顾
- 出发问题：聊天超强，自动化缺位——缺的是软件可直接消费的决策。
- 鸿沟：形状问题被结构化输出解决了；概率（未校准）与成本延迟（串行生成）没解决。
- 定义：Jev = 非结构化状态进、类型化概率决策出的函数调用。
缺口找到了，定义也有了。但它为什么叫"Jev"这么个奇怪的名字，又为什么自称"系统一"？两个名字各藏着一个设计判断——下一节拆解。