Jev 能让 AI 操作电脑更快吗？从 Codex 日历演示到 7 秒机票搜索

2026 年 9 月 15 日，TypeSafe AI 发布了早期访问模型 Jev。它能读自然语言，但不写文章、不生成代码，而是返回程序可以直接使用的选择、评分和概率。官方把这类面向快速决策的模型称为 System One。与其把它理解成另一个聊天助手，不如先看一个具体问题：AI 已经知道要填写日历了，为什么每点一下，还要等它想那么久？TypeSafe 发布说明给出的方向，是把其中一部分判断从通用语言模型里拆出来。

最近的两个开发者项目，让这个想法变得直观：一个把 Jev 接入 Codex 的电脑操作流程，另一个在约 7 秒内完成了一次机票搜索。不过，点鼠标只是它的一种用法。沿着官方例程和公开项目继续看，同一类快速判断还出现在工单分流、知识库筛选、文档整理、代码审查和游戏控制里。理解这些分工，才能看清它能帮什么忙，以及哪些事仍然需要通用大模型与普通程序完成。

不写长答案，先选对下一步

设想一个日历界面上有“上个月”“下个月”“新建事件”三个按钮。程序已经拿到了按钮名称，当前目标是翻到上个月。此时并不需要一篇解释，只需要知道应该选择哪个按钮。

Jev 的接口就是按这类问题组织的：发送当前状态，以及预先定义的问题和答案范围，再接收结构化结果。根据官方问题类型文档，三种基本问法分别是：

其中，评分不是精确计算器，真值概率也不是中间等级。多个互不依赖的问题可以共享同一份状态并行求解；真正依赖上一轮结果的问题，仍要等待下一次调用。软件负责组织流程，模型只回答被明确交给它的判断。

另一个容易误会的地方是“看屏幕”。截至 9 月 19 日，官方模型规格列出的 jev-1.13.0 只接受文字输入，不接受图片、音频或视频。因此，演示里即使出现完整电脑画面，也不能据此认定 Jev 本身具备视觉读屏能力。

接入 Codex 后，变快的是哪一段？

9 月 18 日，开发者 Sac 在 X 发布了添加 Mac 日历事件的对比说明。他把自己的组合称作“Jev Use”，描述其过程更连贯，同时明确说 token 消耗差不多。这一点很重要：不能把“动作更快”顺手改写成“这次测试也节省了大量 token”。该帖没有给出重复次数、完整计时表和跨任务成功率，适合看作作者演示，而不是通用性能结论。

沿着作者公开的 Jev-cu 仓库继续看，分工很清楚：Codex Computer Use（电脑操作，kem-pyoo-ter yoos）负责读取界面和执行，Jev 从界面文字候选里选择元素、动作，并判断完成度与风险。只给 Jev 传文字，不传截图。

读取当前界面 → 整理文字候选
                   ↓
             Jev 选择下一步
                   ↓
              本地策略检查
                   ↓
           Codex 执行并重新观察

这份分工解释了它可能快在哪里：当任务已经进入清楚、连续的小步骤，不必每次都让通用模型重新组织一段长推理。代价是周边程序必须把状态、候选和动作边界准备好；读不到的控件、不完整的界面信息和复杂任务规划，不会因为中间换成 Jev 就自动解决。

它也不是给 Codex 换一个模型地址便能得到的能力。仓库要求在 Codex 桌面应用的指定电脑操作运行环境中使用，并保留试运行和敏感操作确认。TypeSafe 自己另有官方智能体技能，用途是让编程智能体理解其接口与设计模式，不能与这个社区电脑操作项目混为一谈。

7 秒机票搜索，实际用了两个模型

另一个案例是 Browser Use 的 Jev Ultrafast。它把网页控件整理成带编号的候选，交给 Jev 选择动作与目标；需要输入自由文本时，再调用一个小型生成模型。当前公开演示中，城市文字由 Mercury 2.5 生成，Jev 负责操作选择。因此，这不是“一个不会生成文字的模型，突然独立完成了所有输入”。

