ARTICLE · 1046116
Jev:当 AI 不再忙着说话,软件开始学会判断
Jev:当 AI 不再忙着说话,软件开始学会判断一个浏览器 Agent，在大约 7 秒内完成航班搜索；一个游戏控制器，不看截图，靠读取游戏状态来操作马里奥；还有人把 AI 接进无人机仿真，让它判断前面的障碍该绕开，还是往上飞。 这些项目有一个共同点，里面负责选下一步的 AI，叫 Jev。 它有个挺反直觉的特点：不生成聊天回复。 你没法让它像 ChatGPT 那样写一篇文章。但你可以给它一个场景、几道问题，让它迅速返回选择、评分和概率。 这让我觉得有意思：我们习惯用“能聊多深、能写多好”来评价 AI，但软件运行时，大量需要智能的瞬间，其实只有一个很小的问题，接下来该怎么办？ 先看一个日常场景。 用户发来消息：“我已经被扣了两次钱，客服三天没回复，再解决不了我就注销账号。” 让聊天模型处理，它可以写出一段安抚用户的回复。可在回复之前，客服系统还有几件事要决定：这条消息交给谁？有多紧急？用户是不是在要求退款？ Jev 就适合插在这里。开发者把消息交给它，再定义好问题和答案范围：
官方把这三类问题分别叫Choice、Score、Noul。它们可以放在同一次调用里，围绕同一份材料分别判断。输入不必预先整理得像数据库那样工整，自然语言、JSON 都可以；输出则是代码能直接使用的值。 如果你写过代码，可以把它想成一种“懂语义的 if”。 传统规则很擅长判断“金额是否大于 100”，但“这位客户是不是已经快失去耐心”就很难靠几个关键词写完整。Jev 想填补的，正是这种能被人快速理解、又难以穷举规则的判断。 TypeSafe 把这类模型称为System One，借用了《思考，快与慢》里“系统一”的概念，强调快速、聚焦的判断。这是产品的定位和比喻，不等于模型真的拥有了人脑的直觉系统。当前 Jev 接受文本形式的输入，不能直接看图片、听音频。 你可能会问：大模型也能输出 JSON，这有什么新鲜的？ 真正值得观察的地方，在于它把“给程序做判断”单独做成了一类模型服务。按照 TypeSafe 的介绍，Jev 使用面向校准决策的强化学习方法 RLCD，以及并行输出机制；它不需要先生成一段自然语言回答，再让程序从里面找答案。 官方公布的响应时间为 70—500 毫秒，输入价格为每百万 token 0.042 美元，输出免费。这些是厂商公布的数据，实际速度还受输入长度、网络和部署位置影响。至于宣传中的几十倍、上百倍优势，也有具体任务和对照条件，不能直接理解成所有 AI 应用都会提速这么多。 答案符合格式，不代表判断符合事实。 当选项只有“账单、技术、账户”时，模型不会凭空返回一个没定义的部门，但仍然可能把账单问题分给技术团队。 Browser Use 的 jev-ultrafast 展示了一个很直观的用法：给浏览器一个自然语言目标，让它在 Google Flights 上查找苏黎世到伦敦的航班。 程序把页面里的可操作元素整理出来，Jev 负责选择操作和目标。需要输入城市名称等文字时，再由另一个模型生成内容。于是，“选哪个按钮”和“输入什么文字”有了不同的负责人。 项目公布的小规模测试里，优化后完成任务的中位数约为7.1 秒。 一个要连续操作十几步的 Agent，每一步省下一点等待，整个过程的体感就可能明显改善。用户最终感受到的，是软件终于跟得上自己的节奏。 typesafe-mario 的做法更有意思。 它不把游戏截图发给 Jev，而是从模拟器遥测和 RAM 中提取信息：马里奥怎么移动、跳跃轨迹如何、敌人和地形在哪里，再整理成紧凑的 JSON。 Jev 从“向右”“跳跃”“向右跑跳”等合法动作中选一个，模拟器执行若干帧，再把新状态送回来。它是一个实验性控制器，不应仅凭仓库演示就宣称已经具备稳定通关能力。项目与输入设计 这个例子的妙处在于：AI 不一定要用人类看屏幕的方式，才能参与游戏。 如果系统已经知道角色位置和敌人距离，把这些信息直接给模型，往往比让它重新从像素中识别更省事。这里值得学的，还有开发者如何把复杂场景整理成一个可判断的问题。 jev-drone 把这种思路带进了 MuJoCo 无人机仿真。 视觉处理代码先把相机信息转成简洁的场景描述。Jev 再以大约每秒 2.5 次的频率，判断该保持路线、向左找空隙、向右绕行、爬升，还是刹车。 作者报告，在其中一段障碍路线里，只会倾向更宽一侧的简单规则会被横梁挡住；加入 Jev 后，系统能选择爬升并完成路线。 
更值得看的是它的分工：底层飞行控制以 500Hz 运行，安全层以 50Hz 运行，Jev 只给战术建议，代码保留否决权。 模型可以建议“往上飞”，但程序仍要检查上方空间和爬升条件。这个案例发生在仿真环境里，却很清楚地展示了如何把语义判断接进一个实时系统。 Jarrod Watts 的 jev-trader 会读取 Monad 上 Kuru 的 MON-USDC 订单簿，围绕约 300 毫秒一个区块的节奏选择买卖方向，再由代码处理限价单。 它值得看的地方是工程结构：读取市场、判断方向、管理订单、更新状态，被接成了一条持续循环的流水线。循环跑得快，并不构成策略有收益的证据。 想观察它的人还要注意一个小细节：项目默认使用的是 mock 启发式模型。必须设置 MODEL=jev 并提供相应 API Key，才真的在调用 Jev；不提供私钥时可以运行 dry-run，读取真实盘口并模拟成交。 相比游戏和交易，我觉得 Your Signal 更接近普通人的日常。 这是一个 Chrome 扩展。你设定兴趣和过滤偏好，Jev 对 X 时间线里可见帖子的文本做判断：相关不相关？有没有实质内容？是不是推广或互动诱饵？扩展再按你的设置高亮、淡化、折叠或隐藏内容，而且这些显示变化可以撤销。 
它需要你自己的 Jev API Key，文本会送到远程 API 处理，并非离线运行。Your Signal 项目 这个方向很容易让人继续联想：资料收藏夹、RSS 阅读器、工作消息列表，都有大量“这条值不值得我看”的判断。便宜的语义判断，让个人定制过滤器有了更多实验空间。 看完演示，如果想自己动手，我会把这些项目分成几条路线。它们多数开放的是应用代码，运行时仍调用 Jev 服务，不能把“项目开源”理解为“Jev 模型权重开源”。
我的上手建议是：先选一个你能判断对错的小任务。比如挑一批邮件手动标好类别，再比较模型结果。亲眼看到它在哪些地方选错，比只盯着演示里的速度更能帮助你理解它。 我对 Jev 最感兴趣的地方，是它让一种产品形态变得更具体：AI 可以是一颗随时被调用的小零件。 下面几点是我从这些项目里得到的判断，还需要更广泛的实际使用来验证。 首先，AI 系统的分工会变得更细。 一个任务里，规划、生成文字、选择工具、检查风险、执行操作，需要的能力并不相同。浏览器案例已经把这种分工摆出来了：有的部分负责写，有的部分负责选，程序负责执行。开发者要做的是把它们接成一套在速度、成本和成功率上都合适的流程。 这也意味着，我们评价 Agent 时，不能只问它接了哪个最强模型。每个环节是否用对方法，同样影响最终体验。 其次，判断足够便宜之后，一些原本不值得做的功能才开始值得做。 给十封邮件分类当然有用，但如果每一条信息、每一个候选结果、每一次工具调用，都能以很低的成本多判断一次，产品设计的空间就扩大了。 个人信息流过滤器就是一个例子。用户不需要主动打开聊天窗口，AI 已经在后台替他判断哪些内容更值得注意。我的预期是，类似能力会逐渐进入搜索、阅读、客服和自动化工具，成为用户未必看见、却能感受到的功能。 第三，模型如何表达不确定性，会影响软件敢把多少工作交给它。 “选了 A”提供了一条执行路径；“A、B 都有可能”则提醒程序，下一步也许该补充信息或升级处理。 在我看来，真正有价值的自动化，是既能处理熟悉场景，也能在不确定时走向合适的下一步。 最后，围绕模型的工程设计，仍然非常关键。 把一个复杂任务拆成一连串足够清楚的小判断，是这些演示背后共同的工程功夫。 所以，我会继续关注 Jev，以及沿着这个方向生长出来的项目。它们提供了一种很具体的想象：以后我们打开软件，AI 可能已经在后台完成了分流、筛选和下一步选择，留给我们的界面反而更简单。 关注知识星球（XinGPT Research），学会用AI做投资
一、怎么理解 Jev？给软件装上一个会理解语义的判断函数
二、它能玩出什么花样？这几个案例最能打开脑洞
1. 七秒查航班：让浏览器少等几次“大脑”
关注
重播 分享 赞
2. 不看画面玩马里奥：先把世界翻译成模型能用的信息
3. 给无人机当参谋：前面堵住了，可以往上飞
4. 每个区块选一次买卖：把决策塞进高频循环
5. 给自己的信息流装一个筛子