简介：面向VR/AR初学者、独立开发者及教学备课人员，这份文档以“创建虚拟展览体验”为主线，给出可扩展的开发脚本案例与流程框架，帮助读者快速理清从创意到可发布应用的实现路径。内容围绕项目初始化与环境配置、3D模型导入与场景布置、头部追踪和手势识别等交互逻辑、UI与音效设计、构建发布及后期维护展开，并补充3D建模、纹理编辑、音频处理等工具衔接，以及LOD、延迟加载等性能优化与兼容性测试思路。压缩包仅含1个doc文件，约21KB，篇幅精简，适合作为项目启动清单、课程案例或开发流程速查表。目前已有807人学习，可作为VR/AR展览类项目入门与框架搭建的参考。

1. 虚拟展览的第一道坎：先把帧率预算定死，再谈模型精度

做过一个校内展厅的 VR/AR 版本，最开始两周全花在把展品模型往精细处打磨，结果戴上头显五分钟就头晕。问题不在模型，在于帧率和延迟从头到尾没被写进需求文档。虚拟展览这类项目，在常见的 VR/AR 开发脚本案例里最容易漏掉的一节，恰恰是性能预算：目标设备是 PC 头显还是一体机、跑 72 帧还是 90 帧、单眼分辨率多少、允许几个 draw call，这些数字先定下来，后面选引擎、导模型、写交互才有边界，插件和 SDK 也才知道该装哪几个。这套方案面向要交一份完整 VR/AR 设计或毕设的同学，也面向需要给甲方交付一个可演示展厅的开发者，从项目初始化、场景搭建、交互开发、UI 与音效，一路走到构建发布和验收答辩，每一步都给到能照着改的参数与脚本。

2. 需求拆解与引擎选型：三类展览需求与四个模块的职责边界

虚拟展览最怕的需求描述是「要沉浸、要好看、要能交互」。这三句话没法验收，也没法排期。我在动手前会把它们拆成展品数量、观众动线长度、交互深度、目标设备四条硬指标，再倒推引擎和工程结构。这一章讲的就是拆解方法和选型依据，工程目录与参数基线也一并给出，后面几章的脚本都跑在这套结构上。

2.1 把「沉浸感」翻译成四条可验收的需求

展品数量决定资源预算。一个 200 平米的展厅，如果放 30 件展品，每件平均面数控制在 8000 三角面以内，全场景静态几何加起来约 25 万面，一体机勉强能扛；放到 60 件，就必须上 LOD 和分块加载。观众动线决定场景分块方式，环形动线可以按扇区分批加载，直线动线则要保证前后视野里同时存在的物件不超过两区块。交互深度决定脚本复杂度，只是「看一眼出文字」和「抓取展品翻转查看」是两个量级的工程量。目标设备决定一切上限。

下面这张表是我一般会先填完再开工的需求拆解模板，填不满就说明需求还没聊透。

填这张表的过程本身就是排雷。比如「可交互展品 8 件」这一条，如果一开始没写，后期每加一件都要重新做碰撞体、重新挂脚本、重新测性能，返工成本远高于前期定死。

2.2 Unity 与 Unreal 两条路：四个判断条件

引擎选型在课程设计和毕设里经常被当成信仰问题，其实它就是四个条件的选择题：团队人数与周期、目标设备、美术资源来源、脚本语言熟悉度。

一个 8 到 12 周的毕设或课程设计，团队 1 到 3 人，目标设备是一体机，答案基本落在 Unity + URP 这一侧。反过来，如果展厅要在 PC 头显上做高精度实时反射和复杂后处理，且周期在半年以上，Unreal 的默认画质能省掉大量调参工作。这里没有绝对优劣，只有预算匹配。

我踩过的一个坑是「两个引擎都想试」。原型阶段各花一周，最后两边都只到半成品。选型一旦定了，插件生态也要跟着定：一体机通常要装厂商提供的 XR 插件包，Unity 侧还要配套 XR Interaction Toolkit 之类的交互框架，插件版本和引擎版本强绑定，升级引擎前先确认插件有没有对应版本，这是血泪经验。

