| 角色 | 交互设计 · 可运行原型 · Design Engineering · AI辅助编程 |
| 项目类型 | 持续原型探索与整合 |
| 平台 | Web（浏览器端 3D 原型，three.js / R3F） |
| 时间跨度 | 2026年2月 – 8月 |
| 我的贡献 | 1. 独立完成从 LidarLab 3D 到 5 个专项 Demo 的设计与实现； |
<aside>
</aside>
Scanat 的核心操作发生在 3D 模型中。拖拽命中、相机运动、空间方向、遮挡以及多个工具共存时的交互冲突，都很难只通过 Figma 判断。
从 2026 年 2 月开始，我使用 AI 辅助编程制作可运行 3D 原型：先为具体问题建立独立 Demo，验证交互手感和几何逻辑；到 8 月再把已经验证过的功能整合进 3D Studio，检查它们进入同一产品环境后的状态和冲突。
**我的工作：**独立完成原型实现，并在整合过程中整理代码职责、统一拾取入口、Feature 注册方式和基础测试规则。
Scanat 用户需要直接在 3D 模型中测量、标注和编辑。Figma 可以说明界面结构，但无法真实判断拖拽是否容易命中、相机变化后控件是否稳定、空间方向是否正确，以及动画和遮挡在实际运行中的效果。
因此我逐渐把可运行原型加入设计过程，用浏览器直接验证这些问题。
专项 Demo 适合解决单点问题，但真实产品中的笔记、测量、Gizmo、相机控制和模型缩放会同时作用在同一个场景中。随着 Demo 增加，我开始需要验证共享指针事件、跨工具状态、坐标变化和视觉层级等问题。
这成为重新建立综合原型的直接原因。
3D Studio 并不是一开始就规划好的平台，而是随着真实项目逐步形成的。
2026 年 2 月，我先制作 LidarLab 3D，验证浏览器端加载点云、距离测量和体积可视化是否可行。后来 Scanat Volume 的部分可视化探索也直接使用了这里的测试结果。
这一版只是一次性验证工具，没有为后续扩展设计结构。主要考虑这个阶段最重要的是快速验证 3D 技术和交互是否可行，在需求尚未稳定时提前建立完整架构反而会增加维护成本。
2026 年 5 月到 7 月，新的 3D 交互需求陆续出现。我没有继续扩展旧原型，而是为每个问题单独建立 Demo。这样每个 Demo 都只包含验证当前问题所需的最小功能，避免已有状态和交互干扰测试。
| Demo | 时间 | 主要验证内容 |
|---|---|---|
| scale-transition | 2026-05 | 模型比例变化后，相机如何补偿视觉大小 |
| cube-gizmo | 2026-06 起 | Gizmo 在触屏和鼠标两种输入方式下如何移动、旋转和命中 |
| measure-copy | 2026-07 | 复制测量项后如何把它移动到新位置，以及拖拽放大镜的交互 |
| reset-view | 2026-07 | 相机如何从任意状态平滑回到默认视角 |
| note-text-display | 2026-07 | 场景内锚点、引线和文字如何在相机运动时保持流畅 |
每个 Demo 只处理一个问题，可以更快地调整交互和排查边界情况。
到 2026 年 8 月，单点问题已经积累到一定数量。我重新整理旧原型，把已验证的交互迁移进更接近 Scanat 产品环境的 3D Studio。
专项 Demo 继续用于快速单点测试，3D Studio 用来检查功能共存时的交互、状态和性能。
两种原型解决的问题不同：
| 独立 Demo | 3D Studio | |
|---|---|---|
| 主要目的 | 验证单个交互是否成立 | 验证多个功能同时存在时是否冲突 |
| 修改范围 | 小，可以快速试错 | 需要考虑已有功能和产品状态 |
| 适合观察 | 拖拽手感、数学、局部边界情况 | 跨功能状态、视觉层级、指针冲突、整体操作流程 |
后续复杂交互仍可以先在专项 Demo 中快速验证，再放入 3D Studio 检查真实产品环境下的共存问题。
开始整合时，核心文件 LidarViewer.tsx 已有 3543 行，组件、算法和面板 UI 混在一起。如果继续把专项 Demo 接进去，后续很难单独定位问题。
因此我先按职责拆成：
core/：几何与算法；viewer/：场景、相机等 3D 基础能力；features/：各功能独立目录。拆分后，主文件缩到约 1559 行，主要保留场景总装和壳层状态。
当笔记、测量和 Gizmo 等功能逐渐进入同一个 3D 场景后，我关注的不再只是单个 Demo 是否可用，而是它们同时存在时会不会互相干扰。例如一次点击可能被多个工具同时响应，或者不同功能争夺同一类操作。
因此我先统一了输入规则：由当前任务和工具状态决定谁响应用户操作，避免多个功能同时处理同一次输入。规则确定后，再在 AI 的协助下把它落实到可运行原型中。
功能入口：根据使用时机决定位置。 不同功能的使用方式并不一样：有些属于持续使用的工具，有些只在选中对象后才有意义。我根据任务状态把入口分别放在工具栏、侧边面板或选中态操作区，而不是把所有功能平铺在同一层级。实现上，再在 AI 的协助下整理成可复用的功能注册方式。
验证方式：先确认逻辑，再测试手感。 Gizmo 等 3D 交互既有空间计算，也有实际操作体验。如果两类问题混在一起，很难判断到底是交互方案还是实现出了问题。因此我先在 AI 协助下验证移动、旋转等基础逻辑，再回到浏览器测试命中范围、拖拽手感和不同视角下的表现。
整合过程中还发现了显隐状态、浏览器运行状态等静态稿无法暴露的问题。这些情况进一步说明：对于复杂 3D 交互，可运行原型不仅用于展示方案，也是在设计阶段提前发现边界问题的一种工具。
3D Studio 综合工作区
在接近真实产品的界面中同时运行多个 3D 功能，用于检查跨工具状态与交互冲突。
https://res.cloudinary.com/v7b2p5ho/video/upload/v1786953524/cljqazqkn2zgc7kperws.mov
专项 Demo 入口
每个功能仍然保留独立页面。在需要调整单个交互时，可以回到专项 Demo 中快速测试，再把确定后的版本同步到 3D Studio。
https://res.cloudinary.com/v7b2p5ho/video/upload/v1786953526/qi4qgbid6okgfi5ahpun.mov
**原型产出：**2026 年 2 月到 8 月，共完成 LidarLab 3D、5 个专项 Demo 和整合后的 3D Studio。
**产品应用：**几个Demo的可视化探索均应用于生产环境的效果和参数交付，尤其是体积测量、立方体Gizmo以及修改比例等，大大减少了设计与开发的沟通成本。几项功能也均已上线，整体的交互和动画效果与Demo基本一致。
**内部评价：**立方体Gizmo、重置视角、修改比例功能的动画和交互参数直接应用于生产环境，开发同事认为这大大节省了开发时长，减少了试错成本。