客户选了互斥的产品选项，Agent 怎样给出可复核的配置缺口

客户已经选好几个产品选项，Agent 应对照获批规则指出冲突和缺项，并保留客户原选择。它可以提出需要确认的组合，不能暗中替客户删掉一个选项。产品配置校验 Agent 开发适合从“给定选项、解释规则、形成确认表”开始，避免把配置核对扩成没有证据的专业选型。

先明确选择属于哪类字段

选项表至少区分变体属性、必选属性、可选附加项和纯说明项。颜色、尺寸可能共同定位可售型号；客户希望预约说明会，只是服务偏好，不能因此生成一个新SKU。字段在页面上长得一样，不表示它们具有相同商业含义。规则所有者要先确认哪些改变产品身份，哪些仅留在备注。

Odoo的变体文档原文描述属性值排除及不同变体创建方式，说明选项展示与可购买变体不应混为一谈。本文借用这种区分设计工作表，不宣称该产品原生覆盖所有企业的复杂依赖，也不照搬价格字段。

配置输入保留原始选择、规范化选项代码和来源。自然语言说“大一点”时，不能直接套成大号；只有客户已确认具体选项，才进入本篇规则核对。若基础参数来自系列默认或型号覆盖，应先完成属性来源核对，否则互斥规则可能对着错误产品执行。

合成规则规定红色与大号互斥。客户选择蓝色、大号时，可形成候选；选择红色、大号时，表中应同时留下两项原值、命中的规则和影响。输出不能只有“配置无效”，应说明要保留红色还是大号由客户决定，以及哪位销售窗口负责确认可选范围。

系统可以展示两个待讨论方向，但不能把其中一个预先勾选为客户已同意。尤其不能以库存或模型偏好替代客户取舍；本篇没有库存数据，也不推断哪种组合更安全、更耐用。涉及工程性能时，交有权专业人员判断。

下载配置规则与合成演练。附件包括正常组合、互斥组合、仅说明的多选项和缺尺寸，分别保留预期与实际结果栏。说明项用单独字段保存，避免把“礼盒、预约说明”拼进型号后生成不存在的产品身份。

缺尺寸时可以只问“请选择已批准目录中的尺寸”，不必要求客户重新填写颜色。互斥时则要解释两个选择为什么不能共存，并请客户决定保留哪项。两个问题混用，会让客户觉得系统不断重复询问已经给过的信息。

规则未覆盖的组合应标为未知，不视作默认允许。规则表没有明确某种说明项能否与主产品同售时，可以保留备注，却不能将其加进正式订单。模型不能从相似产品的做法补出本产品规则。提交给销售的表要区分确有冲突、缺必要条件、规则缺依据和资料读取失败，便于各自补办。

每条规则应有适用产品、条件、禁止或依赖动作、批准来源和版本。双向互斥与单向依赖不同：不能因为选A要求B，就推导选B也必须A。首期可只支持业务方能清楚写下的规则，对未表达清楚的逻辑列入人工区，而不是宣称自动理解所有配置。

客户改了颜色，不能只删除上一条红色冲突。应在同一请求中保留修改前后配置，用新组合重新检查所有已批准约束；其他已确认属性不随意清空。某个冲突消失，并不说明缺尺寸也已经解决。

负责人还需确认规则版本。目录更新后，旧确认表标出需复核的组合，不把新规则偷偷套进已经讨论完的选择。评审时让销售从每条结论反查规则，再从每条规则寻找输入证据，检查有没有未经客户同意的替换。

客户看到冲突时，应先能辨认自己原来选了什么，再看到可以继续讨论的选择。把错误字段自动改红可以辅助定位，但只靠颜色仍无法解释影响；文字说明应同时提及选项名称与命中规则，避免客户为消除提示而误删其他选择。

规则维护窗口最好提供一条允许和一条禁止组合，作为每次改版的固定核对对。用蓝色大号与红色大号对照，就能验证排除是否过宽；只测试禁止项被拒绝，可能漏掉正常组合也被一并阻断。

若选的是商业套装，应把组合可行与套装必带清单分开，再看套装包含项确认。宽泛目标尚不清楚时，可先用询盘最小追问明确条件；本篇只核已有配置。更多方向见客服专题。在定制咨询提交脱敏选项表、两条冲突和一条允许组合，可以先确定规则表达、客户确认和人工例外范围。