2.3 工程目录与项目参数基线

目录结构建议在创建工程的第一天就定好，不要等资源堆到几百个再整理。我习惯按「场景 / 脚本 / 预制体 / 美术 / 音频 / 配置」六分法，好处是打包时能按目录做资源分组，也方便后期做 Addressables 分组。

# 在工程根目录 Assets 下执行，一次建好六类目录 mkdir -p Assets/Scenes # 场景文件，按展厅扇区命名 mkdir -p Assets/Scripts/Core # 输入抽象、状态机、管理器 mkdir -p Assets/Scripts/Interact # 展品拾取、凝视触发 mkdir -p Assets/Prefabs/Exhibit # 展品预制体，一件一个 mkdir -p Assets/Art/Models # FBX 原始模型 mkdir -p Assets/Art/Materials # 材质与贴图 mkdir -p Assets/Audio/Mixers # 混音器与音频组 mkdir -p Assets/Config # ScriptableObject 配置资产

这段命令的作用不只是建文件夹。Scripts/Core和Scripts/Interact分开，是为了让输入抽象层不依赖具体展品逻辑，换设备时只改 Core；Prefabs/Exhibit一件展品一个预制体，是为了后期按展品做异步加载；Config目录放 ScriptableObject，展品名称、介绍文本、音频片段都挂成配置资产，改文案不用重新编译脚本。

项目参数这块，Player Settings 里有几项必须在第一天就改，改晚了会牵连所有资源的导入设置：

固定注视点渲染这一项要单独说。它把视野边缘的像素分辨率降下来，中心区域保持原样，视觉上几乎察觉不到，但 GPU 负载能降两成左右。开启后如果发现文字发虚，把 UI 画布的渲染模式改成 Overlay 单独处理，别让 UI 跟着一起降采样。

3. 场景与内容搭建：模型管线、空间布局与灯光材质的三段预算

场景搭建看起来是美术活，实际上一半是工程活。同样一批模型，导入设置不同，帧率能差一倍。这一章按「模型进来 → 摆到位置上 → 打光上材质 → 界面和声音怎么进空间」的顺序走，每一段都给具体的数值区间，照填即可。

3.1 模型导入规范：面数、材质槽与缩放三件事

模型进引擎前先过三道关。第一道是面数，一体机上单件展品的三角面建议控制在 5000 到 8000，超过 12000 就要做 LOD。第二道是材质槽，一个模型挂 5 个以上材质槽，渲染时就多 5 次 draw call，展品类模型建议合并到 2 个槽以内（主体 + 透明件）。第三道是缩放，模型在建模软件里按真实尺寸导出，单位统一成米，导入时 Scale Factor 保持 1，不要靠引擎里拉缩放来凑大小，缩放不归一会让物理碰撞体和光照贴图都出问题。

格式上 FBX 最稳，OBJ 不带材质和动画，只适合临时占位。导入后记得勾选「Generate Lightmap UVs」，否则后面烘焙光照贴图时会报 UV 重叠，这个报错很隐蔽，只表现为烘焙结果一片脏污。还有一个容易漏的点：导入设置里的「Read/Write Enabled」默认关闭，如果脚本里要读取模型顶点做高亮描边，必须打开，但打开后内存占用会翻倍，用完记得关。

3.2 展厅坐标与动线：以「一个展位 3 米」为单位做布局

虚拟展厅最容易做塌的地方是尺度感。现实里 3 米宽的一个展位，在 VR 里如果做成 1.5 米，观众会觉得所有东西都是玩具；做成 6 米，又会觉得自己变小了。我一般以一个展位 3 米宽、2.6 米高作为基准单位，所有布局按这个单位取整。

坐标系上，把展厅原点放在入口正中央，Y 轴朝上，观众初始朝向 +Z。这样切分扇区时可以直接按 Z 值分段加载。环形动线的话，把展厅拆成四个扇区，每个扇区覆盖 90 度，玩家进入某个扇区时加载该扇区及其相邻扇区，离开两个扇区以外就卸载。这套规则写进配置资产里，后期改展厅尺寸只改数字不改代码。

