机器视觉产品化：参数分层、公差管理与复检数据反哺

机器视觉检测设备交付后，客户真正关心的不是算法，而是参数、公差与复检逻辑。本文从产品经理视角拆解：如何将算子翻译成产品语言、用三层用户与配方管理降低误操作、将公差视为商业条款，以及让复检数据反哺模型迭代。算法决定下限，产品化决定上限。

销售带客户来公司看 demo，客户在检测机前站了十分钟，问了一个问题：“你们这个，算法是自己写的吗？”

我说核心算子是自研的，一部分用了开源库封装。客户点点头，又摇摇头：“我不管谁写的，我就想知道，产线上的小伙子能不能用明白。”

这句话我记到现在。那天我意识到一件事：客户问的是算法，关心的却是产品。

这个系列前面两篇，（2）写了一条缺陷检测需求怎么从产线走到闭环，（3）写了设备怎么选型、POC 怎么跑。这一篇回到产品本身：一台机器视觉检测设备交付到产线之后，客户每天真正面对的是什么？

不是算法。是参数、公差和复检逻辑。

我拆过我们自己的检测软件，也拆过两三家同行的 demo，一个粗略但基本靠谱的观察：算法内核大概占整个系统两成的工作量，剩下八成，是配置、权限、配方、界面、数据这些“不像技术”的技术。而客户满意度的高低，几乎都落在这八成里。算法是发动机，产品是整辆车——发动机再好，方向盘搞得人看不懂，车还是没法上路。

下面按我自己踩坑的顺序，讲三件事：参数怎么暴露、公差怎么定、复检怎么收口。

一、先把“算子”翻译成产品语言

算法工程师跟我讲 blob 分析、边缘提取、模板匹配、频域滤波，客户跟我讲的永远是三句话：这个划痕能不能检？最小能检多小？换了产品还准吗？

中间的翻译工作，就是产品经理的活。

拿“划痕检测”举例。在算法侧，它可能是“灰度梯度 + 形态学 + 面积过滤”的一个组合；到了产品侧，它得变成一个检测项，挂在某个工位下面，带着自己的配置面板：相机用哪台、光源开哪个通道、检测区域框在哪里、判定阈值给多少、面积下限设多小。

这个面板上每一个字段，都是一个产品决策。

我早期犯过一个错：把算法参数原样暴露出去，阈值就是阈值，灰度就是灰度，当时觉得这样“专业”。结果客户的调试工程师自己把自己调崩了——阈值从 30 改到 80，检测画面里什么都不出来了，他分不清是光源没开对还是阈值改错了，一个电话打到售后。我们远程排查了半天，最后发现根本不是阈值的事：换型之后，检测区域还停留在上一个产品的位置上。

那一刻我明白了一件事：参数暴露多少，取决于用户是谁，而不是参数有多核心。

二、参数不能全给人看：三层用户和配方管理

一台检测设备在整个生命周期里会碰到三层人，这是我后来固化下来的产品设计前提：

算法/应用工程师：项目交付期进场，要看全部参数，阈值、滤波核大小、特征权重这些“内脏”都归他；

产线调试员：日常换型换料进场，只需要检测区域位置、检测项开关、灵敏度档位这几个“旋钮”；

产线操作工：三班倒，看大屏，只认两个结果——OK 和 NG，外加一个“换型”按钮。

三层人看到三个界面，本质是同一套参数的三层皮。谁看到不该看的参数，谁就是新的故障源。

“灵敏度”这个控件我想单独说一下。客户不爱听“阈值 0.35”，但他能听懂“灵敏度：低 / 中 / 高”。我们后来把五六个连续参数按产线实际工况收敛成三档，交付时工程师把三档背后的真实参数调好封死，界面上只留档位切换。上线之后相关客诉明显下降——不是算法变好了，是人不会再把参数调到不可理喻的位置。

再说换型。一条产线可能跑三五种产品，每种产品的检测区域、公差、光源参数都不一样。产品上必须有一个“配方”概念：A 型号一套参数包，B 型号一套参数包，切换产品等于加载配方，加载完自动提示“请放标准件试跑验证”。这话说出来好像理所当然，但我真见过没有配方管理的同行产品，换型靠 U 盘拷配置文件，有人拷错了批次，整晚误杀八百多件，第二天全数人工复判，产线主管差点掀桌子。

那八百件里其实没几个真缺陷。全是参数问题，不是算法问题。

三、公差不是算法参数，是商业条款

