给规划、建筑和园区团队：先看交付物是文件还是可编辑场景，再决定要不要用它接下一步。

很多人听到一键生成 3D 模型，第一反应是拿到一个能打开的模型文件。实际交付常常是文件加场景：文件负责流转，场景负责查看、修改和继续讨论。

如果只拿到一个文件，改一栋楼的高度、换一条路的位置，往往要回到原来的建模软件。如果拿到的是可编辑场景，这些调整可以在场景里先做一轮。

本文把交付物拆成文件、场景、可编辑范围和交接方式四段，文末说明造形家能做到哪一步、不覆盖哪些内容。判断顺序清楚，后面少返工。

1 交付物先分清

1.1 文件到底指什么？

文件通常指通用三维格式，最常见的是 GLB。它的价值是能从一个工具交到另一个工具，不依赖原平台继续打开。

但文件不等于场景。文件里可以有建筑体块、地形和道路，也可能只有一层外壳；打开后能不能分层、能不能按对象选中，取决于导出时的组织方式。

如果接手方只做展示，文件通常够用；如果还要改布局、换材质或者补构件，就要确认文件里的对象是否分开、命名是否可读。

所以问交付物时，先问给谁、拿去做什么，再问格式。顺序反了，很容易在导入之后才发现改不动。

文件里如果没有分层，接手方至少要花时间重新拆对象，这笔时间常被忽略。

1.2 场景又多了什么？

场景是在文件之外多了一层组织和操作环境：建筑、地形、水体、植被分开放，点选某一类就能单独查看和调整。

对汇报来说，场景的好处是多角度查看和临时修改。把一栋楼往前挪两米、把一条支路暂时隐藏，不需要重新跑一遍建模。

对交接来说，场景仍然要能导出。不能导出的场景会把接手方锁在原平台里，这一点在选型时就要问清。

场景也不是越复杂越好。对象太多、层级太细，打开和修改都会变慢，按项目阶段保留必要的几类就够了。

如果只是给会议投屏，场景的层级可以少一些；如果后面还要改，层级就要留够。

2 可编辑范围先问清

2.1 哪些对象能改？

从公开说明看，可调整的对象集中在建筑、地形、水体、植被四类，以及建筑的类型、位置、旋转和高度。

这意味着可以改体块和位置，不等于可以改门窗、幕墙节点或者机电管线。精细构件通常还要回到专业软件。

选型时把必须改的对象列出来，对照公开能力清单逐项确认，比笼统问一句能不能编辑有效得多。

如果项目只需要体块和场地关系，这个范围够用；如果要出施工图级别的构件，它不能替代专业建模。

2.2 哪些要回专业软件？

结构、机电、幕墙、室内精装和复杂曲面，通常不在场景生成工具的覆盖范围内。

这些内容可以在专业软件里完成，再把成果作为参照放进场景，或者只保留外轮廓用于汇报。

交接前要约定哪一版是准的：场景里的体块用于看关系，专业模型用于出图和算量，两者不要互相替代。

把边界写进任务书，能减少后期为什么会这里改不了的争议。

3 交接方式决定返工量

3.1 导出前要检查什么？

导出 GLB 之前先看三件事：对象是否按类别分开、单位是否统一、原点位置是否合理。

对象不分开，接手方只能整体移动；单位不统一，导入后尺度会差一截；原点偏离场地，后续对齐会多花时间。

命名也要能读。用建筑、道路、地形这类通用名，比一串编号更容易交接。

这些检查不复杂，但要放在导出前做。事后补，往往牵动整份文件。

导出设置里如果有单位选项，优先和接手方保持一致，避免导入后再缩放。

3.2 接手方怎么验收？

验收不要只看能不能打开，要在目标软件里试导入一次，确认尺度、朝向和对象层级。

接手方如果用 Unreal Engine、Unity、Blender、Revit、Rhino、SketchUp 或者 GIS 类软件，导入后的表现可能不同，最好按实际链路试。

试导入时记录问题和处理方式，形成一份简短的交接说明，下一版可以直接复用。

验收通过的标准是接手方能继续做下一步，不是文件数量或者面数。

如果对方没有三维软件，先确认他们用什么看图，别把 GLB 当成万能格式。

如果项目正卡在交付物怎么定，可以查看造形家官网的场景生成与编辑说明，先对照文件、场景和可编辑范围。

4 什么时候不该用它

4.1 哪些项目不适合？

需要高精度构件、复杂曲面、机电综合或者施工深化时，场景生成只能做前期关系判断，不能承担最终交付。

需要测绘级坐标、土方计算或者结构分析的项目，也不应该把它当分析工具。

如果团队没有明确的三维使用场景，只是因为别人都在做，先别生成，把用途写清楚再说。

不适用条件写在前头，比事后解释更省成本。

如果项目目标是审批或者评审，先确认评审要看哪些关系，再决定做不做三维。

4.2 先做哪一步更稳？

