用 HappyOyster 1.0 搭开放世界原型，真正容易翻车的地方不是“能不能生成”，而是生成一类场景要占多少显存、要等多久，以及等不到的时候画面会怎样。把两件事拆开管：实时生成循环只回答“什么时候发请求、缓存命中就用已有的、超时怎么退回去”；资源预算只回答“显存和帧间隔到哪条线就必须收手”。两条线混成一个阈值，调起来会来回打架。

判断方向：先用最小可验证场景建立显存与帧间隔基线，再把实时生成循环限制在请求、缓存命中、超时回退三步内，最后用降级开关兜住超限情况。适用场景是原型期、以验证可行性为目标、单机或小规模联机的开放世界；风险边界是基线只在你当前的显卡、分辨率、场景密度组合下成立，换配置就要重新记录，不能把一张表当成通用结论。

列出开放世界原型的最小可验证场景

原型阶段不要一次做整张地图。先把开放世界拆成若干可以单独生成、单独回收的小场景，每类独立跑一次、记录一次，才能看出哪一种最吃资源。场景清单建议固定四个字段，缺一个都会让后面的基线记录对不上号。

• 触发条件：什么状态下允许生成，例如玩家距锚点多近、镜头是否朝向该区域、是否已有同类场景占用槽位。
• 停留时长上限：该场景允许在内存里活多久，超过就进回收队列，避免玩家离开后资源还挂着。
• 资源释放点：写清释放判定，例如距离超过阈值、停留超时、切换区域、显存告警。
• 输入与输出：输入是状态量（锚点位置、随机种子、生态类型、时间），输出是句柄和用量（网格数量、贴图占用、音频句柄、碰撞体）。

下面这份场景描述可以直接改字段使用，输出里的数值先留空，等基线跑完再填。把样例存成配置或常量表，后续每加一类场景就复制一份。

{
  scene_id: 'roadside_stop',
  enter_when: 'player_distance_to_anchor < 60',
  max_dwell_s: 90,
  release_on: ['player_distance_to_anchor > 120', 'dwell_timeout'],
  input: { anchor_pose: 'vec3', seed: 'int', biome: 'string' },
  output: { meshes: null, textures_mb: null, audio_handles: null },
  budget: { vram_mb: null, gen_ms: null }
}

先控制在三到五类，例如路边停留点、开阔地形、室内小空间各一类，够看出差异就行。每类场景都单独跑一遍，不要合并测试。

用 nvidia-smi 和计时记录建立资源基线

基线要在三个时刻各记一次：空场景空闲、生成过程中、回收之后。只看生成完成的那一瞬间，看不出资源有没有真的还回去。显存和利用率用下面的命令持续采样到文件，跑完再对齐时间轴。

nvidia-smi `--query-gpu`=memory.used,utilization.gpu `--format`=csv -l 1 > gpu_baseline.csv

1 秒周期对原型够用；要看单次生成的尖峰，把 -l 1 换成 -lms 200，或者在应用内自己打点。计时建议双轨：一轨在生成调用前后各取一次时间戳，算单次生成耗时；一轨记录帧间隔，看生成期间画面有没有明显停顿。两侧时间戳用同一个时钟源，别一边用系统时间一边用引擎帧时间。

记录表模板固定字段，每次测试新建一份：

timestamp, phase, memory_used_MiB, gpu_util_pct, frame_interval_ms, gen_ms, note
, idle,         , , , ,
, gen_start,    , , , ,
, gen_done,     , , , ,
, after_release,, , , ,

phase 只填四个值（idle、gen_start、gen_done、after_release），note 里写场景 ID 和本次改动。同一份表至少重复跑三次，看数值是否稳定；波动很大时优先怀疑后台进程或场景本身的随机性，而不是生成机制。memory.used 是整卡数值，包含其他进程占用，所以比较前后差值要在同一台机器、同一批后台程序下进行。

给实时生成循环画伪代码边界

循环把“请求生成”和“等待生成”分开，任何一步超过阈值都必须能退出。骨架里的生成调用是占位函数，替换成 HappyOyster 1.0 的实际入口即可，其余结构不用动。

state = {
  active_scenes: {},   # scene_id -> handle
  cache: {},           # key -> handle
  budget: { vram_mb: 300, timeout_ms: 120 }
}

def frame_update(state, player):
    need = pick_needed_scenes(player, state)   # 输入状态：位置、朝向、时间
    for s in need:
        key = scene_key(s)
        if key in state.cache:                 # 第二步：缓存命中
            attach(state.cache[key])
            continue
        t0 = now_ms()
        try:
            handle = generate_scene(s, deadline_ms=state.budget.timeout_ms)  # 生成调用占位
        except Timeout:
            handle = None
        if handle is None:
            fallback_low_detail(s)             # 第三步：超时回退
        else:
            state.active_scenes[s.id] = handle
        record('gen_ms', now_ms() - t0)

    for sid, h in list(state.active_scenes.items()):   # 释放旧资源
        if should_release(sid, player, state):
            release(h)
            del state.active_scenes[sid]

timeout_ms 先设一个明显偏小的值，例如 50 毫秒，确认超时分支真的会走进 fallback_low_detail。验证方式是看日志里回退次数是否随负载上升而出现，以及回退后画面是否仍可操作，而不是卡住等生成。链路确认通了，再把 timeout_ms 调回合理值。释放旧资源放在生成之后而不是之前，避免同一帧内既释放又申请。

设定资源超限时的降级策略

显存或延迟触顶时优先降颗粒度，不要直接退出。降级开关写成可热改的配置，三档对应三个负载档位，触发条件同时看显存和帧间隔，任一超线就降一档。

{
  "tiers": [
    { "name": "high", "scene_radius_m": 80, "object_density": 1.0, "gen_interval_ms": 200,  "texture_budget_mb": 512 },
    { "name": "mid",  "scene_radius_m": 50, "object_density": 0.6, "gen_interval_ms": 500,  "texture_budget_mb": 256 },
    { "name": "low",  "scene_radius_m": 30, "object_density": 0.3, "gen_interval_ms": 1200, "texture_budget_mb": 128 }
  ],
  "trigger": { "vram_used_pct": 0.85, "frame_interval_ms": 40 },
  "recover_after_s": 20,
  "log_degrade": true
}

验证方式是逐步加负载：先只开一类场景，再同时开两类、三类，观察日志里的降级次数是否按预期出现，以及降档后帧间隔是否回到阈值以内。降级日志至少记录触发档位、触发原因（显存还是帧间隔）、当时的场景数量，否则事后分不清是配置问题还是某类场景本身太重。恢复条件要留迟滞时间，避免在阈值附近反复升降档。

把验证结果写回场景切分清单

跑完基线后回到第一份场景清单，把每类场景分成三种结论：可以实时生成、只能预生成、必须剔除。依据是你自己记录到的显存差值和生成耗时，不是猜测。

保留项要写清是实时生成还是预生成，剔除项写明延后还是换实现。下一次测试入口固定为三样东西一起提交：改动后的场景清单、清空的基线记录表、同一套降级配置，避免有人只改场景却对不上旧基线。单次改动控制在清单里一到两类场景，改完重跑基线并覆盖记录表，资源边界才始终有对应的测量依据。