一、项目背景

这个客户是华东一家做了二十六年的工业品经销集团，代理三十多个品牌，轴承、密封件、气动元件、低压电器，SKU 三十二万出头。第一次去他们仓库调研的时候，我看到业务员桌上摞着七八本纸质样本，边角都翻卷了。客户在电话那头报一个型号，业务员就翻，翻不到就打给厂家的技术支持，来回半个小时是常态。

真正让他们下决心做系统的是一笔退货。有个客户要一批耐高温的油封，业务员按客户口述的尺寸找了个型号发过去，装上去两天就漏了。查下来是材质选错了，客户工况温度到两百度，业务员给的是丁腈橡胶的，只能扛一百二。这批货两万多块钱，往返运费加上客户产线停机赔偿，一共赔了小十万。

他们财务给我拉过一组数据。全年退货金额占销售额的百分之四点一，其中因为选型错误导致的占到六成以上。另一头，业务员平均一天只能报出十一单价，剩下时间全耗在查资料和问厂家上。三十万 SKU 里，有实际动销记录的不到八万，剩下二十多万是躺在系统里的死数据，参数残缺、描述混乱、同一个东西在三个品牌下有三种叫法。

二、落地场景

我们用 XpShop 的 S2B2C 供应链平台做底子，把商城、参数库、库存和履约串起来，AI 部分跑在客户机房的私有化底座上。整个系统对外呈现的是四件事。

参数化选型是入口。客户不用记型号，进来先选大类，比如深沟球轴承，然后填内径、外径、宽度、精度等级、润滑方式、工作温度这些参数，系统筛出符合条件的候选清单，按库存和价格排序。填不全也能用，系统会按已知参数给出模糊结果并提示缺哪几项。

型号互换推荐解决的是替代问题。客户手上有个旧型号，可能是停产的，可能是别家品牌的，输进来之后系统给出参数等效或者兼容的可选项，并且标注差异点在哪里，比如"外径一致，宽度差 0.5 毫米，需确认安装空间"。

一客一价按客户资质和历史采购量走。同一个型号，年采购五百万的战略客户和零散询价的散户看到的价格不一样，这套规则原来在业务员脑子里，现在挪进系统。

多仓履约和缺货替代放在下单环节。集团在六个城市有仓，系统按客户收货地址、库存量、运费成本算出最优发货仓，缺货时自动推荐可替代型号，替代方案需要客户确认后才生效，不能系统自己换。

三、关键技术挑战与解决思路

最大的坑在参数治理，比我们预估的难得多。项目排期里给参数清洗留了三周，实际做了九周。

三十二万 SKU 的参数来源杂得很，有的是厂家提供的电子样本，有的是十几年前手工录进 ERP 的，有的干脆只有一个型号和一句描述。同一个"耐温 200℃"，在数据里可能写成"200度""200C""≤200℃""高温型"。品牌之间的参数命名也不统一，A 品牌叫"内径"，B 品牌叫"孔径"，C 品牌用的是英制。

我们的做法分三层。底层建了一套类目参数字典，按大类定义标准参数名、单位、取值范围，这部分是人工和客户的技术工程师一起定的，花了两周，定了两百六十多个类目模板。中间层用大模型做参数抽取，把非结构化的描述文本和 PDF 样本里的表格转成结构化字段，抽完之后跑规则校验，比如外径必须大于内径、精度等级必须在枚举范围内。顶层是人工复核队列，抽取置信度低于阈值的进队列，客户的技术团队每天处理一批。

跑第一轮的时候抽取准确率只有百分之七十一，问题出在扫描件样本上。老品牌的样本是九十年代印刷的 PDF 扫描图，表格线歪、字迹模糊，OCR 出来一塌糊涂。后来我们把这部分单独拎出来，接了版面分析做表格还原，再送模型抽取，这一类的准确率从五成多提到八成六。整体抽取准确率最终稳定在百分之九十三点二，剩下的进人工。

型号互换匹配的难点在于"等效"没有统一定义。严格的等效要求所有参数一致，但实际业务里，很多情况下某些参数差一点是可以接受的，得看具体工况。我们的处理是把参数分成三档：关键参数必须完全一致，比如安装尺寸；重要参数允许在容差内浮动，比如额定载荷不低于原型号的百分之九十五；参考参数只做提示，比如颜色、包装规格。每个类目的分档由技术工程师配置，不是系统自己拍。

