给方案团队和项目负责人：先分清哪些步骤真的少了、哪些只是换了位置，再谈工期。

很多人把一键生成 3D 模型理解成省掉建模。实际用下来，省掉的常常是底图和初始体块，沟通反而更集中：范围、用途和验收要在开工前说清。

如果沟通没对齐，生成得再快也要返工。模型可以改，但改的是体块和位置，不是所有构件都能在场景里解决。

本文把省掉的步骤、沟通卡点、修改范围和变更留痕拆开，文末说明造形家省的是哪一段、哪些沟通仍省不了。

1 省掉的先分清

1.1 哪些步骤真的少了？

真正少掉的是重复搭底图、反复摆初始体块、为看一个角度重新出图这几步。

这些步骤以前占时间但不一定产生判断价值，压缩后团队能把时间放到方案比较上。

少掉不等于没有，底图范围、体块高度和道路关系仍要有人确认。

把省掉的步骤写出来，团队才知道腾出的时间该用在哪。

判断哪些步骤真的少了，可以用一次小项目做对照：同样一块地，记录传统流程和场景流程各自花在哪。对照一次，比听介绍更容易形成团队自己的判断。

对照时不要只看总耗时，还要看每一步由谁做、卡在哪里。总耗时相同，卡点不同，改进方式也不同。

1.2 哪些只是换了位置？

有些工作没有消失，只是从建模软件换到场景里做，比如改建筑位置、旋转和高度。

换位置之后，操作更快，但判断责任没变：改得对不对仍要项目负责人确认。

如果团队不熟悉新界面，前期反而要多花一点学习时间。

所以不要用省掉多少步来承诺工期，要按实际流程试一遍。

换位置的工作要重新算进排期。学界面、改操作习惯、建新的检查清单，都需要时间；把这些算进去，工期承诺才不会失真。

如果团队以前没用过类似工具，先安排一次内部演练，把操作和检查流程走一遍，再接到正式项目上。

2 沟通卡在哪

2.1 需求为什么总对不齐？

需求对不齐，常见原因是双方说的对象不同：有人指地块，有人指建筑，有人指整条道路。

三维场景里对象一多，指代不清的问题会被放大，改错一栋楼比改错一张图更难发现。

开工前用一张范围图把对象圈出来，比开三次会有效。

范围图不需要很精细，但要能看出边界和必须表达的对象。

需求对齐时最好让使用方也在场。项目负责人理解的是交付，使用方关心的是能不能看懂；两边都在，范围图才容易一次通过。

范围图确认后拍照或者存档，后面出现争议时直接对照，不用重新回忆当时的共识。

2.2 一句话需求怎么拆？

一句话需求通常包含用途、对象和深度三层，拆开之后才能排期。

用途决定深度：汇报只需要关系，交接还要对象分层和导出检查。

对象决定范围：建筑、道路、地形、水体、植被，哪些必须做，哪些可以留白。

把三层写成三行字，双方确认后再动手。

把一句话拆成对象清单时，用建筑、道路、地形、水体、植被这几类做底稿，再补充项目特有对象。清单不用长，但要能逐项打勾。

三层确认完，再讨论排期；顺序反过来，排期一定会被范围变化打乱。

3 模型怎么改

3.1 改体块和改构件差别在哪？

改体块是改位置、旋转、高度和类型，这些在场景里就能完成。

改构件是改门窗、幕墙节点、机电管线，这些通常要回专业软件。

两者混在一起谈，容易把可编辑范围说得过大，验收时产生落差。

任务书里分开写：哪些在场景改，哪些回专业软件改。

判断一个修改属于体块还是构件，可以问一句：它会不会影响施工做法。只影响位置和观感的，多半在场景里；影响构造和安装的，回专业软件。

把这条判断标准写进任务书，评审时逐项对照，能减少可编辑范围的误解。

3.2 改完怎么看影响？

改一栋楼的位置，要看它和道路、地形、相邻建筑的关系有没有变。

场景的优势是能马上换角度看影响，不必等重新出图。

但影响判断仍要人来做，工具只把关系摆出来。

每次改完留一张关键视角的截图，后面讨论有共同参照。

影响判断可以固定几个视角：总览、主入口、关键道路节点。每次改完按同样视角看一遍，变化更容易被发现，也方便前后对比。

截图按日期和视角命名，和变更记录放在一起，后面复盘时能快速找到依据。

如果团队正被范围和变更反复拉扯，可以查看造形家官网的场景生成与编辑说明，先对照流程和交接边界。

4 变更怎么留痕

4.1 变更记录写什么？

