重新理解 Jev：把语义判断变成软件能力

Sep 25, 2026 — AI , LLM , Jev , RLCD

Jev 为什么火起来了？

9 月 15 日 Diogo Almeida 在 X 网站发布相关帖子，不到一个小时就推送到我的信息流里。

老实说第一天关注的人不多，但是回顾整个时间线，有以下关键因素驱动着 Jev 爆火：

创始人背书 + 反差定位：“前 OpenAI 研究员”、“ChatGPT 核心贡献者”、“不再做Chat模型、只做决策”，在大家都在聊谁家的 LLM 更厉害时，突然出现这么个玩意。
极致速度与成本：输入收费，输出免费，毫秒级低延时，适合 Agent / 自动化中海量高频小决策（路由、分类、打分、下一步动作）。
平台快速接入：Vercel 第一天就接入，OpenRouter 第二天接入，大大降低了尝试门槛，不用等官方的 waiting-list。
概念清晰且互补：不与 GPT/Claude 正面竞争，而是补齐 Agent 工作流里最缺的“低延迟决策控制层”，契合当下开发者痛点。
社区自强化：游戏、浏览器、广告分析、航班查询等演示视频又快又准，太有视觉冲击力了，传播效率高。从英文核心圈快速扩散到中日等社区，出现聚合站、长文拆解、二次创作，形成正反馈。

我自己的第一印象，只是简单的把它理解成一个小小的“分类模型”：输入一段文字，然后返回一个分类、概率或者分数。

9 月 18 号，我在项目组的技术群里分享了一段话，那时候我还没有自己上手验证，抛砖引玉一下：

这两天新出的 jev 模型挺火的，速度超快，费用低，不同于 System Two 的大模型，它是 system one 的直觉型小模型，并行约束解码，不是一个个 token 的生成，适合分类、路由、评分、判断这些需要语义直觉但不需要长篇大论的决策，初看挺适合客服会话场景

但真正拿它做了一些 Demo，结合 TypeSafe 创始人的访谈之后，我感觉自己对这个模型的理解有点肤浅了。尤其是高强度用了几天 Jev 之后，我认为这个小模型还是有点意思的。

Jev 最大的魅力是它在尝试回答一个问题：大模型的智能，怎么才能真正成为软件的一部分？

过去几年，LLM 厂商们的重心都放在聊天和推理上，取得了难以置信的发展。如今，整个行业（其实也就御三家+国产模型😅）基本上每个月都有新模型发布。

但是，Jev 走的是另一条路：让 AI 更适合被代码调用。

从 Pre-training、RLHF、RLVR 到 RLCD

回顾一下这几年 LLM 的发展历程，大概经历了几个重要阶段。

首先是 Pre-training，也就是预训练。

预训练（Pre-training）：让模型大量学习互联网、代码、书籍等数据，通过预测下一个 Token 学会语言、知识和各种模式。

今天大模型能够理解语言、写代码、掌握大量知识，基础能力主要来自这里。

之后是 RLHF。

RLHF（Reinforcement Learning from Human Feedback）：利用人的反馈继续训练模型，让它更懂人的指令，也更容易给出符合人类预期的回答。

这一步让模型从一个强大的文本续写器，逐渐变成今天我们熟悉的 ChatGPT。

再往后是 RLVR。

RLVR（Reinforcement Learning with Verifiable Rewards）：利用可以明确验证的结果训练模型，例如数学答案是否正确、代码测试是否通过。

数学和 Coding 很适合这种训练，因为结果可以验证。模型可以不断尝试和推理，再通过奖励把有效的路径强化下来，这也推动了今天推理模型的发展。

TypeSafe 在此基础上探索的是另一种后训练方向，他们把它叫做 RLCD。

RLCD（Reinforcement Learning for Calibrated Decisions）：通过强化学习，让模型输出更加稳定、经过校准的决策概率。

这里最关键的词是 Calibrated，也就是“校准”。

什么叫校准？比如一个模型连续做很多次判断，每次都说“我有 80% 的把握”。如果长期来看，这些判断真的大约有 80% 是正确的，那么这个 80% 才有实际意义。

所以这几个方向可以简单理解为，RLHF 主要解决模型能不能按照人的意图完成任务，RLVR 主要解决模型能不能完成可以验证的复杂问题，而 Jev 想进一步解决的是：一个判断能不能足够稳定，以及它给出的概率到底可不可信。

这也是理解 Jev 的第一个关键点。

Jev 的主要消费者是代码

我们现在使用大模型，通常是用户写 Prompt，模型返回自然语言，再由用户阅读和判断。

Jev 更强调 Machine Native。

