一个没有报错的失败案例
先看一个很典型的场景。玩家输入“做一个躲避陨石的小游戏，飞船左右移动，撞到陨石就结束”。模型生成了完整的页面：飞船贴在底部，陨石从上方落下，键盘左右键可以移动。运行时没有任何红色报错，看上去一切正常。
问题在于：碰撞检测函数写好了，却没有在每一帧的更新循环里被调用；结束画面写好了，却没有任何事件会触发它。游戏永远不会结束，分数永远是0。这种缺陷不会抛出异常，日志里干干净净，靠语法检查、单元测试甚至“页面能打开”这种冒烟测试，都发现不了。
无代码生成里最常见的失败，大多是这一类：每一块零件都在，零件之间没有接上。所以“检查AI写出来的游戏能不能玩”不能停在“代码能不能跑”，要检查的是游戏规则有没有真正生效。
生成之后的闭环：运行、观察、诊断、修复、重测
在金沙娱乐AI的无代码创作思路里，一个合理的流程，是把生成当成循环的起点，而不是终点。
- 生成：自然语言先被整理成规则描述，再落成可执行的代码或配置。这一步可以参考 自然语言怎样转成规则与可执行逻辑 里讲的中间表示。
- 运行：在隔离的运行环境里启动游戏，收集控制台错误、帧率卡顿、资源加载失败、状态变量的变化轨迹。
- 诊断：把“预期行为”和“观察到的行为”摆在一起比较。预期来自用户的原话和规则清单，观察来自运行时记录。
- 修复：带着具体证据去改，比如“第120帧陨石与飞船包围盒重叠，但游戏状态仍为running”，而不是让模型把整份代码重写一遍。
- 重测：修完以后，把之前所有通过的检查重新跑一遍，确认没有把别处改坏。
这个循环里最关键的是第二步和第三步：运行时必须产出可读的证据。如果游戏只是一个黑盒，只能截图给模型看，修复就变成了猜；如果运行时能输出结构化的状态日志，比如当前分数、存活状态、每条规则触发的次数，诊断才有抓手。
验证要分层，别把一切都交给“能不能打开”
把检查拆成几层，成本和覆盖面都会清楚很多。
| 层级 | 检查什么 | 典型发现 | 能否全自动 |
|---|---|---|---|
| 语法与运行时 | 能否加载，是否抛异常 | 变量未定义、资源缺失 | 可以 |
| 规则完整性 | 每条规则有没有事件、条件、结果 | 有“撞击结束”却没有触发路径 | 大部分可以 |
| 可达性与可完成 | 目标是否有办法达成 | 通关分数高于场景能产出的总分 | 需要试玩 |
| 行为一致性 | 游戏行为是否符合用户描述 | 说好的“三条命”实际一碰就死 | 需要试玩加比对 |
| 体验与难度 | 手感、节奏、公平感 | 第一关过难 | 部分自动，最终靠人 |
其中最容易被忽略的是第二层。一个可用的做法是，把用户的描述先拆成“核心规则清单”，比如移动、得分、失败、重开，再逐条检查是否存在对应的“事件、条件、动作”三元组，且这个三元组在运行时至少被触发过一次。“失败规则从未被触发”本身就是一个强信号。
会玩游戏的测试智能体
静态检查解决不了“游戏内应有行为”的问题，得让一个智能体真的去玩。学术上已经有这样的思路：有研究把游戏生成从一次性“代码到游戏”，改成“写代码与试玩的对话”，构造了包含200个浏览器小游戏生成任务的评测集，覆盖八种类型，让会真正操作游戏的GUI智能体按“游戏内应有行为”给游戏评分；其提出的Play2Code方法，在这个基准上的规则通过率为66.8%，比单次生成和智能体编码基线分别高出37.1和14.6个百分点。这些数字来自该研究本身的评测设置，不能直接当成任何产品的表现。
测试智能体不需要是高手。另有研究提醒，大模型智能体不一定是高水平玩家，但可以用来衡量游戏难度：如果一个只会随机乱按的智能体一直存活，说明游戏没有威胁；如果一个会基本躲避的智能体在第10秒（示意）就必死，说明难度设置有问题。
测试智能体一个好用的分工是这样：
- 随机探索型：随机按键、随机点击，专门找崩溃、卡死、不可达状态。
- 目标驱动型：拿到“通关”“拿到100分”这类目标去尝试，检查目标能否达成。
- 对照型：读用户的原话，逐条验证，比如“撞三次才结束”就故意撞三次看结果。
工具编排上，这些智能体需要调用启动器、输入注入、状态读取等工具，这也是为什么无代码生成更适合走 Function Calling 与工具链 的路线，而不是让一个模型独自包办。
修复不能越修越坏
发现问题只是一半。带着“第120帧碰撞未触发结束”这样的证据回到修复环节，改法通常是局部的：补上碰撞函数的调用，或者补上事件与结束画面的连接。
真正的风险是修复引入新问题。比如为了让陨石碰撞生效，改了更新循环的顺序，结果分数结算晚了一帧，导致结束画面显示的分数少1。所以每一次修复后都应该做两件事：把此前所有已通过的检查重放一遍，作为回归测试；同时给每个版本留快照，一旦回归失败，可以直接回到上一个能玩的版本。
机器验证不了的部分
最后要老实划边界。机器可以保证一款游戏“至少是完整的”，规则接得上、目标够得着、不会卡死。它很难替你判断：这一关是不是无聊，反馈够不够爽，难度曲线是不是合理。
所以更务实的设计（也是金沙娱乐官网倾向的产品思路），是把验证结果如实呈现给创作者：哪些规则被测过，哪些目标被智能体达成过，哪里存在不确定。这样创作者拿到的不是“已完成”的承诺，而是一份可以继续打磨的起点。
对金沙娱乐这类无代码创作工具来说，下一步值得追问的是：当用户说出“再难一点”这句话时，验证系统能不能重新证明游戏依然能通关。
