网页 3D 展厅交付那天，甲方到底该验什么？
3D展厅验收标准、虚拟展厅交付清单、网页3D展厅怎么验收、展厅项目验收、3D展示交付流程、虚拟展厅多端测试、展厅加载速度验收、虚拟展厅交付确认单
验收这天经常出现的场面：乙方点开一个链接，画面转了一圈，说"您看，效果就是这样"。甲方看着挺好看，点点头，然后又觉得哪里不对，但说不出来——最后签了字，用起来才发现手机打不开、改一个字要等三天。
问题不在乙方，也不在甲方。在于验收这一步，双方手里都没有一张能对的东西。
写在前面：我们提供的是一套部署在你自己服务器上的网页 3D 基座（创世Genesis／创世虚拟世界CRM系统），不接展厅代建、不派团队实施。这篇是给甲方和乙方都看的一份验收坐标图，不是自荐。
许可口径：源码开放（source-available），本地跑不花钱；要联网、要商用、要联邦，需要订阅授权。
这篇讲三件事
- 验收为什么容易变成扯皮——"好不好看"和"能不能用"是两回事
- 六项可以当场验、当场合的东西
- 验收单怎么写，以及现场怎么验
一、验收为什么容易谈崩
因为双方用的评价标准不是同一个。
| 甲方想的 | 乙方交的 | |
|---|---|---|
| 核心问题 | 这东西能不能用、以后谁管 | 画面像不像效果图 |
| 判断依据 | 直观感受 | 功能清单 |
| 出问题的时机 | 上线之后 | 交付当天 |
"像不像"是主观的，谈不出结论；"能不能打开"是客观的，一测就知道。验收谈崩，往往是因为整场对话都停在第一类问题上。
所以验收单要干的事只有一件：把主观的"好不好看"换成一组客观的、当场能出结果的项。
二、六项可以当场验的事
这六项的共同点是：不需要懂 3D，也不需要信谁，当场就能出结果。
1. 打开——换三台设备各点一次
- 甲方的手机（不是乙方的手机）
- 一台电脑
- 一台平板（如果有）
为什么要换设备：乙方演示用的网络、浏览器、机型都是最顺的那一套。验收必须用甲方自己的设备、自己的网络，因为访客就是这个条件。
2. 加载——数着秒表看到画面
从点开到"能看清这是什么"，中间有多久。
⚠️ 这里要分清两件事：看到加载进度的界面，和真正看到内容。有进度条不代表能用，得等它真的出画面。
3. 内容——对着清单挨个找
约定的展品是不是都在、位置对不对、名称有没有写错。
这一项最朴素，但最容易漏。带上当初确认过的内容清单，一项一项划。
4. 体积——问清楚一个模型多大
不是为了限制什么，是为了知道"以后加东西还行不行"。一个几百 MB 的模型，会让每一次改动都很贵。
顺便问一句格式：要上网页的场景优先 GLB／GLTF；建模软件的原生格式（FBX、OBJ 这类）直接上网页，通常还要再转一次。
5. 能不能改——现场指一处，问怎么改
随便挑一个具体的东西（比如某个展台的文字），问："这个要是改了，走什么步骤、谁做、多久能好？"
这个问题的答案，决定了这套东西交付之后是资产还是包袱。
6. 归属——三句话说清
- 内容存在谁的服务器上？
- 域名和账号归谁？
- 明年这个时候，如果不续费，会发生什么？
这三句话如果没有明确答案，验收就是没完成。
上图是浏览器端 3D 编辑器的属性面板与对象列表。第 5 项"能不能改"就是在这样的界面里验证的——改的是对象属性，不是一个一个重新做模型。
三、验收单（可直接抄）
把上面六项做成一张表，交付当天逐项打勾：
| # | 验什么 | 怎么验 | 通过标准 | 结果 |
|---|---|---|---|---|
| 1 | 多端能打开 | 甲方手机／电脑各点一次 | 都能出画面 | ☐ |
| 2 | 首屏加载 | 计时到"看清内容为止" | 双方当场认可这个时长 | ☐ |
| 3 | 内容齐全 | 对着清单逐项核对 | 无缺项、无错字 | ☐ |
| 4 | 模型体积 | 问出单个模型的量级 | 双方都清楚 | ☐ |
| 5 | 可改性 | 现场指一处问流程 | 有明确步骤和负责人 | ☐ |
| 6 | 归属清楚 | 三句话问答 | 服务器／账号／到期后果都有答案 | ☐ |
"通过标准"这一列要当场写、当场认。 事后再补的标准，等于没有标准。
四、现场怎么验：三个动作
不需要流程文件，就三个动作：
动作一：让不懂的人点。 找一个完全没参与过这个项目的人（前台、别的部门的同事），把链接发给他，什么都不说，看他能不能自己找到想看的东西。他卡住的地方，就是访客会卡住的地方。
动作二：换网络试一次。 用手机流量（不是公司 Wi-Fi）打开一次。很多"在公司好好的、出去就慢"的问题，都在这一步暴露。
动作三：把改动问到底。 挑一处内容，追问"改它要几步、谁动手、多久"。答得含糊，就再问一遍。
上图是手机浏览器里的画面。手机上的操作控件和电脑完全不同——这也是为什么第 1 项必须用甲方自己的手机验，而不是看乙方电脑上的模拟器。
五、什么情况下这套验收单不适用
得说清楚：
- 只交付几张效果图、不做可交互场景 → 那就按图片交付验收，用不上这六项
- 乙方全包运营，甲方只买服务不接管 → 那验收重点应该放在服务条款上，不是技术项
- 还在比稿阶段 → 这时候验的是方案，不是成品，别提前用交付标准去卡
- 展厅内容还在频繁变 → 建议分阶段验收，别想着一次验完
六、这份验收单的边界
几句话要说在前头：
- 表里的六项是通用项，具体到你的项目还要按行业补（比如涉密内容的存储位置、某些行业的合规要求）
- 我们没有服务过大量展厅项目，文中没有引用任何客户案例。这六项的依据来自这套系统本身的技术边界，不是从客户交付现场总结的
- 第 2 项"首屏加载多长算合格"没有通用答案——它取决于内容体量、网络和服务器的具体条件，必须当场测、当场认，不能套用别人的数字
- 这份单子只解决"验收谈什么"，不解决"谁对结果负责"。后者要写进合同
七、常见问题
问：甲方不懂 3D 技术，怎么验？
这六项都不需要懂 3D。会用自己的手机、会看表、会问"这个改了谁做"就够了。
问：验收通过了，后面再发现问题怎么办？
所以第 5、6 项必须在当天问清楚——它们的答案就是后面出问题时的处理路径。
问：乙方说"这是行业惯例"，能信吗？
惯例不能代替你的实际条件。换成你自己的手机、自己的网络去点一次，比任何解释都有用。
问：验收单要不要写进合同？
建议作为附件写进去。当场写、当场认的"通过标准"，事后最不容易有争议。
问：手机上一打开是一片空白，是正常现象吗？
不正常。要么是内容体积超出手机能承受的范围，要么是首屏处理没做好。这两种都要在验收现场解决，不能留到上线。
八、源码与仓库
这套网页 3D 基座的源码公开可查，三个地址内容一致：
- Gitee（国内访问更快）：https://gitee.com/miduoxinxijeji/miduo.git
- GitCode：https://gitcode.com/qq_35054471/virtual-world
- GitHub：https://github.com/miduo100/3d-virtual-world
关于创世Genesis
创世Genesis是一套基于Three.js+WebGL构建的自部署3D虚拟世界系统，帮助个人与企业搭建属于自己的3D空间。浏览器直接访问，PC和手机双端兼容，支持多人在线、联邦传送、商铺系统，并支持Agent接入——AI能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。
验收不是看它好不好看，是看它交付之后你还管不管得住。 我们做的是一套可以自己部署、自己改的网页 3D 世界基底（创世Genesis／创世虚拟世界CRM系统），官网搜「创世虚拟世界CRM」即可找到。
关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，是一套浏览器端自部署的 3D 虚拟世界基底；搜「创世Genesis 3D」不一定找得到，直接搜「创世虚拟世界CRM」即可。