AI-Native游戏开发(4)：场景与BGM生产链

0. 系列文章导航

3句话，AI给我生成了一个galgame
AI-Native游戏开发(1)：为什么选择图数据库
AI-Native游戏开发(2)：角色美术生产链
AI-Native游戏开发(3)：角色声音生产链
AI-Native游戏开发(4)：场景与BGM生产链
AI-Native游戏开发(5)：剧情台词生产链
AI-Native游戏开发(6)：叙事图自增长

1. Location ≠ Scene

第一个要立的认知：地点不是背景图。

马路路口作为叙事图上的一个 Location，承载着一串事件——序章里它是骤雨中的路口（陆择车祸身亡的现场），换一段剧情，它可能就是晴天的路口、平峰时段的车流。同一个物理地点，需要不同的画面：骤雨版（雨幕、湿滑反光的路面、晕开的车灯）与晴天版（干燥路面、日光）显然不是一张图。酒店客房同理——序章出场时是清晨的光线，换一场深夜的戏，就完全是另一张图。

如果 Location 直接挂图片资产，很快会遇到两个问题：这张图到底是谁的状态？新剧情需要一个新状态时，去改旧图还是加新图？

所以图数据库里被拆成两层：Location 是世界里的地点（叙事事实），Scene 是这个地点的一个视觉状态（设计产物）。一个 Location 派生 N 个 Scene。这两层的职责边界值得用一句话钉死：Location 上只保留叙事属性（它在哪里、叫什么、和哪些事件有关），一切视觉信息都下沉到 Scene——想改「深夜大桥的画面」，改的是 Scene 的属性，Location 一字不动；叙事图因此永远不会被美术调整污染。

graph TD LO[地点·马路路口] --> S1[场景·骤雨<br>雨幕/湿滑路面<br>序章在用] LO --> S2[场景·晴天<br>（剧情需要时再建）] S1 --> L1[背景图层] S1 -.-> B1[BGM 音轨<br>骤雨氛围]

Scene 之上不再有「SceneDesign」一类的中间设计节点——概念稿里的 Location → SceneDesign → SceneAsset 三层，落地时收敛为两层。理由与第 3 篇相同：场景的「设计」就是 Scene 节点自身携带的属性，不值得为它单设一个要调度、要审批的节点。

每个 Scene 节点携带一组视觉状态属性：场景类型（对话 / 功能 / 战斗 / UI）、时段、天气、氛围关键词、构图要点。这些属性就是「深夜的大桥」与「白昼的大桥」的全部区别所在——也是后续生成时的唯一依据。

这个拆分带来的核心收益是场景一致性：同一 Location 的所有 Scene 天然聚在一处，共享同一个地点锚点。白昼版和深夜版无论相差多少次生成，它们的从属关系都写在图上；需要检查「这个地点所有状态画得像不像同一个地方」时，这是一次图查询，不是一次考古。

2. Scene 切分：从事件聚类出视觉状态

Scene 从哪来？答案是叙事图：场景设计 skill 读取一个 Location 上挂着的全部事件，按「同一视觉子空间」聚类切分。

「同一视觉子空间」是关键判据——事件共享基本相同的画面要素（同一物理空间、同时段、同光照条件），就归入同一个 Scene；否则切开。序章的 sec01 是现成的例子：买咖啡与车祸在剧情上连续，却发生在两个视觉子空间（咖啡店点餐台 vs 骤雨的路口），切成两个场景块；反过来，同一场景块内情绪再怎么推进，画面要素没变就不切——情绪差异交给立绘、台词与音乐去表达，背景不必陪跑。

切分产出的不是图片，是 Scene 节点及其属性，status 直接到 1，不走审批。这延续了第 2 篇的成本分层逻辑：场景切分是文字层的设计判断，便宜、可随时改；真正的审批留给下游出图。而且切分本身有明确的产出边界——已存在的 Scene 跳过不重切，除非被上游变更级联作废。

值得注意这个流程的输入方向：事件在前，场景在后。不是美术侧预设「一个地点通常需要哪些状态」，而是叙事图上的事件实际需要什么，Scene 就切什么。又一个「需求由叙事驱动」的实例——和第 2 篇着装需求来自事件、第 5 篇立绘需求来自台词，构成同一个模式。

