创作者输入：“做个点球大战小游戏。”这是一个范围很小的需求：没有跑动，没有传球，没有越位，只有射门和扑救。正因为小，它很适合用来说明一件事——即便是最简单的体育小游戏，从文字到可玩原型之间也至少隔着六层生成，每一层都有明确的产物和必须通过的检查点。
下面按乐鱼体育生成流程中的层级逐一列出。数值均为设计参考。
第一层 Prompt：把一句话变成结构化需求
产物：一份字段表，包括运动类型（足球，点球）、模式（单人对电脑）、玩家角色（射门还是扑救，或轮流）、轮数（默认5轮）、难度（默认中等）。
检查点：
- 每个字段是否都有值，是用户说的还是系统推断的，是否已标注来源。
- 是否存在无法推断、且猜错代价高的字段，例如玩家只射门还是射门与扑救轮流——它决定了后面要生成一套还是两套操作。这类字段应在本层用一个问题确认。
第二层 Design：确定玩法循环
产物：一份玩法说明。以默认设计为例：玩家与电脑轮流主罚，玩家射门时通过滑动选择方向和力度，玩家扑救时在球出脚后点击扑救方向；每轮一射一扑，五轮后比较进球数。
检查点：
- 一次完整的玩法循环是否闭合：开始 → 射门 → 判定 → 切换 → 下一轮 → 结束。
- 玩家在每个环节是否都有可做的事，是否存在只能看不能操作的长时间等待。
- 操作方式是否与目标设备匹配，手机上用滑动，键盘上用方向键加蓄力。
第三层 Asset：生成素材，但素材要带逻辑属性
产物：球门、球、罚球点、门将、主罚球员、背景看台等素材。
检查点：
- 球门不只是一张图，要有门框碰撞体和“球完全越过门线”的判定区域。以标准球门为参考，宽7.32米、高2.44米，罚球点距门线11米。
- 门将的扑救动作要覆盖球门的主要区域，左上、左下、中路、右上、右下至少五个方向都要有对应动作和判定范围，否则会出现某个角永远扑不到的情况。
- 素材比例是否一致：门将站在门线上时，伸手够不够得到横梁附近。
这一层最容易出现的错觉是“素材做完了游戏就做完了一半”。实际上素材只是被后面各层引用的对象，没有碰撞和判定属性的素材，只能出现在截图里。
第四层 Rules：生成规则，并检查规则之间的关系
产物：规则表。每队各罚5球，进球多者胜；若5轮后打平，进入突然死亡，每轮一射一扑，一方进一方不进即结束；若某一方在剩余轮次里已不可能追平，比赛提前结束。
检查点：
- 每种可能的比分走向是否都能到达终局。例如3轮后3比0，对方剩余2轮最多追到2分，应提前结束；如果规则层漏掉了这条，游戏会继续打完毫无悬念的两轮。
- 突然死亡是否有出口。理论上它可以一直继续，所以需要确认是否设置轮次上限，以及达到上限后如何判定。
- 用户修改后是否产生冲突。如果创作者把轮数改成3轮，同时又要求“先进5球者胜”，规则层应当提示两者矛盾，而不是生成一个永远结束不了的游戏。
第五层 Logic：把所有东西串成游戏循环
产物：可运行的游戏逻辑，包括输入处理、射门物理、AI门将决策、进球判定、计分、轮次切换、终局判定和UI更新。
检查点：
- 比分是否只有一个来源。进球判定写入规则层的比分，UI只读取显示，不自己计数。
- AI门将是否有合理的决策方式。以中等难度为例，扑救方向按一定概率猜对，反应时间留有空隙，而不是读取球的实际方向后每次都扑对。
- 每个状态是否都有出口：射门后球停在门框上方、球弹回场内，这些边界情况是否都能判定结束并进入下一轮。
第六层 Prototype：让AI先玩几百局
产物：一个可以交给创作者试玩的版本，附带自动测试报告。
检查点：
- 模拟数百局，是否每一局都能正常结束，突然死亡最长持续了几轮。
- 玩家射门命中率和门将扑救率是否落在设计区间内。以设计参考为例，中等难度下玩家射门进球率在六到八成较为合适，如果模拟显示超过九成，说明门将太弱。
- 是否存在“必进点”，即某个方向和力度组合每次都能进。这类问题靠少量人工试玩很难发现，靠大量模拟则很容易暴露。
通过检查的版本记为V1交给创作者。创作者说“门将太强”，调整后生成V2；觉得V2太容易，可以回到V1。关于让AI自动试玩并定位问题的更多做法，可以参考避免一开局就无法通关的检查方法。
为什么要分这么多层
把六层合并成“一步生成”在技术上并非不可能，但问题会被混在一起：比赛结束不了，是规则漏了提前结束，是逻辑层的状态没有出口，还是素材的判定区域画错了？分层的意义就在于每一层有明确的产物和检查点，出错时能定位到具体哪一层，只重做这一层及其下游。
点球大战只是最简单的例子。换成足球全场比赛或赛车，每一层的产物更复杂，检查点更多，但层级结构不变。在乐鱼体育的生成流程里，这六层对应着不同的检查与回退节点；如果想看一个完整比赛从地图、球员、AI对手到游戏循环的逐层依赖和常见断裂，可以阅读从地图、球队、规则一直生成到可玩小游戏。
