上线 3D 配置器前，企业需要准备哪些资料？

建立唯一的产品资料来源

项目最常见的延误并不是开发，而是不同部门对同一选项使用了不同名称、编码或限制条件。开始前应指定一份可确认的产品资料作为基础。

这份资料不需要一开始就完美，但必须能够说明每个产品、模块和选项的正式名称、可选范围和责任人。

• 产品型号、版本与适用市场

• 颜色、材质、部件、尺寸和附件列表

• 每个选项对应的图片、模型或纹理素材

• SKU、价格、交期或销售备注

• 资料的维护部门与确认流程

指定责任人和变更流程

项目不能只依赖一个共享文件夹。应明确谁有权确认产品名称、规则、价格相关映射、视觉素材和交接字段；每一项还应记录来源、责任人、审核人、生效日期，以及发生何种变化后必须重新测试。

交付内容	最终责任方	必须复核的变更
产品和选项目录	产品团队	新型号、新选项或产品编码变化
规则与兼容性	产品或工程团队	依赖、互斥或默认值变化
价格与商业映射	销售或电商团队	价格、SKU、税费或市场变化
3D 素材和品牌展示	市场或设计团队	模型、贴图、相机或文案变化
询盘与系统交接	销售运营或 IT	表单字段、CRM、购物车或订单变化

这不需要复杂的治理流程，但能避免常见问题：视觉、数据和销售流程各自更新后，配置器却无法准确呈现当前已确认的产品方案。

把销售经验转成可执行规则

很多规则原本只存在于销售或工程团队的经验中，例如某种尺寸不能搭配特定材质，或某个附件只能用于高配版本。配置器上线前，需要将这些判断写成可讨论、可验证的条件。

先梳理影响成交和交付的关键规则，不必把所有边缘情况都放进第一期。

• 默认推荐什么配置

• 哪些选项必须同时出现

• 哪些选项不能同时出现

• 哪些选择会影响价格、SKU 或交期

• 出现不兼容选择时如何向用户说明

提前约定上线后的交接方式

配置结果最终由谁使用，决定了需要输出什么信息。官网询盘、经销商演示和 Shopify 下单的交接方式不同，应在交互设计前明确。

• 用户配置后看到什么下一步动作

• 销售团队收到哪些客户与配置数据

• 是否需要保存链接、PDF 或配置单

• 新产品和新规则由谁维护

• 用什么指标判断第一期是否有效

3D 资产要说明“能否直接进入网页”

提供模型文件并不等于模型已经可以用于 Web。评估前应标记每个产品的文件格式、面数、材质数量、贴图分辨率、单位、坐标和拆分方式，并说明哪些部件需要独立切换。

建议至少整理以下资产清单：

资料	需要确认的内容
原始模型	格式、单位、比例、坐标、部件层级和版权归属
Web 模型	是否已有 GLB/glTF，面数和文件大小是否适合移动端
材质贴图	颜色、粗糙度、金属度、法线和纹理授权
场景素材	地面、灯光、背景、相机视角和品牌视觉要求
产品数据	型号、选项编码、价格、库存、交期和适用市场

如果没有可用模型，也应在项目启动时单独列出建模、拆分、轻量化和材质制作的工作量，而不是把它们隐含在前端开发费用里。

提前准备可进入生产的数据模板

开发前应让每个可选项都有一行或一条完整记录。可用模板需要把客户看到的名称、稳定数据和对应的视觉素材关联起来，以便在开发前发现缺失输入，而不是等到实现阶段才暴露问题。

• 产品和选项 ID、显示名称、适用市场和语言

• 所属产品或模块、显示顺序、默认值和可用状态

• 规则引用：前置条件、互斥关系和受影响选项

• 适用时记录 SKU、价格状态、交期影响和销售备注

• 模型节点、材质、贴图、图片或其他视觉引用

这份模板既是规则评审和素材制作的起点。不要等到界面完成后，才发现某个选项没有有效编码、没有确认贴图，或没有业务责任人。

先定义第一期的验收标准

除了“页面上线”，还应写清代表性产品能完成哪些配置路径、哪些不兼容组合必须被拦截、提交后销售能收到哪些字段，以及移动端的加载和交互要求。验收标准越具体，后续修改范围越容易控制。

上线前测试完整的业务路径

验收不仅要覆盖界面，也要覆盖交接过程。应尽早约定代表性案例，让各团队围绕同一份预期结果测试。

测试路径	需要验证的内容
默认配置	初始状态、名称和推荐选择正确
有效的自定义选择	3D 外观、规则、编码和摘要保持一致
无效组合	被阻止的选择和解释足够清楚
报价或订单交接	销售、CRM、购物车或订单收到相同配置
移动端与恢复流程	支持设备上的加载、交互、提交和报错提示正常

为每条路径记录预期的配置摘要，包括选项编码以及相关的价格或交期状态。这样验收才能追溯，也能为后续产品更新提供实际可用的回归检查清单。