Vibe 一个桌游模拟器

发表于 |

作为一个桌游爱好者，我打算用 Codex 去 Vibe 一个桌游模拟器，这样我可以尝试自定义规则和 Bot 强度。这篇文章我会介绍我 Vibe 的经验。

我的项目是 https://github.com/CalvinNeo/OpenBoardGame。

D0

作为 Demo 实现了一个掼蛋游戏。

发现问题：

  • AI 对规则理解非常不正确，例如缺少对三带二、同花顺炸弹的支持，并且也不能顺子的长度和一手牌数量的上限。
  • AI 对空间感不熟悉，一些提示文字和牌重合。

# Jan28 - Jan29

在这 2 天中，我大概用了 45 刀左右的额度。完成了 Cabo、骷髅牌、你画我猜、璀璨宝石四个游戏逻辑和 Bot 的开发。并且，我还支持了断开重连、房间管理等机制。我还优化了 UI 的美观度和便捷度。

AI 会理解错一些点。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/ab26a9c00cd5d9720b39bf3e248b672881cb52ed 这个修复 commit 就展示了 AI 对璀璨宝石最大数量的多次理解问题：

  1. 一开始，它根本没有实现这个限制。
  2. 后面，它实现为只有超过 10 才不能拿，但是从 9 到 12 这个行为是被它允许的。
  3. 最后，才修改对了。

AI 会漏掉一些情况。例如 https://github.com/CalvinNeo/OpenBoardGame/commit/c8e82736975325f0b9300b471524ec86b005129e#diff-794e220aafafcfac193a89abd6fb142d92255d544728f217d64e7a1162c79e28 这个修复 commit 展示了 AI 对用户离开规则的遗漏：

  1. 先前，AI 处理了 in game 的情况。此时如果最后一个活人玩家离开游戏，那么这个房间可以被手动清理掉。
  2. 但是，它漏掉了 in lobby 的情况。此时房间并没有开始游戏，那么玩家离开房间（比如创建一个新的房间）不会导致该房间出于可以被清理的状态。

经验：

  • 让 agent 缩小阅读的范围。例如可以告诉它“这是完全的前端修改，你不需要看后端代码或者其他游戏的代码”，这样它就可以更快解决问题，并且能节省不少额度。这随着项目增大是尤为有效的，因为看 thinking 是可以发现它有倾向去学习其他代码是怎么做的。
  • 让 AI 先整理信息，然后再写一个 design 征求意见非常重要。因为 AI 在实现的时候还是偏向于漏点东西的，这也可能是出于对问题的不正确理解。
  • 逻辑比较独立的部分，可以让 AI 整理出测试。虽然目前也没看到 AI 会主动修改代码从而 break 掉测试，但这样会更有自信。

Jan 30 - Jan 31

这几天主要实现了出包魔法师、猜狐狸、截码战三个游戏。

Feb 1 - Feb 3

这几天主要实现了角斗士棋、Store&Load、印象花语、AI 画物语四个游戏。主要是由 Gemini 生成游戏说明书，再由 Codex 生成 design。等我 Review 了之后，再实现代码。

角斗士棋和印象花语中都涉及到了拖拽旋转对象的设计。我发现 AI 在适配手机端上的拖拽是相对比较蠢的，需要手动告诉怎么搞。

角斗士棋实现起来很简单，但是其实要打磨的很多：

  • 手机版如何精准地把方块放到格子里面就很难困难。因为每个方块的焦点并不是方块的重心。后来加了上下左右移动的键，但是感觉还是很蠢。
  • 还有一些奇怪的 bug。

印象花语这个游戏，我对实体版的一些物理效果进行了模拟：

  • 因为印章可以印得深浅不一，所以我增加了点按时长来决定透明度的机制。并且我也增加了根据色彩学原理来模拟印章叠加的效果。
  • 因为可以倾斜印章，使得只盖一半。所以我增加了一个 Mask 机制，可以去 Clip 印章。这个就好像我在按之前垫了一张废纸，这样章可以只盖一半在画布上。

我觉得这一部分涉及到物理世界的原理的，应该只有人类能意识到并且提出来。

Store&Load 是非常有意思的点，AI 当时给我提供了一个完全不一样的解决方案。例如它执着于解决 Session 的问题，如何处理同名玩家和同名 Room。但是我提出了一个非常简单的做法，就是完全新建一个 Room，然后新玩家可以进去 Claim 老玩家的 Seat。这样做能够减少很多的复杂度。另外，我还发现新创建的房间并不支持 Auto Save 选择了，这个我觉得也是 AI 本身缺乏引申的能力。

AI 画物语的实现是跟其他桌游完全不一样的，因为要涉及生成图。所以我开了 https://github.com/CalvinNeo/aidixitgen 这个 repo。

一开始它是用的 pollinations 做的。然后我发现这个工具经常生成水母，然后问了他，他说是提示词的问题：