*图：从项目原始演示视频提取的完成帧，保留作者叠加的计时与分工说明。画面是机票搜索结果，不是购票成功；右侧 178 毫秒是该次运行的 Jev 请求延迟中位数，不是整个任务耗时。*

作者的测量记录给出 7.073 秒：从首次预测到接受完成判断，包含模型请求、文本生成和页面等待，但不含浏览器启动、初始导航及事后独立核验。它还提供了三组交替运行的对照：

两边用的是同一个 Jev 版本和同一个文本模型。 约 25% 的中位耗时下降，比较的是运行程序优化，而不是 Jev 与另一个大模型的胜负。优化减少了重复界面读取和浏览器通信；只有三组、一个任务，也不足以推断所有网站都能获得相同收益。

这反而是案例最有价值的地方：快速模型之外，界面读取、目标校验和执行循环本身，同样影响体验。让 AI 操作得快，需要模型与软件一起配合。

不点鼠标时，Jev 还能在哪些地方帮忙？

电脑操作需要回答“下一步点哪个按钮”，后台系统也经常遇到类似问题：“这条反馈交给谁”“哪份材料能支持答案”“这两个记录是不是同一个东西”。区别在于，后者甚至不需要打开一个界面。下面既有官方提供的设计例程，也有社区作者已经公开实现的项目；它们说明了具体做法，不代表所有场景都已达到成熟产品的可靠性。

用户反馈来了，先分清故障、账单还是新需求

一条客服留言可能同时提到登录失败、重复扣费和功能建议。先写一封漂亮的回复，并不能解决后台应该怎样分派的问题。

TypeSafe 的工单分流例程把判断拆成类别、故障严重程度、是否提供复现步骤、是否明确要求退款、情绪强度等小问题，放在同一次请求里求解。程序再决定哪些答案与当前分支有关：记录产品建议、转交技术人员，或给账单工单加上待处理标记。

这也给产品团队提供了一种可迁移的思路：把已获准处理的反馈文本先归类、标出需要补充的信息，再由人员决定优先级。这里的“需求初筛”是依据例程提出的应用设想，不是已经完成的产品经理测评；退款批准、客户承诺和实际派单权限仍由业务系统掌握。

技能装了很多，先帮智能体找到该读哪一个

“修改现有演示文稿”和“从零制作演示文稿”听起来相近，却可能对应两个不同技能。把所有技能名称塞进提示词，不等于智能体就会选对。

官方技能建议例程以 Hermes 的 182 个技能为候选：第一轮粗看整个目录，并判断当前请求是否需要技能；第二轮再详细读取前三个候选，最后允许推荐一个，也允许一个都不推荐。得到的是技能名称建议，真正加载技能、读文件和完成任务的仍是主智能体。

类似分工也可以用在模型选择上。官方意图路由例程区分了数据库查询、专业语言模型和人工处理：查订单状态不必先让昂贵模型写一遍推理，复杂投诉也不应仅凭一个分类结果自动办完。

知识库找到了材料，再检查它是否真的支持答案

检索出来的段落可能措辞很像问题，却没有回答问题；也可能恰好证明问题的前提错了。将这些材料一股脑交给生成模型，并不总是合适。

官方检索材料分类例程在检索与生成之间加入 Jev：分别判断段落是否相关、有无可用证据、是否反驳问题前提，以及是否夹带操纵模型的指令。程序把可用证据与冲突证据分开交给回答模型。反驳用户前提的材料应该被标明并保留，而不是为了让答案看起来一致就删掉。

回答写完，还可以接上官方引用核验例程：程序先找引文是否存在于原文，再让 Jev 判断上下文是支持、反驳，还是没有涉及该主张。这适合做研究报告、教程或资料问答的辅助检查，但它不替代来源搜索，也不能保证每个事实都被审查到。

从邮件选对字段，也帮两份清单找出疑似重复项

邮件里同时出现发件人邮箱、财务邮箱和抄送邮箱，真正需要填进表格的却只是收据接收地址。难点不是“有没有邮箱”，而是“哪个邮箱扮演这个角色”。

