先区分四种基础规则
大多数配置逻辑都可以从依赖、互斥、必选和默认推荐开始描述。把规则分类后，产品、设计与开发团队才容易讨论同一件事。
依赖：选择 A 后才允许选择 B
互斥：选择 A 后必须取消 B
必选：完成方案前必须选择某个项目
默认推荐：给用户一个可用的起点，但允许按条件修改
规则应该属于产品数据，而不只写在界面代码里
简单项目可以在前端直接实现规则，但产品和选项增长后，规则应以结构化数据表达，例如通过选项编码、条件和结果维护。这样才能更容易测试、复用和更新。
3D 场景只负责呈现状态变化，规则引擎负责判断哪些选择有效、哪些字段需要更新。这个边界能避免视觉逻辑和业务逻辑互相缠绕。
为产品、选项和模块建立稳定 ID
规则中引用 ID，而不是界面上展示的文案
把可见性、可选性和价格影响分开描述
为规则变化保留版本和测试记录
不要悄悄替用户修改选择
当一个新选择会使已有配置失效，界面应明确告诉用户发生了什么，并提供可理解的下一步。直接重置用户的选择，会降低对产品和工具的信任。
对复杂产品来说，规则提示本身也是销售解释的一部分。它可以说明限制来自安全、规格、交期或产品定位。
在选项不可用时说明原因
在自动替换前展示受影响的选择
把重要规则放在配置流程靠前位置
用真实产品语言替代技术错误提示
用一个产品例子验证规则设计
例如一款模块化家具可以规定：选择三人位沙发后才显示贵妃位；选择户外面料后才允许选择防水内衬；某种尺寸不能搭配特定底座。每条规则都应说明触发条件、受影响选项、用户提示和最终输出，而不只是写成“前端判断一下”。
| 规则 | 触发条件 | 系统动作 | 用户看到的说明 |
|---|---|---|---|
| 依赖 | 选择基础模块 A | 开启附件 B | “选择 A 后可添加 B” |
| 互斥 | 选择材质 C | 禁用材质 D | “C 与 D 不能同时使用” |
| 价格影响 | 选择升级配置 | 更新价格状态 | “该选项需要重新报价” |
| 交付限制 | 选择特殊规格 | 标记人工确认 | “提交后由销售确认交期” |
规则上线前要做可追踪测试
规则测试不应只验证一个“正常配置”。至少要覆盖默认配置、每个依赖和互斥关系、撤销选择、直接打开分享链接、移动端操作，以及规则变化后旧配置是否仍能读取。
每条重要规则都可以保留测试编号、输入选项、预期结果和实际结果。这样在新增产品或修改价格时，团队能快速判断哪些路径需要重新验收。
规则复杂度也会影响项目费用
简单的颜色替换通常只需要呈现状态变化；包含多个产品模块、地区价格、库存、交期和报价版本的规则，则需要更多产品梳理、交互设计、开发和测试工作。这些内容应在项目费用评估阶段单独列出。