Machine Native：模型的输入和输出首先考虑机器如何消费和使用。

也就是说，模型最终服务的对象可以直接是程序。

程序很多时候不需要几百字解释，它需要的是这种结果：

0.83

refund

Yes: 0.91

拿到这些结果以后，代码就可以继续执行后面的业务逻辑。

这也是 Jev 和我们平时使用 ChatGPT 很不一样的地方。ChatGPT 更擅长把结果组织成人能理解的内容，Jev 则希望把模型的判断能力直接接进代码。

System One 和 System Two

TypeSafe 把 Jev 定义成一种 System One Model。

System One：快速、直觉式的判断能力。

比如有人突然朝你扔一个球，你通常会下意识伸手去接，不需要先计算速度、角度和运动轨迹。

相对应的 System Two，则更接近需要多步骤分析和推理的能力。

比如排查一个生产环境 API 偶发超时的问题，你可能需要看日志、检查调用链、分析数据库和网络，再修改代码并运行测试，整个过程依赖很多中间结果。

过去几年，推理模型在强化的主要就是这种 System Two 能力，而Jev 处理的是另一类问题。

例如：

这封邮件有多紧急？
这个客户现在是不是很不满意？
这条工单应该属于物流、退款还是售后？
这个用户有多大流失风险？

这些问题同样需要语言理解，但通常不需要连续推很多步。模型读完输入以后，基本可以直接形成判断。

这类问题可以叫 Single-hop。

Single-hop：看到输入以后，可以比较直接地得到结果，不依赖很多中间推理步骤。

一个 Coding Agent 则更接近 Multi-hop，因为它需要理解需求、分析代码、定位问题、修改实现、运行测试，再根据结果继续调整。

所以我现在更倾向于把 Jev 和推理模型看成两种互补能力：Jev 强化快速判断，推理模型负责复杂推理。

Jev 和传统分类模型有什么区别？

Jev 的 Choice、Score 这些输出形式，很容易让人想到传统分类模型。

但传统分类模型一般会针对某一个任务单独准备数据和标签，然后训练专门的模型。比如垃圾邮件分类可能只有：

spam
not_spam

如果需求换成客户流失预测，通常又要重新准备相应的数据和模型。

Jev 的底层能力来自经过大规模预训练的模型，语言、知识和通用语义理解能力已经存在。TypeSafe 在这个基础上继续训练，把重点放到稳定判断、概率校准和程序化调用上。

所以分类只是 Jev 的一种输出形式，它真正想提供的，是一层可以让软件反复调用的通用语义判断能力。

传统代码最擅长明确规则：

if (age >= 18) {
  allow();
}

麻烦的是现实世界里还有大量很难量化的问题，比如客户是否生气、邮件是否紧急、退款是否可疑、内容是否存在风险。

你当然可以继续写规则：

if (
  email.includes("very angry") ||
  email.includes("terrible")
) {
  urgency = 0.9;
}

但真实语言的表达方式太多了，规则很快就会失控。

现在可以换一种写法：

const urgency = await jev.score(email);

if (urgency > 0.8) {
  notifyManager();
}

这里最重要的是职责划分：模型负责语义判断，代码负责业务规则。

例如，0.8 以上通知主管，0.6～0.8 进入人工队列，0.6 以下正常处理。这些规则依然由程序员控制，模型只负责回答“这封邮件到底有多紧急”。

这也是我觉得 Jev 很有工程价值的一点。

很多 AI Agent 现在会把大量业务规则塞进一个 System Prompt，让模型同时负责理解、判断和决策。项目复杂以后，很容易出现奇怪结果，而且很难知道问题到底出在哪。

Jev 的思路更接近传统软件工程：把一个大的决策拆成多个更小、更明确的语义判断。

例如：

IsFraudRisk(user)

IsPolicyViolation(user)

IsHighValueCustomer(user)

IsRefundEligible(order)

然后由业务代码组合这些结果：

if (
  fraudRisk > 0.9 ||
  policyViolation > 0.85
) {
  reject();
}

这样模型的职责更小，业务逻辑也更显式，更容易控制、调试和验证。

Choice、Noul 和 Score

Jev 提供的输出形式也体现了这种设计。

Choice：从几个候选项中选择一个。

例如：

物流
退款
售后
商品咨询

Noul：针对一个 Yes / No 判断，返回 Yes 的概率。

例如：

Yes: 0.87

Score：针对某个属性返回一个连续分数。

例如：

0.76

这些输出看起来很简单，但非常适合程序。Choice 可以决定分支，Noul 可以和阈值结合，Score 可以用于排序、筛选和策略判断。

程序真正需要的很多时候就是一个可以继续计算的值。