官方候选值提取例程先用程序找出候选邮箱、电话号码或金额，再让 Jev 选择符合语义要求的一项，最后由代码原样复制并规范化。数值不需要由模型重新打一遍，但候选没被找出来、或模型选错对象，依然会导致错误。

*图：官方例程原图。从左到右是“文档 → 程序提取候选值 → 模型选择 → 程序规范化与后续处理”。蓝色部分才是模型负责的判断，不是由模型包办整张表格。*

另一类问题是两份清单里的名称略有差异，到底是不是同一条商品记录。官方实体对齐例程比较两份啤酒目录中的 450 对候选，区分“不同产品”“可能相关、交人工复核”“同一产品”，并提供字段是否一致的辅助判断。将这一方法用于自己的商品或物料清单，需要重新验证匹配规则；不能只因名称相似就自动合并历史记录。

文档格式丢了，恢复结构不一定要重新写一遍

从网页或旧系统复制一份通知，常会得到断行混乱、标题和列表标记丢失的纯文本。此时需要的可能只是恢复排版，而不是请模型改写内容。

官方文档结构恢复例程分两遍处理：先判断相邻行是不是一句话被截断，再把合并后的文本块识别为标题、段落、列表、引用、代码或提示。程序负责拼接原文和添加 Markdown（轻量标记文本，mark-daun）标记，不让 Jev 自由生成新的正文。

这是一种“判断结构、代码排版”的协作方式，不等于 Jev 已能识别任意截图、恢复扫描件，或独立完成所有文档格式转换。原文缺失的内容不会因此自动补回来。

代码改完了，先提示哪些地方值得仔细检查

社区项目 Jev Review把代码审查拆成多个阶段：对代码改动或指定范围的源文件做风险判断，选择相关片段，再评估问题类型、严重程度和是否需要进一步审阅。它关注正确性、安全、可靠性、兼容性及测试覆盖，而不是要求 Jev 直接写一篇长评审意见。

*图：来自 Jev Review 作者仓库的界面示例，展示文件列表、检查进度和判断矩阵。不是本站运行截图；图中分数不是漏洞检出率，也不能证明对应代码确有缺陷。*

作者明确把它定位为实验：尚未整合编译器诊断、静态分析器或生成式解释，发现项是提醒人继续检查的线索，不是缺陷证明。因而更合理的用法是辅助确定审阅重点，再结合测试、代码上下文和人工判断；本地显示报告也不意味着模型调用离线进行。

一句话控制家居，设备命令与闲聊分开走

TypeSafe 的智能家居示例用“关闭家里所有灯”说明分工：同一次请求判断它是否是设备指令、范围是全屋还是某个区域、目标是什么设备，以及要执行什么动作。程序只使用与本次指令有关的答案。

遇到复合指令，示例会让语言模型先拆成多个原子命令；遇到一般知识问答或聊天，再交给生成模型。这里快的是指令分类和路由，不是 Jev 自己连接了所有品牌的设备。真实设备的接入、权限、执行结果与必要确认，仍属于控制系统的职责。

游戏里选动作，但读到的是状态，不是画面

TypeSafe Mario是另一种公开实验。周边程序从模拟器遥测和内存中提取角色位置、跳跃阶段、附近敌人、地形及响应延迟，整理成结构化状态；Jev 再从向右、跳跃、向右跑跳等合法动作中选择，模拟器执行若干帧后重新观察。

这展示了快速判断可以进入交互循环，但不能把它描述成“Jev 看懂游戏截图”：仓库明确不向模型发送截图，精确时序计算也留在代码中。公开实现同样不等于稳定通关或优于专用游戏控制器；有价值的是看清“环境状态由程序提供，动作选择由模型完成”这条路径。

这些场景共同指向一件事：Jev 的对象不一定是鼠标，而是软件里那些答案范围明确、规则又难以完全写死的判断。 先把输入、候选和执行边界设计好，再测自己的任务，比先追求某个通用提速倍数更实际。

速度数字要看清比较对象

