从六条工单实测看 Jev：如何把模糊语义变成可控程序分支

把大模型接进业务后，我越来越在意一个问题：系统究竟需要模型生成内容，还是只需要它补一个普通代码难以完成的语义判断？

TypeSafe AI 的 Jev 选择了后者。它不写自然语言答案，而是接受一份 state 和若干预定义问题，返回 Choice、Score、Noul 以及相应概率。外围代码负责业务流程、确定性检查和最终动作。

本文不把它当作聊天模型的新版本，而从程序设计角度看这种接口怎样拆职责。

从“让 AI 处理”退回到具体问题

假设输入是：

我被扣了两次钱，请今天退回多扣的一笔。

一句“让 AI 处理这条工单”包含了太多不同责任。拆开后至少有三件事：

1. 用户主要诉求属于哪个队列？
2. 客服介入的紧迫程度有多高？
3. 用户是否明确提出退款？

第一项适合 Choice，第二项适合有序的 Score，第三项适合 Noul。三个问题都读取同一条消息，可以一起求值；订单是否真的重复扣费，则必须读取交易数据，放在后续确定性流程。

这种拆法让每个判断都有明确输入、候选范围和失败去向。少写几个 token 只是附带收益。

三种原语对应三种语义

Choice 从无顺序的固定集合中选一个，返回完整概率分布和 confidence。候选项应该写清边界并包含无匹配出口，否则类型再安全，也会把输入硬塞进错误分类。

Score 在一组有顺序、可独立理解的等级上评分。返回的小数是等级编号按概率加权的结果。它的含义来自等级定义，不是客观测量值。

Noul 判断一个明确命题为真的概率。接近 0.5 表示 yes 和 no 难分，不表示程度居中。需要表达强弱时应使用 Score，而不是把 Noul 当滑杆。

Choice 和 Score 的 confidence 从概率分布形状归纳而来。分布集中时 confidence 较高，分布分散时较低。它不是业务正确率，也不是执行动作的授权。

独立问题可以一起问，依赖步骤仍要分层

Jev 在一个请求里共享 state，对各个问题独立求值。这很适合提前计算后续分支可能用到的判断，再由代码决定采用哪一项。

但是，如果第二步依赖第一步查出的新数据，就必须继续分层。例如：先识别订单号，再查支付库，最后判断是否重复扣费。模型接口再快，也不能替代不存在的事实。

我会把整个流程画成四层：

原始状态
  ↓
语义判断（Choice / Score / Noul）
  ↓
确定性数据和规则校验
  ↓
执行、确认或人工复核

这样做还有一个好处：即使未来更换模型，交易规则和执行代码也不必跟着重写。

六条样本看到的边界

我在 2026 年 9 月 20 日使用 Node.js v22.21.1、@typesafe-ai/sdk@0.6.0 顺序发送六次真实请求。每次包含路由、紧迫度和明确退款三个问题；jev-latest 六次实际返回的版本都是 jev-1.13.0。

中英文重复扣费样本都路由到退款，明确退款的 Noul 概率为 0.99；两条明确否定退款的样本为 0.03。

真正值得保留的是模糊输入：

昨天那个事情，能否帮忙处理？

它给 other 0.70、support 0.30，route confidence 为 0.54。示例策略在 confidence 低于 0.8 时返回 human_review，因此不会自动采用结果。

这不是在证明 0.8 是正确阈值。它只展示概率怎样进入代码。真实阈值需要根据人工标签、误判代价和回退成本调整。

计时同样只做记录：第一条 1962.02 毫秒，后五条 744.75–823.44 毫秒。数据包含网络往返和响应解析，无预热、无重复统计、无对照模型，不能单独证明官方倍率或冷启动原因。

和结构化输出大模型怎样分工

通用大模型已经可以可靠地按 schema 输出 JSON，所以 Jev 的价值不能只归结为“不会写错括号”。

当任务既需要判断，又要生成解释、方案或代码，通用模型依然合适。当流程只需要大量固定候选判断，并希望原生拿到概率、统一做风险分流时，专门接口更有吸引力。

两者也可以组成级联：Jev 先处理高频、低风险判断；低置信或复杂样本再交给推理模型或人工。这样能把昂贵能力放在真正需要的位置，同时保留规则和人工兜底。

我会保留的工程约束

• 记录版本化 model ID，不只记录 jev-latest；别名升级后答案可能变化。
• 用自己的中文数据做验证。官方说明英语是主要训练语言，中文并非同等表现。
• 为候选缺失、低置信和独立信号冲突设置明确回退。
• 高风险动作继续读取真实数据并请求用户确认，模型只提供语义信号。
• 把原始概率保存为可复盘数据，执行策略和阈值写在代码里。

安装 TypeSafe Agent skill 只是让 Coding Agent 知道怎样写这套接口，不会把 Jev 下载到本地，也不能用 Jev 替换聊天或代码模型。

这次实验让我最认同的一点，是先把“智能”收窄。程序越清楚地说明哪一步需要判断、哪一步必须查事实、哪一步需要授权，AI 就越容易成为可维护的依赖，而不是另一块模糊状态。

如果是你来接入，会先选路由、评分，还是输出复核作为第一个低风险场景？

资料入口：System One 与 Jev 发布说明、Primitives、Confidence、Models。完整实验与下载见原博客文章。