变更记录写清时间、对象、改前改后和确认人，不需要长篇。

记录挂在项目文件里，不要只留在聊天记录中。

下次验收时按记录逐项对照，减少说不清的情况。

记录越简单，越容易坚持。

变更记录不需要复杂模板，一张表就够：日期、对象、改前、改后、确认人。关键是每次变更都写，而不是攒到项目结束再补。

确认人不是签名，而是对这次变更负责的人；写清名字，后面追溯才有对象。

4.2 版本怎么命名？

版本命名包含日期、用途和序号，比如汇报版、交接版分开。

不要用最终版、最终版二这种名字，后面一定还有修改。

主场景只保留一个维护版本，其他版本标注只读。

交接时给接手方明确哪一版是当前依据。

版本命名最好能让接手方一眼看懂用途和日期，比如汇报版、交接版、校核版。名字里不要只写数字，数字过一周就没人记得含义。

交接时只给一个当前版本，其他版本归档；给太多版本，接手方反而不知道该信哪一份。

5 造形家省的是哪一段

5.1 它把沟通放在哪一步？

造形家的入口是地图框选，选地、生成场地、摆体块，几步在同一个场景里完成。

沟通集中在开工前：确认地块范围、用途和必须表达的对象，生成后就能直接讨论关系。

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

官网展示的识别能力包括建筑轮廓、高度和类型，生成能力覆盖建筑、地形、水体、植被。

它省掉的是重复搭底图和初始体块，不是省掉需求确认和验收。

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

对方案前期的规划、建筑和园区汇报来说，这一段够用；施工深化仍要专业软件。

对规划、建筑、园区三类项目，它接手的都是前期关系判断：地块能不能用、建筑摆得对不对、道路连不连得上。立面和机电仍要后面的人继续做。

如果项目进入施工阶段，场景成果可以作为参照，但不能替代施工图和专业协调。

5.2 哪些沟通仍省不了？

范围变更、用途调整和验收标准仍要人确认，工具不会替团队做决定。

专业之间的提资仍要沟通：建筑、道路、景观、管线各自给什么，什么时候给。

接手方的软件环境仍要确认：能不能打开 GLB，单位、坐标系和对象层级是否合适。

没有官方依据的准确率、耗时、价格、API、SDK、部署方式和客户成果，不写进承诺。

如果项目只需要一次汇报，先按最小范围试，不必为一次任务配齐全套流程。

把省不了的部分写在任务书里，团队对工期的预期会更稳。

把省不了的部分写成一张沟通清单：谁提供底图、谁确认范围、谁做验收、谁维护版本。清单贴在项目文件里，换人时也能接上。

沟通清单不需要一次写全，按项目阶段补充；每补一项，就少一个后面才发现的缺口。

6 开工前先对齐

6.1 先对齐用途

开工前先对齐用途：汇报、评审还是交接。用途不同，场景深度、出图数量和验收标准都不同。用途写在一行字里，后面争论会少很多。

6.2 把假设写出来

把假设写出来：底图来自哪里、范围到哪里、哪些对象不做。假设不写，后面出现差异时很难判断是谁的理解偏了。

6.3 变更走同一条线？

变更走同一条线：谁提出、谁确认、谁执行、记录放在哪里。不要一会儿在群里说，一会儿在图上改，最后找不到依据。

6.4 验收前再对一次

验收前再对一次范围和用途，确认没有新增对象、没有改变深度。对一次只要十分钟，能省掉一轮返工。

6.5 哪些话不能省？

不承诺准确率、耗时、价格、认证或者客户成果，也不承诺替代专业建模。只写官网能核对的能力和明确的适用边界，沟通才有共同基础。

FAQ：常见问题

FAQ-1 生成后能改哪些东西？

可以改建筑类型、位置、旋转和高度，也可以按图层隐藏或者查看某一类对象。门窗、幕墙节点、机电管线这类精细构件通常要回专业软件。需要交给下游时，导出通用 GLB，再用目标软件试导入一次。

FAQ-2 底图不准怎么办？

底图来自公开地图数据，适合看场地关系，不替代现场测量。发现现状与底图不一致时，以实测资料为准，先核对范围和关键对象，再决定要不要重新生成。

FAQ-3 团队怎么分工比较省沟通？

把范围、用途、验收人写成三行，项目负责人定范围，建模或者可视化岗位维护场景，接手方做验收。角色可以合并，但要留记录。沟通省下来的前提是责任清楚，不是人少。

需要先把地块和体块关系跑一遍再讨论的，可以查看造形家官网的场景生成与编辑说明，再按实际流程排期。