很多机器视觉项目，算法明明已经能跑了，但就是交付不了。

现场最常见的情况是这样的：

客户说：

“这个怎么没检出来？”

工程师说：

“这个算边界样本，不一定该判不良。”

客户又说：

“这个肯定不能流出去。”

供应商再说：

“可之前给的样本里，这种情况是算合格的。”

说来说去，最后就变成了扯皮。

表面上看，大家在争算法准不准。 实际上，争的是一件更基础的事：

到底什么算合格，什么算不合格？

这个问题如果一开始没说清楚，后面算法怎么调都会很被动。

很多项目不是算法不行，而是标准没讲清楚

机器视觉不是凭感觉判断，它本质上是在执行标准。

可是很多项目最麻烦的地方就在于，标准一开始是模糊的。

明显的好品，大家都没意见。 明显的坏品，大家也没意见。

真正容易出问题的，是那些卡在中间的样本。

比如轻微划痕、浅压痕、小毛刺、局部反光、轻微脏污。

看起来有点问题，但又不是特别严重。

现场人员可能觉得能接受，质检人员可能觉得不能放。客户可能今天说可以，明天又说不行。

这种样本，就是边界样本。

边界样本不定清，后面一定会反复吵

边界样本如果不提前定义清楚，后面一定会出问题。

因为算法不是人，它不能理解这些话：

“差不多就行。”

“这个看情况。”

“这个最好别有。”

“这个偶尔可以接受。”

你不给它一个明确边界，它就只能按数据和规则去判断。

结果就是：

客户觉得算法漏检。 工程师觉得客户临时改标准。 客户觉得供应商能力不行。 供应商觉得客户标准一直在变。

最后项目不是卡在技术上，而是卡在沟通和标准上。

限度样本，其实就是提前把话说清楚

所以限度样本非常重要。

限度样本说白了，就是大家提前坐下来，把那些最容易吵架的样本拿出来，一张一张确认：

这个算合格吗？

这个必须判不良吗？

这个程度还能接受吗？

再严重一点是不是就不行了？

这些样本一旦确认下来，就相当于给视觉系统划了一条线。

这条线不是只给算法看的，也是给客户、供应商、现场和质检一起看的。

没有限度样本，后面就是凭感觉说话。 有了限度样本，后面才有依据可讲。

不做限度样本，后面就是反复补锅

很多项目一开始不愿意花时间做这件事，觉得先把算法跑起来再说。

结果后面验收时才发现，真正麻烦的不是模型训练，而是大家对“合格”的理解根本不一样。

然后就开始反复改。

今天客户说这个要检出来，工程师加规则。 明天误检多了，又要放宽。 后天换一批料，边界又变了。

最后软件里堆了一堆参数，系统越来越复杂，项目却越来越难交付。

这时候你会发现：

大家以为自己在调算法，其实一直在补前面没定清楚的标准。

成熟的视觉项目，一定会提前定样本边界

成熟一点的机器视觉项目，一定会提前做限度样本。

不是等到验收吵起来了再说，而是在项目初期就把样本边界定下来。

哪些是明确合格，哪些是明确不良，哪些是容易争议的边界样本，都要尽量提前确认。

尤其是那些客户最在意、现场最容易波动、算法最容易误判的样本，更应该拿出来讨论清楚。

因为视觉项目真正难的，有时候不是把缺陷检出来，而是先让所有人承认：

这个东西，到底算不算缺陷。

限度样本不是形式，而是交付依据

算法可以优化，但它不能替人定义标准。

限度样本的价值就在这里。

它不是简单摆几件样品，也不是走形式留档，而是把模糊的口头要求，变成大家都认可的判断依据。

没有这个依据，算法再强，后面也很容易被质疑。

有了这个依据，工程师调算法才知道往哪里调，客户验收也知道按什么验，现场出了争议也有东西可以对照。

所以机器视觉项目里，限度样本不是可有可无的小事。

它往往直接决定项目后面是顺利交付，还是反复扯皮。

血泪教训

很多时候，项目卡住不是因为算法不行，而是因为一开始没人把“什么算合格”讲清楚。

如果你做过视觉项目，应该很容易理解这种情况：

最累的不是调参数，而是每次标准变来变去。

最怕的也不是缺陷难检，而是今天说可以，明天又说不行。

所以，机器视觉项目别只盯着算法。