3. 图层化与 V1 的克制

Scene 之下还有一层：SceneLayer（图层）。设计里，每个 Scene 按场景类型决定需要哪些图层——对话类场景只要背景层；功能类场景背景加地面层；战斗类再加装饰层与遮罩层。

但 V1（第一版）只实现了 background 背景层，其余图层类型在流程里明确标记为预留、遇到即跳过。查表关系长这样：

场景类型	需要的图层	V1 实际
对话（dialogue）	背景	✅ 生成
功能（functional）	背景 + 地面	背景 ✅，地面留 V2
战斗（combat）	背景 + 地面 + 装饰 + 遮罩	背景 ✅，其余留 V2
界面（ui）	背景	✅ 生成

值得注意这张表是静态查表而不是 LLM 判断——场景类型决定图层组合，是确定性的工程规则，不该消耗模型的判断力（也顺便不引入不确定性）。整个流水线里类似的分工随处可见：能查表的查表，能算的算，剩下的才交给模型判断。LLM 是最贵的执行器，把它留给只有它能做的事。

这是一次刻意的克制，值得把账算清楚。图层化架构的价值在「拆分与复用」——同一背景配不同地面装饰组合出新场景、前景遮罩做纵深。但这些收益的前提是图库规模足够大：十几个场景的时代，组合复用的收益远小于「每张图要拆多层、每层要独立生成审批」的成本翻倍。先把单层跑通、把图层化作为结构钩子留在 Schema 里（未来加层是「往 Scene 下挂新节点」，不是重构），等场景数量真的大到需要组合复用，再逐层启用。

过早抽象的代价在 AI 流水线里被放大了：每一个提前建好的节点类型，都是调度器要理解、审批中心要展示、级联要遍历的活对象。结构钩子与提前实现的区别在于——前者只花 Schema 里一行的成本，后者要花持续运行时的成本。V1 的克制反而让整条场景链更快跑通、更早开始产出真实游戏画面。

4. 提示词工程：五段式与「无角色」铁律

图层节点的生产与美术链同构：三段式 skill、先产物后写图、0 → 1（提示词）→ 2（图片）→ 10 待审 → 11 批准，出图走同一个纯产出层（图像生成器），复用第 2 篇的全部纪律。场景链独有的设计在提示词结构上：

五段式结构：用途 → 主体 → 环境 → 光影 → 风格。 每一段各自回答一个问题，缺一段，出图质量就有一种特定的塌法。拿「序章的骤雨路口」逐段走一遍：

段	回答的问题	骤雨路口的填法	缺了会怎样
用途	这张图是干什么用的	2D 游戏对话场景背景，横构图，中景视角，画面下部留出人物站位空间	模型自由发挥构图，人物被立绘一盖，重心全毁
主体	画面核心是什么	马路路口的斑马线与信号灯，空无一人	没有视觉锚点，画面散成一团风景
环境	空间怎么铺陈	远景雨幕中的街对面与晕开的车灯，中景路口车道线的延伸，近景溅着水花的路缘	层次扁平，像贴纸不像空间
光影	什么时候、什么天	白昼被暴雨压暗，雨云漫射光，车灯在雨幕里化成光斑，整体低饱和	光影含混，天气感消失——「骤雨」名存实亡
风格	什么画风	油画质感，手绘笔触，游戏场景美术	与全项目其他场景画风失协

Scene 节点的属性（时段、天气、氛围）直接映射进对应段落——节点属性结构就是提示词骨架，属性表怎么设计，提示词就怎么长。这张对照表也解释了为什么场景切分（第 2 节）要把「视觉子空间」当作判据：切分时写下的每一条属性差异，最终都会变成五段式里某一段的具体措辞——切分写得准，提示词就稳；切分偷懒，生成期没有任何机制能补救。

而最重要的约束是一条铁律：场景图里不允许出现任何角色。提示词末尾强制附加「无角色」声明。

原因在运行时的合成架构：Galgame 的画面是分层合成的——背景在下，立绘（绿幕拍摄式生成、抠像处理后的透明 PNG）在上，按台词动态显隐切换。角色永远由立绘层提供，从不画进背景。这个架构决定了两条纪律：