为什么这个代码里面的 prompt 这么喜欢生成 jellyfish？
这是一个非常经典且有趣的 AI 生成现象，通常被称为 “模式坍塌” (Mode Collapse) 或 “安全区偏差”。出现大量水母（Jellyfish）、热气球、云朵、漂浮的岛屿，原因主要有三点：
关键词的“刻板印象”： 你的代码里用了 surreal（超现实）、dreamlike（梦幻）、whimsical（异想天开）这些词。 在 AI 的训练数据（Latent Space）里，水母是“梦幻”和“超现实”的超级代表物。它们透明、发光、漂浮，长得就像外星生物，完美符合 AI 对“梦境”的理解。只要你还要“唯美”和“超现实”，AI 就会懒惰地选择水母。
Prompt 缺乏约束： 我们在请求 AI 写创意时，给的指令太宽泛了（”Generate ONE single short… description”）。当指令太宽泛时，AI 会倾向于输出它认为“最稳妥、最符合题意”的高概率词汇。对于 Dixit 风格，水母就是那个“最稳妥”的答案。
风格修饰词的引导： 我们在画图时强制加了 soft colors（柔和色彩）和 floating（虽然没写但 dreamlike 隐含了漂浮感）。这也极大地增加了生成海洋生物或云端生物的概率。

然后，我又发现它生成的东西太容易重复了，例如几乎生成了两个只是风格不同的钟。所以我后面又设计了双主体的方案，结果最后生成的结果是比较理想的了。

后来发现 pollinations 一直 502 了，所以就换 hugglingface 了。

Feb 4 - Feb 6

这几天主要实现了前端美化、Flip 7、德国心脏病、绝妙误解。

主要是由 Gemini 生成游戏说明书以及设计。然后由 Codex 去实现。但是我要求 Codex 在实现前先问我不清楚的项目，而不是自己随便实现一版。事实发现，让 Codex 去问一下自己不知道的，而不代替我做决定，是很重要的。

AI 前端的主要问题：

  • UI 直白
    例如用一个列表表示玩家信息。用一个表格表示当前状态。这对玩家而言体感不好，感觉是在上班。
  • 没有交互设计
    特别是手机端玩家，操作的时候需要翻来翻去。
  • UI 可能存在 Bug
    例如在手机端会发现 Flip 7 的 Game 面板会非常少。

德国心脏病的开发是非常典型的。主要包含几点：

  • 得到的开发计划是经典版的 Halli Galli，也就是牌上的水果一定是相同的。这个跟我们玩的不一样，所以后面让它开发了一个 DLC 一样的东西。
  • 电脑根本没有给翻拍和按铃的等待时间，所以加上 bot 之后，基本 bot 都是秒按铃，秒翻牌，根本没法玩。即使没有 bot，我们也需要考虑人类的反应时间，以及各个网络的延迟。所以我这里要求加了等待 3s 的按铃时间，以及在点击翻拍后，有一个 1s 的倒计时，方便大家准备看新水果。
  • AI 生成的界面依然是列表，这个我让 AI 改成了围成一个圆。

Feb 7 - Feb 10

主要工作是修复之前各个游戏的问题。例如：

  • cabo 的规则实现错误
  • flip7 的相关问题
  • 继续修理绝妙误解中糟糕的前端问题
  • 印章话语支持投票
  • 支持日志复制
  • 发现之前代码中有 valid 检查，一直是死代码，启用

实现了新游戏，包括：Gold Rush、Hanabi、Cyber Pictures、The Gang、逻辑猫。

对 FRONTEND.md 进行了修订，后续的移动端 UI 开始要好一些了。

此外，还支持了新的功能：

  • Download Memories，用来下载整个游戏的回放
    实现的过程中，发现设计非常死板。例如花了大篇幅去展示什么 user id，但是游戏内容就缩在一小列里面。而且他非常喜欢表格。
  • 在游戏过程中开启 Auto Save

Feb 11 - Feb 12, Feb 26-27

主要支持了我画我猜、方鸟、小早川、牛头王。快艇骰子。

方鸟这个游戏非常有趣，是 Gemini 生成了一段很有歧义的规则说明，然后 Codex 直接按照错误的方式理解了。

Feb 28 - Mar 12

这段时间开始尝试探索 AI 多模态能力的边界。主要开发的游戏有历史奇旅、卡卡颂、德州扑克、project L、璀璨宝石宝可梦。此外，还尝试了诸如 Claude code 等其他模型的能力。

其中：

  • 历史奇旅主要是识别质量较高的游戏卡牌
  • 卡卡颂是识别卡牌，并能拓扑地利用它们
    实际上，识别是最难的。我大部分时间用来调试 Codex 生成 72 个基础地图。Codex 经常是分不清城堡是否占边，是否占角。还分不清城堡和道路的重合关系。在生成 svg 的时候，非常喜欢用圆而不是二次曲线去拟合，导致生成的图片很僵硬。
    但是，一旦生成成功，后面包括地图连通性判断就非常简单，直接一遍过。
  • project L 是阅读游戏说明书，然后生成
    这里面主要是前端显示问题。就是一个 svg 生成好好的，让它转成前端，就变成了长方形的长条而不是正方形的格子了。
  • 宝可梦是识别质量较低的游戏卡牌
    可以说非常痛苦，目前来看人工校对是必要的。强烈建议对于这种任务，让 ai 首先生成一个校对工具，这样每次的错误至少是能收敛的。另外，确实是有 corner case AI 无法识别，这样就只能人工标注。
    另外，这种 case，AI 喜欢写一段识别代码，我建议提示 AI 不要用 tesserocr。另外，这种类似于“蒸馏”的方式其实挺好。

此外，还进行了一些优化：

  • 将 app.js 拆分以减少 tokens 开销
  • 引入 vendor 减少 cdn 故障导致的无法游戏
  • 增强游戏选择界面
  • 引入帮助功能