展厅孪生项目的验收清单：验什么、怎么验

本文给的是通用验收框架与验证方法，供拟定验收条款时参考；具体指标门槛、责任划分与验收流程，以合同、技术协议和项目实际情况为准，不针对任何单一品牌或平台硬编参数。

验收那天的场景大多相似：乙方工程师抱着自己的笔记本投到大屏上，鼠标一路推着走——鸟瞰、下钻、切图层、弹出设备详情，画面流畅，数字在跳。半小时演示完，甲方几个人对视一眼，觉得挑不出毛病，签了字。三个月后运维反馈：屏上那台空调的读数，从上线就没变过。

孪生项目验收最大的风险，在于很多东西根本看不出真假。 三维好不好看，外行看一眼也有判断；但数据是不是真的实时、点位是不是接在了对的构件上、数据源断了界面会怎么样——这些光看演示看不出来，演示恰恰是绕开这些问题设计的。

所以验收的核心不是”再看一遍演示”，而是设计一批能证伪的动作：系统若是假的，这个动作一定让它露馅。这篇按七组给出可逐条打勾的清单，重点在数据真实性和异常降级。想先弄清孪生的定义与能力分级，看数字孪生是什么；这个方向的全部内容在数字孪生专题。

验收的三个前提

展开清单之前，先把三个前提立住。这三条不立，后面每一条都能被绕过去。

一、在真实运行环境验。 用展厅实际那台主机、那块屏、那条网络。开发机通常配置更高、网络更干净，甚至挂着一份本地测试数据。

二、用真实数据验。 验收前明确当前连的是哪一路数据源，且现场可核对。带演示模式的系统尤其要注意——演示模式与实时模式必须在界面上明显区分。

三、由甲方的人动手操作。 乙方推鼠标演示，验的是”这条路径能走通”，不是”这个系统能用”。让运维和讲解员按自己的习惯乱点，才会暴露真问题。

一句话：乙方在开发机上演示的，验的是演示，不是系统。

第一组：三维场景

这组最容易验，也最容易被过度关注：

• 模型完整性：对照确认过的范围清单逐项核对。缺失多出现在边角区域和后期变更的部分。
• 精度与观看距离匹配：站在观众实际站位看，构件轮廓与文字标签是否清晰；同时看是不是堆了大量这个距离根本看不到的细节。精度过剩和精度不足一样是问题，前者直接换来掉帧。
• 帧率在验收机器上实测：在展厅那台机器上跑典型操作序列（鸟瞰旋转、下钻、切图层），并把预设视角挨个切几轮，看帧率是否稳定、有无闪烁或加载不全。帧率门槛应在合同或技术协议中按实际展示内容与硬件配置约定，并以验收机器实测为准，不套用别处的数字。
• 冷启动加载时间：从双击图标到可交互，计时记录。开馆前等太久，运维会干脆让它常开着，长时稳定性的问题就全跑出来了。

第二组：数据真实性（重点）

这是整份清单的核心。判断数据是不是真的实时，唯一可靠的办法是主动改变物理世界的某个状态，再看屏幕跟不跟。 从下面挑几个现场可控、不影响正常运行的动作：

• 改变一个可控的物理状态：现场开关一台可安全操作的设备，或遮挡、加热一个传感器，掐表记录屏幕跟随变化用了多久。不变就是没接；变了，把时间记下来作为延迟基线。
• 反向再做一次：把状态改回去，看屏幕是否也跟着回去。只跟一个方向的，往往是碰巧撞上了某段脚本或缓存刷新。
• 随机抽点核对数值：抽若干点位（别用乙方推荐的那几个），同一时刻记录屏上显示值，与源系统读数逐个比对。要抽不同类型、不同区域的点，包括边角位置。
• 核对时间戳：界面是否显示采集时间或最后更新时间？没有就要求补上。没有时间戳的实时数据无法验证。
• 确认延迟量级并写进记录：不同数据源的实时性天然不同，开关量可能秒级，能耗累计值可能分钟级甚至更长。目的不是逼出一个统一的低延迟，而是把每类数据的真实延迟摸清、记录下来，并确认够用。

数据从哪来、走什么协议，可配合孪生数据接入怎么做一起看。

第三组：映射正确性

数据是真的，不代表接对了地方。同类设备张冠李戴是孪生项目里最隐蔽的错误——三号楼的电表接到了四号楼的模型上，界面照样跳数，谁也看不出来。

• 抽查点位与构件的对应关系：随机抽若干构件，点开看它绑的点位编号，与点表核对。重点抽同类型、同规格、位置相邻的设备，这正是最容易接错的地方。
• 用第二组的物理动作交叉验证：操作 A 设备，看是不是 A 在屏上变、而不是隔壁的 B 在变。这一条比核对编号更硬，因为它连点表本身有没有错都一起验了。
• 核对命名口径与静态属性：屏上的设备名、房间名、区域划分是否与运维日常口径一致（不一致会让人看到告警找不到现场位置）；设备型号、安装时间、责任部门是否准确。这类错误常来自台账本身，早发现早好。

第四组：异常与降级（必验）