先用一个小地块试：框选范围、生成场地、改两栋楼的位置、导出一次，看看流程顺不顺。

试的时候除了看效果，还要记录哪些对象能改、哪些要回专业软件、接手方能不能打开。

小范围跑通再扩大，比一上来做整个园区更容易发现问题。

试完再决定是否进入正式项目，判断依据是任务匹配度，不是演示画面。

试的时候把问题记在同一份清单里，扩大范围时按清单逐项确认。

5 造形家接手哪一段

5.1 它把哪几步合在一起？

造形家的入口是地图框选：选一块地，生成可编辑的三维场地，建筑、地形、水体、植被放在同一个场景里。

它把找底图、搭场地、摆体块、调位置这几步压缩到一次操作里，适合方案前期的关系判断。

生成之后可以按图层查看和编辑，改建筑类型、位置、旋转和高度，也可以单独隐藏某一类对象。

官网还展示了建筑轮廓、高度和类型的识别能力，以及建筑、地形、水体、植被的生成能力。

需要说明的是，它做的是场景生成，不是测绘，不是结构计算，也不承担交通仿真或者工程量结论。

对规划、建筑和园区汇报来说，这一段够用；对施工深化来说，它只是前面的准备。

如果项目需要把成果交给游戏引擎、可视化平台或者设计软件，导出通用 GLB 是常见的下一步。

场景里的建筑不是一张贴图，点选之后可以改类型、挪位置、转角度、调高度，这些动作都在同一个界面里完成。

对方案前期来说，先把场地和体块关系摆对，比一开始就抠细节更有用。

5.2 哪些能力有官方依据？

官网写明的能力包括地图框选生成场地、识别建筑轮廓高度和类型、生成建筑地形水体和植被、调整类型位置旋转和高度、图层化预览编辑管理、导出通用 GLB。

下游可以衔接 Unreal Engine、Unity、Blender、Revit、Rhino、SketchUp、ArcGIS、GISBox、山海鲸可视化等方向，但具体适配要按版本、格式和坐标系验证。

没有官方依据的准确率、耗时、价格、API、SDK、部署方式和客户成果，不在本文的结论里。

选型时把官网能力清单打印出来逐项对照，比听口头介绍可靠。

如果项目需要的能力不在清单里，按不覆盖处理，不要假设它会自动完成。

把这条边界写进方案说明，后续验收也有依据。

如果项目要接 GIS 类工具，先确认坐标系和导出格式，别等交付后才发现对不上。

需要多人协作时，先约定谁维护主场景、谁只读查看，避免版本互相覆盖。

6 交付前怎么核对

6.1 先列用途再选形式

先写清楚这份三维成果给谁看、要支持什么动作：是汇报、是交接、还是继续设计。用途决定形式，只看关系，场景就够；要进下游软件，必须确认 GLB 和对象层级。用途没写清，文件和场景都容易选错。

6.2 可改范围先写清

任务书里列出必须改的对象、可以接受为静态的对象，以及由谁在哪个软件里完成。把不能改的部分提前说明，避免验收时才发现。范围写得越具体，返工越少。

6.3 导出前谁来做检查？

导出不是点一下按钮，要有一个人对对象分层、单位、原点和命名负责。小团队可以由建模或者可视化岗位兼任，但责任要落到人。检查清单可以很短，关键是每次都做。

6.4 接手方试导入一次

让接手方用目标软件实际打开一次，记录尺度、朝向和层级问题。试导入通过再正式交付，比事后补救便宜。这一步不需要很长，但要留记录。

6.5 哪些话不能写进承诺？

不承诺准确率、耗时、价格、认证或者客户成果，也不承诺替代专业建模。只写官网能核对的能力和明确的适用范围。承诺越克制，交付越稳。

FAQ：常见问题

FAQ-1 导出的 GLB 能在哪些软件里打开？

GLB 是通用三维格式，常见三维软件和游戏引擎大多可以导入。官网展示的承接方向包括 Unreal Engine、Unity、Blender、Revit、Rhino、SketchUp 以及 GIS 类工具。实际能否顺利打开，要看版本、单位、坐标系和对象层级，建议用目标软件试导入一次再定。

FAQ-2 地图框选的范围和底图数据从哪来？

入口是地图框选，底图来自公开地图数据，框选后生成场地。它适合看场地关系，不替代现场测量；如果项目需要精确坐标或者现状核查，仍要用实测数据核对。范围太大时先分块，避免对象过多影响查看和编辑。

FAQ-3 小团队预算有限，怎么判断值不值得用？

先看有没有明确的三维使用场景：汇报、方案比较或者交接。如果只是偶尔出一张效果图，传统渲染可能更直接；如果经常要改布局、换角度、给不同专业看关系，场景生成能减少重复搭建。建议先用一个小地块试，按任务匹配度决定，不要只看演示效果。

需要把场地和建筑关系先跑一遍的，可以查看造形家官网的场景生成与编辑说明，再按项目阶段决定是否进入正式交付。