AI 生成的 3D 博物馆网页为什么卡？性能排查与提示词拆解
一个大模型用半天时间生成了可交互的苏州博物馆 3D 网页，评论区却分成「惊艳」和「卡到爆」两派。本文梳理卡顿的真实原因（GPU 填充率、树木面数、水面反射、像素比），给出访问者与开发者两端的排查优化清单，并拆解这类 3D 项目该怎么给提示词、效果边界在哪、与高斯泼溅等路线如何取舍。
一个提示词加半天时间，能换来什么？最近的一场讨论里，有人用新一代大模型（帖中称 GPT-6 Astra，中等推理档位）做出了一个可交互的苏州博物馆 3D 网页：建筑模型、贴图、前后端、参考资料检索全部由模型自己完成，原本拖了一个月的教程录制也因此补齐。
结果一发出来，反馈立刻分成两派。一派惊叹「垂直行业要洗牌」，另一派的第一反应是「卡到爆」。讨论很快从「AI 能不能做」转向更实际的问题：同一个页面，为什么有人丝滑有人卡死？卡顿到底出在哪一层？要让模型做出这种东西，提示词该怎么给？
现象：同一页面，体验天差地别
把讨论里出现的反馈粗略归类，会发现它并不随机：
| 反馈类型 | 典型描述 | 大致原因 |
|---|---|---|
| 移动端芯片卡顿 | M1 Pro 显卡占用吃满，M1 Max 反而丝滑 | 同代芯片 GPU 核心数、内存带宽差距成倍 |
| 桌面独显流畅 | 中高端独显开高品质无压力 | 填充率与显存带宽充足 |
| 高分屏更吃力 | 4K 显示器明显更卡 | 像素数量翻倍，填充成本同步翻倍 |
| 浏览器差异 | 同一台机器换个浏览器就不卡了 | 硬件加速开关、渲染后端不同 |
| 手机端小卡 | 能开但略顿 | 移动 GPU 与降频 |
一个关键点是：这类页面的瓶颈几乎从来不在 CPU。有人观察到 CPU 占用不到 10%，GPU 却已经吃满——这是典型的渲染管线瓶颈，而不是「算力不够」。所以拿 CPU 型号去猜体验好坏，往往会得出互相矛盾的结论。
卡顿的三个真实来源
1. 面数分布极不均匀
讨论里有人指出，场景中几棵树用的三角面数量是整栋建筑的十几倍。这在 AI 生成的场景里非常常见：建筑部分会被反复打磨，而树木、石头这类「配角」要么被高模直接复制多份，要么由模型凭感觉堆细节，最后成了隐藏的性能黑洞。
2. 水面反射等于把场景再渲染一遍
原作者自己也提到：本地把湖面反射去掉之后非常丝滑。平面反射的实现方式通常是把整个场景从一个镜像相机再渲染一次，开销直接翻倍，而且分辨率越高越贵。在一个本来就很重的场景里，这一项往往就是压垮低端 GPU 的最后一根稻草。
3. 高品质开关把多项成本一起拉高
页面右上角的「高品质渲染」通常不止改一个参数：像素比、阴影、后处理、反射精度可能同时上调。所以在弱机器上，它带来的不是「稍微好一点」，而是数量级的负载变化。
另外，远景闪烁、细长几何抖动这类问题，多半和相机近远裁剪面设置、深度精度有关，属于观感问题，但也会让人误以为「性能差」。
访问者端：先做这七件事
如果你只是想看看这个页面，不打算改代码，按下面顺序排查，通常几分钟内就能定位：
- 关掉高品质渲染，用默认画质再试一次。
- 缩小窗口或降低系统缩放（浏览器缩放调到 80%～100%），减少实际像素数。
- 确认浏览器硬件加速已开启，在浏览器里查看 GPU 状态页（Chrome/Edge 为
chrome://gpu），确认 WebGL 显示为硬件加速。 - 关掉其他吃 GPU 的标签页：视频、地图、其他 WebGL 页面都会抢资源。
- 换一个浏览器交叉验证。同一台机器上不同浏览器的差异经常比换一台机器还大。
- 笔记本插电、关掉省电模式，核显机器注意散热，降频后帧率会断崖式下跌。
- 4K 屏先切到 2K 或 1080p 验证。如果立刻流畅，说明瓶颈是填充率而非几何复杂度。
判断「是页面太重还是我的机器弱」，最简单的办法是用同一台机器打开另一个已知较轻的 WebGL 演示做对比。如果别的也卡，问题在你这边；只有这个卡，问题在页面。
开发者端：值得改的几处
如果这个页面要继续迭代，优化的性价比从高到低大致如下：
- 树木改用实例化或合并几何，远景切 LOD 或直接换成 billboard 卡片；更好的做法是从现成植被素材库里取，而不是让模型手搓。
- 水面反射降级：反射用低分辨率渲染目标、限制参与反射的图层，或者干脆用预烘焙的环境贴图近似；只在「高品质」模式开启真实反射。
- 限制像素比上限，别让 4K 屏直接按 2 倍甚至 3 倍像素渲染：
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 1.5));
- 压缩几何与贴图：几何用 Draco 或 meshopt，贴图控制尺寸并考虑 KTX2。
- 减少 draw call 与透明材质，能合并的材质合并，透明排序本身也很贵。
- 加自适应画质：连续几秒帧率低于阈值就自动关阴影、关反射，比死磕优化更容易落地。
- 处理远景闪烁：调整相机 near/far 比例、必要时开启对数深度缓冲，或给薄几何加一点厚度。
有一点值得强调：给用户一个「画质 / 性能」两档开关，比强行把高端效果优化到能跑在弱机器上更现实。原作者选择不再优化、把它当性能测试工具，也是一种取舍。
对这类需要长时间连续生成、调试、跑代理任务的工作，本地机器休眠或网络抖动会打断流程，有些人会改用一台长期在线的远程机器挂任务，例如整机放在机房的远程 Mac，这只是可选方案之一，与页面本身的渲染性能无关。
提示词：把「许愿」拆成一次项目委托
从结果看，作者给的不是一句「帮我做个博物馆」，而是一个带目标、带交付形态的任务，并且让模型自己去检索资料——页面上还标注了参考链接，这点很值得学。可复用的做法：
- 先要资料清单，再要实现。让它列出建筑结构、尺寸关系、参考来源，确认无误后再进入建模。
- 分阶段确认：资料 → 结构拆解 → 单体与材质 → 交互与相机 → 性能优化，每步都能纠偏。
- 写清约束：目标帧率、面数上限、要支持的设备档次、必须提供画质开关。
- 让它自测自改：明确「帧率低于多少就降级」的规则，让模型自己读性能数据再优化，这比人工逐个试快得多。
- 控制范围。范围越小、返工越少，额度消耗越可控。至于具体花了多少，原作者只说多个任务并行跑一天后额度还剩三成左右，实际计费请以你所用套餐的官方说明为准。
效果的真实边界
需要承认的是，这类产物的观感是「远看唬人，近看露怯」：水池边的石头形状怪异、树冠抽象、远处有闪烁，镜头也只能沿预设路径移动，不能像世界模型那样自由漫游。所以它的合适场景是：方案预览、教程演示、内部沟通、Demo 原型；不合适场景是：交付级建筑表现、需要精确尺寸与材质的正式成果。
与其他路线对比：
- AI 直接生成 glTF + Three.js：可控、可交互、易集成到网页，但细节和真实感有限。
- 高斯泼溅 / 世界模型：真实感和漫游体验更好，但资产体积大、编辑困难、交互逻辑要另做。
- 传统 DCC 建模：精度最高，成本与周期也最高。
三者不是替代关系，而是按交付标准选工具。
小结
模型能在半天内产出一个可交互的 3D 场景，这件事本身已经成立；但它产出的是一份「原型级」资产，性能与细节都需要人来收尾。对使用者来说，先分清是设备瓶颈还是页面瓶颈，再决定是调画质还是改代码；对开发者来说，把树木面数、水面反射、像素比这三处按住，体验就能上一个台阶。
