记一次：我为什么不再让 AI 直接生成博客里的赛博朋克家具

先说结论

我暂时不打算把博客首页做成一张高保真的赛博朋克电影海报。

这次我决定换个更笨、但更靠谱的办法：用 Blender 做模块化家具，导出 GLB，再交给 Three.js 负责场景组合和交互。

AI 生成 3D 模型，快是快

前面我试了 Meshy，也试了混元。

给它们看的参考图是正交视图，里面有正面、侧面、背面和俯视图。我原本以为这已经足够清楚了，结果生成出来以后，四个视角被理解成了四个物体。

这事其实也不能完全怪工具。

图生 3D 更擅长回答“这个东西大概长什么样”，不太擅长回答：

• 这四张图是不是同一个物体
• 哪些部分需要拆成独立 Mesh
• 哪个节点是根节点
• 交互时应该移动整个家具，还是只移动坐垫
• 碰撞体应该放在哪里

最后得到的模型看起来像沙发，但离“能放进博客首页里交互的沙发”还有一段距离。

我真正需要的不是一个模型

我需要的是一套可以被程序理解的资产。

比如一个沙发，至少应该有这样的结构：

sofa_root
├── sofa_base
├── backrest
├── cushion_left
├── cushion_right
├── armrest_left
├── armrest_right
├── accent_strip_cyan
├── accent_strip_magenta
└── collider_sofa

点击沙发时，我可以让整个 sofa_root 高亮。

点击左边坐垫时，我可以只让 cushion_left 抬起来。

需要做碰撞检测时，我可以使用 collider_sofa，不用拿一堆高精度三角面去和相机射线硬碰硬。

这才是我想要的“3D 家具”。

为什么选 Blender

Blender 不会替我猜。

这听起来不如 AI 自动生成那么酷，但对这个项目反而是优点。

我可以明确规定：

• 沙发宽 2.4 米
• 根节点位于地面中心
• 坐垫是两个独立对象
• 灯带是独立的 emissive 网格
• 碰撞体是单独的简化盒体
• 不把文章文字烘焙进模型贴图
• 不把灯光和摄像机一起导出

这些东西如果交给图生 3D，常常要靠运气。如果用 Blender，可以靠规则。

低模不等于粗糙

我一开始也担心，低面数会不会让赛博朋克房间看起来像一堆积木。

后来发现，赛博朋克感并不主要来自模型面数。

真正影响观感的是：

• 暗色材质和少量金属反射
• 青色、紫色和暖黄色的局部光源
• 结构清楚的小倒角
• 屏幕上的动态数据
• 发光灯带的位置
• 镜头构图和空间留白
• Bloom 的强度控制

所以我现在更倾向于：

低复杂度几何体，高质量灯光和材质。

这比做一个很重的高模场景更适合博客。

Blender 和 Three.js 怎么分工

Blender 负责资产本身：

• 建模
• 部件拆分
• 材质槽
• UV
• 原点和尺寸
• 碰撞体
• GLB 导出

Three.js 负责运行时：

• 加载 GLB
• 组合房间
• 切换昼夜主题
• 控制灯光
• 加载文章数据
• 给屏幕生成 CanvasTexture
• 射线检测和点击反馈
• 移动端性能降级

这样一来，模型只是模型，博客内容也不会被锁死在模型里。

文章标题和摘要继续用 HTML，终端屏幕只负责做视觉入口。点击以后，还是打开真实的文章页面。

这次先从沙发开始

我先抽取了之前房间设计里的沙发，做了一张实时 3D 风格参考图，也补了一张只包含同一个沙发四个视角的建模参考图。

但我不会再把“生成一张图”当成建模完成。

接下来要验证的是：

• Blender 里是否能稳定拆出独立部件
• GLB 导出后节点名称是否保留
• Three.js 是否能准确射线命中目标部件
• 沙发移动时碰撞体是否同步
• 桌面端和移动端是否都能接受

如果沙发这一件能跑通，后面的床、衣柜、服务器机架和文章终端就可以复用同一套方法。

最后

之前那套方案更像是在追求一张漂亮的概念图。

现在我想做的是一个真正能住进去的博客首页。

它可以不那么写实，但每个东西都应该有自己的位置、名字和用途。说白了，先把房间搭稳，再考虑霓虹灯是不是够亮。

站长