Snapshot

2. 设计单页面核心流程并推动团队采用；
3. 上线后继续完成两轮控件迭代。 | | 当前状态 | 已上线并持续使用 |

TL;DR

Scanat 的 CAD 制图团队需要从扫描得到的 3D 建筑模型中提取平面和立面轮廓。在过去，部分断面仍需人工参考模型重绘，因此我们设计了轮廓图功能：用户选择需要的平面或立面、设置切割位置，系统自动生成二维轮廓，并以 DXF 导出到 CAD 继续使用。

**我的工作：**从开放需求阶段参与功能定义，设计核心工作流与 3D 空间交互，并在上线后根据实际使用完成两轮控件迭代。

https://res.cloudinary.com/v7b2p5ho/video/upload/v1786613134/pu6weyazrptggllgv0iv.mov

1. Problem

需求概述

CAD 制图团队拿到 Scanat 的 3D 模型后，部分平面和立面仍需人工重绘。由于模型本身已包含这些几何信息，核心问题是：如何自动完成 3D → 2D 轮廓提取，并继续接入原有 CAD 流程。

三个核心设计问题

1. 怎么让 3D 切割更容易理解？ 底层是 X / Y / Z，但用户对此的理解成本高；同时还要明确切割方向和具体位置。
2. 怎么围绕同一模型连续操作？ 创建和调整切割面时，模型、当前状态和已有轮廓都需要持续可见。
3. Scanat 与 CAD 如何分工？ Scanat 负责从 3D 模型提取轮廓，后续制图继续交给 CAD。

**界面约束：**切割面需要精确定位，同时控件不能长期占用 3D 画布。

前期调研

我查看了 3D 建模、建筑可视化和 CAD 工具中的切面 / 剖切操作，并结合内部 CAD 工作流确认两点：界面应使用平面 / 立面等建筑语义，而不是直接暴露 X / Y / Z；生成结果需要顺畅回到 CAD。“轮廓图”的功能名称也在这一阶段确定。

2. Approach

项目从开放需求开始，设计过程可以概括为四步：

1. **定义空间语言：**将 X / Y / Z 转换为平面、正立面和侧立面；
2. **确定工作区结构：**对比三阶段与单页面流程；
3. **迭代切割面控制：**从画布拖拽改为滑块 + 数值输入，再整合进右侧面板；
4. **衔接 CAD：**以 DXF 输出二维轮廓，继续原有制图流程。

3. Design Decisions

决策一：让模型成为持续工作区，而不是流程中的一个预览页面

产品经理最初提出三个阶段：先查看模型和已保存轮廓列表，进入独立页面新建或编辑轮廓，保存后再返回列表。

我提出把轮廓列表、切割面控制和 3D 模型保留在同一个工作区。主要因为轮廓本质上是由当前模型和一个或多个切割面共同定义的结果。在创建、调整和检查过程中，模型不是一个可以离开的预览页面，而是始终存在的操作上下文。

这个判断主要来自两个实际场景：

1. 创建过程始终依赖模型。 放置、移动和增加切割面时，用户都需要持续观察切割面与建筑结构的关系；
2. 已保存轮廓很少需要独立打开编辑。 如果结果不合适，实际操作通常是继续调整当前切割面再重新生成，而不是从列表进入另一个编辑器。

最终团队采用单页面结构：列表负责管理结果，切割面控件负责当前操作，模型负责持续提供空间上下文。后续控件虽然又迭代了两次，但页面结构没有再拆分。

单页面结构会增加同屏状态管理的复杂度，但我认为这是值得承担的，因为用户操作始终依赖当前 3D 模型；如果为了页面结构更简单而拆成多步流程，反而会丢失任务上下文。

决策二：用“平面 / 立面”代替 X / Y / Z

从技术实现上看，轮廓图实际上是在 3D 模型的 X / Y / Z 三个方向放置切割面。最直接的做法是让用户选择 X、Y、Z 轴，但这会把模型坐标系直接暴露给用户，并额外引入“哪个轴对应建筑哪个方向”的理解成本。

建筑制图用户真正关心的并不是“沿 Y 轴切一刀”，而是“我要这个建筑的平面、正立面或侧立面”。因此最终没有把 X / Y / Z 作为主要操作语言，而是在页面顶部提供：平面 / 正立面 / 侧立面。