// SectorManager.cs // 按玩家所在的 Z 轴区间做扇区分块加载，避免整场景常驻内存 using UnityEngine; public class SectorManager : MonoBehaviour { [System.Serializable] public struct Sector { public string id; // 扇区标识，如 "A" "B" public float zStart; // 扇区起始 Z public float zEnd; // 扇区结束 Z public GameObject root; // 该扇区下的所有静态物体 } public Sector[] sectors; // 四个扇区在 Inspector 里按序填入 public Transform player; // 玩家相机 public float keepDistance = 12f; // 相邻扇区预加载距离 void Update() { float z = player.position.z; foreach (var s in sectors) { // 玩家在扇区内，或距离扇区边界在预加载范围内，则激活 bool active = z >= s.zStart - keepDistance && z <= s.zEnd + keepDistance; if (s.root.activeSelf != active) s.root.SetActive(active); } } }

这段脚本的逻辑是按 Z 轴位置做粗粒度剔除，keepDistance决定预加载范围，取 12 米大约相当于四个展位的长度，够玩家走进下一个扇区时内容已经就位。用SetActive而不是SetActive加卸载，是因为展品预制体里挂着状态（比如面板是否打开），频繁销毁重建会丢状态。真正吃内存的大贴图和大模型，交给后面的异步加载处理，这一层只做可见性管理。

3.3 灯光与材质：烘焙为主，实时光只留一盏

一体机上同时开三盏实时光源基本就到极限了。我通常的做法是：场景主光用烘焙的定向光，展品重点照明用烘焙的聚光灯，实时只保留一盏跟随玩家的小范围补光，用来防止观众走进阴影区后画面全黑。烘焙参数上，光照贴图分辨率按展位给 20 到 40 texel 每米，整个展厅控制在 4 张 1024 贴图以内。

材质方面，URP 下优先用 Lit 着色器，少用 Standard。透明材质是性能杀手，展柜玻璃这类需要透明的物件，用单面透明材质加一层反射贴图模拟，不要用双面透明加实时折射，后者在移动端几乎跑不动。金属度参数别直接拉满，真实展品的金属度一般在 0.7 到 0.9 之间，拉满会显得像塑料镀膜。

还有一个细节是展品的自发光。有些展品需要打背光展示轮廓，用 Emission 加一张遮罩贴图即可，但注意 Emission 会参与全局光照计算，如果场景里有大量自发光物件，烘焙时间会翻倍。我的处理是给自发光物件单独一个 Layer，烘焙时排除，靠后期处理里的 Bloom 补一点辉光，视觉上差别不大，成本低很多。

3.4 UI 与音效的空间化处理

UI 别贴在相机前面。VR 里最难受的体验之一是文字面板跟着头转，看久了像坐船。做法是把信息面板做成 World Space Canvas，固定在展品旁边 1.2 到 1.8 米的距离，高度略低于视线，观众想看的时候转头看过去，不想看就移开视线。字号的换算基准是：1 米距离上，正文字号不小于 0.03 米高，标题不小于 0.06 米高，低于这个值在一体机的纱窗效应下会糊成一片。

音效分三层：环境层是展厅的底噪和混响，常驻播放，音量压到 -18dB 左右；交互层是点击、抓取的反馈音，-12dB，要干脆；叙事层是展品讲解音频，-6dB，是主角。三层各自挂到 AudioMixer 的不同分组上，观众在设置里调「讲解音量」时只动叙事层，环境层保持不动，这样不会一调音量整个展厅就死寂。