举个栗子：客服 Agent

客服 Agent 其实很适合拿来理解 Jev，因为一个完整的客服流程里，存在大量看起来简单、实际又很难完全靠规则写清楚的判断。

比如一条用户消息进来以后，系统往往需要先判断：用户在问物流、退款还是商品问题，有没有多个诉求，情绪是否激烈，问题是否紧急，要不要转人工，当前消息和前面的会话是不是同一个主题。

这些判断单独看都不复杂，但它们会直接影响后面的 Workflow 怎么走。

假设一个用户发来这样一条消息：

包裹已经晚了十天，我不想要了，把钱退给我，你们客服一直没有解决这个问题。

如果直接交给一个通用 LLM Agent，很容易把所有事情都塞进同一个 Prompt：让模型判断用户意图、订单问题、情绪、退款资格、是否转人工，然后直接决定下一步做什么。

Jev 更适合把这些问题拆开，先得到几个独立的语义判断：

intent.refund = 0.96
intent.logistics = 0.82
customer_frustrated = 0.91
urgent = 0.76
needs_human_review = 0.68

这些结果本身还不会触发退款，它们只是给程序提供判断信号。

接下来，业务代码再去查询真实订单和平台规则：

if (refundIntent > 0.8) {
  const order = await getOrder(orderId);
  const policy = await checkRefundPolicy(order);

  if (policy.requiresApproval) {
    createApprovalRequest();
  }
}

这样职责就很清楚了：

Jev 负责语义判断： 用户主要想解决什么问题、情绪有多强烈、是否出现了升级处理的信号。
业务代码负责规则： 什么阈值进入哪个 Workflow、退款要满足哪些条件、什么时候必须审批、什么情况需要转人工。
推理模型负责复杂处理： 当问题需要查询订单、读取物流轨迹、结合知识库和历史会话继续分析时，再交给更擅长多步骤推理的模型处理，最后生成符合用户语言和当前场景的回复。

对客服系统来说，这种拆法有一个很实际的好处：出了问题以后更容易知道到底是哪一层出了错。

如果用户明明在申请退款，refundIntent 却很低，可以直接检查语义判断。如果判断结果没问题，但系统走错了 Workflow，就去检查业务规则。如果路由和数据都正确，最终回复还是有问题，再去看推理模型和生成逻辑。

这比把所有逻辑全部塞进一个 System Prompt 更容易控制和调试。

多轮会话

客服场景还有一个很常见的问题：用户的诉求会随着会话变化。

比如用户第一天问：

我的包裹到哪里了？

系统当前记录的会话状态可能是：

current_topic: logistics
order_id: xxx
logistics_status: delayed

第二天用户又发来：

已经这么久了，我不要了，给我退款。

这时候真正发生的变化，是用户已经从物流查询转到了退款。

Jev 可以针对新消息和当前会话状态做判断：

topic_changed = 0.94
new_topic = refund
customer_frustrated = 0.88

程序再根据这些结果更新 Conversation State。

这里有一个很重要的工程边界：会话状态应该由系统维护，Jev 负责判断新的输入对当前状态意味着什么。

订单号、物流状态、历史工单、当前 Workflow 这些都属于系统里的事实数据，不应该依赖模型自己“记住”。模型更适合处理那些程序很难直接判断的语义变化。

退款、取消和转人工

像退款、取消订单这类操作，风险会更高一些。

如果直接让模型做最终决定，整个业务行为会过度依赖模型的一次判断：

if (await ai.shouldRefund(message)) {
  refund();
}

实际上，退款是否成立通常还取决于订单状态、物流信息、平台规则、金额、平台政策，甚至人工审批。

Jev 更适合提供这些语义信号：

refund_requested = 0.98
customer_claims_item_not_received = 0.93
customer_frustrated = 0.87
possible_policy_exception = 0.61

程序再把这些判断和真实业务数据组合起来，决定是否进入退款流程、是否需要补充信息、是否创建审批任务。

转人工也是一样，系统完全可以分别判断，然后由代码决定哪些条件组合起来需要转人工：

customer_frustrated = 0.92
repeated_failed_resolution = 0.86
possible_fraud = 0.18
policy_exception = 0.71

这种方式比直接问模型一句“要不要转人工？”更容易知道具体发生了什么，也更方便调整策略。

如果以后业务发现“高价值客户遇到连续两次处理失败时应该更早转人工”，修改的是业务代码和阈值，不需要重新把整个判断逻辑揉进一个巨大的 Prompt。

真正复杂的问题交给推理模型

当然，客服里也有很多问题已经超出了 Single-hop 判断。

比如用户说：

