最近面试了几家 WebGL 方向的公司，主要集中在点云平台和编辑器相关领域。
在这个过程中，也系统性地看了一些市面上的编辑器产品形态，以及部分开源编辑器的实现方式，算是一次比较完整的横向对比。
一个比较明显的感受是：现在不少编辑器产品在尝试快速向 AI 能力靠拢，尤其是图生场景、文生场景，希望以此横向扩展业务边界，配合 SaaS 或 ToC 的增长模型。
如果把时间放在 2024 年，这样的方向我认为是相对合理的探索路径；
但放到现在这个阶段，我个人反而觉得难度和风险都在上升。在工程层面，AI 更适合作为“能力放大器”，而不是直接替代编辑器底层设计的起点。
从一个最基础的 3D 编辑器视角来看，本质仍然是：
编辑 → 生成 Scene Graph（场景图）→ 交给引擎渲染。
例如 Babylon.js 早期通过 .babylon 文件来承载场景描述，再由引擎的 loader 加载渲染，这是一种非常典型的“编辑器 + 引擎”一体化思路；而 Three.js 则更明确地只聚焦在渲染后端，其余能力更多作为生态衍生。
但在我看来，.babylon 这类方案也存在一些结构性问题：
一是文件体量与表达冗余；
二是缺乏一个清晰的中间表示（IR）层，导致编辑器与渲染引擎之间的抽象仍然不够稳定。
对比之下，Three.js 通过 ShaderChunk + ShaderLib 的方式，在运行时拼装材质，架构上非常清晰，但代价是：材质是在运行期生成，而不是在编辑期静态确定。
这种方式并非不可行，但从现代游戏与编辑器工业的经验来看，我更倾向于认为：
编辑期就应该尽可能完成结构与语义的收敛，而不是把关键决策全部推迟到 runtime。
这里就不得不提到 Bevy。
虽然 Bevy 目前并没有一个成熟的可视化编辑器，但你会看到社区里常常讨论：为什么可以用 Godot、Blender 甚至自研工具作为 Bevy 的“编辑端”。
这背后其实和 Bevy 的核心设计有关：ECS 本身就承担了中间表示（IR）的角色。
Bevy 取消了传统意义上的 Scene Graph，把世界拆解为一组可组合、可分析的数据组件。它更像是在描述一个 DAG 结构：
每个 Component 只是语义节点，最终通过系统调度和依赖关系进行拓扑执行，生成真正的渲染与逻辑结果。
也正因为如此，编辑器不再是“必须内建”的前提条件，只要能够稳定地产出 ECS 数据，本质上就已经完成了编辑期的工作。
这时再回到 AI，其实关系非常直接：
关键不在于“用不用 AI”，而在于 AI 输出的是什么。
目前市面上的 AI 3D 编辑器，大致有两种路径：
一种是直接调用模型生成接口，生成模型后丢进场景；
另一种是通过识别或匹配，将已有模型库中的资产放入场景。
但这两种方式，本质上都默认了一个前提：
模型是独立资产，场景只是一个容器。
就像我们通过 loader 加载 glb 一样，模型只是一个 slot，被挂载到场景中；
而真正复杂的结构语义、依赖关系、约束条件，并没有在编辑期被充分表达。如果这种‘直接操作 runtime 结果’是长期可扩展的路径，那么在更成熟的编辑器体系中，理论上应该已经被大规模采用；但现实情况似乎并非如此。
这也是我目前对很多“AI 编辑器”持保留态度的原因：
如果 AI 只是绕过 IR，直接操作 runtime 结果，那么它更像是在加速试错，而不是在提升系统上限。
真正有价值的方向，应该是让 AI 参与到“结构生成”这一层，而不是只生成最终表现。
第二点为什么我说上面的AI形式在2024年左右是可以的尤其是TOC市场，本质上是因为，现在比如grok，gemini，都可以生成web3D的场景甚至可以结合自家的视觉结合库，我为什么要用你的编辑器产品呢。大家使用编辑器本身就是不喜欢黑盒的感觉，但是我想要低成本使用编辑器，所以我觉得AI编辑器的未来是有一套自己独立的描述结构，通过双Agent的方式，一个用作生成一个用作校验，最后去比gemini ,grok导入的web3D的项目可以通过双Agent在编辑器解析成我们自己的独特描述结构。 最近在一些个人实验中（例如用 Rust 编写 CLI 来描述 Web3D 场景），也更明显地感受到 Three.js 与 Babylon.js 在序列化层面的差异，这反而进一步暴露了“缺乏统一描述结构”的问题。
这里并不是否定 AI 在编辑器中的价值，相反，我认为 AI 在结构生成、校验与约束层面，反而有更大的发挥空间。
后续可以会写一些OT,CRDT结合DAG的在编辑器或者平台的应用导向，比如材质节点生成器。
封面图片 ANTIPOLYGON YOUTUBE 来自于 Unsplash
