回看过去三年的 AI 叙事，主线一直是「大模型越来越大、越来越聪明、越来越全能」。一个模型既能聊天，又能写代码，还能看图做表，什么都会。整个行业默认「智能」是一块铁板，不可拆分。 Jev 的出现，撕开了这块铁板。它证明了有些工作需要推理和表达，有些只需要快速判断。把两者绑在一起，是一种结构性的浪费
我看 Jev，最值得关注的不是又出现了一个便宜模型，而是它让开发者重新审视一个习惯：软件需要做判断时，为什么总要先请模型写一段话？
过去几年的 AI 产品，大量围绕聊天和生成展开。但自动化系统里，许多任务只需要知道：是否相关、是否匹配、下一步选哪个。表达能力和判断能力长期被打包调用，其中可能藏着大量不必要的成本。
从洗衣提醒到手机操作，判断有自己的接口
原文介绍的 Jev，由前 OpenAI 研究员 Diogo Almeida 创办的 TypeSafe AI 推出。它不生成文字，只输出概率判断。
Home Assistant 社区的 HA-Jev 插件，是一个很直观的例子。它读取洗衣机功率和洗衣房门的状态，判断衣服是否被忘在机器里。置信度超过 0.8，就发送提醒。据报道，一次判断只需几十毫秒，花费 0.000015 美元。
这个任务的终点是触发提醒。系统得到一个可用于决策的数值，就能继续执行，没必要再从一段自然语言里提取答案。
手机操作也出现了类似尝试。Droidrun 团队的 mobile-jev 在演示中控制 Android 手机打开 Uber、填写行程，直到付款界面，9 个步骤耗时 21 秒。输入文字从用户指令中提取，界面操作则通过概率匹配选择。
我看重的是这种接口变化：模型输出可以直接接入程序的控制流程。它离软件内部的一个判断函数更近了。
过滤、匹配和排序，正在成为独立的模型任务
原文中最有启发的案例，是用 Jev 压缩 Claude Code 的上下文。
开发者没有让模型总结历史，而是给每条历史工具调用的相关性打分，低于阈值就删除。据报道，接近 100 万 token 的上下文，在 1 秒内缩减到 8.6 万。
摘要需要重新组织和生成信息，过滤只需要决定哪些信息留下。两者解决的问题有交集，计算路径却很不同。我的判断是，设计 AI 工作流时，应该先问清楚究竟需要哪一种能力。
同样的思路还出现在数据库和数据清洗里。pg-jev、duckdb-jev 尝试对数据库记录做自然语言驱动的概率过滤与排序。一位开发者处理 9081 条产品匹配数据，据报道用时 13 分钟，花费 32 美分。
游戏里的即时操作、内容之间的链接匹配，也属于这一类需求。原文提到，有开发者扫描近六百个网页，在 45 秒内完成内部链接地图重构，花费 21 美分。背后的核心工作，是反复判断两个页面是否值得连接。
这些案例来自不同任务和演示，不能直接当作统一的性能评测。但它们共同指出了一个方向：软件里有大量语义判断，值得从通用生成流程中单独拆出来。
判断变便宜，会改变值得做的事情
Jev 的名字取自经济学家杰文斯。原文借用“杰文斯悖论”解释它的潜在影响：资源使用效率提高、成本下降，可能刺激更多需求，最终扩大总消耗。
据原文介绍，Jev 的定价是每百万输入 token 0.042 美元，输出免费。具体业务能省多少钱，仍取决于输入长度、调用次数和准确率要求，不能只看单价。
我更关注成本下降之后，产品边界会怎样移动。
过去，一项判断即使有用，也可能因为调用太慢、费用太高而被放弃。当成本足够低，开发者就可以给每条数据库记录增加语义筛选，给每次工具调用增加检查，也可以认真处理“衣服是不是忘拿了”这样的小需求。
这时，需求本身会增长。原来只在关键节点调用模型的系统，可能开始在大量细小环节使用模型。智能服务的颗粒度会越来越细。
系统开始分工，生成模型仍有重要位置
原文还提到，开源社区迅速出现了基于 Google DiffusionGemma 的跟进实现，初步测试准确率接近官方。这个信号值得关注，但仅凭早期测试，还不足以判断一个模型品类已经成熟。
更明确的变化发生在架构思路上：一个 AI 系统可以由不同能力共同完成任务。高频筛选、匹配和动作选择交给快速判断模型；复杂推理、开放式规划、代码与文档生成，继续使用适合这些任务的模型。
我不赞同把生成式大模型的角色简单缩成“公关发言人”。会输出文字，并不意味着它的价值只有表达。真正需要重新设计的，是任务与能力之间的匹配关系。
判断模型也需要边界。返回概率只是让系统更容易使用结果，并不会自动保证判断可靠。删掉一条上下文是否损失关键信息，选择一次操作是否会出错，都要在实际任务里验证。
对我而言，Jev 带来的启发是：先拆任务，再选模型。需要判断的地方直接判断，需要推理和生成的地方投入相应能力。这种分工，可能比继续让一个模型包办所有环节，更能推动 AI 进入日常软件。