这一组常被整组跳过，理由是”正常情况下不会发生”。但恰恰是它决定了系统会不会在出问题时给出误导性信息，属于安全性问题。

• 断开数据源，看界面反应：在可控条件下（断开某一路采集链路，或请乙方在测试环境模拟）观察。可接受的表现是数值灰掉、标注”断连”、显示最后更新时间。
• 重点验证：会不会把陈旧数据当实时数据显示。断连后数值原样挂在屏上、毫无提示，属必须整改项——看着像实时的旧数据，比一片空白危险得多，它会让人基于错误信息做判断。
• 恢复后是否自动回到实时：数据源接回来，界面能否自动恢复并清除断连提示，还是要重启软件。
• 部分断连的表现：只断一路时，应是局部标注断连、其余照常，而不是整屏报错。
• 降级视图是否可用：断连时的展示预案是否已做好并可切换。降级方案怎么设计属于中控编排范畴，详见孪生展项与中控联动。

第五组：交互与联动

展厅里孪生系统是要被讲解员当工具用的，交互不顺就没人用。

• 预设视角与下钻返回：每个视角落点是否准确、过渡是否顺滑；从园区钻到楼栋再到设备后逐级返回，看是否回到原位置和图层，还是弹回初始状态。
• 复位功能：先故意把系统操作得乱七八糟（切图层、钻到深处、开弹窗），再按复位，看能否回到干净的待机态。
• 与中控、讲解动线联动：按实际讲解流程完整走一遍，每段的视角、图层、灯光、音频是否都到位。
• 跳段测试：这条最容易漏。讲解员经常跳段，从第一段直接跳到第四段，看状态对不对——要验的是任意跳转都能得到确定结果，不只是顺序走一遍没问题。
• 误操作容错：连续快点、切换途中再切，看会不会卡死。

第六组：性能与长时稳定性

这一组验收当天做不完，建议单列观察期条款。

• 跨越完整开馆时段的连续运行：按真实使用强度跑满一个开馆时段（或数日），期间定时记录帧率与内存占用。
• 内存泄漏与帧率衰减：内存占用是否持续单向上涨不回落；刚启动流畅、跑几小时后变卡，是典型的资源累积症状。记录首尾的帧率与内存对比。
• 断电恢复与定时任务：意外断电重启后能否自动回到待机场景；闭馆自动复位、开馆自动启动是否真按时执行，最好实地观察一次。这两条决定运维的日常负担。

第七组：交付物（写进合同）

交付物最容易被”下周补给你”糊弄过去，而它决定了这套系统几年后还能不能维护。交付物清单要在合同或技术协议里逐项列明，并作为验收的必要条件。

交付物	为什么必须要
点表（编号、类型、来源系统、采集频率）	排查数据问题的依据
映射表（点位与三维构件的对应关系）	设备增减、区域改造时靠它更新
指令清单（可调用的视角、图层、场景切换指令）	后期接中控、接新展项的依据
三维模型源文件与更新方法	决定能不能换人维护
账号与权限清单	账号留在乙方手上，系统就不完全属于你
部署与恢复说明	主机故障更换时的依据
数据源对接说明（接了哪些、什么协议、谁维护）	上游改造时才知道会影响什么

其中模型源文件和指令清单要特别盯住：前者关系到能不能换供应商，后者关系到能不能接新东西。验收后再补，议价能力已经不在甲方手上了。整体落地流程可参考数字孪生展厅怎么做。

怎么把清单变成验收方案

七组不必平均用力。证伪动作放在最前（第二、三、四组），它们最可能触发整改；长时稳定性单列观察期。结论建议用三档：通过、限期整改后复验、不通过，并明确一票否决项——数据不实时、映射错误、断连时用旧数据冒充实时。

这是通用框架而非万能模板：各项目的数据源、展项形态与运维能力差别很大，具体条款以合同约定和项目实际为准。清单的价值是把”看起来做完了”变成”可以逐条打勾”，它降低漏验概率，但不替代专业判断。

小结

孪生项目验收的难点不在三维，在于数据的真伪、映射的对错、异常时的表现——这三样光看演示都看不出来。所以验收要做的是设计能证伪的动作：改变一个可控的物理状态看屏幕跟不跟、抽点位和源系统对数、断开数据源看会不会拿旧数据冒充实时。

七组里数据真实性和异常降级是重点；交付物要写进合同——点表、映射表、指令清单、模型源文件、账号权限，缺一项都是几年后的麻烦。

三个前提贯穿始终：在真实运行环境、用真实数据、由甲方的人动手操作。 乙方在开发机上演示的，验的是演示，不是系统。

延伸阅读：孪生展项与中控联动、孪生数据接入怎么做、数字孪生展厅怎么做，或看数字孪生专题。

---

要把孪生大屏、沙盘、灯光与影片接进一条可验收、可复位的讲解动线？了解企服君自研 SoftControl 展厅中控——支持 Modbus / RS232 / RS485 / TCP-UDP 等常见控制协议，可按讲解分段一键切换与定时复位。也可以直接说说现场需求，我们帮你定制方案、聊聊对接。