今天的软件，正在做一件有点奇怪的事情。

假设一个客服系统收到一句话：

“我的付款连续失败三天了，能不能赶紧帮我处理？”

程序想知道的，无非是几个问题：

这件事紧不紧急？

应该转给 Billing、Technical 还是 Sales？

这个用户有多生气？

现在常见的做法，是把整段文字交给 GPT、Claude 这样的语言模型，让它分析几秒钟，生成一段自然语言或者 JSON。

最后，程序把大部分内容扔掉，只留下：

billing

或者：

true

或者：

8/10

我们调用一个能够写代码、写文章、讨论哲学的大语言模型，生成几十上百个 token，最后只为了得到一个 if 语句需要的答案。

TypeSafe AI 想把这套流程缩短。

他们刚刚发布了一个叫 Jev 的模型。

它不需要和人聊天，也不负责替人写代码。

它的任务，是直接给软件提供判断结果。

TypeSafe 把 Jev 称为一种 System One Model。

这个名字借用了《Thinking, Fast and Slow》里的 System 1 / System 2：一种快速、直觉式的判断系统，对应另一种更慢、更复杂的推理系统。

理解 Jev，不需要记住这套概念。

可以把它看成：

一个带有大模型语义理解能力的函数。

传统 LLM 的接口大概是：

文字 → 模型 → 文字

Jev 的接口更接近：

状态 + 问题 → 模型 → 判断 + 概率

比如，输入一段用户反馈后，程序可以同时问它：

这个问题是否紧急？

应该分到哪个部门？

用户的情绪有多强烈？

Jev 可以直接返回：

department = billing

同时告诉程序：

billing 的概率是多少，technical 的概率是多少，sales 的概率又是多少。

这里很容易产生一个误解：既然 Jev 是“为代码使用”设计的，它是不是另一个 Codex 或 Claude Code？

两者处理的是完全不同的问题。

Codex、Claude Code 这类模型接收人的需求，然后生成或修改代码；Jev 面向的调用者就是运行中的程序。程序把当前状态交给它，再拿回一个可以直接进入下一步逻辑的判断结果。

所以，“给代码用的 AI”在 Jev 这里，指的不是帮程序员写代码。

它更接近于：让代码可以直接调用一种语义判断能力。

看到这里，你可能会觉得：

这不就是分类器吗？

某种程度上，确实是。

分类器早就存在几十年了。

垃圾邮件过滤、信用卡反欺诈、广告排序、推荐系统，背后到处都是 classifier、ranker 和 scorer。

Jev 想处理的是一个更宽泛的问题：

能不能把大语言模型获得的通用语义理解能力，变成一个便宜、快速、可以被软件高频调用的判断函数？

过去几年，我们逐渐习惯了一个前提：

AI 的输出应该是语言。

ChatGPT 是给人用的。

人提出问题，模型返回文字。

整个 LLM 技术栈的基本单位也因此变成了 token。

可软件本身并不需要大量自然语言。

软件更喜欢：

boolean。

enum。

float。

object。

函数返回值。

程序想知道的通常是：

refund_intent = 0.91

或者：

dangerous = true

于是，今天的 AI 工程里出现了大量适配工作：

要求模型输出 JSON。

规定 JSON Schema。

做 constrained decoding。

解析失败以后 retry。

再做 validator。

防止模型突然多说一句：

“Sure! Here is the JSON you requested.”

这些技术都很成熟，也确实解决了很多问题。

Jev 直接把问题提到了接口层：

如果最终使用答案的是程序，模型是否有必要先生成字符串？

这里讨论的是 AI interface。

传统软件最擅长确定性的规则：

if amount > 10000: manual_review()

现实世界里，大量问题很难写成这么清晰的规则。

比如：

这封邮件是不是在威胁取消订阅？

这段对话需不需要转人工？

这个搜索结果到底相关不相关？

Agent 下一步准备执行的操作危险吗？

这个 bug 应该归到哪个模块？

这些问题，人通常很快就能做出判断。

但你很难把整个判断过程写成几十条稳定的程序规则。

LLM 出现以后，这类模糊判断可以交给模型处理。

代价也很明显：速度慢、成本高，而且每一次判断都可能变成一次完整的文本生成。

Jev 想进入的，就是这片区域。

它更像：

一个带语义理解能力的 if。

对于 AI Agent，这种能力很容易找到用武之地。

一个 Agent 真正执行任务时，并不会只调用一次 AI。

它可能不断判断：

下一步调用哪个工具？

这个搜索结果够不够好？

页面上应该点击哪个按钮？

当前动作是否危险？

要不要继续搜索？

要不要升级到更强、更贵的模型？

如果每一个小判断都调用一次完整大模型，再等待几秒钟，Agent 很难真正变成实时软件。

TypeSafe 目前公开的信息显示，Jev 并非简单给一个小语言模型套上 JSON Schema。

他们宣称自己设计了新的模型架构、parallel sampler，以及一种叫 RLCD——Reinforcement Learning for Calibrated Decisions 的训练方法。

Jev 不需要像普通 LLM 一样，一个 token 一个 token 地生成完整字符串。

