模拟示例：改好的队服又变回了红色
以下为说明问题构造的模拟场景。用户用一句话生成了一支5v5足球队“北岸灯塔”（记为V1），随后做了三处手动修改：队服从红白改为深绿，10号球员改名为“林远”，阵型从1-2-1改为2-1-1。接着他对AI说：“让这支队打得更偏快攻。”
新结果里，阵型确实变成了更适合快攻的1-1-2，两名边路球员的速度倾向也提高了。但队服变回了红白，10号又叫回原来的名字。用户的反馈是：“我只想改打法，为什么把我改过的东西也改掉了？”
原因排查：覆盖是从哪一步发生的
遇到这类问题，按下面的顺序看，通常能很快定位：
- 这次重生成的范围是什么。如果是在整支球队的层级发起的，AI会输出一份完整的新球队，所有字段都会有新值。
- 被覆盖的字段有没有被标记为“手动修改”。旧的做法里，编辑器只记录字段当前的值，不记录这个值是谁写的，重生成时无从区分。
- 这次AI要求是否真的涉及被覆盖的字段。“偏快攻”和队服颜色、球员名字毫无关系，这两处被覆盖纯属误伤；阵型被改则是AI要求本身导致的，属于需要确认的冲突。
也就是说，问题有两类：一类是范围过大导致的误伤，一类是AI要求和用户修改真正冲突。两类需要不同的处理。
局部修改：让AI只动它该动的那一块
App把生成结果拆成可以单独操作的部分：球队外观、球员名单、阵型与战术、比赛规则、AI对手。用户可以直接手动改任何一个字段，也可以选中某一部分再让AI重新生成。
上面的例子里，“偏快攻”只需要作用于“阵型与战术”，外观和名单根本不应该进入重生成范围。App在接收到AI要求时，会先判断它涉及哪些部分，并把范围显示出来让用户确认，例如“本次将修改：阵型、战术倾向、边路球员速度倾向”。
字段的三种状态，决定重生成时怎么合并
每个字段除了值，还记录它的来源：
| 字段状态 | 怎么产生 | AI重生成时的处理 |
|---|---|---|
| AI生成 | 由AI写入，用户未改过 | 可以直接覆盖 |
| 手动修改 | 用户改过的字段 | 默认保留，若AI要改，列出来让用户确认 |
| 锁定 | 用户主动点了锁定 | 绝不覆盖，AI需在此约束下生成 |
回到例子：队服和10号名字属于“手动修改”，不在本次范围内，直接保留。阵型也是“手动修改”，但它在本次范围内，而且“偏快攻”确实需要改阵型，这时App不会静默覆盖，而是显示一条冲突：“你将阵型改为2-1-1，快攻方案建议1-1-2，保留哪一个？”
如果用户事先把阵型锁定了，AI就必须在2-1-1的前提下实现快攻，例如提高边路前插频率、缩短由守转攻的出球时间。锁定不是禁止AI工作，而是给它一个不能动的约束。
手动改规则时，AI对手需要重新校验
合并不只发生在“AI覆盖手动”的方向，手动修改也可能让AI生成的部分失效。例如用户把比赛从5v5手动改成3v3，此前生成的AI对手仍按五人阵型设计了高位逼抢。App会把对手标记为“需要重新校验”，并提示用户选择：让AI按新规则重新生成对手，或者手动调整对手阵容。在校验完成之前，自动试玩会先检查比赛能否正常开始、得分和结束。
版本：被覆盖了也能找回来
即使合并规则再细，也会有用户确认错了的时候。所以每一次手动保存和每一次AI生成，都会形成一个版本：
处理步骤如下：
- 打开项目的版本列表，找到被覆盖之前的那个版本，比如V2
- 选择“与当前版本对比”，App会逐字段列出差异，并标注每处差异来自手动修改还是AI生成
- 只想找回队服颜色时，选择“恢复此字段”，不必把整个项目退回V2
- 需要完全回到旧状态时，选择“恢复为此版本”，当前内容会先存成新版本，不会丢失
版本记录保存在项目里，换设备以后同样可以查看，具体的同步方式可以参考项目云同步的说明。如果项目被其他玩家继续改编，版本关系会延伸成一棵版本树，每个分支都能回溯到原作。
预防：让AI重生成之前做三件事
- 把确定不想变的字段锁上，尤其是队名、队服、核心球员名字这类身份信息
- 在要修改的那一部分上发起重生成，而不是在整个项目上发起
- 看一眼重生成前显示的影响范围，范围里出现了不相关的部分，就先取消，缩小选择后再来
判断一个AI生成工具是否好用，可以做一个简单测试：手动改三个字段，再让AI改一个无关的方向，看那三个字段是否原样保留。能保留，这个工具才适合长期创作。
