刚出来的决策模型，在 x 上很火。我在 codex 里试了下，发现没有很快啊，我问 codex 适合操作哪种游戏，他说适合 2048 ，不适合毫秒级实时操作的游戏。然后我给他一个 2048 网站，让他玩通第一关，后面太慢了，我就停止了。然后我发他:感觉超级慢的啊，是不是 jev 的决策很快，耗时操作都在你这边截图，然后还要读图片.他的回答:
对，主要慢在我这边的操作链路，但 Jev 调用本身也不是零延迟。
这次测试大致是：
- Jev 每次决策：约 5 ～ 6 秒
- 启动 Playwright 、发送按键、重新读取页面：约 7 ～ 9 秒
- 截图后人工识别棋盘：额外增加时间
- 浏览器控制通道还出现过超时
所以慢的原因不是单纯 Jev ，而是：
截图 → 识别棋盘 → 调 Jev → 启动浏览器命令 → 按键 → 截图
其中最应该优化的是：
- 直接读取网页 DOM 中的棋盘数据，不经过截图识别。
- 保持一个长期运行的浏览器进程，不要每一步都重新启动
npx playwright。 - 只把有效方向交给 Jev ，避免它选择不会改变棋盘的动作。
- 让本地 2048 算法负责普通步骤，Jev 只做策略判断。
所以你看到的速度，确实不能代表 Jev 单独决策的速度；这次更像是“浏览器自动化 + 截图识别 + Jev”的端到端速度。 我看 x 甚至有用 jev 玩类似马里奥那种横板跳跃游戏的，不知道怎么接进去的。 jev 的官网是 typesafe.ai,大家可以去加入 waitlist,马上就能通过
Select Language