// ExhibitAudio.cs // 展品音频的三层控制：环境层常驻，交互层一次性，讲解层可打断 using UnityEngine; using UnityEngine.Audio; public class ExhibitAudio : MonoBehaviour { public AudioMixerGroup ambientGroup; // 环境层分组 public AudioMixerGroup sfxGroup; // 交互层分组 public AudioMixerGroup voiceGroup; // 讲解层分组 private AudioSource ambient; // 环境音，循环 private AudioSource sfx; // 交互音，PlayOneShot private AudioSource voice; // 讲解音，同一时刻只允许一条 void Awake() { ambient = gameObject.AddComponent<AudioSource>(); ambient.loop = true; ambient.outputAudioMixerGroup = ambientGroup; sfx = gameObject.AddComponent<AudioSource>(); sfx.playOnAwake = false; sfx.outputAudioMixerGroup = sfxGroup; sfx.spatialBlend = 1f; // 完全 3D 空间化 voice = gameObject.AddComponent<AudioSource>(); voice.playOnAwake = false; voice.outputAudioMixerGroup = voiceGroup; voice.spatialBlend = 0.4f; // 半空间化，保证讲解清晰 } public void PlaySfx(AudioClip clip) => sfx.PlayOneShot(clip); public void PlayVoice(AudioClip clip) { if (voice.isPlaying) voice.Stop(); // 讲解互斥，避免两条音频叠在一起 voice.clip = clip; voice.Play(); } }

三个 AudioSource 分开挂的好处是混音器分组独立，观众在设置面板里调任一层的音量互不干扰。spatialBlend是空间化程度，1 表示完全按 3D 位置衰减，0 表示纯 2D，讲解音频取 0.4 是折中：既有方位感，又不会因为观众转头就听不清。PlayVoice里的互斥判断很关键，展厅里两个展品挨得近，观众快速扫视时很容易同时触发两段讲解，叠在一起就变成噪音。

4. 交互功能开发：输入抽象层与展品拾取脚本的具体实现

交互这块，代码写得多不如接口分得清。头部追踪、手柄射线、手势识别三种输入在底层完全不是一回事，但如果上层每个展品都要分别判断「现在是哪种输入」，脚本会迅速膨胀到没法维护。做法是先做一层输入抽象，把所有设备统一成「有一条射线、有一个确认动作」的模型，展品逻辑只依赖这层抽象。

4.1 输入抽象层：把头部、手柄、手势收成一套接口

接口只暴露两个东西：射线（起点、方向）和确认（按下、松开）。头部追踪的射线就是相机正前方，确认动作由凝视停留时长模拟；手柄的射线是手柄指向，确认是扳机键；手势识别的射线是手心朝向，确认是捏合。三种输入在各自的实现类里处理，上层拿到的永远是同一份数据。

// IInputProvider.cs // 所有输入设备的统一出口：给一条射线 + 一个确认状态 using UnityEngine; public interface IInputProvider { bool TryGetRay(out Ray ray); // 当前是否有一条有效射线 bool ConfirmPressed { get; } // 本帧是否按下确认 bool ConfirmHeld { get; } // 本帧是否持续按住 } // GazeInputProvider.cs // 头部凝视实现：射线取相机正前方，确认由停留计时器给出 public class GazeInputProvider : MonoBehaviour, IInputProvider { public Transform eye; // 主相机 public float dwellSeconds = 1.2f; // 停留多久算一次确认 private float timer; public bool ConfirmPressed { get; private set; } public bool ConfirmHeld => timer > 0f; public bool TryGetRay(out Ray ray) { ray = new Ray(eye.position, eye.forward); return true; } void Update() { // 确认状态每帧重置，真正的计时在交互控制器里累加 ConfirmPressed = false; if (timer >= dwellSeconds) { ConfirmPressed = true; timer = 0f; } } public void AddDwell(float delta) => timer += delta; public void ResetDwell() => timer = 0f; }

接口只有三个成员，目的是让新增设备变成「加一个实现类」，而不是改所有展品脚本。TryGetRay返回 bool 是因为有些输入在特定状态下没有有效射线，比如手势识别在手掌张开放平的时候，这时上层应该跳过检测而不是拿一条错误方向去射线检测。AddDwell和ResetDwell暴露给交互控制器，是因为停留计时的累加条件依赖射线是否命中同一个目标，这个判断只有控制器知道。

4.2 展品拾取与信息面板的完整脚本

