做游戏时用了 AI，玩家运行游戏时未必还要调用模型。一段生成好的程序，可以像其他程序一样处理移动、碰撞和升级。模型参与过制作，并不会让每次按键都产生 Token 费用。
第七期聊到 PokéBonk，使用感受集中在几个细节：手机和电脑都能打开，再次进入时进度还在。节目没有提供它的完整技术栈或经核实的经营数据。可以从这些体验谈网页游戏的完成度，不能替开发者断言它到底怎样使用 AI。
哪些内容在制作时确定，哪些需要现场生成
假设做一个打怪升级游戏。地图、敌人行为、掉落规则和装备说明，都可以在开发时生成并写进程序。玩家重复游玩，执行的是已经交付的代码。
若希望每个 NPC 都能针对玩家的自由输入作答，模型就进入了运行环节。此时要考虑一次对话的等待、调用失败的处理，以及玩家人数增加后的费用。也可以只让少数角色具备这项能力，其他部分沿用固定规则。
选择时可以拿一段玩法具体比较：预先写好的分支是否已经够用？自由生成是否带来玩家能够感受到的变化？如果只是在相同意思上换几种措辞，在线生成增加的费用和不稳定性可能不划算。
初始投入可以分摊，服务费用仍会发生
一个假设的单人浏览器游戏，初始制作成本是 C，累计有 N 次游玩。只分摊这笔制作成本，每次是 C/N。这个算式没有计入资源下载、服务器和后续维护。
账号、排行榜、联机状态以及支付，都可能带来持续开销。运行时使用模型的部分，还要另算调用成本。讨论低成本分发时，需要先说明游戏究竟把哪些计算留给客户端，哪些仍依赖服务端。
节目提出的做法是把制作阶段的投入变成能够被反复使用的作品。这种成本结构值得尝试，但收入还取决于玩家是否愿意付费，以及获客、更新和运营要花多少钱。
一个链接能打开，手机上是否真的好玩
MDN 的网页游戏发布指南介绍了自行托管和市场分发等路径。网页方便通过链接试用，适合把一个小版本尽早交给别人玩。
适配仍要在设备上检查。鼠标能精确点击的小按钮，放在触屏上可能难以操作；键盘移动改成虚拟摇杆后，会遮住多少画面？页面进入后台再回来，游戏是否恢复？进度保存在当前浏览器，换设备后是否还能继续？
这些问题在桌面演示里很容易漏掉。浏览器的图形、输入、音频和存储能力提供了开发基础，实际体验还要由游戏处理。
早期版本可以只做一段完整流程：进入、游玩、失败或结束、退出，再次打开。把这段流程交给朋友，观察他在哪儿卡住，比先堆更多关卡更容易发现问题。等他愿意主动再玩一局，再考虑增加内容和付费设计。