用户先选择自己希望生成的图纸方向，系统再映射到对应的空间切割轴。这个设计把系统的坐标模型转换成了用户的任务模型，也把“切哪个方向”和下一步的“切在哪里”拆成两个更容易理解的问题。

决策三：让控件负责精确输入，让 3D 画布负责空间反馈

第一版允许用户直接在 3D 画布中拖拽切割面。这种方式符合很多 3D 软件的直接操控习惯，也能让用户快速看到平面移动，但实际内测后发现，它不适合需要明确位置与精度的制图场景：用户能看见平面“差不多在哪里”，却很难确认它“准确在哪里”。

因此我重新划分了控件和画布的职责：

• 滑块用于快速移动，找到大致位置；
• 数值输入用于精确定位；
• 3D 画布不再承担主要的精确输入，而是实时展示切割面与建筑模型之间的空间关系。

这样既保留了空间操作的即时反馈，也满足了 CAD 场景对位置精度的要求。

改成面板控件后又出现了第二个问题：浮动面板会占用模型空间，尤其在小屏幕上影响观察。我们考虑过允许面板拖动或最小化，但那仍然要求用户自己处理面板与模型的重叠。最终把轮廓图控件整合进产品已有的右侧可折叠面板，需要时展开，不使用时收起。

决策四：在同一工作区管理一个或多个切割面

轮廓图并不只对应单一方向或单一平面。用户可以先在顶部选择平面、正立面或侧立面，再根据需要在当前模型中添加相应的切割面；一个轮廓也可以包含多个切割面。

因此多切割面管理没有被设计成多个独立页面，而是继续留在同一模型上下文里。用户调整某个切割面时，仍然能看到模型、其他切割面以及当前轮廓之间的关系。这样做的重点不是增加一套复杂的“对象管理器”，而是让多个空间状态始终围绕同一个模型被理解和调整。

https://res.cloudinary.com/v7b2p5ho/video/upload/v1786935043/i4rxwmzj2rpy0olbfuch.mov

决策五：只解决 3D → 2D 的断点，而不重新创造 CAD

最初的问题来自一个非常具体的重复工作：CAD 团队已经拿到了 Scanat 的 3D 模型，却仍然需要对照模型手动重绘部分二维断面。

因此这个功能的产品边界不是“在 Scanat 里完成整套二维制图”，而是利用 Scanat 已经拥有的 3D 几何数据，把最重复的一段工作自动化：用户选择所需方向和切割位置，系统生成二维轮廓，再导出 DXF 文件继续在原有 CAD 软件中编辑。

这种边界让 Scanat 专注于自己最有数据优势的 3D → 2D 几何提取，同时保留用户已经成熟的 CAD 工作方式，而不是为了一个功能复制另一套专业软件能力。

4. Outcome

• 上线与持续使用：轮廓图已正式上线，并持续被用于从 Scanat 的 3D 模型生成平面与立面轮廓；
• 内部使用信号：根据团队内部观察与访谈，轮廓图成为平台中使用较多的专业功能之一，尤其与 CAD 制图工作流结合紧密，提升了绘图效率。模型角度调整、轮廓图角度调整、dxf精度调整等都是根据绘图同事的反馈所进行的持续迭代。
• 方案稳定性：上线后的两轮迭代主要集中在切割面的控制精度和画布占用，单页面工作区的核心结构一直保留。

5. Reflection

1. **关于空间交互：**第一版采用画布直接拖拽，因为这种操作更接近常见 3D 软件。但实际制图更重视位置精度。如果重新做一次，我会更早把“方向选择”和“位置输入”拆开验证，并用可交互原型测试拖拽在真实任务中的精度边界。
2. **关于用户语言：**这次把 X / Y / Z 转换成平面 / 正立面 / 侧立面，让我更明确地意识到，专业工具里的技术模型不应该自动成为界面语言。面对复杂系统时，我会先区分底层数据结构和用户真正做决策时使用的概念。
3. **关于页面结构：**项目后续改过两次控件，但没有重新拆分页面。对于围绕同一个 3D 对象连续操作的功能，我会先判断哪些状态必须持续可见，再决定是否需要页面级切换。