TypeSafe 的发布材料给出了 70～500 毫秒的端到端响应范围，但注明其公开评测通常从美国西海岸的笔记本运行，服务也位于当地。这个范围不能直接当成国内网络、任意输入长度和完整电脑任务的速度承诺。

*图：来自 TypeSafe 发布页的四工作流比较。横轴是对数成本，不是时间；评测以参考模型的预测作为比较依据，而非人工真值。它展示的是厂商定义下的成本与表现关系，不能读成电脑操作成功率排行榜。*

网络路径不同，实测结果也会不同。Octomind 开发者 Don Karter 在 9 月 18 日公布的个人调用记录中，用笔记本经 Cloudflare 对十条命令做结构化判断，端到端耗时为 386～834 毫秒。这个小样本支持“亚秒级调用值得探索”，却不是跨地区、大规模或电脑操作基准。

衡量这类模型，与其问每秒生成多少 token，不如看一次判断耗时、每项任务需要多少次调用、失败后重试几次，以及最后有没有完成正确的事情。

不会编造字段，仍然可能选错按钮

Jev 把输出限制在给定的答案空间里，确实减少了一类集成麻烦：程序不必从一段散文里猜出动作名称。但合法选项里仍然可能有错误答案。目标是保存草稿，它选择了另一个允许出现的按钮，输出格式依然完全合规。

*图：截取自官方原图的结构化输出错误率面板。TypeSafe 说明 Jev 的 0% 来自输出格式保证，并非所有任务的实测零错误率；不能据此写成“不会误判”。*

官方于 9 月 17 日复核的 Jev 1.13 已知问题也没有回避限制：数值精度、计数、日期比较、多层推理，以及混有大量无关信息的状态，都可能出问题；对抗性文字还可能影响判断。

于是，日历案例里有一个很实用的区别：选出“下个月”按钮是一项语义判断，计算跨时区会议日期则应交给确定性的日期逻辑。 让它点得更流畅，不等于日程内容可以免于核验。

置信度也不是保险单。官方置信度说明把它定义为对答案概率分布集中程度的统计，不应简单理解成“0.9 就保证这次有 90% 正确率”。阈值需要用自己的任务校准；付款、发送、删除等操作仍应保留权限检查和人工确认，而不能由模型自报“低风险”就直接放行。

更值得期待的是分工，而不是替代

在现阶段，Jev 最适合接手的是答案范围清楚、频繁重复、延迟敏感的小判断。需要写文档、生成代码、解释复杂需求时，生成模型仍有职责；能由代码精确计算的数值、日期、权限和操作结果，也没有必要重新交给模型猜。这与 TypeSafe 强调的代码掌握流程、模型承担局部判断是一致的。

接入前还要看两个现实条件。当前官方规格显示，英文是主要训练语言，中文等语言可以输入，但效果不保证相同；标准接口价格为每百万输入 token 0.042 美元，输出免费，但辅助模型与运行环境仍可能另有成本。请求总预算是 64k token，状态加最长单个问题的预算是 32k，不能把两者混为一个“可随意塞入的 64k 上下文”。

此次核验到的官方使用入口是云端接口、开发工具包和技能，未找到官方可下载模型权重。GitHub 上公开的电脑操作、代码审查或游戏控制程序，不等于 Jev 模型已经能够离线部署。界面文字、客户邮件、业务清单和项目源代码都可能包含敏感信息，准备接入实际办公系统时，数据能否发送到外部服务需要先确认。

Jev 带来的启发不是“以后不需要大模型”，而是把原来交给一个模型包办的工作重新分工：复杂任务交给擅长推理与生成的模型，明确的小判断走更快的路径，权限与结果检查留在可靠的软件边界内。衡量这套组合是否值得用，最终看的仍应是相同任务下的正确完成率、端到端耗时和总成本，而不是某一段视频看起来有多快。

*资料核验截至 2026 年 9 月 19 日。本文依据官方文档、公开例程、作者项目与调用记录整理；业务迁移建议属于文中明确说明的应用设想。各例程可能使用不同模型版本和测试环境，未进行本站模型或应用场景运行复测。*