我把 Jev 接进 4 款小游戏：从连连看到塔防，它到底会不会玩？

大家好！我是瓜哥。前互联网技术副总裁，现在带队死磕 AI 编程。

这几天一直在玩 Jev，看到很多人都在把 Jev 接到游戏里来测试它的决策能力。

我也把 Jev 接进在连连看、消消乐、卡丁车、塔防游戏里，从配对、消除走到驾驶和布防，来看看它的决策速度和质量。

测试流程相同：程序整理状态并筛出候选，Jev 选一个，游戏代码执行。

这些小测验通过调用 TypeSafe Jev API 完成，四种玩法都使用 Choice，从程序提供的有限动作中选一个。

今天，我们就一起来看看 Jev 的真实表现。

如果你也在自己折腾产品、天天跟 AI 写代码较劲，那这个号你大概率会觉得对味。

一、游戏都在问下一步选哪个

1. 从清牌到守城，问题逐关升级

① 我把四种玩法放进一张表

② 这张表并不是给模型打分

四组运行来自不同游戏和时间，动作数量也不同。

我把它们当作接入案例，考察 Jev 在决策上的表现。

2. 每一回合都经过同一个动作回路

① 代码先准备输入，Jev 再选候选

每一局都按这个顺序运行：

1. 游戏生成当前状态

1. 代码筛出合法动作

1. Jev 返回一个候选

1. 程序再次校验后执行

下一步再读取新状态，发起下一次判断，如此循环。

② 接口没有接管鼠标或游戏规则

四个网页绘制棋盘、赛道和敌军，也计算消除、计分、移动、攻击与碰撞，Jev 只参与预先定义的判断点。

每一步都进行了记录和检查，来确保 Jev 的调用和决策有效。

二、连连看：程序先算，Jev 再选

这类游戏，可能会有多个合法候选。

Jev 会对候选的概率进行判断，快速给出决策结果后，本地程序仍会再次检查，随后才执行消除。

我看了日志，按逐条请求记录还原棋盘、候选和 Jev 返回值，能清楚看到 18 次选择如何逐渐清空棋盘。

1. 36 枚花果牌，最后被逐对清空

① 牌面画出来以前，棋盘已经是数据

这盘棋盘是 6×6，共 36 枚牌、18 对。

网页画面里有柿子、梅花、锦鲤和茶壶，程序内部用名称保存每个位置，空格则记成 null。

② 能不能连，先由游戏规则计算

代码检查两张同图案的牌之间是否存在空路径，并限制最多两个转弯。合法牌对由程序列出，Jev 不能把柿子连到茶壶，也不能选候选表里没有的坐标。

结束后查看日志，18 次请求都成功，每次选择都属于当时的合法候选，最后清空 18 对。

小结一下：

从这个 Case 能看出，你不能指望 Jev 太多，想要发挥作用，任务相关的选项和约束都要提前设置。

三、消消乐：Jev 决定消除谁

这一关仍是棋盘，但一步棋不仅会拿走宝石，还会触发消除、计分和补位。

Jev 收到宝石类型、分数、当前回合和交换候选。

浏览器绘制宝石动画、消除效果和补位过程，每回合都会生成新状态。

1. 八步实验只观察它怎样选

① 先从相邻交换里筛出能三连的动作

消消乐同样是 6×6 棋盘。

每一步，程序先筛出能形成三连的相邻交换，再交给 Jev。

Jev 选择交换方向，程序负责消除、加分、下落和补位。

② 得分 240，不等于已经通关

这次运行固定观察 8 步，每次选择都来自程序生成的候选，最后得到 240 分。

小结一下：

Jev 在这游戏里依然是只负责对输入问题进行判断，更多的处理动作还是要依赖程序本身来完成。

四、卡丁车：Jev 选驾驶动作

上一个消消乐每一步都会等上一步结算完，再生成新棋盘。

卡丁车有点不一样，API 还在返回时，玩家和对手仍然沿赛道移动，这对决策速度提出了更为严苛的要求。

1. 状态里有车道、路况和附近车辆

① 三圈赛道被拆成 36 个决策时点

游戏设置是三圈赛制，每圈 12 段。

