第一步：这句话里只有三个词是硬信息，其余都要系统补齐
意图解析先做的不是生成，而是拆字段。“雨天”落到天气和物理两层，“城市街道”落到场景类型和边界形态，“3v3”落到人数和规则模板。剩下的信息玩家一个字都没说：一场踢几分钟、有没有守门员、平局怎么办、用什么视角、AI对手强不强。
这些空白不能靠大模型随手填满后直接开工，而是要变成一张可确认的卡片。系统给出默认值，同时标注“这是推测”，玩家点一下就能改。
| 字段 | 来源 | 示例默认值 |
|---|---|---|
| 天气 | 玩家明确 | 中雨，地面持续积水 |
| 场景 | 玩家明确 | 封闭的一段城市街道 |
| 人数 | 玩家明确 | 每队3人，无替补 |
| 比赛时长 | 系统推测 | 每场6分钟 |
| 守门员 | 系统推测 | 不设固定门将 |
| 胜负条件 | 系统推测 | 时间到比分高者胜，平局进入金球 |
这一步最常见的错误是“过度理解”。比如把“城市街道”理解成开放世界，生成了一个可以跑出去的十字路口，后面所有环节都会被拖累。所以意图解析阶段宁可少生成，也要先把边界说清楚。
第二步：规则要先于场地定下来
很多人以为先画场地再定规则，实际顺序反过来更稳。规则决定场地需要什么：不设守门员，球门就要缩小，示例里设为1.2米宽、0.8米高；不设边线出界，两侧墙面和路沿就要承担反弹功能；采用金球制，Game Loop 里就必须有“进球即结束”的分支。
规则引擎在这里做的是一致性检查，而不是写文案：得分条件是否可达、胜负条件是否一定会触发、有没有两条规则互相打架。比如“界外球由对方发出”和“墙面反弹不算出界”同时存在时，路沿那条线到底算不算边界，必须有唯一答案。
第三步：一段街道怎么变成一块能踢的场
示例场地取一段24米长、14米宽的封闭街道。空间模型要回答的问题很具体：两端的球门放在哪里，路沿算场内还是场外，消防栓、路灯杆、邮筒这些街道元素放在哪里才不毁掉比赛。
判断原则是“布景可以挡视线，不能挡比赛主线”。球门前方6米范围内不放固定障碍，中圈附近保留完整的传球通道；路灯杆可以放在边路，但要和墙面至少留出一个球员身位，否则会出现球卡在夹角、谁也踢不出来的死区。每个障碍物生成时都附带碰撞体，而不是只画一个模型。
出生点也在这一步定：双方三名球员的开球站位、进球后的重新开球位置，都要落在可通行区域内，而且不能和障碍物的碰撞体重叠。
第四步：雨天不是贴一层反光材质
这是整句话里最容易被做成“只有画面”的部分。真正的雨天要改物理引擎的参数，而这些参数不该由文字大模型直接拍脑袋，而是从物理预设里选取并调整。
在示例设定里，湿地面的摩擦降低，球员从全速急停的滑行距离从干地的约0.4米拉长到约0.9米；球在湿沥青上滚得更远，但一进水坑又会明显减速。这两种效果方向相反，恰恰是雨天街球好玩的地方：贴地长传可能被水坑“吃掉”，而在湿滑路面上的低平射门会更快。
风险在于参数一旦过头，比赛就变成滑冰。因此物理参数生成后要带一个可玩性区间，超出区间直接回退到上一档，而不是等到试玩才发现没人能停住球。
第五步和第六步：三名球员怎么分工，AI对手凭什么应对湿地
3v3没有复杂阵型，但仍需要角色：一名偏后的组织者、一名边路推进者、一名靠前的终结者。球员模板决定跑位倾向，属性差异只做小幅区分，避免某个位置一家独大。
AI对手的关键在于它如何“知道”地面湿。正确的做法是让AI在决策层面适应环境：看到水坑少打地面长传，更多选择短传配合；在对手急停滑行时选择贴身逼抢的时机。错误的做法是给AI悄悄提高湿地抓地力或射门精度，让它在同样的物理条件下比玩家更稳。前者是战术，后者是数值作弊，玩家很快就能感觉出来。关于这条边界，可以参考体育游戏智能对手栏目里的讨论。
第七步：静态验证先挡掉“根本跑不起来”的问题
生成完成后，系统先不试玩，而是逐项做静态检查：
- Spawn：六名球员的出生点是否都在可通行区域内
- Goal：两个球门是否都能从中圈沿地面路线到达
- Collision：障碍物碰撞体是否和墙体、球门重叠
- Rule：界外、反弹、重新开球规则是否互相冲突
- Score 与 Win Condition：进球能否计分，时间到或金球后比赛能否结束
- Game Loop：开球、进球、重新开球、终场是否形成完整循环
这一层能发现的是结构错误，发现不了“能跑但不好玩”的问题，那要交给下一步。
第八步：让AI先替玩家踢几十场
自动试玩的思路是 Generate → Play → Detect Problem → Modify → Play Again。系统让两队AI按不同风格反复对踢，记录每一场的进球位置、比赛是否正常结束、球有没有长时间停在同一个位置。
模拟试玩记录：雨天街道3v3第一版
示例中系统自动试玩了20场，发现三个问题。
- 有4场出现球卡在路灯杆和墙面之间超过10秒，原因是两者间距小于球员身位，修正方式是把路灯杆外移0.6米。
- 一侧球门前恰好生成了水坑，这一侧的进球数明显偏低，修正方式是把水坑移到边路。
- 金球加时阶段，有一场双方AI都退守不前，比赛拖得过长，修正方式是加时超过2分钟后改为点球决胜。
修正后再踢20场，三个问题均未复现，这一版才进入玩家手里。
这里的AI测试只能说明“规则跑得通、没有明显卡死”，并不能替代真人判断手感。雨天够不够滑、对抗激不激烈，仍然要玩家自己踢过才知道。更完整的测试思路可以看自动游戏测试这篇。
第九步：玩家改一个参数，系统要重新检查哪些地方
作品交到玩家手里后，最常见的修改是“雨再大一点”“场地再长一点”“AI别那么爱抢”。每一种修改影响的范围不同：调雨量会动物理参数，需要重跑可玩性区间和试玩；拉长场地会动出生点和障碍布局，需要重跑静态验证；调AI风格只影响对手行为，只需要针对性试玩几场。
所有修改都按版本保存：系统生成的是V1，玩家调了雨量存为V2，再让AI补一个夜间灯光存为V3。任何一个版本都能查看、对比差异，发现V3不如V2时可以一键恢复。
第十步：发布前请创作者自己核对这五件事
乐鱼体育会在发布前再跑一次完整校验，但以下几项建议创作者亲自踢一场确认：
- 从开球到终场哨，至少完整走完一场，包括一次进球后的重新开球。
- 在最湿滑的区域做一次急停转身，确认还能控制方向。
- 把球故意踢向场地角落和障碍物背后，确认不会卡死。
- 故意打平一次，确认加时和决胜规则能正常结束比赛。
- 用简介写清楚规则里的特殊设定，比如墙面反弹不算出界，让第一次打开的玩家不至于困惑。
五项都过了再点发布。一句话生成省掉的是搭建的体力活，但“这局球到底能不能踢完”仍需要创作者亲自踢一场来确认。
