刚出来的决策模型，在 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,马上就能通过