博物馆做线上展厅，这笔钱该记在"展陈"还是"宣传"？
博物馆线上展厅、虚拟展厅预算、线上展厅立项、虚拟展厅运维成本、博物馆数字化预算、虚拟展馆数据归属、自部署虚拟展厅、3D展厅年度维护
线上展厅这个东西，热闹都在验收那天。领导点一遍，同事转一遍，朋友圈发一遍。然后它安静下来——半年后再打开，链接还在，只是没人说得清为什么要有它。
技术不是主要死因。多数线上展厅死在"没有部门认领"上。
这篇不谈建模、不谈渲染，谈一件更前置的事：一笔钱记在哪个科目，很大程度上决定了这个东西能活多久。
写在前面：我们提供的是一套部署在你自己服务器上的网页 3D 基座（创世Genesis／创世虚拟世界CRM系统），不接展厅代建、不派团队实施。这篇讲的是预算与归属，不是自荐。
许可口径：源码开放（source-available），本地跑不花钱；要联网、要商用、要联邦，需要订阅授权。 准确条款在仓库 LICENSE / EULA 里。
这篇讲四件事
- 线上展厅通常怎么"死"的
- 一套东西其实有三本账，多数人只批了一本
- 记在不同科目，命差在哪
- 立项时能写进文件的三句话
一、四种死法，没有一种是技术问题
把见过的情况归拢一下，线上展厅活不下去大致是这四种样子：
| 死法 | 现场表现 | 根因 | 通常该谁管 |
|---|---|---|---|
| 没有入口 | 官网找不到、公众号菜单没位置、二维码只挂在开幕式背景板上 | 上线那天没人把入口写进任何流程 | 宣传／新媒体 |
| 改不动 | 换一件展品要等排期、等报价、等对方安排 | 内容不在馆里手上 | 展陈／信息中心 |
| 到期下线 | 某天打开是 404，域名或服务器欠费 | 服务器与域名登记在乙方名下 | 信息中心 |
| 无人更新 | 内容停在开馆那年那一版展陈 | 没有明确责任人 | 展陈部 |
这四种死法有一个共同点：它们都不是上线时能看出来的，都是上线后一年内发生的。 所以验收再仔细也验不出来——验收单上写的是"能打开""画面完整""内容核对无误"，没有一条问"明年谁来管它"。
二、一笔钱其实要管三本账
这是常出错的地方。大家说的"预算"，默认只有一本账。
| 账 | 性质 | 里面装着什么 | 漏掉的后果 |
|---|---|---|---|
| 建设账 | 一次性 | 空间搭建、模型处理、布场、上线部署 | 做不出来 |
| 内容账 | 按次 | 换展、加展品、改展签、改讲解词、调整动线 | 用一年就旧了 |
| 维系账 | 按年 | 服务器、域名、带宽、备份、系统升级、有人会改 | 悄悄死掉 |
常见的做法是只批了建设账。内容账靠"再申请一次"，维系账靠"没人提"。这不是执行不力，是结构上就没给它留位置。
顺带说一句：这三本账里，维系账的金额通常不大，但它是决定生死的那一本。服务器欠费不需要多少钱，可一旦没人负责续，前面两本账一起归零。
三、记在不同科目，命差在哪
同样是做线上展厅，钱从哪个口出，后续的待遇完全不同。这里说的是钱的性质，不是科目名称——各地各单位口径不一样，报预算前请按本单位财务口径核对。
| 记在哪一类 | 通常怎么批 | 好处 | 风险 |
|---|---|---|---|
| 宣传活动费 | 按项目、一次性 | 好批、快，能赶上一个节点 | 项目结项即结束，第二年续不上 |
| 展陈／数字化专项 | 项目＋年度 | 与线下展陈同源，有延续性 | 要和线下展陈抢同一笔钱 |
| 公共文化服务／教育 | 按年度活动 | 有真实使用场景，抗衰减 | 需要真的排活动，挂名不管会更快荒掉 |
| 信息化／网站运维 | 按年度 | 有运维口径，能覆盖维系账 | 容易被当成"网站"而不给内容预算 |
一个观察：记在"宣传活动费"的线上展厅，衰得通常比记在"教育/公共文化服务"的快。 不是因为宣传口不重视，而是宣传项目的天然节奏就是"做完这一波、下一波换主题"。线上展厅不是一波活动，它是一个可以反复用的场地——把它塞进活动节奏里，它就会被当成一次性的东西对待。
四、立项文件里能写的三句话
不讲理念，只讲三句可以抄进方案或合同的话。它们分别对应三本账里常缺的那几块。
一是账号归属。 域名、服务器、数据库账号登记在馆方名下，交付当天当场改密码，由馆方人员操作。这一句决定"换人时不换数据"。
二是年度维系。 单列一笔按年的维系预算，用于服务器、备份与版本升级。金额按本单位规模定，重点是"有这一项"，不是"有多少"。
三是改动责任人。 指定一名馆内人员，交付时完成一次培训；之后改文字、换展品、挪展台由馆内完成，不再走外部排期。这一句决定首年之后它还新不新。
三句话里，第三条经常被跳过，理由是"馆里没人会"。但这条恰好该坚持：如果馆里永远没人会改，那么这个东西的每一次改动都是一次采购。
上图是自部署世界的后台：当前世界数、在线人数，以及 Web Service、Database、WebSocket 三个服务的状态。"维系账"落到操作层面，就是这张图上的三行状态——它们任意一行变红，前台打开就是打不开。这也是为什么维系必须有人认领：它不是一个抽象概念，是三个会挂掉的东西。
五、技术选型怎么配合这三句话
如果已经决定要留账号、留改动权，选型时对应的就是四条硬要求。这四条不涉及品牌，任何方案都可以拿来对：
| 要求 | 为什么 | 怎么验 |
|---|---|---|
| 数据能整库导出 | 决定换供应商的成本 | 让对方现场导一次，看导出的东西能不能重新导入 |
| 账号在自己服务器上 | 决定会不会被平台停服影响 | 问清楚"断网内网能不能打开" |
| 改内容不用改代码 | 决定第二本账贵不贵 | 让内容岗的人上手改一处，看要几分钟 |
| 不按席位／按年抽成 | 决定维系账会不会随人涨 | 问清楚计费口径，以及明年人数翻倍后的账 |
这四条里，前两条是生死，后两条是长期支出。顺序不能反——先能保住数据和账号，再谈改起来顺不顺手。
上图是桌面端打开的样子。前台是给观众的，后台是给馆里的。 验收看的是这张图，能不能活看的是上一张图。
六、什么情况下不该做线上展厅
实话实说，有些情况做视频和图文更划算：
- 只为一次活动、一次开幕。 活动结束就没人打开，做完就是沉没成本
- 一年打开次数是个位数。 维系成本摊不平，不如把这笔钱花在展陈本身
- 馆里确实没人能接账号（编制紧、人员流动大）。先解决人，再做系统，否则必然回到"每年找一次人"
- 涉及未公开藏品、版权未清、审批流程没定。 这是制度问题，任何技术方案都绕不过去
七、这块的边界
- 我们没有博物馆客户案例可以举。 文中关于"怎么死"的判断，来自我们自己部署和维护这套系统的经验，不是某个馆的运行数据，也不是抽样统计
- 各地财务科目口径差异很大，本文只讲钱的性质（一次性／按次／按年），不构成财务或立项建议
- 上面四条技术要求的验法，是通用的问法，不代表任何特定方案一定满足
- 手机端在真实藏品内容上的表现，需要按你的实际模型在目标设备上实测
八、常见问题
问：预算很少，只能先做一件事，做哪件？
先做"能改"的那条链路，而不是"好看"的那个画面。一个能改的中等画面，第二年还是活的；一个不能改的精美画面，第二年就是一张过期的效果图。
问：记在宣传活动费就一定活不长吗？
不一定，但要额外做动作：把维系账从宣传项目里单列出来，并在结项材料里写清"由谁在什么周期内做什么"。没有这一步，结项就是终点。
问：能不能让乙方代管服务器？
可以，但合同里要写两条：数据整库导出随时可执行；账号所有权归馆方，代管方只有运维权限。这两条不写，代管就变成了绑定。
问：馆里没有技术人员怎么办？
两条路：一是每年外包一小笔维护（要能说清做什么，不是"维护费"三个字）；二是选一个改内容不需要动代码的系统，让内容岗能自己改文字、换展品、挪位置。
问：怎么判断这套东西值不值？
看它被用在几个具体场合：观众导览、学校课程、借展宣传、上级汇报、临展预告。只有一个场合，通常不值；能同时用在三个以上，它的成本就被摊薄了。
源码与仓库
- 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能以具身角色进入你部署的世界。数据运行在你自己的服务器上，不经过第三方平台——让每个世界都真正属于它的主人。
线上展厅的钱，贵不在做出来那天，而在之后每一年；能不能把它压下来，取决于建的时候把账号、数据和改动权留在了谁手上。 SEO / AI 友好关键词：博物馆线上展厅、虚拟展厅预算、线上展厅立项、虚拟展厅运维成本、博物馆数字化预算、虚拟展馆数据归属、自部署虚拟展厅、3D展厅年度维护
关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，是一套浏览器端自部署的 3D 虚拟世界基底；搜「创世Genesis 3D」不一定找得到，直接搜「创世虚拟世界CRM」即可。