停了半年没做出来的 3D 场景工具，我用 AI 把它落成了产品

公司经常会遇到 3D 场景需求，也就是大家常说的数字孪生。每次做类似项目，都绕不开模型摆放、场景配置、设备数据接入和可视化展示。

我们最早在网上找过不少开源代码，也采购和试用过付费产品。付费方案功能很丰富，但大部分能力与我们的实际项目无关，真正需要的部分又很难直接嵌进现有业务。继续围绕这些产品做二次开发，团队要先理解复杂的产品体系，再寻找适合自己的使用方式。

后来我们让前端同事学习 3D，并尝试自己做编辑器。这个方向持续了半年，依然没有形成可以投入使用的东西。问题逐渐清楚：任务看起来是“做一个 3D 页面”，实际同时包含编辑交互、场景状态、模型资源、数据绑定、运行展示和后端管理。让一个前端在缺少清晰边界的情况下边学边做，很容易一直停留在试验阶段。

我决定停掉原来的推进方式，自己接手需求，用 AI 做一个简单、能跑通业务的版本。这个项目后来有了一个很直接的名字：3D编辑器全栈。

先把“数字孪生平台”缩小成可交付闭环

接手后，我先处理范围，而没有立即讨论渲染效果。

“数字孪生”这个词很大，可以一直扩展到实时数据、告警联动、动画、多人协作、模板市场和复杂仿真。如果把这些都放进第一阶段，AI 生成再多代码也只会让项目更快失控。

我把最初目标收敛成一条可验证的链路：用户能够进入编辑环境，把模型和场景元素组织起来，调整位置、旋转、缩放等属性，保存项目，并为后续的数据接入和运行展示保留结构。

这个定义解决了两个关键问题。第一，团队可以用实际操作判断产品是否成立，而不用争论抽象的“平台能力”；第二，AI 每次接到的任务都有明确上下文，例如场景对象应怎样表达、属性面板修改什么状态、保存时哪些信息必须被序列化。

我也保留了扩展方向，但把它们放在边界清楚的模块里。数据源、特效、HUD、预设和协作可以继续演进，不需要在第一个闭环里一次性完成全部想象。

把一个大需求拆成 AI 能稳定执行的工程任务

AI 编程最容易出现的问题，是单个页面看起来完成了，模块组合后却无法工作。我的重点放在系统拆分和接口一致性上。

整个产品被分成几层：编辑器负责场景操作和即时反馈；状态层维护当前项目、对象属性与编辑历史；服务层处理数据绑定、特效和布局等领域能力；API 层连接项目、模型、文件和数据源；后端负责认证、持久化及资源管理。

有了这张结构图，我再让 AI 按模块推进。每个任务都要说明输入、输出、依赖关系以及验收动作。比如实现属性编辑时，要求同时考虑数值输入、场景对象更新和状态保存，避免只完成一个视觉控件。处理项目保存时，则先统一前端数据结构和 API 边界，再补后端能力。

我会持续检查 AI 产物是否破坏已有约定。相似概念如果各自创建一套类型，后面就会出现界面能修改、场景能响应、保存结果却不一致的情况。此时需要先合并模型和职责，再继续增加功能。领导 AI 完成复杂工程，核心动作正是维护这些长期约束，让每一次生成都能进入同一个产品体系。

交互细节决定编辑器能不能真的使用

3D 编辑器很容易做出一个“能展示”的界面，真正使用时，差别往往藏在高频操作里。

位置、旋转和缩放需要频繁微调。我让 AI 为这类参数设计了可拖动数值输入：可以左右拖动快速改变，也可以点击后精确输入；X、Y、Z 使用不同颜色，旋转值保留角度单位。变化范围较大的灯光强度、距离等参数继续使用滑块，让用户快速观察画面变化。

这里没有追求控件形式统一。我根据操作目标选择交互：精确调整适合数值输入，大范围试探适合滑块，离散配置适合选择项。这样的判断看起来很小，却直接影响编辑器会成为长期工具，还是只适合演示一次。

场景能力也采用同样思路。数据绑定、告警、特效、HUD 和布局被组织成相对独立的服务，既能连接当前编辑状态，又能保留各自的演进空间。这样增加一种展示效果或数据规则时，不必反复改动场景核心。

用全栈边界把 Demo 推到可持续迭代

当编辑链路跑起来后，我继续补齐产品需要的后端边界。前端采用 React、Three.js 相关生态和 TypeScript 来承载编辑体验；后端使用 Nest.js，对项目、模型、文件、数据源和预设等资源提供统一 API，并配置 PostgreSQL、Redis 和 MinIO 来处理结构化数据、缓存与文件资源。

选择这些组件的原因很朴素：项目需要保存，模型文件需要独立管理，接口需要认证，前后端需要长期保持清楚的契约。它们共同说明这个成果已经从一次性页面进入全栈产品结构。

工程中还保留了类型检查、构建、代码检查、单元测试和端到端测试入口。我的验证方式以业务路径为中心：属性调整后场景是否同步，保存和再次读取能否保持结构，模型资源与项目数据是否分开管理，新增模块是否继续遵守统一 API 边界。工具命令负责暴露工程错误，最终判断仍然来自完整操作链路。

这种验证也帮助我约束 AI。生成代码只是中间结果，只有能被现有模块接住、能构建、能沿业务路径继续运行，才算完成任务。

这次落地改变的是项目推进方式

回头看，原方案停滞半年的根源不只是 3D 技术门槛。需求过大、范围模糊、学习路径和交付路径混在一起，导致投入一直无法收敛成产品。

我接手后做的几件事很明确：从公司真实使用场景里提取最小闭环；把编辑器拆成可独立验证的层次；给 AI 持续提供结构、约束和验收标准；在交互与架构冲突时做取舍；最后补齐前后端边界和验证入口。

AI 显著压缩了实现周期，也放大了工程组织的重要性。它可以快速生成组件、服务和接口，但产品应该做到什么程度、哪些能力先进入闭环、模块之间如何长期兼容，仍然需要有人持续判断。

3D编辑器全栈最初只是我在项目停滞后提出的一个简单想法：既然现成产品太重，内部探索又迟迟没有结果，那就先做一个真正适合我们使用的版本。最终形成的成果已经具备继续接入场景、数据和展示需求的全栈基础，也让后续迭代有了稳定起点。

这正是我理解的 AI 时代工程落地：把模糊业务变成清晰系统，再组织 AI 一步步完成可验证、可交付、可持续演进的产品。