重建数据结构
↓迁移历史数据
↓改造全部接口
↓长期兼容新老链路
范围与风险快速扩张整车商城
重构
在兼容历史商品、订单和外围系统数据的前提下，重构高维个性化选配体系、后台交互与公共配置能力。
项目概览不是从零设计，
不是从零设计，
而是让复杂系统平稳演进。
组合规模爆发旧模式无法继续承载
→配置体验割裂业务路径与后台结构错位
→历史链路复杂存量数据与多系统依赖
→分层完成重构突破能力，优化体验，稳定落地
重构的关键不是把旧系统做得更“新”，而是判断哪些结构必须稳定、哪些体验必须改变、哪些能力值得抽象。
02
业务可用 / 后台页面结构重构让后台按照业务路径组织，
让后台按照业务路径组织，
而不是按照历史模块堆砌。
系统具备高维配置能力后，还需要让业务能够理解、配置和验证。原后台以“商品—车型—个性化配置”组织字段，与 App 用户路径脱节，系统知识也高度依赖老员工。
个性化配置 / 外观
标准车漆
页面素材主视觉 + 4 张车辆角度图
主视觉正前方侧面后侧内饰
外观轮毂内饰选装
标准车漆选项前台双列展示
墨玉青¥ 30,000已启用
萤石白价格已包含已启用
曜石黑配日曜金¥ 50,000已启用
曜石黑配日珥金¥ 30,000已启用
当前配置影响App → 外观 → 标准车漆
App 实时预览
真实页面已适配为 iPhone 样式
9:41▮▮▮ ᯤ ▰
‹个性化配置
01 / 前后台路径对齐
后台的导航、字段和素材都明确对应到 App 页面，业务可以边配置边确认展示位置。
商城配置助手
知识已同步输入配置或系统使用问题↑
02 / 内嵌知识问答
问答不只解释概念，还给出排查顺序和直达后台功能的入口。
设计原则：后台应该服务业务理解，而不是映射数据库结构。
03
稳定落地 / 历史数据与公共能力演进重构不是推翻历史，
重构不是推翻历史，
而是在稳定基础上完成演进。
新能力能承载、业务也能使用之后，最后一步是让它安全进入存量体系。历史配置关系与订单数据已被大量业务模块和外围系统引用，全面替换会把一次商城重构扩大为全链路迁移工程。
保持核心结构
↓抽象公共配置
↓优化操作方式
↓分阶段演进
上下游稳定，体验质变关键取舍 / 为什么不推翻存量关系
保留稳定标识，重构重复维护方式。
历史配置关系已连接个性化选配、订单、客服、数据分析及外围系统。直接替换会引发历史订单重映射和上下游接口改造，因此本次保留稳定关联，将改造重点放在配置、素材与操作方式上。
历史配置关系保持稳定订单与外围系统同时抽象公共配置与素材
一个配置变化，也要重做整套内容
相同的外观、轮毂、卡钳和座位内容，在不同组合中被反复配置与上传。
组合 01组合 02组合 03组合 04
重复维护：基本信息 · 价格 · 图片 · 360° 素材
配置资产独立维护，组合按需引用
每个配置项拥有独立的基本信息、价格和图片素材，相同内容只维护一次。
组合只记录引用关系，不再复制整套内容原方案约 1200 张
→
重构后约 120 张
素材维护量减少约 90%
01 / 测试环境配置图片素材与基本内容完成预览和业务验证
验证通过后下载02 / 本地文件完整素材包图片、基本配置与关联关系
在生产环境上传03 / 生产环境上传素材包并自动导入直接复用已验证内容
设计原则：保留合理的历史结构，把重复配置抽象成公共能力。
01
能力突破 / 超高维配置体系当组合达到数十亿级，
当组合达到数十亿级，
传统 SKU 驱动模式已经失效。
重构首先要解决的，是原有模式已经无法承载新的业务规模。高定场景同时包含座位数、外观、内饰、轮毂、卡钳与多组选装规则，可能形成约 80 亿—200 亿种组合。
01选择配置项记录配置 ID
→02规则校验父子与互斥关系
→03组合素材按选择生成预览
→04生成 SKU确认后连接上下游
规则引擎 / 业务可维护
复杂选装关系，不再写死在代码里。
将依赖、互斥与组合限制沉淀为可配置规则，业务维护关系，系统在选择与发布时自动校验。
例如选择外观套件后，才可继续选择对应部件。
选择一项后，系统自动限制与之冲突的配置。
单项均可选择，但特定组合形成后不能再叠加目标配置。
保存与发布前校验双向关系、缺失依赖和冲突组合。
真实素材图层组合
素材按选装结果，动态叠加为完整车辆。
实际图层数量由用户选择的配置项决定，可能是少量图层，也可能叠加十余层；每层只维护自身变化的视觉元素，最终动态合成车辆展示效果。下方为一组脱敏素材示例。
1234567
当前示例进度1 / 7
内饰鱼眼图层组合
内饰素材按选装结果动态叠加，完成后可拖动查看。
实际图层数量同样由用户选择的配置项决定。下方以基础座舱、顶棚、下部饰件和右前座椅为脱敏示例，合成后进入可拖动浏览状态。
1234
拖动探索内饰示例 1 / 4 · 基础座舱
设计原则：当 SKU 无法承载组合复杂度时，让配置项和规则体系承载复杂度，并把规则转化为业务可维护能力。
项目结果用数据证明，
用数据证明，
重构解决了真实问题。
结果从能力上限、业务效率和稳定落地三个层面，对应前面的重构路径。
01
设计配置驱动的高维选配方案
02
将依赖与冲突沉淀为可配置规则
03
判断哪些历史关系必须保留
04
将重复素材与配置抽象为公共能力
本案例涉及企业内部系统，页面、流程、系统名称及数据关系均已进行脱敏和抽象，仅用于展示产品思路与设计方法。