它可以直接针对几个结构化问题输出判断。

TypeSafe 公布的延迟大约在几十到几百毫秒之间，价格则明显低于主流生成模型。

官网还给出了两个非常吸睛的数字：

193.6 倍更快。

444.6 倍更便宜。

这两个数字需要谨慎理解。

TypeSafe 自己也承认，它们来自内部设计的 workflow eval，而且这些收益很可能处在真实使用场景的较高区间。

第三方测试给出了一些更现实的数据。

Nexus Agent 用 1.9 万多个真实 Agent 场景，跑了 3.6 万多次 Jev 调用，中位延迟大约 0.68 秒，95% 的请求在 1.79 秒内完成。

这和官网展示的最佳延迟存在明显差距。

即便如此，这个量级对于大量结构化判断任务来说，仍然具有吸引力。

至少从现有结果看，Jev 的速度优势已经开始在官方 Demo 之外得到一些验证。

TypeSafe 对 Jev 有一个很容易传播的宣传点：

Zero Hallucinations。

这句话需要加上限定条件。

Jev 当然会答错。

比如，允许答案只有：

billing

technical

sales

Jev 不会突然回答：

customer_happiness_team

也不会返回 Markdown，更不会给你写一首诗。

它可以保证：

输出一定符合预先定义的类型。

但“类型正确”和“判断正确”是两回事。

Jev 完全可能非常合法地回答：

billing

而正确答案其实是：

technical

更准确的描述是：

Jev 可以消除大量输出格式错误，但无法消除判断错误。

概率也因此成为 Jev 设计里的关键部分。

自动化系统很难处理的一种情况，是模型出错时没有可靠的预警信号。

假设一个模型准确率 95%。

听起来已经很高。

但如果那 5% 的错误和另外 95% 一样自信，系统依然很难把决策完全交给它。

TypeSafe 把“概率校准”放进了 Jev 的核心设计里。

Jev 不只返回：

billing

它还可以返回每个选项对应的概率。

这样，程序就可以自己决定：

置信度高于 0.95，自动执行。

0.7 到 0.95，交给更强的模型再检查一次。

低于 0.7，交给人工。

如果这种概率足够可靠，未来 AI 系统可能会形成更细的分工：

简单、高频的判断交给 Jev 这类模型。

复杂、低频的推理再交给更强、更贵的 reasoning model。

系统可以根据任务难度和模型信心动态分配算力与成本。

Jev 放弃文本生成，也给自己划出了明确的能力边界。

它不能替你写一篇文章。

不能根据模糊需求生成一个完整 App。

也不适合独立完成几十步复杂推理。

一个更现实的图景是：

同一个 AI 系统里，同时存在不同类型的模型。

大型 reasoning model 负责：

规划、推理、写代码、生成内容。

Jev 这类模型负责：

分类、路由、打分、判断、验证、风控。

这更接近成熟软件系统的组织方式。

我们从来不会要求数据库、浏览器、编译器、GPU 全部用同一种计算范式解决所有问题。

过去几年，很多“智能问题”被统一交给了通用大语言模型。

Jev 提供了另一种路线：

AI stack 也可以逐渐专业化。

TypeSafe 的创始人 Diogo Almeida 曾参与 OpenAI 的 InstructGPT 和 GPT-4 工作。

这段经历，让 Jev 的方向显得颇有意思。

InstructGPT 关注的问题之一，是：

怎样让语言模型更好地按照人的要求说话？

Jev 换了一个使用场景：

当 AI 的主要调用方是代码时，什么样的输出形式最合适？

程序不需要礼貌。

不需要 Markdown。

也不需要“下面是我的分析”。

它通常只需要：

true

billing

0.87

以及：

模型对这个结果有多大把握。

Jev 讨论的不只是速度。

它把注意力放到了一个更基础的问题上：

AI 和软件之间，接口应该长什么样？

过去几年，我们一直在通过 structured output、function calling、JSON mode、tool use、validator 等方式，让语言模型更适合软件调用。

Jev 选择的是另一条路径：

从模型设计阶段，就把软件需要的返回值考虑进去。

现在判断 Jev 会不会成功，还太早。

TypeSafe 没有公开足够完整的架构细节，我们也还没看到可以独立审查 RLCD 的完整研究论文。

目前最漂亮的 benchmark 很大程度上仍然来自 TypeSafe 自己。

第三方测试刚刚开始，样本和任务类型都还有限。

Jev 目前也处在 early access 阶段。

但它提出的问题很清楚。

如果未来 AI 系统继续变复杂，我们大概率不会只依赖一个万能模型完成所有工作。

整个 stack 可能逐渐分成不同的计算原语：

有的负责生成。

有的负责推理。

有的负责搜索。

有的负责判断。

有的负责验证。

Jev 想成为其中高频、低成本、可以直接嵌入程序控制流的那一部分：

一个带有语义理解能力的判断函数。

它最适合进入的地方，可能就是程序里那成千上万个：

if (...)

尤其是那些因为现实世界太模糊、太复杂，人类一直不知道括号里面该怎么写的 if。