试产线跑通的方案，为什么量产失灵

用试产线做试点验证本身是正确的做法：产量小、调整方便、出问题影响可控。问题出在从试产线搬到量产线的时候——很多方案在试产线上跑得很好，一上量产线表现就明显下滑，而这种下滑往往被归因为「算法不行」，实际原因通常有五个，而且都不在算法里。识别这些差异，并在试点阶段就刻意模拟一部分，能让扩展时少走一次弯路。

五个真实差异

这五条里，最容易被低估的是「小概率事件」。试产线跑几百件，某种异常可能一次都没出现过；量产线跑几十万件，同一异常几乎必然发生。如果阈值是按「试产阶段的样本范围内不出错」来设的，那么它在量产条件下就一定会被触发，而且往往是在最不方便的时候。正确的设定方式是把阈值定在「能覆盖正常波动并留有余量」，而不是「刚好卡住试产时观察到的范围」。余量留小了，量产时误报会多；留太大，漏报会增加。这个平衡在做试点时就应该和工艺一起讨论，因为量产时通常没时间再讨论。

扩展前必须补做的一次验证

从试点扩展到整线之前，建议做一次按量产条件的验证，内容至少包括：用真实量产物料连续跑一个完整班次以上、覆盖不同班次与不同操作员、在真实的车间环境（而不是试制区）中运行、并按量产的节拍要求衡量报警处理是否来得及。这次验证的结论应当形成书面记录，包括统计到的误报频次、出现的异常类型、以及为适配量产所做的参数调整。它的价值不只是确认方案可行，更是在扩展决策时提供依据——如果这次验证显示误报频次偏高，那么结论可能是「先扩大试点范围再观望」，而不是直接铺到整线。扩展节奏的判断，可以参考试点成功却扩展失败。

组织上的差异同样重要

还有一层差异不在技术上。试点阶段通常有供应商工程师常驻，遇到问题当场解决；进入量产之后，服务方式会变成远程支持加定期巡检，现场需要自己处理大部分日常问题。如果现场没有培养起最基本的操作与判断能力——比如知道怎么区分是误报还是真问题、知道镜头脏了怎么清、知道什么情况下该找谁——那么系统在量产环境下的可用性会很快下降。因此在试点阶段就应当把知识转移做实：让现场人员参与安装与调试、留下简明的操作与维护说明、并做一次实际演练。这部分内容在服务与响应约定中有更具体的建议。

如果已经在量产线上失灵了

补救的顺序建议是：先取一段量产条件下的数据，按班次、批次、时段分组统计，确认问题是集中在某个条件下还是整体退化。如果集中在特定条件（比如某个批次、某个班次），说明是条件覆盖不足，补充相应样本或针对性调整即可；如果整体退化且图像本身变差了，先查环境与硬件（清洁、照明、支架、温度）；只有在确认图像正常而判定系统性偏移时，才考虑重新训练模型。这个顺序能避免用最贵的手段去解决最便宜的问题，具体判断依据见模型漂移与再标定。