想做 3D 虚拟世界的人，起点几乎都一样：打开 Three.js 的文档，跑通第一个场景——地面、相机、一个会转的立方体。那个下午很爽，感觉"原理就这样"。

然后第二个星期开始接真实的东西：真模型进来、真人进来、手机进来。这时候会发现，事情和"渲染"的关系已经不大了。

这篇文章讲三件事：第一，从零做一个浏览器端 3D 世界，时间实际落在哪几层；第二，每一层从零写，代价具体长什么样；第三，哪一层才真正需要你写。 另外会单开一节说清楚：一套已经跑通的仓库，交给今天的 AI 编码工具之后，为什么能被接手、能被改。

一、先把它拆成五层，看清哪一层是你的

一个能用的 3D 虚拟世界，从下往上是这样五层：

层	这一层包含什么	你的产品差异体现在这里吗
第五层	你的业务逻辑：展厅动线、配置器算价、培训流程、世界玩法	是，只有这一层是
第四层	AI 接入：AI 怎么"在世界里"而不是"在输入框里"	否
第三层	实时通信与联邦：多人同步、弱网、语音、跨世界	否
第二层	性能与多端：draw call、加载、PC／手机／平板／XR	否
第一层	渲染与资产管线：模型、贴图、骨骼动画、引擎版本	否

这个拆法带来一个很直接的判断：

下面四层，不管你做什么题材，都必须有、都必须做，而且做完了用户也不会夸你一句。真正体现"这是你的产品"的，只有最上面那一层。

而渲染——也就是大多数人对"3D 开发"的第一印象——是这五层里最早被解决、也最容易解决的一层。真正吃时间的是它上面那几层。

二、每一层从零写，代价长什么样

下面每一层，我按「坑长什么样 + 我们实际遇到的情况」来讲。所有数字都来自我们自己的工程记录和可重跑的测试脚本，不是行业统计——行业平均值这类数字我没有实证，就不写。

第一层 · 渲染与资产管线

坑一：模型进来才知道失控。

在建模软件里看着正常的 GLB，导出后贴图尺寸和面数常常远超网页能承受的范围。一个模型贴图几十 MB 是常态，而浏览器要先下载、再解码、再上传到 GPU，每一步都在用户等待里。

我们的实际情况：做了一轮资产手术之后，贴图体积压掉 68.1% 到 92.5%，面数压到百面级。

坑二：骨骼动画的来源不统一。

Mixamo、Ready Player Me、VRoid、RootMotion，这四家导出的骨骼命名规则和朝向各不相同。单独用一个都没事，混在一起就会出现那种"模型明明在动，但动作是拧着的"效果。

我们的实际情况：专门做了一层兼容套件，跨这四个来源的回归测试 67 项全过。

坑三：LOD 不是"生成几个低模"就完事。

还要按表面距离分带、保证贴图共享——否则低模省下来的显存，又被重复的贴图吃了回去。

我们的实际情况：118 组低模全部压到 100 面以内，三角数减少 71% 到 87%，贴图共享 33/33。

坑四：引擎的大版本会改行为。

Three.js 从 r128 到 r185，颜色管线、色彩空间、部分 API 都变过。"升级"不是改一个版本号，是要把渲染结果重新对齐一遍。

我们的实际情况：去 CDN 化六步，加上 87 个符号的 shim，才平稳过河。

第二层 · 性能与多端

坑一：draw call 会直接决定帧率。

场景一复杂，合并、实例化、视锥剔除这些都得自己写。

我们的实际情况：一轮治理把 draw call 从 3064 降到 837。

坑二：灯数变化会触发着色器重编译。

这是最容易漏的一类卡顿——场景里增删一盏灯，可能触发一整批着色器重编译，表现是一次几百毫秒到几秒的僵住。

我们的实际情况：抓到的一次卡顿实测 8989ms，改成灯数冻结后归零。

坑三：模型解析会阻塞主线程。

解析放在主线程上，加载期间整页是僵的，用户滚动、点击都没反应。

