两句输入，改动范围差了不止一个量级
在乐鱼体育的MOD生成流程里，我们常用两句输入做内部对照。下面的球队名称、轮次和人数都是为说明问题设计的模拟示例：
- 输入A：“给青岚港这支球队生成一套未来科技风球衣。”
- 输入B：“把这个足球联赛改成16支球队双循环赛制。”
两句话长度差不多，改动范围却差得很远。输入A的主体是一个Asset：球衣的纹理、配色、号码字体、袖口图案。输入B的主体是一条Rule：原本8支球队双循环的联赛要扩成16支球队双循环，赛程、积分、晋级、场馆这些原本稳定的系统都要跟着动。
| 对照项 | 输入A：未来科技风球衣 | 输入B：16队双循环 |
|---|---|---|
| 主要层级 | Asset（Uniform） | Rule（League） |
| 直接改动 | 贴图、配色、号码样式 | 球队数量、赛程生成、积分与晋级 |
| 牵连系统 | Team主客场设置、Character模型 | Team名单、Character名册、场馆、比赛数量、存档 |
| 出错后果 | 看着别扭、场上分不清 | 赛季跑不完、排名算错、晋级名额冲突 |
| 需要的验证 | 渲染与撞色检查 | 完整模拟一个赛季 |
公开资料显示，目前的AI MOD生成大多还是第三方小工具，例如按提示词生成Minecraft模组的网站，暂未见大型平台推出官方的AI MOD生成产品。体育游戏的特殊之处在于，它的乐趣很大一部分来自赛季、积分和晋级这些规则系统。如果生成器只能处理输入A，它本质上是一个素材生成器；玩家很快会从“换球衣”走到“换赛制”，这时系统必须接得住。
一套球衣也不是纯外观：Uniform挂在哪些系统上
先说输入A。很多人以为球衣就是一张贴图，AI把图生成好、替换进去就结束了。实际做下来，一套球衣至少挂在三处：
- Team：每支球队通常有主场、客场和第三套球衣。未来科技风如果用了大面积荧光青，而联赛里另一支球队铁杉城的主场球衣也偏青绿，两队交手时系统要自动切换客场服，否则场上22名球员很难分清。
- Character：球衣要贴在球员模型上。宽肩型、瘦长型球员模型的UV展开可能不同，一张在标准体型上好看的贴图，在门将长袖模型上可能出现图案断裂。
- 比赛可读性：号码和名字要在默认转播视角下看得清。科技风常用细线条和半透明发光效果，远景镜头里号码很容易糊成一片。门将服还要和双方球员、裁判服都拉开差距。
所以即使是输入A，系统也不应该只交付一张图。合理的输出是：主客场加门将共一组球衣、一份与联赛其余球队主色的撞色检查结果、一组在比赛默认镜头下的号码截图。玩家看到“与铁杉城主场撞色，交手时建议启用客场白色版本”这类提示，才知道这套球衣真正上场会是什么样。
这一层的改动可以做到相对独立：换掉球衣不会影响积分表，也不会让比赛无法结束。素材类MOD出错代价低，适合让AI大胆生成、玩家快速试换。
改成16支球队以后，规则会沿着依赖链往外扩散
输入B的难点不在“16”这个数字，而在于它碰到的是League这个中枢对象。原联赛8支球队双循环，每队打14轮，每轮4场，一个赛季共56场；改成16支球队双循环后，每队要打30轮，每轮8场，一个赛季共240场。比赛总数变成原来的四倍多，下面这些系统都要重新检查：
- 赛程：30轮赛程要让每支球队主客场大致交替，不能出现连续四轮客场。
- 场馆：新增的8支球队需要主场。如果AI只生成了球队名单没生成场馆，赛程生成器可能把新球队的主场比赛全部塞进默认球场，同一比赛日出现一座球场两场比赛。
- 排名：8队时同分情况少，规则里可能只写了“积分相同比净胜球”。16队、30轮以后三队同分明显增多，需要补全相互战绩、进球数等后续判定顺序。
- 晋级：原来前2名进入杯赛阶段，扩军后是否改为前4名？要不要增加降级，降几支？这些不该由AI替玩家拍板，要作为待确认项列出来。
- 比赛数量：玩家亲自操作的比赛从14场变成30场，体能、伤病、黄牌累计停赛这些原本累积不起来的系统开始真正起作用。
这部分的逐项检查我们在虚拟联赛MOD里单独拆开讲过。这里只强调一点：规则改动没有“只改一处”的版本。系统如果只改了球队数量字段，界面上显示MOD生成成功，实际上埋下了好几个要到第十几轮才会暴露的问题。
Team、Character、League、Rules之间的依赖要显式写出来
两个输入对照下来，能看出MOD生成系统需要的是一张依赖图，而不是一个素材文件夹。乐鱼体育在MOD设计中把对象分成这几类：
| 对象 | 包含内容 | 典型依赖 |
|---|---|---|
| Team | 队名、队徽、主客场、所属联赛 | 依赖League、场馆、Uniform |
| Uniform | 主客场及门将球衣、号码样式 | 依赖Team配色、Character模型 |
| Character | 球员名册、体型、属性、位置 | 依赖Team，影响AI阵容选择 |
| League | 参赛球队、赛制、轮次 | 依赖Team列表，驱动赛程 |
| Rules | 积分、排名判定、晋级、停赛 | 依赖League结构 |
| Compatibility | 基于的游戏版本、数据结构版本 | 约束以上全部对象 |
AI生成一个MOD时，除了内容本身，还要生成一份依赖声明：这个MOD修改了哪些对象、新增了哪些对象、读取了哪些它没有修改的对象。输入A的依赖声明很短，只改Uniform，读取Team配色和Character模型。输入B的依赖声明很长：新增8个Team、8座场馆、约200名球员（按每队25人名册计算），修改League和Rules。
依赖声明写清楚以后，冲突检测才有依据。比如玩家同时启用一个“全联赛复古球衣包”和输入B生成的16队联赛MOD，复古球衣包只覆盖原来8支球队，新增的8支球队就会穿默认白衣。系统可以在加载时提示“球衣包未覆盖8支新增球队”，而不是让玩家踢到第三轮才发现。
系统怎么判断玩家到底想改到哪一层
真实输入不会像A和B那样边界清楚。“把这个联赛做成赛博朋克风格”可能只想换球衣和球场灯光，也可能想把比赛改到夜间、加入新的计分方式。乐鱼体育的做法是让语言模型先做意图解析，输出一份“改动层级草案”，而不是直接开始生成：
- 识别涉及的对象：只出现球队和外观词时，默认只动Asset层。
- 识别规则词：出现“赛制”“轮次”“晋级”“积分”“球队数量”等词时，标记Rule层改动。
- 展开依赖：按依赖图列出被牵连的对象，比如改球队数量会自动展开到赛程、场馆、排名、晋级。
- 列出待确认项：凡是有多种合理答案的，例如晋级名额、同分判定顺序，都交给玩家选择或接受默认值。
- 生成并验证：玩家确认后才开始生成，生成后立刻跑验证。
分工上，语言模型负责理解和拆解，真正排赛程、算积分的应该是规则引擎，判断比赛能否正常进行要靠运行时和测试智能体。把排赛程这种约束严格的任务直接交给文字模型输出，常见结果是某两支球队在同一轮碰了两次，或者某支球队少打一个客场。
哪里最容易出错，怎么在发布前发现
素材层的错误大多肉眼可见，规则层的错误往往要跑起来才知道。输入B这类MOD，发布前至少要做一次快速模拟赛季：用AI对AI把240场比赛以低细节模式跑完，然后核对：
- 每支球队是否恰好打了30场，主客场各15场。
- 每个比赛日是否存在同一场馆被重复占用。
- 最终积分表能否正常排序，同分时判定顺序是否生效。
- 晋级名额与下一阶段的参赛队数是否匹配。
- 在第15轮存档、读档后，赛季能否继续推进。
这类检查适合交给自动游戏测试智能体，它不需要踢得好，只需要把赛季完整走一遍并记录异常。公开资料里，EA SEED在2020年的论文中用强化学习智能体提高测试覆盖率、发现地图问题；但2026年的GBQA基准也显示，表现最好的模型只找出约48%的已验证bug。所以自动模拟适合发现结构性问题，最后仍要玩家亲自踢几轮确认节奏和手感。
MOD生成那一刻，就要记下兼容信息
最后一层是Compatibility。一个MOD生成时，它基于的是某个具体的游戏版本和数据结构版本。输入A的球衣MOD，如果下个版本球员模型换了UV布局，贴图会错位；输入B的联赛MOD，如果下个版本在Rules里新增“黄牌累计停赛”字段，旧MOD没有这个字段，系统要决定用默认值补上还是提示玩家。
因此每个AI生成的MOD都应在生成时写入版本基线：游戏版本、数据结构版本、依赖的其他MOD及其版本。游戏更新以后，兼容检查才能判断哪些MOD可以直接用、哪些需要迁移、哪些需要回退，具体处理方式可以参考版本兼容的讨论。
给玩家的判断标准：你的MOD改到了哪一层
回到标题的问题：改素材，还是连规则一起改？这取决于玩家的意图，但系统必须具备改规则的能力，并且在改规则时把依赖讲清楚。提交一个MOD请求前，可以按下面几条自查：
- 只换外观：确认撞色、号码可读性、门将服区分，就可以放心试。
- 涉及球队数量或赛制：要求系统列出赛程、场馆、排名、晋级、比赛数量五项变化，逐项确认后再生成。
- 同时启用多个MOD：先看依赖声明里有没有覆盖同一对象，有没有漏掉新增球队。
- 准备长期玩的联赛MOD：确认它记录了版本基线，游戏更新后才能被正确迁移。
