Jev 爆火之后，给企业应用配一个 AI 决策模型

9 月 15 日，旧金山公司 TypeSafe AI 结束两年隐匿期，开放了一个叫 Jev 的模型。发布当天，它冲上 Hacker News 千分级热度；24 小时内，近 13% 的 Vercel 付费团队用上了它，Vercel 称这是其 AI Gateway 历史上被采纳最快的模型，超过了此前所有发布。一周内，Cloudflare、LangChain、Langfuse 相继集成，国内券商出了专题研报。

一个不聊天的模型，为什么能刷成这样？因为它盯上的那层需求，恰好是 AI 应用里最费钱的暗账。而在它身后，一场开源复现潮已经起来------OpenJev（现名 SemIf）是其中热度较高的一个。围绕这条路线，葡萄城技术团队做了一次验证：把「读概率、不生成文本」的开源决策模型部署到服务端，用活字格的服务端命令发起调用，接进业务流程。这篇文章把 Jev 的来龙去脉、开源复现的现状和这条落地链路一次讲清楚。

Jev 是什么：一个拒绝聊天的模型

Jev 的定位用一句话讲清：只做判断，不做表达。

传统大模型无论问什么，都走同一条路------逐字生成一段文本，程序再从文本里解析出结果。Jev 把这条路的后半段砍掉了：开发者预先声明问题与选项空间（选择、评分、是否），模型基于输入状态直接返回结构化结果和概率分布，全程没有文本生成。因为答案只能落在预先定义的输出空间里，它结构上给不出格式错误------官方称其在结构化输出与工具调用场景的错误率为 0%，作为对照，前沿模型通常在 0.5% 以上。

TypeSafe 把它叫作「System One」模型，借的是卡尼曼的快慢思维框架：快系统负责高频直觉判断，慢系统负责深度推理。国内有券商研报给了一个更形象的比喻------给 Agent 装上「小脑」。名字本身也有典故：Jev 取自经济学家杰文斯（Jevons），暗合杰文斯悖论------智能的使用成本暴跌，智能的用量会暴涨。

数字层面，官方口径是：端到端响应 70 到 500 毫秒（前沿模型通常 3 秒以上）；输入每百万 token 0.042 美元，输出免费（因为输出本来就只有几个结果值）；在官方的工作流评测里，比大模型快 20 到 200 倍、便宜 40 到 400 倍。官方演示里有个直观例子：给一批客服消息打标，Jev 用了 2.3 秒、约 0.1 美分，同样的活儿交给聊天大模型要 20 秒。

这些数字都来自 TypeSafe 自己，当上限参考就好。但它刷屏的真正原因，藏在下一节。

它戳中的是 Agent 的账单

一个 AI 应用的开销，大头往往落在大量细碎的判断上：这条消息是投诉还是咨询、该调哪个工具、这步操作有没有风险、要不要重试、工单派给谁。这些判断一天发生成千上万次，每一次都要大模型写一段文字才能得出结论------等于雇了一个作家来做收发室的活。

Jev 做的事，是把这层高频小判断从大模型身上剥出来，交给一个便宜的专用层。快慢分工：贵的模型管慢思考，轻的决策模型管快判断。这个分工逻辑对做企业应用的人来说一点都不陌生------它解决的问题，就是业务系统里最常见的「高频小判断」。

门槛也在明面上

Jev 是闭源托管服务，走 API 调用。对企业落地来说，有几道现实门槛：判断请求和数据要出网；按调用量付费；按央广网报道，该服务尚未向中国大陆地区开放。

于是开源社区的反应很快------发布三天后，独立开发者 Theo Lee 的开源项目 OpenJev 冲上 Hacker News 拿了 600 多分，随后更名为 SemIf；NanoJev、simple-jev 等一批同类项目接连出现在 GitHub 趋势榜上，国内团队也交出了最早一批跨平台开源复现。一场「决策模型开源复现潮」已经成型。

OpenJev 验证的事：读概率，别让模型写作文

OpenJev 的页面把两条技术路线并排摆出来，这是它最有价值的部分。同一个开源模型、同一个问题、同一组封闭选项：

一条路是直接读概率。把选项放进提示词，跑一次前向传播，从模型输出的 logits 里读出各选项的概率，只在给定选项上做归一化。没有解码，没有逐字生成，算完即得。

另一条路是逐字生成。让模型把对各选项的概率写成一段 JSON 文本，一个 token 一个 token 吐出来，再解析回概率。同样的结果，多付一整轮生成循环的代价。

SemIf 仓库公布的对比数字：直接读 logits 中位耗时 1.023 秒，自回归生成 JSON 是 5.332 秒，差 5.21 倍。它的公开跑分（页面标注 Authored 口径，浏览器构建经过量化）：

两层信息：3 GB 的权重在本地就能逼近托管商用模型；对封闭选项的判断，读概率这条路把逐字解码的开销整个绕开了。

丑话也要说在前面。SemIf 的 README 写得很清楚：它复现的是接口模式，并没有复现 Jev 未公开的模型和训练过程；与 Jev 的对比数字读自公开发布的记录，覆盖的是可对齐的 102 行公开子集。直接读出的概率是给定选项上的归一化结果，属于「模型在这些选项里的偏好排序」，并非校准过的置信度；量化构建也会影响精度。这些限制在落地时都要处理，后面细说。

企业应用里，这类判断到处都是

把视角挪到企业应用，Jev 官方演示的场景和业务系统几乎是重合的：