交互控制器挂在玩家身上，每帧拿一次射线，做一次 Physics.Raycast，命中的展品交给它自己处理面板。射线长度给 6 米，展厅尺度下足够覆盖一个展位；LayerMask 只勾展品层，避免打到墙体、地板和 UI 上。

// ExhibitInteractor.cs // 玩家侧交互控制器：射线检测 + 停留计时 + 展品状态切换 using UnityEngine; public class ExhibitInteractor : MonoBehaviour { [Header("射线参数")] public float maxDistance = 6f; // 展厅尺度下一个展位的距离 public LayerMask exhibitLayer; // 只检测展品层 [Header("凝视触发")] public float dwellTime = 1.2f; // 低于 1 秒误触率明显上升 public float resetAngle = 8f; // 视线偏移超过该角度重置计时 private ExhibitItem current; // 当前指向的展品 private float timer; // 停留计时 private Vector3 lastDir; // 上一帧射线方向 void Update() { var provider = InputManager.Current; // 输入抽象层的当前实现 if (provider == null || !provider.TryGetRay(out Ray ray)) { ResetAll(); return; } if (!Physics.Raycast(ray, out RaycastHit hit, maxDistance, exhibitLayer)) { ResetAll(); return; } var item = hit.collider.GetComponentInParent<ExhibitItem>(); if (item == null) { ResetAll(); return; } // 目标切换或视线偏移过大，都重新计时 if (item != current || Vector3.Angle(lastDir, ray.direction) > resetAngle) { current = item; timer = 0f; } timer += Time.deltaTime; lastDir = ray.direction; // 手柄类输入直接读 ConfirmPressed，凝视类输入走停留计时 bool fire = provider.ConfirmPressed || timer >= dwellTime; if (fire && !item.IsOpened) { item.OpenPanel(); timer = 0f; } } void ResetAll() { current = null; timer = 0f; } }

关键点在三处。GetComponentInParent而不是GetComponent，是因为展品模型往往有多个子网格，碰撞体挂在子物体上，向上找才能拿到完整的展品组件。视线偏移 8 度就重置计时，是为了防止观众扫视时对沿途每个展品都触发一次弹窗，这个阈值调到 5 度会太敏感，调到 15 度又会出现「明明看着它却不弹」的困惑。provider.ConfirmPressed || timer >= dwellTime这一行把两种输入合并了，手柄按扳机立刻触发，头部凝视则等满 1.2 秒，同一套控制器适配两种设备。

4.3 展品侧的状态管理：面板开关与复位

展品这一侧要做的是「被打开时做什么、被再次指向时做什么、离开时做什么」。面板不要每次打开都实例化，那是性能黑洞；正确做法是预制体在展品初始化时创建一次，之后只切 SetActive。面板朝向要朝向观众，但不能每帧都追着相机转，那会让人眼晕，改成打开瞬间朝向一次即可。

// ExhibitItem.cs // 展品侧：持有面板引用，管理打开/关闭状态与音频触发 using UnityEngine; public class ExhibitItem : MonoBehaviour { public string exhibitId; // 展品唯一标识，对应配置资产 public Transform panelAnchor; // 面板挂点，位于展品侧上方 public AudioClip voiceClip; // 讲解音频 private GameObject panel; // 面板实例，初始化时创建一次 private ExhibitAudio audioHub; public bool IsOpened { get; private set; } void Start() { audioHub = FindObjectOfType<ExhibitAudio>(); panel = Instantiate(Resources.Load<GameObject>("Panel/InfoPanel"), panelAnchor); panel.SetActive(false); } // 由交互控制器调用，传入观众相机位置用于面板朝向 public void OpenPanel() { IsOpened = true; panel.SetActive(true); var cam = Camera.main.transform; Vector3 dir = cam.position - panel.transform.position; dir.y = 0f; // 只绕 Y 轴转，避免面板仰俯 panel.transform.rotation = Quaternion.LookRotation(dir); if (voiceClip != null) audioHub.PlayVoice(voiceClip); } public void ClosePanel() { IsOpened = false; panel.SetActive(false); } }

