一张地图被上传后的第一周，通常还是“一个作品”。到第三周，它可能已经变成一片森林：有人把地图搬到雪地，有人把所有敌人换成了机械单位，有人保留原地形却重写了任务，还有人把其中两个分支的房间拼在了一起。此时如果你问平台一句“这张图现在到底是谁做的”，多数社区给出的答案是页面上那一行作者名。

这就是 AI UGC 社区正在面对的新问题。AI 让二创的门槛低到只需要一句话：“把这张图改成夜晚，加一队巡逻的守卫。”于是二创的数量和速度，会远远超过传统 UGC 社区里人工改图的节奏。当衍生作品以指数速度出现时，社区需要的已经不只是“上传”和“点赞”，而是一套回答“谁改了什么”的机制。金沙娱乐在研究 AI UGC游戏 社区形态时，越来越倾向于把它理解成一个游戏内容的版本管理系统。

Remix 和 Fork 不是一回事

在讨论版本树之前，需要先区分两个经常被混用的动作。二创（Remix）指在原作基础上修改并保持关联：新作品继承原作的部分结构，在页面上显示“基于某作品”，原作者可以看到衍生数量。分叉（Fork）则更像一次独立起步：从某个版本复制出去后，走自己的演化方向，与原作的关系只在历史里保留。

两者在社区里的含义不同。Remix 的价值在于“连接”：玩家可以顺着链条逛，原作者的作品因为被二创而获得更多曝光。Fork 的价值在于“自由”：一个作者想把玩法改到面目全非，不希望原作品的评价和规则拖累它。把两者都称作“复制”，会让署名、推荐权重和分成规则一起变得含糊。

为什么整包快照不够用

最容易想到的做法，是每次修改都存一份完整的地图文件，再用父子关系连起来。这能回答“有哪些版本”，却回答不了“这一版改了什么”。比如某个玩家对一张地图做了三处调整：把出生点挪动了二十米，替换了两个敌人的行为脚本，新增一段过场对话。如果只有两份完整文件，系统只能告诉你“文件不同”，没法说明有哪一部分是新作者的贡献。

更合理的做法是每个版本记录一份变更集（Changeset）：以关卡布局、角色数据、脚本、资源引用、文案这些对象为粒度，写明新增、修改、删除了哪些条目。这样版本之间就可以做“对象级”的差异比较。有了这种差异，我们才能说“这一版 70% 的关卡结构来自原作，新作者新增了一条支线和两个敌人行为”，而不是模糊地判断“看上去像”。

谁改了什么：署名与贡献归属

创作者署名（Creator Attribution）在 AI 参与之后变得更复杂。一条链条里可能同时出现这几类贡献者：原作者，提供了最初的结构；改编者，通过自然语言指令让 AI 完成了改动；素材作者，其贴图或模型被引用；以及辅助生成的工具本身。一个粗暴的规则是“最后修改者署名”，会把前面所有人的劳动抹去；另一个粗暴的规则是“永远只写原作者”，则让后来者没有动力。

比较可行的做法，是把署名拆成两层。第一层是显式的关系：每个作品页显示“基于……的二创”，并可以逐级回溯到根作品，这一层不随修改大小变化。第二层是按变更集估算的贡献占比：不需要精确到小数点，只要能区分“重大改编”和“换了一张贴图的重发”。占比可以被用于展示、也可以被用于社区激励，但不应该直接和金钱挂钩，否则会激励作者去制造无意义的微小改动来刷占比。

对于角色类作品，问题还会多一层：被二创的角色，性格和世界观是否还“是同一个角色”？这一点我们在角色二创的一致性里有专门讨论，版本树能提供的是可核查的历史，而一致性检查则需要基于角色设定去做。

资源依赖：一个素材下架以后会发生什么

版本树的另一半是资源依赖（Asset Dependency）。一个地图不只包含自己的关卡数据，还引用大量外部资源：贴图、模型、音效、脚本模块、共享的角色包。设想这样一个场景：社区里一个流行的树木模型被原作者下架，因为其中一部分素材的授权出现了问题。如果平台没有依赖图，它既不知道有多少作品引用了这个模型，也没法提前通知下游作者，结果是一批地图在某天突然缺了所有的树，玩家看到的是一片空地和大量差评。

有了依赖图，处理流程就可以是一条清楚的链：素材状态变化，系统找出所有直接引用它的版本，再沿版本树向下找出继承这些引用的衍生作品，按影响程度分级通知：仍可运行但需要替换的，会显示缺失的，以及已经无法加载的。AI 在这里可以帮上忙，例如为被下架的素材推荐风格相近的替代品，但替换动作仍应该产生一条新的版本记录，而不是悄悄覆盖旧版本。

版本树带来的社区治理收益

当上述三样东西都有了，社区的许多老问题会变得容易处理。抄袭与借鉴的边界，不再靠版主凭印象裁决，而是有变更集与时间线作为依据；推荐系统可以区分“原创新作”和“轻微改动的重发”，避免它们抢占同一批曝光位，这与我们在质量排序里提到的相似度多样性控制是配合的；玩家可以沿着一棵树选择自己喜欢的分支，而不是在一堆看起来差不多的地图里盲选。

关于社区规则本身应该由谁制定、怎样制定，可以参考官网观察里的讨论：当玩家都能用 AI 做内容，平台更应该做的是规则和秩序的设计者。金沙娱乐AI 在这个方向上的设想，是让版本关系在生成阶段就自动写入，玩家提出一句修改指令的同时，系统已经生成了对应的变更集，而不需要作者事后手工填写来源。

最小可行的字段清单

不必一上来就搭建完整系统。如果只能先做五个字段，建议是：父版本编号，用于还原关系；关系类型，标记是二创还是分叉；变更集摘要，按对象类别列出改动；资源引用清单，含来源和授权状态；创作方式标记，注明由人工编辑还是由 AI 指令完成。有了这五个字段，社区就已经从“一堆作品”变成了“一棵可以回溯的树”，后面的排序、署名分配和风险预警才有可依赖的数据。像金沙娱乐大模型这样负责理解玩家指令的模型，也可以顺手把“这次改了什么”翻译成变更集，让版本记录成为生成流程的副产品。