设备售后 App 增加“拍照找配件”，从识别零件到下单能走多远？
拍照找配件最适合做“候选缩小器”，不适合单独充当配件主数据或自动下单依据。可靠的设备售后 App 应先通过设备序列号、型号、版本和服务合同限定范围，再用照片返回少量候选，由现场人员核对关键特征；确认后生成服务单、询价或订单草稿。只有条码、铭牌或唯一结构特征已经给出确定证据时，系统才应减少人工步骤。
先区分“看起来像”与“就是这个料号”
工业配件常出现外观相似但规格不同的情形：同一外壳可能对应不同电压、接口、固件或左右方向；旧料号可能已被新料替代；已经安装或磨损的零件还可能缺少包装和标签。一张照片可以帮助检索相似对象，却不能天然证明兼容设备、可销售地区、数量单位和当前替代关系。
TRUMPF 的官方对象识别说明展示了一条真实可用的路径：用户拍摄零件，系统建议相应物料号，用户选择正确零件，再进入配件问题的服务单；其识别依据是持续扩充的 TRUMPF 数据库。页面也明确了移动设备、网络和 MyTRUMPF 账号等使用条件，直接下单只在支持相应 E-Shop 的国家可用。这说明视觉识别可以显著减少查目录的时间，但确认、服务流程与交易条件仍是产品的一部分。
Google Cloud 的视觉商品搜索文档则说明了底层机制的一个通用形态：一个商品由多个视角的参考图片描述，查询图片返回按视觉和语义相似度排序的候选列表。它支持“找相似候选”的设计判断，但不能证明某个通用服务已经理解企业自己的配件兼容、替代料和库存规则。
哪些情况值得做，哪些先用更简单的方法
| 现场情况 | 首选方式 | 原因 |
|---|---|---|
| 条码、二维码或清晰料号仍可读 | 扫码或 OCR | 标识比外观更接近确定身份，成本也更低 |
| 零件已安装、磨损或没有包装 | 图片候选检索 | 照片能缩小范围，但应保留人工确认 |
| 多个版本外观几乎相同 | 设备序列号＋BOM/兼容表 | 视觉结果不足以区分安全或电气差异 |
| 现场只想问“这是什么、能否替换” | 图片＋服务单 | 先把照片、设备和问题交给配件专员判断 |
| 高频、标准化且误发成本可控 | 组合识别后生成订单草稿 | 可以减少录入，但仍需要价格、库存和收货确认 |
如果配件种类少、查询频率低，或者主数据连料号和图片都不完整，先改善目录、铭牌、扫码和客服查询通常更划算。不能因为模型能在演示照片中认出一个零件，就直接立项完整 AI 系统。
一条可靠链路需要六步
1. 先锁定设备，而不是先打开相机
让用户从已绑定设备、序列号、工单或扫码入口进入。系统先取得设备型号、出厂配置、安装位置、客户权限和当前服务状态，再把图片检索限制在可能适配的配件范围内。若设备身份未知，结果应显著标为待确认。
2. 引导拍到可区分的特征
界面应提示角度、距离、光线和需要补拍的铭牌、接口、孔位或整体位置。保存原图时记录拍摄人、时间、设备和工单，但不要把客户现场、人员或无关文件永久留在训练资料中。低清、遮挡或多零件同框时应主动要求重拍，而不是给出看似精确的答案。
3. 返回候选，不伪装成唯一答案
结果页至少展示候选料号、名称、关键差异、参考图和置信信息。置信分数只表示模型在当前数据和阈值下的判断，不等于兼容概率。高风险或相似件多的类别可以只显示前三个候选或直接转人工，不用统一阈值覆盖全部零件。
4. 用业务规则完成兼容性核对
图片候选进入正式目录后，再核对设备型号、BOM 版本、序列号区间、左右件、尺寸、电气参数、区域、停售状态和替代料链。视觉模型负责“可能是哪一个”，配件主数据负责“能不能装、应该买哪一个”。如果两个来源冲突，应停止自动推进并显示冲突原因。
5. 把人工确认设计成可学习的动作
现场人员或配件专员可以确认、改选、标记无法判断并补充原因。系统保存候选、最终选择和关键证据，用于发现照片规范、目录资料或模型的薄弱类别；不能把每次人工改选不经审核地直接写回训练集。
6. 先生成草稿，再逐步开放交易
第一版更适合生成服务单、询价或购物车草稿，并让用户确认数量、价格、交期、收货地址和旧件退回要求。只有识别、兼容、价格和库存都来自可验证数据，且错误订单能够拦截和撤销时，才考虑减少确认步骤。
这条链路应与设备制造企业怎样连接报修、配件与维保合同放在同一套售后数据中设计，而不是另建一个只会返回图片标签的孤立工具。
数据准备决定项目上限
首期数据至少包括四类：
- 配件主数据： 稳定料号、名称、规格、单位、状态和替代关系；
- 设备关系： 型号、序列号区间、BOM/配置版本、适配与禁配条件；
- 参考图片： 多角度、已安装、磨损、不同光线和容易混淆的反例，并记录图片权利与来源；
- 业务结果： 人工最终选择、退换原因、错发记录和无法识别原因。
训练集和测试集还要按实际时间、设备或批次隔离，避免同一零件的近似照片同时出现在两边，造成结果虚高。新品、替代料和包装变化需要版本化更新；删除或停售配件也必须从检索、缓存和推荐中一致退出。
验收不要只报一个“准确率”
AWS 的自定义标签评测文档把预测区分为真阳性、假阳性和假阴性，并按标签提供 precision、recall 与 F1；它也说明提高置信阈值通常会提高 precision、降低 recall。对配件识别，这个取舍必须按业务后果决定，而不是采用模型默认值。
建议至少按配件类别、设备型号和拍摄条件分别记录：
- 第一候选正确率与前三候选命中率；
- 错把不兼容件列为可用的严重错误数；
- 无结果、要求重拍和转人工的比例；
- 从拍照到确认候选、建立服务单或订单草稿的时间；
- 人工改选、订单撤销、错发和退换原因；
- 新料号加入后到可检索的时间，以及旧料停用后的清除结果。
如果错误配件可能损坏设备或带来安全风险，优先压低假阳性，并让不确定结果转人工；如果用途只是帮助客服快速列出候选，前三候选覆盖和人工节省时间可能更重要。具体门槛必须用企业自己的代表性样本确定，不能把云服务示例值当作上线承诺。
常见误区
“模型置信度高，就可以自动下单。” 置信度来自视觉分类，不包含设备兼容、库存、价格和客户授权。
“拍得越多，模型自然越准。” 重复、单一角度或错误标注会放大偏差。新增图片应补充真实变化和难例，而不是只增加相似样本。
“识别失败都交给客服，所以不需要无结果设计。” 没有结构化原因，客服会重复查找，团队也无法判断应补图片、补主数据还是调整阈值。
“先做识别，后面再接配件系统。” 没有稳定料号、兼容关系和替代料链，识别结果无法安全进入询价、库存与订单流程。
负责人立项前要回答的七个问题
- 现场最难找的是哪些配件，当前每次查询要经过哪些人和资料？
- 条码、铭牌或设备序列号是否已经能解决大部分问题？
- 哪些外观相似件绝不能混淆，错误后果是什么？
- 配件主数据、BOM、替代料和库存由哪个系统负责？
- 图片来自哪里，是否有权用于训练、测试和长期保存？
- 结果只生成候选、服务单、询价还是订单草稿，谁做最终确认？
- 新品、停售、替代和现场纠错由谁持续维护并重新验收？
拍照识别真正的价值，不是让 App 看起来更智能，而是把现场人员从翻目录和描述零件的重复工作中解放出来，同时不牺牲配件身份与订单责任。首期若能稳定做到“限定设备—返回候选—人工确认—形成服务记录”，往往比追求完全自动下单更可用，也更容易验收。
参考来源
- TRUMPF：Object recognition，拍照建议物料号、用户确认、服务单与适用条件；访问于 2026-10-10。
- Google Cloud：Vision API Product Search documentation，参考图片、多个视角与排序候选的检索机制；访问于 2026-10-10。
- AWS：Metrics for evaluating your model，逐标签 precision、recall、F1 与阈值取舍；访问于 2026-10-10。