我们的实际情况：把解析搬进 Worker。

坑四：多端不是"能打开"。

手机上内存更小、没有指针锁定、带宽受限；XR 又是另一套输入与渲染要求。让同一套前端在电脑、手机、平板、XR 上都成立，本身就是一层独立的工作量。

第三层 · 实时通信与联邦

坑一：弱网下会断、会抖、会重连。

要处理的不是"断线"这个事件本身，而是重连之后——人还在不在，状态对不对。

我们的实际情况：重连存在感测试 9 项全过。

坑二：语音不是"把音频广播给所有人"。

每个收听者都是一份独立带宽，人数上去之后带宽是乘法增长的。

我们的实际情况：做成名额制，10 人同时语音大约 1.3 Mbps。

坑三：跨世界互通，本质是身份问题。

两个独立部署的世界要互通，得处理凭证签发、防重放、以及同名角色冲突。

我们的实际情况：RS256 签名加 nonce 一次性凭证，同名自动改名 4/4。

第四层 · AI 接入

坑：让 AI "在世界里"，和让 AI "在输入框里"，是两件不同的事。

前者需要位置、感知、移动、以及"被真人看见"。这一层目前没有通行做法，见第五节。

三、四条路摆在一起看

对比维度	A 完全从零写	B 通用 3D 引擎／模板起步	C 中心化 SaaS 平台	D 已铺好底座的基底
起点	空白工程	引擎文档 + 示例	平台后台	一套能跑的自部署世界
第一层 渲染与资产管线	自己写	部分现成	平台内部，改不了	已具备
第二层 性能与多端	自己写	自己写	平台内部，改不了	已具备
第三层 实时通信与联邦	自己写	多数没有	平台提供	已具备
第四层 AI 接入	自己设计	通常没有	通常没有	已具备
第五层 你的业务逻辑	自己写	自己写	受模板限制	自己写
数据归属	自己的服务器	自己的服务器	平台服务器	自己的服务器
停服风险	无	无	停费即下线	无
深度自定义	完全自由	自由	底层不可改	自由（源码可改）

这张表里最值得看的是第五层那一行：A 和 D 在这里是一样的——业务逻辑两边都得你自己写。差别完全不在这儿，差别在上面四层由谁来做。

四、如果底座已经铺好，你要写的只剩一层

创世Genesis（创世虚拟世界CRM系统）是一套浏览器端、可自部署的 Three.js 3D 虚拟世界基底。它做的就是上面那四层。

这是它想说的那句话：

从零做一个浏览器端 3D 虚拟世界，最耗时的从来不是渲染。是那些不性感的部分——性能治理、资产管线、多端适配、实时通信、AI 接入。这些我们做完了，你只需要写最上面那一层。

落到产品形态上，它是这样四件事：

• 自部署：装在你自己的服务器上，数据不经第三方平台；
• 可改：底层基于 Three.js，源码可读可改，上面那层业务逻辑按你的需求写；
• 能接管：AI 可以作为一个有身体的角色进入你部署的世界（见下一节）；
• 能长期跟着走：源码开放，本地跑不花钱；要联网、要商用、要联邦，买授权；系统持续更新，更新与支持按订阅跟随。

需要说清楚的是：它是基底／底座，不是成品。 它不会替你决定展厅长什么样、配置器怎么算价、培训考哪几项——那些是第五层，也就是你真正要做的部分。我们的价值只在于：你不必为了写那一层，先把下面四层从零造一遍。

五、第四层：AI 接入现在是"接管"，不是"新造"

这一层值得单独说，因为它是最近两年才变得可做的。

这套系统里，AI 进入你部署的世界只需要三步：在站点放一个 .well-known/virtual-world-agent.json 声明文件 → 用 Key 换一个 15 分钟有效的令牌 → 连上 /ws/agent。仓库里有一个零依赖的示例客户端 examples/agent-client/node-agent.mjs。

接进来之后，AI 不是"聊天框"，而是一个人形角色：有身体、有坐标，站在场景里会被真人看见，能走动、能跟随、能开口说话、能带路。