我的包裹一个星期没有更新，昨天客服说已经发出了，但物流公司说根本没有收到，我下周就要出国，现在应该怎么办？

这个问题需要先查订单，再查物流轨迹，确认仓库状态，读取平台规则，可能还要结合用户之前和客服的沟通记录，最后才能决定应该解释、催物流、补发、退款还是转人工。

这种任务更适合推理模型。

Jev 可以先判断：

intent = logistics_issue
requires_order_lookup = 0.98
requires_complex_resolution = 0.91
customer_frustrated = 0.84

业务代码看到 requires_complex_resolution 很高，就把后面的任务交给 Agent。Agent 再调用订单、物流和知识库工具，完成多步骤处理。

所以在一个完整的客服 Agent 里，可以形成这样的分工：Jev 做快速语义判断，业务代码控制 Workflow，推理模型解决复杂问题。

回复判断

Jev 的位置也不一定只在消息进入的时候。

推理模型生成最终回复以后，还可以再做一些简单检查，例如：

language_match = 0.99
customer_question_answered = 0.95
unresolved_intent = 0.08
policy_risk = 0.04

这些结果可以帮助程序判断回复是否需要重新生成、是否应该进入人工检查，或者是否还有用户问题没有处理。

不过这里也要注意边界。

这些分数只能说明模型对回复的判断，不能证明订单信息、退款资格或者物流状态一定正确。涉及真实业务事实的内容，最终还是要回到数据库、API、规则系统或者人工审批来验证。

所以我现在觉得，Jev 在客服 Agent 里最合适的位置，就是自然语言和确定性程序之间。

用户输入的是模糊的自然语言，Jev 把它转换成程序可以使用的判断信号，业务代码再根据真实数据和明确规则决定下一步动作。遇到需要复杂分析的问题，再交给推理模型。

这样拆开以后，一个客服 Agent 可以很自然地分成三层：

Data
订单、物流、商品、客户资料、会话状态

Logic
退款规则、审批规则、路由规则、阈值、Workflow

Intelligence
意图、情绪、风险、优先级、主题变化、语义判断

这三部分的边界清楚以后，Jev 在整个系统里的位置也就很明确了。

Smart Software

把前面的客服 Agent 拆开以后，其实可以看到一种很清楚的软件结构。

过去的软件大致可以理解成：

Software = Logic + Data

代码负责规则和流程，数据库负责保存事实和状态。遇到“这个客户到底有多生气”“这句话到底是在咨询还是投诉”这类问题时，传统程序往往很难直接处理，只能继续堆规则，或者交给人工。

现在软件里开始多出第三种能力：

Software = Logic + Data + Intelligence

这里的 Intelligence，可以理解成处理模糊语义的能力，例如：

理解
判断
打分
分类
排序
预测

我觉得 Jev 真正有意思的地方就在这里：它尝试把这些能力做成软件内部可以直接调用的 Intelligence Primitive。

Primitive：可以被其他代码反复组合和调用的基础能力，可以把它理解成软件系统里的基本构件。

函数、数据库查询、HTTP 请求已经是我们很熟悉的软件能力。以后，“判断这条消息有多紧急”、“识别用户当前的主要诉求”、“判断一段内容是否存在风险”，也可能变成同样普通的程序能力。

这样看 Jev，会比把它理解成一个分类模型更准确。它想解决的，是怎么把预训练模型已经拥有的语义能力变成软件可以长期使用的一部分。

代码继续处理确定性的逻辑，数据继续提供事实和状态，模型补上那些过去很难直接编码的判断。

这就是我理解的 Smart Software。

总结

你要说 Jev 有多少创新性，倒也未必。这条技术路线一直有人在探索，第二天甚至就出来了抄袭争议 😅，只是 Jev 恰好在这个时间点火了。

对我们这些应用开发者来说，我觉得 Jev 的核心价值可以总结成一句话：

把 LLM 已经拥有的语义理解能力，变成稳定、可校准、可以直接进入程序逻辑的判断能力。

到了工程侧，Jev 更适合和推理模型组合使用。单独依赖 Jev 的场景不会很多，它擅长的是快速、直接的语义判断，复杂问题还是要交给推理模型处理。

Jev 做快速判断，程序控制流程，推理模型解决复杂问题。这种组合其实很接近我们熟悉的软件架构：每一层只负责自己擅长的事情，模型能力也不会混成一个巨大的黑盒。

对应用开发者来说，这可能才是 Jev 最实际的价值。我们不需要重新发明一套软件工程方法，而是可以把 AI 能力放进原来已经熟悉的架构里，让它承担过去很难写进代码的那部分语义判断。