面板朝向只取水平方向（dir.y = 0f）是个小技巧。如果面板跟着相机做完整的三维朝向，观众稍微低头，面板就跟着俯下来，读文字时视线一直在动；只绕 Y 轴旋转，面板始终立着，读起来稳。这个细节在答辩演示时很加分，评委不会说清为什么舒服，但会觉得「这个做得像样」。

4.4 调试与性能埋点：让掉帧不再是玄学

VR 项目最怕的是「在我机器上好好的」。掉帧一旦发生，先分清是 CPU 还是 GPU 瓶颈。做法很简单：在场景里挂一个性能面板，实时显示帧时间、draw call、三角面数和 GC 分配。帧时间超过 13.9 毫秒（72 帧的预算）就标红，连续三秒标红就写一条日志，记下当时玩家所在的扇区和朝向的展品。

// PerfProbe.cs // 轻量性能探针：只采样不干扰，超预算时记录现场信息 using UnityEngine; public class PerfProbe : MonoBehaviour { public float frameBudgetMs = 13.9f; // 72 帧对应的毫秒预算 public int sampleWindow = 60; // 采样窗口帧数 private float[] samples; private int index; private float lastLogTime; void Start() => samples = new float[sampleWindow]; void Update() { samples[index++ % sampleWindow] = Time.unscaledDeltaTime * 1000f; if (Time.time - lastLogTime < 3f) return; // 三秒内最多记一条，防止日志刷屏 float avg = 0f; foreach (var s in samples) avg += s; avg /= sampleWindow; if (avg > frameBudgetMs) { lastLogTime = Time.time; Debug.Log($"[PERF] 平均帧时间 {avg:F1}ms " + $"drawCall={UnityEngine.Rendering.FrameDebugger...}" ); // 实际用 ProfilerRecorder 取 } } }

日志里要带的信息不止帧时间，还要带玩家位置和当前加载的扇区。很多掉帧是特定位置触发的，比如走到某个展位前，展品的高精度模型和面板同时进画面，draw call 瞬间翻倍。有了位置信息，复现就是走两步的事；没有位置信息，就只能靠猜，那就是玄学了。这段代码里取 draw call 的部分，实际项目建议用ProfilerRecorder绑定Draw Calls Count，比反射取值稳，也不会在打包后失效。

5. 发布前排查：从真机掉帧到上架被拒的五类高频问题

编辑器里跑得再顺，打包到真机上总会冒出新的问题。这一章按「构建配置 → 真机问题 → 兼容性回归」的顺序，把我在虚拟展览项目里反复遇到的坑列出来，每条都按现象、原因、解决三步写，遇到同类问题时可以直接对照。

5.1 构建配置里两处必改项

第一处是纹理压缩格式。编辑器里用的无压缩纹理，打包到一体机上如果没设 ASTC，运行时会用 ETC2 甚至 RGBA32 兜底，显存直接翻倍。做法是在 Player Settings 里把 Android 平台的纹理格式限定为 ASTC 6x6，小于 512 的贴图可以用 ASTC 8x8，视觉上几乎无差。

第二处是剥离等级。IL2CPP 的代码剥离默认开中等级别，会把一些通过反射调用的类裁掉，表现为「编辑器正常，打包后某个功能静默失效」。虚拟展览里最容易中招的是 ScriptableObject 配置资产的序列化字段。解决办法是在 link.xml 里显式保留相关程序集，或者在剥离等级里选 Low，代价是包体大几 MB，但省下几小时的排查时间，这笔账很划算。

5.2 五类高频问题：现象、成因与定位路径

第一类：进入展厅后画面抖动，转头有拖影。现象是静态看没问题，一动就糊。原因通常是立体渲染开了多通道（Multi Pass），CPU 要为两只眼睛各提交一次渲染命令，负载翻倍。解决是把渲染模式改成 Single Pass Instanced，改完如果出现部分物体只有一只眼睛能看到，那是该物体的着色器不支持实例化，换成 URP 自带的着色器即可。