检测的判定从来不是“有没有缺陷”，而是“多宽、多深、多大算缺陷”。这条线划在哪里，技术上说是个阈值，商业上说是个责任边界。

我谈需求时必问三个数：

尺寸公差。客户图纸上的公差带，检测判定必须跟图纸对齐，不能自作主张收紧。我见过有设备商为了让验收数据好看，把判定偷偷收紧了 10%，结果过杀率飙到 8%，产线复检人手直接翻倍，客户收货时把这笔账算得清清楚楚，最后拒收。

面积和深度下限。小于多少的瑕疵放行，这个数必须由客户质量部门签字确认，写进验收报告。因为今天放行的一个 0.02 平方毫米的针孔，明天到了下游整机厂那里可能就是退货理由。这个锅谁来背，必须在合同阶段就说清楚，而产品要做的，是让这个数字在界面上有唯一、明确、可追溯的出处。

NG 分级。致命 / 严重 / 轻微，三档对应三种处置——剔除、复检、放行。分级是客户质量体系的语言，检测产品必须原生支持，而不是吐一个统一的 NG 让产线自己猜。

漏检和过杀这对矛盾，客户嘴上都说“我们要求零漏检”，实际谈判的从来是过杀率上限。因为漏检是概率性风险，过杀是每天真金白银花出去的复检工时。我的经验值：过杀率压在 2% 以内，复检工位一个人盯得过来；一旦冲到 5%，就得配两到三个人，客户很快会开始算账——这台设备省下来的目检人力，是不是又填进复检里去了？

所以这一节我的结论是：公差界面上的每一个数字背后都是责任划分，要把它当合同条款来设计，而不是算法的附带参数。

四、复检是过杀的出水口，也是数据的进水口

上面说了，过杀不可能压到零。那被误杀的好件从哪里回到产线？这是复检逻辑要解的问题。

我们踩过的坑很典型：第一版产品只有“剔除”一种处置。客户问，剔掉的件去哪了？现场是操作工拿个料筐接着，攒满一筐端给质检员，质检员在普通办公电脑上打开图片一张张看——没有放大镜、没有缺陷高亮、没有键盘快捷键，一天看两千张，看到最后全凭手感放行。

我去现场看过一次，回来的路上就把复判界面写进了下一版需求池。

复判界面这个东西，做起来琐碎，价值极大：

缺陷区域自动框选，质检员不用自己在图上找茬；滚轮放大到像素级，看边缘形态判断真伤还是脏污；键盘三个键，放行 / 报废 / 待定，手不离键盘，一天下来手速就是产能；每一次人工判定，连图带结果落库。

最后一条是重点。人工复判的每一次纠错，都是一条免费的标注样本：设备判 NG、人工说放行，这是一条过杀样本；设备判 NG、人工确认报废，这是一条确认缺陷样本。这些数据按缺陷类型攒起来，就是下一轮模型迭代最值钱的训练集。

很多工厂检测设备跑了三五年，几万条判定记录就躺在本地数据库里没人碰过。等于守着金矿在要饭。

这些数据怎么从“躺着”变成“反哺”——喂给模型迭代、喂给 SPC 控制图、往回追工艺参数——我打算放到（5）篇展开，这里先埋个线头。

五、算法决定下限，产品化决定上限

写到这里可以收总账了。

一台机器视觉检测设备，客户签合同之前看的是精度和节拍，用起来之后天天摸的是参数、配方和复判界面。算法决定这台设备的下限——检不出就是检不出，谁也糊弄不了；产品化决定上限——同样的算法内核，参数体系、权限分层、数据回流做得好不好，用起来是两个物种。

我现在的判断标准很简单：把算法内核抽掉，剩下的部分还值不值钱。值钱，说明这是个产品；不值钱，说明这只是个套了壳的算法 demo。

下一篇我接着这次埋的线头往下写：检测设备每天产生的海量判定数据，除了放行和剔除，还能反哺什么——训练集、SPC、工艺参数回溯。如果你在产线上被过杀折磨过，或者手里攒着几年的检测数据不知道怎么用，评论区聊聊，下一篇我把实操路径写出来。

（系列前篇：《我所了解的机器视觉检测产品应用（2）：一条缺陷检测需求的完整闭环》《（3）：设备选型与POC验证，检得出更要买得起》）

专栏作家

互联网产品经理Mik，公众号：逆袭产品汪，人人都是产品经理专栏作家。专注于ToB领域产品，包括机器视觉、工业大数据、MES、ERP和物联网等方面。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议