审批分流：报销单走部门经理还是总监，采购申请要不要加签，都是在封闭选项里选一个；
工单路由：售后工单派给哪个处理组，故障单按影响面定 P1 还是 P2；
邮件与线索分诊：进来的邮件是咨询、投诉还是合作，线索按行业和预算归到哪个池------Jev 官方演示的正是客服消息批量打标，OpenJev 自带的示例场景是邮件分诊；
异常分类：表单校验失败后的错误归类，日志告警的级别判定。

这类判断一天跑几千上万次，每次都很小，加起来是一块稳定的基础开销。原来的两种处理方式各有各的难受：写死规则，业务一变规则就得重写，分支一多维护量跟着涨；全交给大模型 API，每次判断都走一轮生成，延迟以秒计，账单按 token 累积，输出还要再解析一遍，格式漂一下下游流程就断。Jev 的出现等于把这个共识摆上了台面：这层需求值得一个专用模型。而对企业（尤其是数据不能出网、且 Jev 未开放的中国大陆企业）来说，开源复现加本地部署，才是现实路径。

这条链路长什么样

OpenJev 本体是浏览器端实验，跑的是 WebGPU 加 wllama 的量化构建。这次验证做的是同一思路的服务端落地：决策模型部署在服务端，暴露一个简单的调用接口，业务系统走 HTTP 过来，拿回各选项的概率。

接入点选在活字格的服务端命令上。链路如下：

活字格的业务逻辑引擎支持可视化编排运行于服务器的业务逻辑，服务端命令里可以发起 HTTP 请求；决策服务给定提示词和选项，返回概率分布。判断完成后概率写回数据表，后面的流程分支、通知、审批走向都由编排决定。整条链路部署在内网，数据不出门------这对 Jev 未覆盖的中国大陆企业来说，是能直接开工的前提。

这个接入点还带出一件更值得注意的事：活字格本身支持 AI 工作流编排。大模型调用、智能体能力、HTTP 服务、规则分支、人工审批，在流程编排器里是同级的节点类型------决策模型接进来之后，跟它们画在同一张编排图上。慢思考的环节调大模型，高频的快判断走决策模型，置信度不够的转人工，快慢分工从架构理念变成流程画布上看得见、改得动的东西。对搭企业应用的团队来说，这可能是整条链路里最实用的一点：判断逻辑的调整发生在编排层，跟业务的调整在同一处。

需要说明的是：OpenJev 是独立的开源研究项目，与 TypeSafe 无关联；这次验证参照的是它公开的方法与跑分口径，链路本身独立部署。

哪些判断适合交给它，哪些不适合

先说适合的，四个条件同时满足：

选项封闭且可枚举。判断的答案是有限集合里选一个，不是开放生成；
调用高频。一天几十次的场景无所谓，一天几千上万次的，成本差会被放大；
对延迟敏感。判断卡在流程主路径上，用户就等在屏幕前；
有兜底。判断错了能转人工、能走默认分支，业务不塌。

再说不适合的。开放式生成（写摘要、拟回复、做解释）不在讨论范围；需要多步推理链的复杂决策，2B-4B 级小模型接不住；选项空间动态变化、无法预先枚举的任务也不合适。

还有一条要诚实说：小模型四成到八成的准确率区间，意味着关键节点必须留人工兜底或规则兜底。这条路省的是「大部分常规判断」的成本，边界情况依然要人来接。

落地时的三个坑

**概率不等于置信度。**softmax 只在给定选项上归一化，模型选不出好答案时，也会在「最不坏的选项」上给一个高概率。工程上的对应做法是设阈值：最高概率低于阈值就不自动执行，转人工处理。顺带一提，SemIf 公开了温度校准的做法，把校准误差从 0.208 降到了 0.069，说明这个坑有解，但要用自己业务数据重新拟合。

公开跑分不能直接搬。开源的量化构建和原版精度有差异，各家的业务数据分布也不同。上线前拿自己的历史数据测一遍，用实测数字定阈值，别拿公开跑分当验收标准。

选项设计就是提示词工程。选项之间的区分度直接决定判断质量。「其他」这种兜底筐选项会吞掉大量概率质量，宁可把选项拆细。选项列表不是配置项，是需要认真设计的对象。

决策模型的落地，比话题本身更值得盯

Jev 的爆火把「高频小判断值得专用模型」这个共识变成了行业话题，OpenJev 们的复现把它变成了开源社区里随手可查的跑分，而剩下的一步------把决策模型接进企业实际的业务流程------发生在每个搭系统的团队手里。这次验证跑通的链路说明：比写死规则灵活，比调用大模型便宜，数据还留在内网，这条路在低代码平台上是真实可用的。

对用低代码平台搭建业务系统的团队来说，这件事的意义还要再放大一层：活字格可以做 AI 工作流编排------大模型管慢思考、决策模型管快判断、规则节点管兜底、人工节点管边界情况，这四类能力画在同一个流程编排里。业务调整时改编排就行，不需要为每一个判断环节单独开发。热点会过去，快慢分工的架构会留下来，这条链路值得每个搭业务系统的团队自己跑一遍。

这篇为了阅读节奏，把模型部署和服务端命令的配置细节都压掉了。如果你正在团队系统里落地这条链路，想要更详细的落地方案------模型选型、服务端部署、服务端命令配置、阈值与兜底设计------可以私信留言，这个话题值得单独展开一篇。