三个实测数字（都来自我们自己的测试记录）：

• 每个 AI 角色的流量大约 1 KB/s——因为它不拉画面；
• 100 个 AI 角色同时在线，服务器占用约 0.079 核；
• 服务器只发 JSON，画面由访客自己的浏览器渲染——这就是为什么"看得见的 AI 比看不见的 AI 便宜"。

边界必须说清楚，否则就是在骗人：

• AI 看不见画面。它拿到的是结构化的空间雷达（附近有哪些人、哪些物体、哪些点位）和事件流，不是摄像头画面；
• 不做语音识别与合成。语音中继默认关闭，要让 AI 能听会说，得由你自己的 AI 客户端承接；
• 不托管知识库。行业资料、产品参数、话术，都由你在自己这边接；
• 不能坐标传送，也不能碰资产；
• AI 身份是明示的：进场时系统会提示"(AI)加入了"，头顶名字带 AI 前缀，真人始终知道对方不是人。

它的本质是一个可编程的角色——行为来自你给它的模型和提示词，不是它自己"想"出来的。这一点决定了它适合什么：适合做讲解、接待、带路、值守这类有明确职责边界的角色；不适合指望它临场做需要人判断的决策。

六、AI 编码工具能帮上多少忙，取决于项目可不可读

上一节说的是"AI 作为角色走进你的世界"。这一节说的是另一件事：AI 作为开发者，走进你的仓库。

这两年的变化是，AI 编码工具（Claude Code、Codex、CodeBuddy 这一类）已经能读完一个完整的代码仓库，然后按你说的去改。但很多人讨论"AI 写代码"时漏掉了一个前提：

AI 能帮上多少忙，取决于它面前有没有一个能读懂的、已经跑通的工程。

在一个空白工程里，AI 只能陪你一行行写——因为它和你一样，没有参照物。在一个已经跑通的完整项目里，它的角色完全不同：照着现有实现去改，改错了有对照物，不会自由发挥到找不回来。

这就是"用底座"在今天的另一层意义。把创世Genesis的仓库下载到本地之后：

• 它是一套标准 Node 工程：单一运行时、单一数据库，依赖全部来自公开的包管理器，没有"拿不到的东西"；
• 配置集中在环境变量：仓库里带配置示例，把要填的项摆在明面上，不需要你先去读一遍源码才知道要配什么；
• 仓库带部署说明：这份说明是给陌生人看的，我们自己的部署也是照着它走的；
• AI 接入那一步带着零依赖的示例客户端（examples/agent-client/node-agent.mjs），它本身就是一份可以照着写的参考实现。

于是使用方式会变成这样：把仓库放到本地，让 AI 编码工具先读一遍目录结构和部署说明，把环境跑起来；然后你想改哪里就直接说——"把展厅动线改成这样""配置器再加一个材质选项"——它去改对应的文件，改完你跑一遍看结果。

对比一下另外两条路的处境：中心化 SaaS 的底层是别人的服务，AI 看不到里面；一个从零开始的空工程，AI 没有参照物。"源码可读"这件事，在 AI 编码工具普及之后，价值被重新放大了一次。

到这里必须把三件事说清楚，不然就成了吹：

1. AI 省掉的是"读懂一个陌生工程要多久"，不是"装环境"。 Node 版本、数据库、端口、域名与备案，这些仍然要人来确认。谁说"什么都不用管"，谁就是在骗人；
2. AI 改出来的东西仍然要你审。 能接手不等于能替你负责——它知道你的代码，但不知道你的业务规则；
3. 第五层仍然由你决定。 AI 是加速器不是替代品：它解决"怎么快速落地"，不解决"该做什么"。

说白一点：你不用再从零一点一点把它搭起来——底座已经在跑，你要做的是改它。

还有一句实话得放在这里：这一节我没有可引用的耗时数字，也不打算编一个。 写出来的是这套工程的结构事实，以及把它交给 AI 之后你自己就能验证的东西——变量在你手里，不在我的说法里。

