把场景、对话、数值压进同一段提示，模型会优先保证整体文案通顺，而不是保证变量名和触发条件对齐。结果就是改一句场景描述，对话分支可能少一个，数值初始值也可能被顺手改掉。可行的做法是把三块拆成三条独立提示：场景提示只负责可检查的空间与物件，对话提示只负责可验证的触发路径，数值提示只负责变量表和变化规则。游点灵里如果支持分步生成或分模块填写，优先用它的分栏；如果只能贴一整段，就本地拆成三段分别生成，再按字段拼回去。

在游点灵这类搭建流程里，场景、对话、数值建议分三条提示生成，每条只带自己需要的字段。先固定可交互物 id 和变量名，再补风格文案与分支台词。每次只验收一类，改动前记录变量快照或截图。工具若不支持分步生成，可分段生成后粘贴，但触发逻辑仍要在工具内试玩确认。边界是：本文只覆盖可核对的字段和验收动作，不保证一次生成即用。

场景提示写清风格、尺寸、镜头、可交互物

场景提示的目标不是好看，而是让生成结果能被逐项核对。建议把提示写成下面这种字段式，而不是一段散文。

场景名：废弃钟楼一层
风格：低饱和手绘、潮湿石墙、暖色油灯
尺寸：单屏 16:9，可走区域约 12x8 格
镜头：斜 45 度俯视，中心锚点在楼梯口
可交互物：木箱 id=crate_01、铁门 id=door_iron、油灯 id=lamp_03
输出要求：每个可交互物给一个碰撞体与交互距离

生成后按四项核对：第一，尺寸和可走区域是否与镜头锚点一致，玩家会不会一进场就卡在墙外；第二，镜头角度和可视边界能不能把 crate_01、door_iron、lamp_03 都收进画面；第三，风格词有没有落到地面材质、墙面材质和光照三处，而不是只写在场景名里；第四，可交互物的 id 是否与后面数值表、对话触发条件逐字一致。这四项里任何一项对不上，先改场景提示，不要先去改对话。

对话提示写清角色关系、触发条件、分支数量

对话最容易崩在触发条件。建议字段清单固定为：角色名、对话对象、关系、触发条件、分支数量上限、每个分支的结束动作。结束动作包括给道具、改变量、结束对话，三者最好只选一种，避免同一分支里改太多状态。

角色：守门人
对话对象：玩家
关系：中立偏警惕
触发条件：玩家进入 door_iron 交互半径且 has_key = false
分支数量：2
分支A：拒绝开门，结束对话，不改变量
分支B：若 has_key = true，开门，设置 door_open = true

试玩时用三条路径验证触发：先空手走到 door_iron，应只出现分支A；再拿到 crate_01 里的钥匙，应出现分支B；最后取消 door_iron 的交互半径，对话不应出现。如果三条路径里有一条不对，先检查触发条件里写的变量名是否和数值表一致，再检查分支数量有没有被模型擅自扩成三条。

数值提示写清变量名、初始值、变化规则

数值提示要当成一张接口表来写，而不是“给玩家一个钥匙”。变量名建议用英文小写加下划线，初始值和变化规则写成一行一条，并强制模型输出关联对象。

变量表：
has_key，初始 false，拾取 crate_01 后设为 true，关联场景 crate_01，关联对话 守门人分支B
door_open，初始 false，守门人分支B设为 true，关联场景 door_iron，关联对话 守门人分支B
lamp_on，初始 false，交互 lamp_03 后取反，关联场景 lamp_03，关联对话 无

生成后把变量名、场景对象、对话触发条件记在同一张表里，方便对照：

这张表里任何一个变量名出现拼写差异，比如 has_key 写成 hasKey，后面就会对不上。验证方式是生成后在变量面板里看初始值，再执行一次拾取或对话，确认变化规则确实写入。

分别生成后做单项验收，不把三类结果混在一起改

改一处崩一处通常是因为同时动了场景、对话和数值。建议固定验收顺序：第一步只验收场景的尺寸、镜头范围和可交互物 id；第二步只验收数值的变量名、初始值和变化规则；第三步只验收对话的触发条件、分支数量和结束动作；第四步才看风格和文案是否顺眼。每次只动一类，改动前用截图、变量快照或对话日志记下当前状态，改完只对比这一类。

如果场景 id 没过，就不要顺手去改对话触发条件，否则无法判断是 id 拼错还是触发条件写错。验收顺序可以写成一张便签：场景 id → 数值变量 → 对话触发 → 文案。跳过任何一步，后面出问题都要回头补。

记录哪类提示改动会影响其他两类的输出

三块拆分后仍然有耦合，尤其是 id、变量名和触发条件。建议维护一张耦合记录表，每次改动后填一行，重新验证结果只写“通过”或“不通过”，不写模糊描述。

这张表不需要每天填，只在改动后填。填完如果“重新验证结果”是不通过，就回到对应那一类提示去改，不要继续叠加新改动。