多仓库存可见性上我们踩了个不算小的坑。最初设计是实时查各仓 WMS，结果大促期间 WMS 接口被打挂了两次。改成本地缓存加增量同步之后，又出现超卖，因为缓存有几秒延迟。最后的方案是分级处理：库存充足时走缓存，库存低于安全线时强制实时查询并加分布式锁。这个方案不优雅，但线上跑了四个月没再出事。我个人觉得这类问题不存在完美解，只能在一致性和可用性之间挑一个自己扛得住的位置。

案例片段（已脱敏）：类目参数模板与互换匹配规则的一段配置。

yaml category: 深沟球轴承 params:  critical:            # 关键参数，必须完全一致    - {name: 内径d, unit: mm, type: number}    - {name: 外径D, unit: mm, type: number}    - {name: 宽度B, unit: mm, type: number}  important:           # 重要参数，容差内可替代    - {name: 额定动载荷Cr, unit: kN, tolerance: ">=0.95x"}    - {name: 极限转速, unit: rpm, tolerance: ">=0.90x"}    - {name: 工作温度上限, unit: C, tolerance: ">=1.0x"}  reference:           # 参考参数，仅提示    - {name: 密封形式}    - {name: 保持架材质} swap_rule:  min_score: 0.88  require_manual_confirm: true  warn_on: [密封形式不一致, 保持架材质不一致]

案例片段（已脱敏）：参数抽取质量的一次批次复盘记录。

batch=2026-XX-XX-P07  source=brand_pdf_scan  total=4820 extracted_ok=4143 (85.9%)  low_conf=531 (11.0%)  failed=146 (3.0%) top_fail_reason:  1. 表格跨页断裂          62  2. 单位缺失无法归一      41  3. 型号列与参数列错位    28  4. 图片型样本无文本层    15 action: 跨页表格合并规则上线后重跑，extracted_ok 升至 91.4%

四、效果数据

系统上线运行了五个多月，客户那边给了几组数字。

选型准确率从原来的百分之八十三点五提到百分之九十六点八。这个口径是按"客户签收后三十天内未因选型问题退货"算的。因选型错误产生的退货金额同比降了七成二。

报价响应时长的变化最直观。原来一个非常规型号的询价平均要一小时四十分钟才能报出去，现在标准品在商城里客户自助就完成了，需要业务员介入的非标询价平均十八分钟。业务员日均处理询价从十一单涨到三十四单，人没加。

缺货率从百分之九点三降到百分之三点一。降下来主要靠两块，一是多仓统一可见之后，原来 A 仓缺货就报缺货的情况没了，能调 B 仓；二是缺货替代推荐让一部分订单转化成了替代型号成交，这部分占月订单量的百分之六点四。

整体退货率从百分之四点一降到百分之一点三。死 SKU 被激活了一部分，原来二十四万零动销的 SKU，五个月里有三万一千多个产生了首单，主要来自参数化选型的长尾曝光。

参数库这边，三十二万 SKU 现在结构化完整度达到百分之九十四点七，剩下五个多点是确实找不到资料的老旧型号，客户决定逐步下架。

文中数据为项目复盘口径，已做脱敏处理。

五、可复用经验总结

回头看这个项目，最值钱的不是选型算法，是那份类目参数字典。算法可以换，模型可以升级，但字典一旦定错，后面全是返工。我们在字典上花了两周，当时觉得慢，现在觉得应该再花一周。定字典这件事必须客户的技术工程师深度参与，光靠我们和大模型是定不出来的，因为里面很多是行业约定俗成的东西，写在任何文档上都找不到。

参数抽取别指望一步到位。我们最初的方案是全自动，抽完直接入库，跑了一周发现脏数据往下游扩散，选型结果开始出错，赶紧回滚。后来加的人工复核队列虽然增加了运营成本，但它同时也是模型的标注来源，客户技术团队复核的结果回流之后，模型准确率每个月还在往上走一点。这个闭环是这个项目里我觉得设计得最对的一处。

替代推荐这类涉及钱和责任的功能，一定要留人工确认。技术上完全可以做成自动替换，我们也确实做出来过，但内部评审时被否了。理由很实在：万一替代件出问题，责任在谁说不清。加了确认按钮之后转化率其实没降多少，客户反而觉得踏实。

库存一致性的方案不必追求理论完美。我们那套分级处理在架构评审时被吐槽过不够干净，但它解决了实际问题。工业品这种客单价高、订单频次不算特别高的场景，允许在少数临界情况下多做一次实时查询，代价可以接受。

这个项目现在还在持续做参数补全，客户技术团队每周处理三千条左右的复核队列。下一阶段他们想把选型能力开放给下游经销商用，这块的权限和价格隔离还得再设计一轮。