请求包含圈数、赛段、车道、速度档、氮气、未来两段路况和附近车辆。

候选动作包括保持、左右变道、氮气和刹车。

② 请求等待期间，赛道不会暂停

程序收到动作后，才更新玩家车道、速度和位置。

状态生成、API 返回、动作生效是三个不同时间点，决策输入速度越慢，输入里的路况就越可能过时。

2. 两次碰撞不是“两次撞路锥”

① 把总数拆成事件，原因就清楚了

36 次请求全部成功，这局 P1（玩家车辆），记录到 2 次碰撞。

遥测显示，一次是对手车接触，另一次是油渍。路锥碰撞为 0 次。

小结一下：

通过这个赛车小游戏，这其实提醒了我们一点，对于实时性要求极为苛刻的场景，Jev 请求的延迟可能是个致命伤。

五、塔防：Jev 选塔型和坐标

最后一关，再加点复杂性：每次布防都要花有限军资，还会改变接下来几波的防线。

这组一共 3 波兵线，真实请求共 8 次，最后顺利通关。

1. 敌军、军资和地图覆盖一起进入状态

① 程序先计算能建的位置

塔防请求包含军资、城防生命、波次、敌军数量、敌人位置、已有防御塔和塔型。程序依据金币是否足够、位置能否建塔、能否覆盖道路或敌人生成候选位置。

② 候选范围带着实验设计的取舍

提供三种不同的防御塔。

当城防安全时，程序设计里优先提供尚未建造过的塔型，从而达到弓箭塔、法师塔和哨兵兵营搭配效果。

2. 八次选择推进到第三波，胜负记录仍要留边界

① 第一座塔是一个具体坐标

第一波开始时有 100 金、20 点城防和 0 座防御塔，程序列出 18 个位置。

Jev 选了第 12 列、第 7 行的弓箭塔，选项概率为 0.36，confidence 为 0.33。

游戏复核金币与坐标后才放置。

小结一下：不同的防御塔、三波不同的敌方单位。在一个复杂的判断场景下，大量的规则还是需要由程序来预设，当前没办法让 Jev 像其他通用大模型一样去做复杂的推理和决策，只能停留在比较明确的判断选择上。

六、 Jev 决策接口的边界

1. 本次演示都使用 Choice

① state 负责告诉它当前局面

TypeSafe API 请求中的 state 可以是文本、JSON 对象或数组，问题写在 questions 里，四款游戏都用 type: "choice"。

候选 ID 和说明放在 criteria，Jev 返回所选项及概率分布。

② 本文没有用到 Score 或 Noul

官方 API 还提供 Score 和 Noul，在本次任务里没有调用。

四款游戏都把任务设计成：从候选动作中选一个。

Choice 的边界由程序列出的答案决定。

2. Jev 收到的是文本与 JSON，不是游戏画面

① 画面给人看，结构化状态给 Jev

TypeSafe 当前 Models 文档说明，Jev 接收文本输入，包括字符串、JSON 对象和文本数组，不接收图片、音频或视频。

棋盘、赛车和塔防地图由本地程序绘制，游戏代码把需要判断的信息转成状态和候选，再发给 API。

② 这证明“能接入”，没有证明“最会玩”

日志证明 Jev 能参与动作范围明确的游戏回合，程序也能检查并执行返回结果。

但实验没有对照 GPT、Claude、随机策略或最优解，也没有多次重复运行来测胜率。

目前只能说决策链路跑通，但并不能说 Jev 能提高游戏里的决策表现。

七、写在最后

通过这四个小游戏的测试，可以给出三个结论：

1. 在 Jev 发挥作用前，程序需要提前做好相关准备。包括输入什么给 Jev，让它如何做判断，是选项，评分还是置信度。

1. Jev 的输入和输出都是很标准的结构化，保证了决策速度确实快于一般的通用大模型，但面对复杂场景的时候，依然需要 GPT 这样的模型帮它提供高质量的输入信息。

1. Jev 除了能玩游戏，其实还可以进行更多场景的扩展，比如企业内的审批流程、产品需求评审、安全风险识别等。

如果你对 Jev 还能干什么感兴趣，点个关注，下期带来 Jev 在企业审批流程场景的实践分享。