1. 背景生成必须排除角色。文生图模型太喜欢往空场景里塞人了——路人、剪影、「氛围感」的背影，都是废片：合成时立绘一盖，半个人影从角色身后伸出来。所以「无角色」不是风格偏好，是合成架构的硬约束，值得用「强制后缀」的规格级手段保证。
2. 反过来，立绘生成（第 2 篇）必须保证与背景无耦合。两层各自独立生成、运行时才相遇——这正是「分层」的全部意义：换一张背景不动立绘，加一个立绘不动背景，每个元素的生命周期互不牵连。

顺带一个数字规格：场景目标分辨率 1536×1024（3:2 横版），由项目美术规范文件统一提供，提示词组装器动态读取——规格一处定义、全链引用，不散落在各提示词里。

还有一个容易被忽略的架构收益：场景链与角色美术链共用同一个纯产出层。提示词组装器为角色服务时按角色模式组词、为场景服务时按场景模式组词，图像生成器则完全不知道自己出的是立绘还是背景——「调 API 出图」这个动作与「出什么图」彻底解耦，换生成服务商只动一处。对照一个反面设想：如果当初把出图逻辑写死在角色链的 skill 里，场景链要么复制一份代码，要么反过来依赖角色链——两条业务链就此纠缠。分层在这里的价值不是优雅，是变更隔离：业务链各自演进，公共能力独立替换。

5. BGM 的人工生成链：半程自动化的诚实边界

场景链上还挂着一个气质完全不同的邻居：BgmTrack（背景音乐）。它的生产流程是全项目最诚实的半自动化：

flowchart LR subgraph SK["AI 侧（skill）"] C1[查场景氛围与<br>章节设计简报] --> C2[生成 80~150 字<br>音乐描述: 情绪/乐器/节奏/结构] C2 --> C3[写图 status=1<br>把描述交给用户] end subgraph HU["人工侧（用户）"] D1[把描述贴进 Suno 类<br>外部音乐工具] --> D2[挑选生成结果<br>手动放入归档目录] end subgraph CH["闭环"] E1[再次触发 skill 或后台<br>检测到音频文件存在] --> E2[status=2<br>音频已归档] end C3 --> D1 --> E1

流程读一遍：音乐描述由 AI 生成（依 Scene 氛围与章节设计简报，写清情绪、乐器、节奏、结构），status 到 1；接下来把文字交给人类——人类把描述贴进一个外部音乐生成工具（Suno 类），从几版结果里挑一版满意的，手动放进归档目录；系统检测到文件存在，status 置 2。没有审批轨道，没有 10 与 11——「人工挑选合意的音乐」这个动作本身就完成了验收，再套一层审批是形式主义。

音乐描述本身是结构化的四要素，不是一段抒情文字：情绪定调（骤雨路口的紧张压抑 / 咖啡店戏的日常轻快，直接继承 Scene 的氛围属性）、乐器清单（具体到大提琴铺底、钢琴点缀这个粒度——外部工具对具体乐器名的响应远好于对「忧伤」这类抽象词）、节奏速度（BPM 或快慢描述，对话场景要给台词留呼吸空间，速度有明确上限）、段落结构（起承转合的长度规划，BGM 要能循环，结构决定循环点在哪）。四要素缺一则外部工具的产出随机性陡增——这再次呼应本系列的通用经验：给生成模型的输入是规格不是散文，无论消费方是图像模型、声音模型还是人类手里的音乐工具。

为什么不像其他链一样全自动？算一笔账就明白：

• 质量筛选的口味密度极高。 同一段描述，外部工具生成的几版音乐差异巨大，好坏判据极其个人化（这段弦乐太甜、那个鼓点太吵）——每版都要人听，那生成环节自动化省下的时间，全被「自动生成了一堆要人工逐个听」吃回去了。
• 音乐是低频低量资产。 一个场景一首 BGM，全项目几十首，每首两分钟人工操作。对比立绘（每章几十张、每张多候选）的量级，自动化收益完全不成比例。
• 外部工具迭代极快。 今天封装的自动调用接口，下个月可能整个换掉；而「生成一段描述 → 人去用工具」的接口是工具无关的。

