Jev，让判断 进入程序

收到一封邮件，软件需要知道该交给售后还是销售；游戏里的守卫发现动静，需要决定继续巡逻还是过去查看。它们都不缺一段流畅的回答。程序正在等待一个能够接进下一步的结果。

Jev 是 TypeSafe 推出的决策模型。应用把当前材料与事先定义的问题交给它，它返回结构化的判断。开发者把这些材料称为 State，可以是一封邮件，也可以是一份游戏状态。返回值落在事先限定的范围里，程序据此进入对应的分支。

它提供三种问题。Choice 从候选中选择；Score 根据定义好的等级评分；Noul 给出一个说法成立的概率。它不负责续写文章，也不会生成一段新代码。比如判断客户是否在投诉之后，回复信仍然需要人工或生成模型撰写。

TypeSafe 把这一类模型称为 System One，借用了“快思考”的比喻。理解这个产品不需要接受整套认知类比。拿一个具体功能看，Jev 所占据的位置，就是材料进入软件以后、某个动作发生以前的那次判断。

“退款”两个字很容易匹配。“东西没问题，但我买错了，能寄回去吗？”却要求程序理解一句话。继续增加关键词，很快就会碰到反问和上下文。许多工作流因此停在这里，把判断交还给人。

生成模型已经能处理这类任务，也能通过结构化输出返回选项。区别不在于过去的软件完全做不到，而在于模型为哪种工作设计。一次只需作出选择的调用，是否有必要沿用生成长文本的整个过程？Jev 把这个问题单独拿出来做。

模型的等待时间会影响产品的形状。一个需要等几秒的判断，适合放在提交按钮之后；如果足够快，它才有机会参与用户正在进行的操作。游戏角色和不断变化的浏览器页面，对这一点尤其敏感。实际能否放进交互循环，还取决于网络和其他步骤的耗时。

更低的调用成本也可能改变使用频率。团队或许愿意给更多条记录做判断，或在一个动作之前多检查一个条件。这些是可以验证的产品假设。Jev 的意义需要落在这些原来不值得做、现在可能值得做的细小功能里，而不能只由发布页上的倍率决定。

一个传统的 Agent 提示词可能同时要求模型理解任务、选工具，再写出调用参数。结果不对时，很难分清它误解了目标，还是选错了工具。把可选动作明确列出来以后，其中一次选择就能独立留下记录。

Jev 让这种分工更适合写进普通程序。应用准备候选，模型判断，代码执行。候选不是固定不变的菜单；浏览器在新页面上可以重新提取按钮，游戏也可以按照当前局面更新可用动作。程序仍然负责告诉模型，此刻究竟允许做什么。

一次请求可以问多个独立问题。例如同一封工单的语言和所属部门，都能读取相同材料。它们不会自动共享彼此的答案。若判断是否超过退货期限需要先查订单，就必须等订单回来。并行能省去一些往返，不能替程序补出尚未取得的数据。

变化也发生在调试时。分类错误可以用原始输入与候选重新检查，执行失败则去看程序和外部服务。把判断从长段提示词里拆出来，会增加一些显式接口，也会给测试留下更窄、更具体的对象。

如果分类器只返回“售后”，程序很容易把结果当成事实。返回概率以后，应用可以保留一条复核路径。有些结果直接流转，另一些先停下来。自动化不再需要对每条输入作出同样强硬的承诺。

Choice 和 Score 会给出答案分布及从中计算的 confidence。分布集中，表示它更偏向某个答案，不能单独证明该答案正确。Noul 返回的是一个说法成立的概率，不带同样的 confidence 字段。

TypeSafe 的 RLCD 训练方法把概率校准列为目标。检查校准需要一批已知答案，观察相近概率的预测是否以接近的频率命中。一个小数写得再精确，也不能替代这项检查；业务数据换了一批，表现也可能跟着变化。

在资料排序中，一次判断失误可能只是把一条结果放错位置。若这个结果会触发取消订单，门槛就应当重新考虑。下面可以调整八条假设记录的处理门槛。自动通过的记录变少时，错误可能减少，但留给人工的工作也会增加。

