Demo 诅咒
定义
Demo 诅咒是文中对 AI 生成 Three.js 场景时一种高频失败状态的命名：程序能跑、功能基本齐全、交互也未必缺失，但视觉完成度始终停留在“基础教程”“练手案例”或“廉价 demo”的水准。
它描述的不是单个 API 用错，也不是某段代码报错，而是一整套默认视觉解法的集体滑坡：AI 会把场景做成“看起来像 3D”，却很难自然达到有风格、有层次、有情绪、有电影感的成品状态。
在本文语境中，这个词专门用来解释：为什么很多 AI 写出的浏览器 3D 项目并非不能运行，而是总带着一股明显的“样板味”“塑料感”和“新手教程感”。
在本文档中的语境
本文讨论的是给 Codex 之类 AI 编码代理安装图形与审美技能包之后，为什么 AI 生成的 3D 游戏或场景会明显摆脱廉价 demo 观感。Demo 诅咒正是这种改进前的基线状态。
作者强调，问题并不在于大模型完全不会写 Three.js。像 new THREE.BoxGeometry()、new THREE.MeshPhongMaterial()、scene.add(mesh) 这类调用，任何主流模型都能正确输出。真正缺的是视觉判断：
- 灯光怎么布才能形成层次，而不是把所有东西平均照亮；
- PBR 材质的金属度、粗糙度、清漆等参数如何调到像“真实物体”而不是塑料；
- 相机该采用什么镜头感、FOV、缓动方式与运动节奏；
- 后处理链路要不要加 Bloom、SSAO、色散、胶片颗粒等；
- 动画该如何带出情绪，而不是只有机械位移。
因此，Demo 诅咒关注的是 3D 图形质量与观感，不只是“能不能做出一个可运行原型”。这一点可以类比 游戏美术可用性 与 原型反馈速度：它们都关心 AI 产出是否真正进入可用状态，但这里衡量的核心不是原型可不可以验证玩法，而是 3D 视觉是否具备足够完成度。
典型症状
文中列出了这种状态最典型的一组症状，几乎构成 AI 默认 Three.js 生成结果的“模板指纹”：
- 旋转立方体；
- 基础 Phong 光照；
- 三个白色点光源把物体均匀打亮；
- 缺少阴影层次；
- 所有物体金属度为 0；
- 粗糙度固定在 0.5；
- 相机匀速绕圈；
- 动画没有任何情绪。
这种组合的结果是：物体轮廓虽然清楚，但没有材质说服力；场景虽然亮，但没有主次关系；镜头虽然在动，但没有叙事感；整套东西虽然“完整”，却很像 2015 年左右的 Unity 或 WebGL 新手教程。
文中甚至用“塑料玩具”来形容这种质感，强调它的问题不是功能不全，而是视觉语言过于保守、过于平均、过于无害。
根源：不是不会 API，而是默认路径偏向高频安全解
Demo 诅咒的根源，被明确归因为模型的默认路径选择，而不是 AI 完全不会 Three.js。
作者的判断是：泛化大模型在生成代码时，会优先落到统计意义上的“最安全解”。在 Three.js 里，这往往表现为类似下面的组合：
BoxGeometry；MeshPhongMaterial；AmbientLight或若干简单白光；OrbitControls；- 少量最通用、最不容易报错的场景组织方式。
这是语言模型工作方式的自然结果：概率最高的 token 序列，往往也是最常见、最保守、最缺乏审美冒险的方案。换句话说，模型不是不会调用 API，而是会优先调用那些在公共语料中最常见、最像教程、最容易成功运行的 API 组合。
所以，Demo 诅咒不是“技术不会”，而是“默认会得太普通”。
为什么不是 Three.js 平台本身不行
文中特别澄清：Demo 诅咒不能被误判为 Three.js 平台能力不足。
相反，作者明确指出 Three.js 的上限很高。作为浏览器里最主流的 JavaScript 3D 库之一，它基于 WebGL/WebGPU，可以在无需插件的前提下运行复杂 3D 场景。文中还给出多类反例，证明浏览器 3D 远不止“教学 demo”水平：
- Three.js 官网 showcase 中已有大量生产级作品，包括品牌互动、游戏、数据可视化和艺术实验；
- slowroads.io 展示了程序化世界、体积雾和动态光照结合后的高质量浏览器 3D 体验；
- Bruno Simon 的代表性互动 3D 作品则体现了物理材质、电影级运镜和高度统一的艺术方向；
- 另外还提到 Lusion、Codrops 等案例，说明高完成度 Three.js 实践长期存在。
因此，问题不在浏览器做不到，也不在 Three.js 做不到，而在 AI 没有自然走到这些高质量实现真正依赖的参数与套路上。
与训练数据结构的关系
文中对成因的进一步解释，落在训练数据结构的不对称上。
公开代码仓库中的绝大多数内容，主要在解决“功能问题”而不是“观感问题”。作者用非常明确的说法指出：训练数据里的代码仓库，99% 都在处理功能实现，视觉打磨几乎不系统出现。
这意味着：
- 如何创建几何体、加入场景、设置相机、响应交互，这类内容在公开语料里很多；
- 但真正决定视觉完成度的灯光细调、材质参数、后处理链路、运镜缓动、色彩统一、情绪动画等内容，往往零散地存在于少量优秀项目源码里；
- 它们通常不属于标准教程，不会被文档完整讲解，也不常以“最佳实践”形式系统整理出来；
- 在问答网站或通用示例中，通常只能找到“怎么让它工作”，很难找到“怎么让它好看”。
于是模型学到的就是一种偏斜分布：功能实现的高频模板极多，视觉完成度相关知识稀少、隐性、分散。最终结果，就是一旦没有额外参照，模型就会不断回到最普通、最保险的默认组合，这正是 Demo 诅咒 的形成机制。
高质量 Three.js 结果真正依赖什么
按照原文，能显著摆脱 Demo 诅咒 的，不是抽象地要求 AI “更有审美”，而是让它参考真实优秀项目中已经被验证过的具体实现细节。
文中点名了多类关键要素：
- HDRI 环境光；
- PBR 材质节点与更真实的材质参数；
- 后处理链路；
- 相机缓动曲线；
- 体积雾等氛围效果；
- 经实践验证的灯光布局；
- 能兼顾效果与性能的场景配置策略。