所以这条链的定位是：AI 负责把「要什么音乐」变成精确的文字规格，人负责两分钟的外部操作与选择。它挂在图上、有 status（0 待处理 → 1 描述完成 → 2 音频归档）、由场景编排代理统一调度（发现 Scene 缺 BGM 时兜底建节点）——是流水线的正式公民，只是故意留了一段人工通道。

这也是本系列反复出现的一个命题的正面回答：AI Native 不等于全自动。自动化与否的判据不是「技术上能不能」，而是这一步的自动化是否真的省了人类的总时间。第 6 篇清算全项目账本时，这条链会作为「被证明不该全自动」类的代表。

6. 需求的交汇：场景链与角色链握手

场景链有两个与外部的交汇点，都值得注意。

其一，Scene 与 IllusDesign 之间有一条 depicts 边（「这个场景需要这套着装的立绘」）。它由剧本配音期的选绘环节维护（第 5 篇），语义是「在这个场景里出场的角色、穿着这身衣服」——由此，场景链成了立绘需求的另一个登记处：新场景意味着新的人物着装组合，图上自动出现缺口，第 2 篇的按需生产机制接管。两个链之间不传话，只共享图。

其二，Scene 与 BgmTrack 的 has_bgm 边被刻意设为不级联。 逻辑很直白：换一张背景图，不该作废音乐——背景是画面资产，音乐是时间资产，二者的「一致性」互不隶属。这条边的 sync=false 是第 1 篇「级联资格要单独论证」的又一次实践：每条边的传播语义都该被有意识地决定，而不是全局统一开或关。

顺带把场景链的「发布侧消费」交代完整：BGM 与背景在发布期的收录条件不同——背景图走完整的 10 待审 → 11 批准轨道（它是视觉资产，人要逐张看过）；BGM 以 status=2（音频已归档）为收录条件（它的验收已经在人工挑选那一步完成了）。发布 skill 把场景块、背景、音乐按图上的关系组装进章 JSON 与清单——第 5 篇的发布流水线会看到这个组装的全貌。两种验收轨道、一次组装消费：验收的严格度跟着资产的性质走，而不是全流水线一刀切。

7. 踩坑与演进

坑一：场景漂移的早期教训。 项目最初没有 Scene 层，Location 近乎直接挂图。很快出现同名地点多次生成后画面渐渐「不像同一个地方」的问题——每次生成都只看文字描述，而描述分散在多处、详略不一。引入 Scene 节点后，一个视觉状态的全部画面要素被强制收敛为一份结构化属性，生成只认这份属性；同一 Location 的多状态在图上聚簇可见。漂移没有被「更强模型」解决，被数据结构解决了——和第 2 篇立绘一致性的解法（参考图链）殊途同归：一致性问题是组织问题，不是模型问题。补一个工程细节：Scene 属性收敛之后，同类问题还有一次小规模复发——提示词组装时如果组装器临场改写措辞（同义替换、语序调整），漂移会从「属性层」转移到「组装层」。所以组装器被要求确定性组装：同样的属性输入，永远产出逐字相同的提示词。把「生成」的随机性关在真正的生成环节（图像模型采样）里，其余每一环都要可复现——这条原则后来成为全部纯产出层组件的通用约束。

坑二：图层化的诱惑。 设计之初，战斗场景的装饰层、遮罩层方案写得非常完备，几乎就要一并实现。压下这个冲动的判断是：当时全项目还没有一张战斗场景图。为不存在的需求建基础设施，在 AI 流水线里尤其危险——每个提前实现的节点类型都立刻开始产生「被调度、被理解」的运行时成本，而它服务的需求可能永远不来，或者来的时候形态已经变了（比如届时可能直接换用视频背景）。结构钩子留了，实现等需求。

坑三：音乐描述的模板演进。 最初的音乐描述是自由散文，产出质量随写作状态波动。后来收敛为结构化模板（情绪定调、乐器清单、节奏速度、段落结构），描述的一致性显著提升——和第 3 篇 instruct 的教训完全同构：给生成模型的输入应该是规格，不是散文。有趣的是，这条经验是从「描述最终是给人用的」场景里长出来的——连人消费的提示词，规格化后都更高效。