大家有没有去试一下 jev 啊

[oldManNewThought]

刚出来的决策模型，在 x 上很火。我在 codex 里试了下，发现没有很快啊，我问 codex 适合操作哪种游戏，他说适合 2048 ，不适合毫秒级实时操作的游戏。然后我给他一个 2048 网站，让他玩通第一关，后面太慢了，我就停止了。然后我发他:感觉超级慢的啊，是不是 jev 的决策很快，耗时操作都在你这边截图，然后还要读图片.他的回答: 对，主要慢在我这边的操作链路，但 Jev 调用本身也不是零延迟。

这次测试大致是：

• Jev 每次决策：约 5 ～ 6 秒
• 启动 Playwright 、发送按键、重新读取页面：约 7 ～ 9 秒
• 截图后人工识别棋盘：额外增加时间
• 浏览器控制通道还出现过超时

所以慢的原因不是单纯 Jev ，而是：

截图 → 识别棋盘 → 调 Jev → 启动浏览器命令 → 按键 → 截图

其中最应该优化的是：

1. 直接读取网页 DOM 中的棋盘数据，不经过截图识别。
2. 保持一个长期运行的浏览器进程，不要每一步都重新启动 npx playwright。
3. 只把有效方向交给 Jev ，避免它选择不会改变棋盘的动作。
4. 让本地 2048 算法负责普通步骤，Je​​v 只做策略判断。

所以你看到的速度，确实不能代表 Jev 单独决策的速度；这次更像是“浏览器自动化 + 截图识别 + Jev”的端到端速度。 我看 x 甚至有用 jev 玩类似马里奥那种横板跳跃游戏的，不知道怎么接进去的。 jev 的官网是 typesafe.ai,大家可以去加入 waitlist,马上就能通过

[neptuno]

已经嵌入到自己的项目里面了，做决策用

[jacketma]

不是说毫秒级响应吗？
实际 5~9 秒就完全没优势了啊

[flik]

是不是需要转为 16 宫格的会快很多呢 不经过截图 而是直接获取对应的块的文本值。通过 cdp 控制就行
null|null|null|2
null|null|2|null
null|null|null|null
null|null|null|null

[oldManNewThought]

@neptuno 老哥是如何嵌入的啊？

[oldManNewThought]

@flik 我估计还得是截图，因为那个游戏很可能是 canvas 写的

[tomchen]

叫 codex 写个 userscript 读 DOM 不就行了，用的时候除了 jev 不用额外的 AI 更不用截图（每步都截图给 codex 得出当前状态？超级小题大做的感觉😂）

[shunia]

你这个 case 应该用这个： https://github.com/browser-use/jev-ultrafast

[penisulaS]

我其实在等一个类似的开源模型

[7gugu]

@penisulaS https://github.com/NandhaKishorM/laya 有的

[neptuno]

@oldManNewThought 搞了个 ai 自动追剧软件，之前是大模型帮我做一些决策，返回的 json ，现在替换成 jev 就是变得更快了而已。

[Newbee24]

@neptuno #1 老哥分享下经验

[delandwu]

试玩了一下，觉得还可以，https://jevstation.com