第二类：展品面板打开后帧率断崖下跌。现象是平时 72 帧，一开面板掉到 40。原因是面板用了 World Space Canvas 且勾了「每帧重建」，文字一多就触发大量网格重建。解决办法是把面板内容拆成静态文字和动态文字两块，静态部分用一张预渲染贴图，动态部分限制在 200 字以内，同时把 Canvas 的更新模式改成「仅当内容变化时重建」。

第三类：手柄射线能看见但点不中展品。现象是射线视觉上穿过了展品，但没有任何反应。原因多半是碰撞体缺失或 Layer 不对。展品模型导入后默认不带碰撞体，需要手动加 BoxCollider 或 MeshCollider，加完还要确认 Layer 是Exhibit，且交互控制器的 LayerMask 里勾了它。MeshCollider 要注意勾选 Convex，否则不会被射线检测命中，这个坑很隐蔽。

第四类：打包后启动黑屏三秒才进场景。现象是应用图标点了之后长时间黑屏，用户以为卡死。原因是首场景加载了太多常驻资源，包括全部展品预制体和音频。解决办法是把首场景做成一个极简的加载场景，只放一个进度条，真正的展厅场景用异步加载，加载期间进度条平滑推进，观感上就没有黑屏了。

第五类：上架审核被拒，理由是隐私政策缺失。现象是功能都正常，但提交后被退回。VR/AR 应用如果调用了任何设备权限（麦克风、存储、相机），必须在应用内提供隐私政策入口，且在商店后台填写数据收集声明。很多同学以为不联网就不用管，实际上只要申请了权限就要声明。这一条建议在开发中期就准备好，别等到提交前才补。

5.3 兼容性回归的抽检矩阵

发布前不可能每台设备都测，但可以按矩阵抽检。抽检的原则是覆盖「芯片档位 × 运行内存 × 系统版本」三个维度，每个维度取两个极端值，加起来测四到六台就够。

抽检时固定跑同一条动线：入口 → 四个扇区各停留 30 秒 → 触发全部可交互展品 → 返回入口。这条动线跑完大约 6 分钟，能覆盖 90% 的资源加载路径。每次改完资源或脚本都跑一遍，记下帧率和内存峰值，形成一张趋势表。趋势表比单次测试有用得多，能提前发现「每加一件展品内存涨 40MB」这种慢性问题。

6. 验收与答辩：用一份可复现的演示流程把方案讲透

答辩现场最忌讳的是「打开应用随便逛逛」。评委不知道你要展示什么，逛到哪儿算哪儿，最后时间花在找展品上，核心设计一句没讲。我的做法是提前写一份演示脚本，把 8 分钟拆成固定节点，每个节点对应一个设计点，边操作边说明为什么这么做。

演示脚本按这个节奏走。第一分钟讲需求约束：目标设备是什么、帧率定在多少、为什么定这个数，顺手打开性能面板让评委看到实时帧率。第二分钟走进第一个扇区，展示模型和灯光，说明面数预算和烘焙策略。第三分钟停在可交互展品前，演示凝视触发，讲清 1.2 秒停留时间和 8 度重置阈值是怎么定下来的，这两个数字最能体现设计思考。第四分钟切到设置面板，演示三层音量独立调节。第五分钟展示扇区切换时的异步加载，说明为什么首场景要做成加载页。最后两分钟留给提问，提前准备好三个可能被问到的点：为什么选这个引擎、性能瓶颈在哪里、如果展品数量翻倍要怎么改。

验收标准建议自己先列一张表，答辩时直接投出来，比口头描述有说服力。

有个容易被忽略的答辩技巧：把「没做什么」也讲出来。比如「手势识别这一版没做，因为目标设备的手势精度不够，强行做会让误触率超过 20%，所以这一版用凝视加手柄双通道」。评委听到这种取舍，比听十个功能列表更能判断你是不是真的想过。我见过太多答辩栽在「什么都做了但什么都说不清」上。

从那以后我每次带项目，都会在开发第一周就把验收表填出来，哪怕填得不准，也要有一个可以对照的靶子。做完再回头改表，改的过程就是复盘的过程。希望这套流程能帮到你，少走几段我走过的弯路。

本文还有配套的精品资源，点击获取