01 · 业务背景
交易从群聊里的自然表达开始，最终要落到订单与履约
汽车膜交易保留了群聊这一沟通入口。客户会在连续消息中补充车型、门店、膜型偏好、数量和交付要求，业务人员随后查询价格及库存，再推进订单。悟客在这个案例中读取当前群聊上下文，把已经确认的信息整理成业务字段，并连接询价、库存、下单和后续履约。客户继续用熟悉的方式沟通，执行环节则获得可检查的输入。
02 · 原有问题
一笔需求分散在多条消息中，人工复制时容易带入旧信息
车型简称可能对应多个具体版本，膜型名称也可能存在近似写法。数量、收货位置和交付时间往往在后面的消息里才补齐，报价之后还可能修改。业务人员若靠记忆从群聊复制，容易把上一笔交易的价格或库存带到当前订单，也可能在信息尚未确认时提前创建订单。支付状态和物流进度回到群里以后，又要重新找到原订单才能继续处理。
03 · 接入与执行
八个步骤依次确认，每次执行都引用当前有效数据
- 需求识别从当前群聊判断采购意图，归集同一笔需求的上下文，并标记仍待确认的字段。
- 车型确认核对车辆品牌、车型及影响匹配的具体信息，无法唯一识别时继续询问。
- 膜型匹配依据已确认车辆信息和客户要求，从当前 SKU 资料中筛选对应膜型。
- 价格查询按现行定价数据查询报价，保留所用 SKU、数量和价格版本供业务人员核对。
- 库存确认检查当前库存与交付位置，库存结果变化时返回确认环节，不沿用旧结果。
- 订单确认汇总车型、膜型、数量、报价及交付信息，让客户或业务人员确认订单内容。
- 订单创建确认完成后才将结构化参数写入订单系统，并保留订单与群聊需求的关联。
- 履约跟进围绕订单跟进支付与物流状态，把异常和需要补充的信息带回人工处理。
八步顺序保留了现有案例的业务闭环。任何会改变匹配、报价或交付的字段发生变化，后续步骤都应重新引用更新后的确认结果。
04 · 人工边界
车型含糊、报价冲突和库存异常都暂停自动执行
悟客不根据简称猜定车型，也不会在多个膜型都可能匹配时替客户选择。群聊里出现相互矛盾的数量或收货信息，价格数据缺少有效版本，库存无法确认，支付异常或物流问题需要协调时，流程转交业务人员。转交记录包含相关群消息、已确认字段、系统查询结果和歧义点。人工修正后，流程从受影响的步骤继续，避免带着未确认信息创建订单。
05 · 结果验证
完成情况按八步状态和业务记录核对，不用回复数量代替闭环
这个案例的公开结果是 8 步完整业务流程。验证时要逐笔查看需求是否归到正确上下文，车型和膜型能否对应，报价与库存是否来自当时有效数据，订单创建前是否完成确认。订单生成以后，还要检查支付和物流状态能否回到同一记录，异常是否进入人工处理。八步齐全说明流程范围已经覆盖，不代表每笔群聊都能自动完成，也不构成其他交易场景的结果保证。
06 · 适用条件
当前 SKU、价格和库存可查询，群聊才能连接可靠执行
这套方式适合交易步骤已经明确，并能提供车型规则、SKU 目录、现行价格和可用库存数据的汽车后市场团队。订单接口要能接收已确认字段，支付与物流状态也需要有可追踪的回传方式。产品、定价或库存数据变化后，应先更新数据再继续报价。若车型规则、订单结构或履约分工不同，就要重新映射八步流程并验证异常处理，不能直接照搬案例中的闭环描述。