Browser Use 的 Jev Ultrafast 已经把这套分工放进浏览器。页面元素先被整理成编号清单，Jev 选择动作和目标。需要填写自由文本时，另一个模型负责文字，浏览器负责真正的输入与点击。项目公开的操作记录比单独的演示计时更有价值，能看见每个选择发生在哪里。

Heist/One 是一个浏览器潜行游戏。Jev 参与守卫的判断，世界更新由确定性的代码控制。角色因此可以对局面作出语义层面的反应，而游戏不必把物理与规则一并交给模型。它仍是可观察的实验项目，不能据此推断复杂游戏中的稳定表现。

json-render 的实验从预设组件里组合界面。应用提供带属性与数据的候选，Jev 决定选择与布局。它不会凭空补出缺少的组件文案；只准备柱状图，也无法期待它选出折线图。这里的变化发生在组件的选用方式上，渲染和动作执行仍有各自的代码。

Jev Search 则把判断放进搜索过程，涉及来源选择、查询理解与相关性排序。真正取得网页的工作交给搜索服务。几个项目的外表差别很大，打开实现之后，都能指出 Jev 负责的具体环节。下方可以切换项目，查看这种分工。

设想一套处理工单的工具。以往只有提交之后才做一次分类，未来也许可以在附件到达、订单状态变化时重新判断该由哪个团队接手。这里需要的不是更长的回复，而是更新得足够及时的分派。是否值得这样做，可以用减少了多少等待和转单来衡量。

在界面里，也许不必为每一种业务状态手工搭建完整页面。设计师维护一组有边界的组件，应用根据当前材料选择组合。变化范围仍受设计系统限制，但同一套软件可以为不同任务显示更合适的内容。这条路需要先把组件候选准备好，不能靠模型替产品决定所有细节。

再往前看，生成模型与决策模型可能在同一项任务里交替工作。生成模型提出候选方案，决策模型按具体问题判断，程序决定是否执行。这样的分工可能让某些环节更容易测量，也可能因为多出调用而变慢。需要对照完整流程，而不是默认拆得越细越好。

这些方向还不能算成熟答案。一个有价值的实验，应当能说出新增的判断改变了什么行为。如果它只是让演示多显示一个概率，却没有改善用户完成任务的过程，界面里的那一位小数就没有带来多少东西。

发布时的速度与成本数字来自 TypeSafe 的评测。它们说明了一个值得尝试的方向，却不能直接成为所有应用的预算。比较采用哪些工作流、怎样取得参考答案，都会影响结果。官方也披露了团队设计任务和结构化包装等可能带来的偏差。

Jev 1.13 的已知问题包括算术、日期比较和噪声上下文。已经拿到两个日期时，用程序计算间隔更直接。若模型参与从叙述里识别日期，也应当让程序继续检查这个日期是否存在。

结构化输出还可能作出错误选择。编号合法的按钮可以是错的，取值范围正确的评分也可能排错优先级。模型没有越出输出类型，与它理解了业务事实，是两项不同的检查。

性能也要算到任务完成。若一次很快的判断触发了重试，计时不能停在首次返回；若每十条自动处理就需要人修正一条，修正时间也属于成本。只有完整路径的记录，才能解释这项改动究竟省了什么。

从一批历史工单开始，保留原来的处理结果，不接实际派单。定义候选团队，给无法确认的输入留一个复核出口。使用中的工具、已有规则与 Jev，可以在相同材料上比较。

把一部分记录留到最后验证，不参与候选描述的调整。否则，反复改提示词之后得到的提升，可能只是在记住那一批例子。错误多的类别应该单独看，避免总体数字掩盖了很少出现却代价很高的情况。

等到判断质量与等待时间都能接受，再把它接进执行分支。权限和结果检查仍留在代码里。运行一段时间后，保留少量人工抽查，检查新输入有没有离开最初的样本范围。

一次模型调用很快就会结束，候选菜单的维护却会继续。客户会换一种表达，团队也会新增业务。后来新增一个业务部门，最初那张候选菜单也要重新打开。