让模型写出一段比赛规则并不难，难的是让它理解这条规则在一张具体地图上、在物理条件下、在真实对抗里会不会成立。本栏目按“提示词→生成→模拟→测试→修正”的顺序，拆解体育游戏生成背后的模型分工。
假设用户对乐鱼体育说：“做一个雨天的山地自行车计时赛，难度中等，8名选手。”一个纯文字大模型可以很快写出一段像模像样的描述：赛道全长12公里，包含三段技术下坡，雨天路面湿滑。但这段文字没有回答任何真正决定游戏能不能玩的问题：12公里在游戏里骑完需要多久，第二段下坡的坡度是多少，湿滑路面让刹车距离增加了多少，8名选手同时出发会不会在第一个弯堵死。体育游戏生成需要的不只是会说话的模型，而是一组分别理解空间、物理、规则和对抗的系统，由它们共同完成从提示词到可玩游戏的过程。
一个面向体育游戏的生成系统，至少要理解四类知识。第一类是运动本身的规则，比如篮球的进攻时间、高尔夫的标准杆、赛车的发车顺序。第二类是空间，赛道的弯道半径、雪道的坡度、球场的尺寸比例。第三类是物理，球的弹跳、车辆的抓地力、滑雪者的速度与转弯半径之间的关系。第四类是游戏设计，难度曲线、玩家节奏、AI对手的行为。只懂其中一类，生成结果就会在另一类上出错。关于这四类知识的更详细拆解，见体育游戏生成大模型到底需要理解哪些东西。
在乐鱼体育的系统设计里，体育游戏生成被拆成六个相对独立的能力模块，每个模块有明确的输入和输出：
| 模块 | 负责的事 | 典型输出 |
|---|---|---|
| Map AI | 按运动规则生成地图并检查可达性 | 赛道、雪道、球场布局 |
| Event AI | 生成球队、赛制、赛程和晋级逻辑 | 对阵表、积分规则 |
| Rule AI | 把自然语言规则转成可执行条目并检测冲突 | 规则表、冲突提示 |
| Sports Game Generator | 把地图、规则、角色组装成可玩原型 | 小游戏可运行版本 |
| Sports World Generator | 生成场馆、天气、观众等赛事环境 | 环境参数与场景 |
| Sports Game Agent | 自动试玩、测试并提出修改建议 | 测试报告、问题列表 |
这些模块面向的是地图生成、赛事生成、游戏创作等不同栏目的功能，但它们共享同一套规则与空间表示，这样一张地图可以直接被赛事和小游戏引用。
文字大模型在这个系统里很重要，它负责理解用户的意图、补全缺失参数、解释系统做出的决定。但它有几个天然的短板：它描述的空间关系无法直接验证，“一个急弯接一段长直道”在文字里很合理，放到坐标系里可能两段根本连不上；它对数值不敏感，可能写出一个Par 3却长达400码的洞；它也无法知道一条规则在实际对抗中会产生什么结果。所以在乐鱼体育的流程里，文字模型的输出会被转成结构化参数，交给空间模型和规则引擎去落地，而不是直接成为最终结果。详见AI为什么不能只靠文字大模型生成完整体育游戏。
空间模型负责把参数变成具体的几何：路线的每一个控制点、每一段的坡度和宽度、障碍的坐标。这里会用到程序化生成与约束求解，例如要求“相邻两个弯之间的直道不短于150米”“任何一段坡度不超过所选难度的上限”。物理模拟则回答“在这样的几何条件下，运动会怎样发生”：一辆车以某个速度进入某个半径的弯道会不会滑出，一个跑酷角色以最大助跑速度能跳多远，一颗高尔夫球在逆风中的落点会缩短多少。空间和物理两层结合，才能判断一张地图对玩家来说是可以完成的，而不只是看上去可以完成。
规则引擎把Rule AI生成的规则条目变成确定的状态机：比赛处于什么阶段，哪些事件会触发得分，什么条件下比赛结束，同分时如何判定。规则引擎的好处是可以做静态检查，比如发现“先得21分获胜”和“每局最多得15分”同时存在，这是一个永远无法达成的胜利条件。运行时则是游戏真正跑起来的地方，它接收玩家输入，驱动AI对手，按帧推进物理和规则，并记录每一个事件。运行时的日志同时也是后面测试Agent分析问题的依据。
测试Agent是整个系统里最接近“玩家”的部分。它会在生成的地图上从起点走到终点，检查碰撞、卡死的位置和走不通的死路；在生成的比赛里按不同水平打若干局，看比赛能否正常结束、比分分布是否合理、AI对手是否有明显的漏洞。实现方式可以是规则脚本驱动的自动玩家，也可以是用强化学习训练出的智能体，后者更擅长发现设计者没想到的“捷径”，比如穿过某个模型缝隙直接抵达终点。测试Agent的水平也需要分档：只用高水平Agent测试，会低估新手玩家遇到的困难；只用低水平Agent，又会把一些本来可以通过的难点误判为设计错误。关于这类Agent能做到什么程度，见AI能不能生成游戏以后，再自己玩一遍检查问题。
把上面这些模块串起来，就是乐鱼体育的核心循环：
这个循环通常会跑不止一次。一次修改可能引出新的问题，比如加宽路段以后超车变得太容易，系统需要再模拟一轮确认。完整的端到端流程见AI能不能从地图、球队、规则一直生成到真正可以玩的体育小游戏。
回到开头的雨天山地自行车计时赛。文字模型把提示词拆成项目、天气、难度、人数四个参数，补全默认的赛道长度和出发方式，并标注“计时赛默认间隔出发”，这就顺带解决了8人同时出发堵在第一个弯的问题。空间模型生成赛道，物理模拟根据湿滑路面把每个下坡弯的安全入弯速度下调；测试Agent试骑后发现第三段下坡在雨天几乎无法控制，失误率远高于中等难度的目标区间。系统给出两个选项：缩短这段下坡，或者在前面加一个减速区。用户选择后，再跑一轮模拟确认，得到可以发布的版本。
自动化再多，也有一些决定只能由用户做出：想要一个紧张刺激的赛事还是一个轻松的娱乐局，愿意让新手玩家失败几次，某条规则是否要保留现实运动中的原样。模型能做的是把这些取舍摆清楚，并告诉用户每种选择的后果。对于不想直接和提示词打交道的用户，同样的取舍也可以在无代码平台里通过表单完成。
本文以一张“雪地越野障碍赛”地图为例，说明AI生成体育游戏后如何用测试Agent自己试玩。文章比较了四类测试Agent：随机探索适合找卡死点和碰撞漏洞，目标导向寻路适合验证终点是否可达，强化学习策略适合发现捷径和规则漏洞，不同技能水平的模拟玩家适合评估难度和胜率分布。文中用一次模拟测试展示“生成—测试—发现问题—修改—再测试”的完整循环，列出Agent能发现的卡死、不可达、比赛无法结束、胜率失衡四类问题，也说明节奏感、爽快感这类主观体验仍需要真人试玩判断。
本文以用户输入“做一个三人制沙滩排球，海边，打到15分”为场景，把体育游戏生成大模型需要理解的内容拆成Sport、Rule、Player、Map、Physics、Event、Score、UI、Game Loop九类，并用表格列出每一类必须输出的字段和可以自动检查的条件。文章说明了模型如何区分标准规则和用户自定义改动、为什么“打到15分”在需要领先2分的规则下必须补一个封顶值、场地尺寸如何同时影响球员跑动和物理参数，以及模拟对局暴露理解偏差后，用户修改一句话时哪些对象需要重新生成、哪些可以保留。
这篇文章讨论的问题是：AI能否从一句提示词出发，依次生成运动类型、规则、地图、球员、AI对手、计分、界面和游戏循环，最后得到一个真正可以玩的体育小游戏。文章以“做一个足球小游戏，规则尽量接近正式比赛，对手是电脑”为模拟场景，逐层说明每一层输出什么、依赖上一层的哪些产物，以及最常见的断裂方式：规则写了越位，地图却没有定义中线和半场归属；计分板显示的比分和规则层实际记录的进球数不一致；AI对手只有寻球逻辑没有状态机，控球方一丢球就全体站桩；游戏循环没有终止条件，比赛永远结束不了。文章强调生成素材不等于生成游戏，一个体育游戏至少要有Map、Player、Rules、Input、AI、Score、Win Condition和Game Loop八个相互引用的部分。最后介绍如何让AI在交付前自动试玩数百局，用比赛能否结束、比分是否一致、球员是否长时间静止等指标定位问题所在的层，并只重新生成出错的那一层及其下游，必要时回退到上一个可用版本。
本文以用户输入“做一条卡丁车赛道，第三个弯很急，要能漂移过去”为例，解释为什么文字大模型不能单独生成完整体育游戏。文字模型擅长意图解析和规则草案，但“很急”这类形容词必须由空间模型换算成弯道半径和赛道宽度，由物理模块用摩擦系数和入弯速度算出刹车距离，由规则引擎把计圈和判罚变成状态机，由运行时每秒几十次更新车辆位置。文章给出了一个半径12米弯道需要约32米刹车区的模拟计算、一张六模块分工表，以及用户要求“再急一点”时各模块如何联动重算。
请留下您的联系方式，我们会尽快与您联系。
