本文聚焦 Jev 这类“不写长答案、只做快速判断”的 System One 模型：以 Jev Ultrafast 和 Jev + Cua Driver 为主线，梳理 10 个公开案例、官方建议的 6 类应用方向，并严格区分演示、作者实测、厂商主张与待验证方案。
主要来源：Jev 发布帖 · TypeSafe AI 技术博客 · Jev Ultrafast · Jev + Cua Driver
本文由 LobsterAI 自动翻译和发布。
一个不能陪你聊天、不能直接写文章的模型，为什么能在 X 上引发关注？
Jev 给出的答案是：软件未必需要 AI 说得更多，它可能只需要 AI 更快地判断下一步。
2026 年 9 月 15 日，TypeSafe AI 创始人 Diogo Almeida 在 X 上发布 Jev，宣称在适配的任务上可比现有 LLM 快 20—200 倍、便宜 40—400 倍，且不收取输出 token 费用。本次检索得到的发布帖页面快照显示约 3380 万次浏览。这个数字说明传播规模，不证明性能；那些令人兴奋的倍数，也不是所有任务上的通用结论。[1][2]
比发布口号更值得看的是随后出现的操作型 Agent：Browser Use 团队用 Jev Ultrafast 演示约 7 秒搜索航班；Cua 推出 Jev + Cua Driver 的开发预览，试图把快速决策接进跨平台电脑操作。前者发布帖的浏览量快照约 260 万，后者约 36.1 万——这才是这轮讨论中不能遗漏的一条主线。[18][21]
除此之外，还有按键过程中理解意图的启动器、语音控制浏览器，以及迅速返回数百项结果的文档检查。不同案例都在尝试把“写出答案”换成“选择下一步动作”。
这些案例指向同一个变化：AI 不再只坐在聊天窗口里等问题，而可能成为软件运行过程中不断被调用的判断函数。
一、Jev 到底是什么：不是另一个聊天框，而是一种决策接口
TypeSafe 把这类模型称为 System One Models，借用的是“快思考”的概念；Jev 是其首个公开模型。公司称它采用新的架构、并行采样方式，以及 RLCD——Reinforcement Learning for Calibrated Decisions，即面向校准决策的强化学习。[2]
理解它，不必先钻进训练细节。你向 Jev 提供当前状态和一组有明确范围的问题，它返回程序可以直接消费的结构化结果，而不是自由文本。[3]
例如，一张客服工单到达后，程序可以分别问：它应该分到哪个队列？紧急程度有多高？它是否包含取消订阅的意图？模型负责模糊判断，代码负责按照结果分流。
目前官方文档列出三种基本能力：Choice 从给定选项中选择，Score 按规则评分，Noul 返回一个陈述为真的程度或概率值。Choice 和 Score 附带概率分布及 confidence；Noul 则返回 0—1 的值，不另附同样的 confidence 字段。[3][4]
同一次请求中的多个问题，可以基于相同状态并行、独立地求值。这也解释了 Jev 为何适合“同时检查很多件小事”，而不适合被直接当成一个会长篇推理、解释和创作的聊天模型。
它的取舍不是“什么都做得更快”，而是放弃自由文本生成，把输出范围收窄到软件真正需要的判断。
也别把这种区别夸张成“LLM 不会输出结构化数据”。现有 LLM 本来就能使用结构化输出。真正值得检验的，是 Jev 在同等任务、同等质量约束下，能否把延迟和成本降到足以改变产品设计的水平。
二、X 上的热度来自哪里：官方发布、解释帖与开发者实测
本次梳理主要覆盖 9 月 15 日至 18 日的公开内容，优先选择可定位原帖、有演示或测试细节的来源，并用官方文档和原作者长文交叉核验。这不是 X 全站热榜，也不是完整的讨论统计。
几条代表性内容呈现出不同层次的关注：创始人发布帖的页面快照约 3380 万浏览；Gregor Zunic 的 Jev Ultrafast 约 260 万；AI/ML API 的国际象棋对照帖约 50.1 万；Cua 的 jev-use 发布帖约 36.1 万；Nader Dabit 的预测启动器约 35.0 万；Moritz Kremb 的语音浏览器约 29.4 万；Dan Shipper 的测试反馈约 21.9 万。[1][5][6][7][8][18][21]
介绍帖里，Rohan Paul 把 Jev 解释为软件中的“智能 if 语句”；Chubby 则一边转述其性能主张，一边强调它不能生成文本，并在回复中说明自己无法验证相关说法。[9][10]
还有一个不能省略的细节：本次提取的 Rohan Paul、Wall St Engine 介绍帖都带有 Paid partnership（付费合作） 标记。它们适合用来观察传播话术，不应被当作独立评测背书。[9][11]
下面拆解十个案例，先看最直接的浏览器与桌面操作，再看其他交互和工作流应用。
三、先看两个重点：Jev 如何真正操作浏览器和电脑
案例 1：Jev Ultrafast——不是更快地描述网页，而是更快地选动作。
Browser Use 的 Gregor Zunic 在 9 月 17 日发布演示：给出一个自然语言目标，Agent 在 Google Flights 搜索苏黎世到伦敦的航班。原帖称耗时约 7 秒、成本约 0.0039 美元；项目名为 Jev Ultrafast，开源仓库是 browser-use/jev-ultrafast。[18][19]
与“用户说一句、浏览器点一下”的指令映射相比，它展示的是一个多步骤任务循环：读取页面状态，选择操作和目标，执行，再根据新页面重新判断。
关键设计是动态、带编号的动作空间。每次观察页面后，程序把当前可操作元素整理成表格；Jev 决定执行点击、输入、选择、滚动、等待、完成或受阻，并选择相应元素。操作类型与候选目标在同一个请求里预测，实际只执行与选中操作匹配的目标，以减少网络往返。[19]
Jev 不生成输入框里要填的文字。 当操作是 TYPE_TEXT 时，系统才调用小型生成式模型写出城市名等内容；当前演示使用 Mercury 2.5。默认决策循环读取结构化 DOM 状态，不把截图直接送给 Jev；执行器还会检查页面是否变化、目标是否被遮挡，以及选中节点是否仍有效。[19][20]
这说明它的速度不是单靠“换一个模型”，而是模型分工、动作约束和浏览器工程一起实现的。项目同模型、同设置的优化前后对照中，任务中位时间从 9.450 秒降到 7.092 秒，浏览器协议调用中位数从 1,092 次降到 101 次；但每组只有三次、且是同一项任务，不能作为通用成功率证明。[20]
“7 秒”也有明确边界。性能文档记录的视频运行时间为 7.073 秒，从首次主页观察后的第一次预测开始，到系统接受 DONE 决策结束；计入模型请求、文字生成、浏览器操作和页面加载，但不计浏览器准备、初始导航，以及结束后的独立结果验收。它完成的是查到匹配航班选项，不是付款订票。[19][20]
成本则保留“作者报告约 0.0039 美元”的表述，不能写成经过审计的总账单。性能文档说明，TypeSafe 返回 token 数而非已结算美元金额，浏览器基础设施成本也未计入。[18][20]
项目仍是 MVP：iframe、Shadow DOM、Canvas、上传、新标签页等不在当前支持范围。模型选了 DONE，不代表任务真的完成，还必须验证网页上的实际结果。[19][20]
案例 2：Jev + Cua Driver——把同样的思路从网页延伸到电脑界面。
Cua 在 9 月 17 日发布 Jev + Cua Driver，称其为 jev-use，面向 macOS、Windows、Linux 提供开发预览。这里的 Cua 指 @trycua 的工具项目，不是说 OpenAI 的 CUA 模型更名为 Jev。[21]
它的分工很明确：Driver 负责观察界面和执行操作；客户端把观察结果转换成有限的候选动作；Jev 选择一个动作 ID；Driver 执行后再检查新的界面状态。[21]
当可访问性树（AX）或 DOM 已经给出足够结构时，可以直接使用这些信息；不足时，项目提出可选的 Cua Perception，借助 OmniParser 等截图解析器生成带类型的视觉区域。视觉解析、决策和动作执行分开，并不等于 Jev 本身突然拥有了原生视觉能力。[21]
这条路线比纯 DOM 浏览器代理覆盖的目标更广，但也不能把“跨平台开发预览”写成“任意桌面应用已稳定支持”。发布长帖末尾仍列出后续运行时接线、可选解析器安装和 Jev provider 集成等工作；关联 PR 也将可选感知扩展与 Jev 配方分开描述。[21][22]
Cua 同时发布了操作 2048 的对照演示，帖文报告 Jev 用时 44.9 秒、约 0.00108 美元 API 等价成本，对照 Astra 为 294.9 秒、约 1.45 美元。作者明确说这些结果只适用于该次运行。本文保留原始值，不把“快五倍、便宜千倍”的宣传概括外推成电脑操作的普遍结论；API 等价成本也不是完整电脑代理运行成本。[23]
把这两个项目放在一起，才能看清浏览器／电脑操作方向的真正变化：先把界面变成可选择的动作，再让快速模型做选择，而不是要求模型每一步都自由生成一段操作方案。
这不意味着慢推理、视觉感知和生成式模型都不需要了。它意味着可以把它们从每一步必经的流程，变成按任务需要调用的组件。
四、另外八个案例：交互、检查与工作流
案例 3：Doom——把模型放进高频控制循环。
官方展示了 Jev 驱动 Doom 的演示。Almeida 在 X 上称，系统约每秒调用模型 10 次，成本约每小时 7 美元。[12]
但技术博客补充了关键前提：模型读取的是以文本和数据结构表示的游戏状态，不是直接看游戏画面；团队也承认，非 AI 的专用 Doom 机器人可以玩得更好。[2]
它展示的不是“通用 AI 已经掌握视觉游戏操作”，而是低延迟决策可以被反复嵌入游戏循环。向其他产品迁移时，类似价值可能出现在实时分流或交互反馈中——这是应用启发，不是已验证的商业落地。
案例 4：维基百科跳转——从真实候选项中选下一步。
官方的 Wikiracing 演示要求模型从一个维基百科页面出发，只通过页面中的链接抵达目标条目。任务的核心不是写一段介绍，而是不断决定“下一条链接点哪个”。[13]
这个设计有一个实用优点：当输出被限定在现有候选链接中，系统就不需要再处理模型编造链接的问题。不过，不编造链接不等于一定选对路线。
官方还披露，Jev 单次选择的候选上限为 255；面对更多链接时，演示采用先分别评分、再明确选择的两阶段方案。因此，“在数千链接中导航”不等于“一次 Choice 请求无上限地处理数千选项”。[2]
案例 5：预测启动器——每次按键都做一次意图判断。
Nader Dabit 的演示把 Jev 接进启动器。输入“我刚下载的 PDF”，系统就把最新 PDF 排到前面。作者称，模型可在每次按键后约 100 毫秒判断意图，并返回带置信度的结果。[6]
值得注意的不是搜索框里多了一个 AI 按钮，而是用户不必先组织一个完整问题、点击发送、等待回答。意图判断发生在输入过程里。
这是一个实验性产品演示。约 100 毫秒是作者报告的体验数据，并非所有地区、所有输入长度下的服务保证；但它确实提出了一个产品问题：如果判断足够快，软件还需要等用户说完才开始响应吗？
案例 6：语音浏览器——听懂指令与执行点击分开处理。
Moritz Kremb 展示的流程是：用户说话，语音转成文本，文本交给 Jev，模型返回概率，再由浏览器执行点击。作者称，Jev 返回概率约需 300 毫秒，每次决策成本约 0.0002 美元。[7]
这个案例不能被简化成“Jev 直接听懂声音”。语音识别是前置环节，300 毫秒也不能直接等同于整个“开口到完成点击”的端到端延迟。
它更清楚地展示了一种分工：语音系统负责转录，Jev 负责从动作中做判断，执行程序负责操作。模型不必包办所有能力，也可能改善整体交互体验。
案例 7：广告过滤——让模糊分类参与页面处理。
Zachi 展示了一款广告过滤扩展，称它对 DOM 元素做“广告／非广告”分类，被判为广告的元素会被移除。[14]
相比聊天，这种任务更符合 Jev 的形状：输出范围很小，但判断需要语义，且可能高频发生。原帖附有演示，并提供了代码线索。
不过，作者称其“不可检测”，本次没有找到足够证据支持这一点，也没有独立的误删率和漏检率测试。对真实用户而言，误删一个正常页面元素，同样是产品故障。演示证明有人做了这个原型，不证明它已经能可靠替代成熟广告过滤方案。
案例 8：文档检查——把抽检变成更密集的逐项检查。
Every 的评测负责人 Mike Taylor 做了一个更容易看清方法的实验：把自己的 27 篇文章与 10 篇刻意带有 AI 写作风格的对照文章放在一起，对每篇同时问 21 个问题，检查重复表达、强行对称论证、过度解释等模式。[15][16]
他报告，在不到 0.7 秒内得到了 777 次判断，估算费用为四分之一美分，即 0.0025 美元。这些数字来自作者测试，不是本文复测。
真正有价值的设想，是在写作或 Agent 工作过程中不断检查，而不只在最后挑几份结果抽查。但不能把“发现某些写作模式”说成“可靠识别 AI 代写”：作者本人明确表示，上生产前还需要更充分的准确率检查。[16]
同一篇长文还记录了另一个独立实验：Dan Shipper 用 12 个合成片段测试四类写作问题。Jev 的单片段中位耗时为 0.35 秒，对照 Fable 5.1 高强度推理为 8.83 秒；估算成本约低 580 倍。但七处预设缺陷中，Jev 找到六处，对照模型找到全部七处。[16]
这比单看倍数更有意义：成本和延迟大幅下降，可以让检查更频繁，却不自动意味着检查更准确。 这组对照，也不能和前面的 777 次判断实验混为一谈。
案例 9：安全管线——更接近真实工作流，但证据仍不完整。
Greg Pstrucha 在 X 上称，他把 Jev 用在团队的一条安全管线中；与原先为控制成本而采用的小模型相比，成本低了五倍以上，同时更快、准确率更高。[17]
这是值得关注的实践反馈，因为它比较的是已有工作流中的替代方案，而不只是好看的展示。但帖子正文没有完整披露基线型号、数据集、具体准确率和速度倍数。
因此，可以说“有团队成员报告了安全管线中的积极测试结果”，不能写成“已经证明全面优于安全模型”，也不能据此宣布某家公司已全面生产部署。
案例 10：国际象棋——速度和棋力不是一回事。
AI/ML API 的演示使用 5 分钟、无加秒的快棋，每一步对应一次 API 调用。帖文称，Jev 对阵 Fable 5.1 时，后者棋盘优势明显，却因每步消耗 6—15 秒最终超时；Jev 的响应约为 2.6 秒。[5]
但换成 GPT-6 Astra，对手在 18 步内将杀 Jev，且仍有剩余时间。
这不是严谨的棋力榜，也不足以代表通用智能高低；它却直观展示了两个容易被营销混在一起的指标：在有时限的系统里，慢可能导致失败，但快也不会自动补足决策质量。
五、官方应用地图：除了操作界面，还能把 Jev 放在哪里？
前面十个案例回答的是“已经有人展示了什么”。TypeSafe 的官方 Use Case Map 则回答另一个问题：“你的工作流里，哪些判断值得尝试交给模型？”页面明确把自己定位为行业应用的头脑风暴地图，而不是客户落地或效果认证清单。[24]
其中最适合接到本文主线的，是以下六类。下面的流程说明是依据官方方向做的应用化解释，不代表这些方案均已实施或达到某个准确率。
方向 1：模型路由——先判断任务，再决定要不要调用大模型。
官方建议用 Jev 识别意图、领域、难度和风险，再按业务规则决定将请求交给哪个模型，以及何时升级到更昂贵的模型。[24]
放到浏览器 Agent 中，一种可测试的分工是：明确的按钮选择走快速决策，遇到需要复杂规划的问题再转交强推理模型。Ultrafast 已展示按需调用文字模型的分工；“通用难度路由”则是可进一步探索的方向，不能说它已在该项目里完成。
评价这种方案，要看整体任务成功率和总成本，而不是只看路由器本身便宜多少。把困难请求误判成简单请求，可能省了调用费，却增加了失败重试。
方向 2：RAG 检索与重排——先选对材料，再让生成模型回答。
官方列出的用途包括查询与候选文档的相关性评分、两两比较重排，以及为下游 AI 选择有用上下文；也提出可以补充或替代 RAG 中的部分 embedding 用途。[24]
更稳妥的落点是先做候选重排：原有检索系统召回一批资料，Jev 判断哪些片段真正与当前问题相关，再把筛选后的内容交给生成模型。这样测试的是上下文选择质量，而不是宣称一个新模型能直接替代所有向量检索基础设施。
它也能与浏览器操作衔接：点开搜索结果后，不一定要把整页内容塞给大模型，可以先判断哪些段落值得读。但检索召回率、重排质量和额外调用延迟，都要在自己的语料上测量。
方向 3：Agent 安全与工具调用检查——判断的不只是“能不能做”，还有“该不该做”。
官方建议在 LLM 输入、输出和工具调用上加入语义检查，识别提示注入、敏感数据暴露、策略违规和工具调用错误，并记录结构化结果及概率，方便追踪失败。[24]
这与电脑操作尤其相关：执行器能确认按钮存在，不代表这次点击符合用户意图。可以把动作是否越权、是否发送敏感内容等问题纳入检查，再交给确定性的权限规则处理。
但这是安全检查的建议用途，不是“能阻止所有注入”的保证。支付、发布和删除等高影响操作仍应保留权限限制、独立校验和必要的人类确认，不能用模型打出的高分取代这些机制。
方向 4：研究与引用核验——检查来源是否真的支持结论。
官方在科研场景中列出按纳入／排除标准筛选论文、检查引文片段是否支持主张，以及标出缺失的对照组、数据集描述和实验设置。[24]
对一篇案例汇总文章，可以把每条主张与对应原文配对，检查是否存在数字不一致、删掉适用条件或把作者观点写成事实等问题。它的价值是把容易漏掉的核查项显式化，而不是让模型凭空决定哪个来源权威。
例如，“约七秒查到航班”与“七秒完成订票”只差几个字，事实却完全不同。自动检查可以提醒编辑回看原文，但仍不能代替获取原始来源、核对日期和人工判断。
方向 5：客服与内容运营——把一份输入拆成多个独立判断。
官方列出工单分类、紧急程度、客户挫败感、流失信号、退款请求识别，以及按团队分流和核对回复是否符合政策；在内容治理中，还建议结合严重程度与置信度决定放行、提醒、复核或阻断。[24]
这些任务适合把“一句话决定怎么处理”拆成多个问题，再由代码组合。例如，同一张工单可以同时判断问题类型、是否要求退款、是否需要人工介入，避免把情绪强烈直接等同于业务优先级。
这里的价值不只是更快，而是规则更容易检查和调整。不过，情绪、风险和意图都是模型估计，涉及用户权益的处置仍要保留复核与申诉途径。
方向 6：从文本提取预测特征——不是让 Jev 直接预测销量。
官方建议从客户咨询、销售记录、评论和市场报告中提取购买意图、紧迫性、产品兴趣、供应担忧和竞争压力等语义信号，再与历史时间序列及其他结构化数据结合，交给预测模型。[24]
这比“问 AI 下个月卖多少”更具体：Jev 负责把文本变成可比较的特征，预测模型负责学习这些特征与真实结果的关系。官方也明确提到用留出的真实结果数据检验特征价值，而不是只凭几个看起来合理的分数。
这张地图值得补进文章的原因，是它把“快速判断”从几个酷演示延伸到了完整工作流。 但应始终分清两种证据：演示说明某件事有人做过；应用地图说明某件事值得尝试。二者都不自动等于生产环境已经验证。
六、三句宣传语，必须拆开看
“快 200 倍、便宜 400 倍”——先问任务，再问比较方式。
官方首页还列出 193.6 倍速度、444.6 倍成本优势。技术博客解释，这组数字来自其工作流评测，并承认可能接近真实收益的高端区间；测试工作流由内部团队构建，参照答案使用其他强模型的平均预测，而不是完全独立的人工真值。[2]
博客也披露，对照 LLM 使用了兼容其 API 的适配器，要求返回结构化决策和概率；这种比较方式可能比只返回简单答案更慢、更贵。演示中的较短输入，同样有利于突出 Jev 的输出效率。[2]
读者应理解为：它在特定决策型工作流中展示了很大的效率潜力，而不是所有任务都能省去两个数量级的成本。官方测试位置、网络距离、输入长度和调用编排都会影响实际体验。
“零幻觉”——保证格式，不保证事实。
官方博客明确表示，图表中的零值不是经验测试得出的“所有问题都答对”，而是由 schema 匹配保证推出的。[2]
翻译成工程语言：它不会输出不在约定范围里的结果，但仍可能在合法选项中选错。一个客服请求被稳定地分错队列，格式再正确也还是错误。
confidence 也不能被当作正确率承诺。官方文档将其解释为从概率分布计算出的统计量，并建议根据业务风险设置不同阈值，低置信度时交给人工或其他系统。[4]
“输出免费”——不等于整个系统免费。
当前公开价格为每百万输入 token 0.042 美元，输出 token 不收费。[2] 但真实系统仍要支付输入处理、语音转录、数据存储、运行环境以及错误处置的成本。
便宜会鼓励更密集的调用。官方说 Jev 的名字来自杰文斯悖论，恰好对应这种预期：单位成本下降，可能让使用量反而大幅增加。[2]
七、真正值得关注的，不是它替代谁，而是它改变了哪些设计约束
从 Jev Ultrafast 和 jev-use 到文档检查，这些案例共同指向的是高频、范围明确、依赖语义判断的节点。它们不只是分类、路由和评分，也包括 Agent 循环中反复出现的操作选择：当前该点哪里、输入什么类型的内容、等待还是结束。
浏览器和电脑操作因此不是边角案例，而是检验这条路线的关键场景。不过，一次选择格式合法，不代表目标正确；一串局部选择合理，也不代表完整任务成功。需要的是观察、选择、执行、验收的完整系统，而不是只有一个快速模型。
它不必独立完成写作、规划和工具执行。一个合理的组合，是让生成式模型负责创作或复杂任务，让决策模型负责局部判断，再由代码控制流程与权限。高风险动作仍要有独立校验和人工确认，不能因为响应快，就把出错后的后果交给模型承担。
对开发者来说，最有说服力的测试不是复刻“快 200 倍”的海报，而是选出自己已有的一项判断任务：固定输入和判定标准，与规则系统、小模型和现有方案比较准确率、漏检率、延迟及总成本，再看是否值得替换。
Jev 还处于早期阶段。现在能确认的是，它已有清晰的接口设计、公开的官方说明，以及一批可追溯的开发者演示；尚不能确认的是，这些优势能否稳定迁移到每一种生产环境。
但它提出的问题值得留下：当 AI 不必每次都说一段话，它能不能像普通函数一样，安静、快速地参与软件的每一次判断？
这比“又一个模型打败了谁”，更值得继续验证。
来源与核查说明
检索日期：2026 年 9 月 19 日。主要范围：9 月 15—18 日可公开检索的 X 原帖，辅以官方技术博客、文档和原作者测试长文。通过公开搜索与页面提取核验文字；本文未对所有演示视频逐帧验证，未亲自调用 Jev API 复测，也未获取 X 全站热度数据。
浏览量为本次提取页面或索引中的快照，可能滞后、变化，不是独立用户数；日期沿用原页面显示日期。厂商宣称、作者自测、产品原型、官方建议场景与本文分析已分别表述。第五节六类方向来自官方 Use Case Map，不计入前面十个已公开展示或报告测试的案例。“付费合作”仅在页面明确显示时标注；未标注不代表已证实不存在商业关系。
[1] Diogo Almeida，Jev 发布长帖，2026-09-15。https://x.com/CompleteSkeptic/status/2099925682726002904
[2] TypeSafe AI，Introducing System One Models & Jev，正文标注 2026-09-15；包含性能方法、适用边界和演示说明。https://typesafe.ai/blog/introducing-system-one-models-and-jev
[3] TypeSafe AI，Introduction：三类问题与并行求值接口。https://docs.typesafe.ai/
[4] TypeSafe AI，Confidence：概率、置信度及风险阈值。https://docs.typesafe.ai/confidence
[5] AI/ML API，Jev 与 Fable 5.1、GPT-6 Astra 国际象棋演示，2026-09-16。https://x.com/aimlapi/status/2100372930282573876
[6] Nader Dabit，预测启动器演示，2026-09-18。https://x.com/dabit3/status/2100756930054504776
[7] Moritz Kremb，语音浏览器演示，2026-09-17。https://x.com/moritzkremb/status/2100577979021832365
[8] Dan Shipper，Every 测试反馈，2026-09-15。https://x.com/danshipper/status/2099947471518474522
[9] Rohan Paul，Jev 解释帖，2026-09-15；页面显示 Paid partnership。https://x.com/rohanpaul_ai/status/2099946321495068746
[10] Chubby，Jev 介绍及验证保留意见，2026-09-16。https://x.com/kimmonismus/status/2100057080698950042
[11] Wall St Engine，发布摘要，2026-09-15；页面显示 Paid partnership。https://x.com/wallstengine/status/2099927802405654900
[12] Diogo Almeida，Doom 演示，2026-09-15。https://x.com/CompleteSkeptic/status/2099925687465570372
[13] Diogo Almeida，Wikiracing 演示，2026-09-15。https://x.com/CompleteSkeptic/status/2099925688925184171
[14] Zachi，广告过滤扩展演示，2026-09-17。https://x.com/iam_zachi/status/2100529273186472318
[15] Mike Taylor，分享 Jev 测试长文的原帖，2026-09-15。https://x.com/hammer_mt/status/2099928662489583948
[16] Mike Taylor，Mini-Vibe Check: TypeSafe’s Jev Judged Everything I’ve Written in 0.7 Seconds，Every，2026-09-15。777 次判断及另一个 12 片段对照实验的细节均来自此文。https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds
[17] Greg Pstrucha，安全管线测试反馈，2026-09-17。https://x.com/grichadev/status/2100437998571860087
[18] Gregor Zunic，Browser Use + Jev = Ultrafast 发布及航班演示，2026-09-17。https://x.com/gregpr07/status/2100411066966749359
[19] Browser Use，Jev Ultrafast 项目 README：动态动作空间、架构、任务范围与 MVP 限制。https://github.com/browser-use/jev-ultrafast
[20] Jev Ultrafast，性能测量说明：计时边界、调用数、费用披露、优化前后对照与失败记录。https://github.com/browser-use/jev-ultrafast/blob/452c1ad2dd628008f1d5608f28158d76e49e6cc0/docs/performance.md
[21] Cua，Jev + Cua Driver / jev-use 发布长帖，2026-09-17。https://x.com/trycua/status/2100649543079502213
[22] Cua，可选视觉感知扩展 PR：与 Jev 配方分离的实现和开发预览边界。https://github.com/trycua/cua/pull/3943
[23] Cua，2048 对照演示与单次运行限定，2026-09-17。https://x.com/trycua/status/2100649546481070362
[24] TypeSafe AI，Example use cases（Use Case Map），2026-09-19 访问。官方用于头脑风暴和设计工作流的场景地图，不是部署案例或性能验证报告。https://docs.typesafe.ai/concepts/use-case-map