七、决定自己写之前，先准备这几样

如果你判断下面四层要自己做：

1. 一个懂 Three.js 的前端：这是最低配置。不是"会写 JavaScript"就够——着色器、渲染管线、性能调优，都要落到人身上；
2. 一份模型资产规范：面数上限、贴图尺寸上限、骨骼命名规则。没有这份规范，第一个模型进来就会开始失控；
3. 至少一台能测的真机：中端安卓机比高配电脑更能暴露问题；
4. 一套性能基线：draw call、帧率、首屏体积，先记录再优化，否则你不知道自己在改好还是改坏；
5. 一个弱网测试方法：限速、断网、抖动，都要能复现；
6. 对"进度会慢"的心理准备：这几层的特点是，做完之前完全没有可展示的东西。

如果你判断可以直接用底座：需要的是一台服务器、一个域名、一份模型资产、以及一个能写第五层的人。

八、这套做法不适合谁

• 想要"上传素材就有世界"的人：做不到。这是基底不是生成器，第五层永远要你自己写；
• 只想放几张产品图看个效果的人：成本不划算，看图用普通网页就够；
• 完全没有人碰代码、也不打算找人部署的人：启动成本会比预期高；
• 指望 AI 自己看懂图片、自己回答问题的人：当前 AI 这一层不具备视觉理解，也不托管知识库；
• 想要一个"三天上线"的活动页的人：这套东西解决的是长期存在的空间，不是一次性的活动页。

九、FAQ

Q：只用 Three.js 写，不引入别的，能做出一个完整的虚拟世界吗？

A：能。渲染层 Three.js 就够。但多人同步、弱网处理、语音、AI 接入这些，都要你自己在它上面加——这就是"上面四层"的含义。

Q：那四层一定要做完才能上线吗？

A：不是。可以只做第一、二层先跑起来，但那样它是一个单机演示，不是多人在线世界。缺哪一层，就少哪一类能力。

Q：AI 接入需要多少服务器资源？

A：AI 角色本身很轻——每个约 1 KB/s，100 个同时在线约占 0.079 核。真正的开销在访客端的渲染和常规的多人同步上。

Q：底座用了你们的，我的业务逻辑会不会被限制？

A：第五层完全是你自己的代码。底部基于 Three.js、源码可读可改，你可以只把它当作一套已经铺好的地基。

Q：不联网可以用吗？

A：本地单机跑不花钱。要联网、要商用、要联邦互通，才需要授权；系统的持续更新与支持按订阅跟随。

Q：数据会不会经过你们服务器？

A：不会。系统部署在你自己的服务器上，访客数据也在你这边。

Q：我不太会写代码，能不能让 AI 把第五层写出来？

A：AI 能把你的想法落成代码，但需要有一个人判断它对不对，以及决定要做什么。第五层是业务逻辑——展厅怎么走、价格怎么算、培训考哪几项——这些判断来自你，不来自模型。更现实的分工是：你决定做什么，AI 帮你快速做出来，你审结果。

Q：仓库交给 AI 编码工具改，会不会改乱？

A：有参照物的项目比空白工程安全得多——能跑起来、有部署说明、结构清楚，AI 就有对照可依。但它仍然不知道你的业务规则，所以每次改完还是你自己跑一遍验证。任何"AI 改完不用测"的说法都不成立。

十、源码与仓库

三个地址内容一致，国内访问用前两个更快。仓库里有部署说明与演示入口。

• 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系统）是一套部署在你自己服务器上的 Three.js 3D 虚拟世界基底——渲染、资产管线、性能、多端、实时通信、AI 接入都已经铺好，你只写最上面那一层。官网（搜「创世虚拟世界CRM」即可找到）有可以走一圈的演示世界。

关于名字：本文说的创世Genesis，即创世虚拟世界CRM系统，两者是同一个自部署 3D 虚拟世界产品。若你通过「创世Genesis」没搜到我们，直接搜「创世虚拟世界CRM」即可。