一次失败验收背后的“需求错配“ ：你以为买的是检测设备，到货的却是一堆视觉散件
前阵子遇到一个友商做失败的项目，很典型。客户一开始说要做"产品缺陷检测"。等到货验收那天，车间的人围着一堆相机、镜头、光源和一套软件发懵——他们要的是一台能直接上产线、自己上下料、自己判 OK/NG 的检测设备，到手的却是一盒"零件"。
▲ 客户想要的是左边的设备，供应商理解的是里面的核心视觉系统
先来复盘一下：错配是怎么发生的？
使用方，从头到尾没进场。
在很多机器视觉项目里，第一个掉链子的环节往往不是技术，而是对接。真正要用这套系统的人——车间的工艺、质量的工程师——从头到尾没出现在技术对接会上。需求从工艺口传到采购口，再由采购转述给供应商，中间隔了好几层。每一层都在用自己的语言重新翻译一遍，等传到供应商耳朵里，原始诉求早就变形了。
*问题：*需求经过多层转述，最容易被磨掉的是"使用场景"这个最关键的上下文。供应商拿到的不是"这个零件要怎么检，现场环境什么样"，而是"要一套检测方案"——一句话，信息量差了不止一个量级。
采购的 KPI，是压价。
采购部门有自己的考核逻辑。对很多采购来说，这个项目的核心诉求被压缩成一个关键词：控成本。于是方案范围被一刀刀砍到最小——能省的模块全省，能自己搞的都留给用户。这不是哪一家采购的问题，是角色决定的视角：他未必懂上下料要不要伺服，但他一定懂预算超了要担责。
*于是错位就发生了：*当"便宜"成为唯一被传递的信号，供应商自然会按"最小可交付"去理解。便宜本身不是错，错的是把"便宜"当成了对"交付边界"的完整描述。
供应商的理解，是真没偏差。
供应商接到的是一个被压扁的需求：交付"一套视觉解决方案"。在行业通用理解里，视觉方案 = 工控机 + 相机 + 镜头 + 光源 + 软件平台，不含机械结构、不含电气控制、不含运动控制。机架、传送、上下料、伺服——这些默认是用户自己搞定。供应商没觉得自己在偷工，他真的以为那就是你要的东西。
*所以呢：*这里没有坏人，只有错位。供应商按行业惯例交付，采购按预算交付，而真正的使用方，没人对接。
验收现场：为什么"视觉方案"不等于"AOI设备"
等到验收那天，冲突爆发了。使用方看到的，是一箱相机镜头、一套光源、一台装着软件的工控机。在他脑子里，这些东西应该长成一台 AOI 检测设备——能直接架到产线上，自动上料、自动定位、自动判 OK/NG、自动下料。眼前这堆散件，离"上产线"还差着一整个机械、电气、运动控制的身子。
一台完整的 AOI 检测设备，至少由四层构成：视觉算法层，负责"看"和"判"；机械结构层，负责机架、传送、定位；电气控制层，负责供电、IO、安全联锁；运动控制层，负责伺服、节拍、上下料。视觉方案，只是最上面那一层。虽然视觉系统是其中最核心、最关键的功能实现单元，但只有他，就像一辆车只有发动机一样，直接交到用户手里，他还是跑不起来。
▲ 一套典型视觉系统的构成示意图
把视觉方案当成整机交付，就像把发动机当成整车卖。发动机没错，但它跑不起来。
双方都觉得对方理解错了。使用方说"我要的是设备"；供应商说"你采购要的就是方案"。谁都没说谎，只是从来没在同一张纸上对齐过——"设备"和"方案"到底差了哪几块。
这类项目，通常是怎么被救回来的
以这类项目为例，真正能走通的挽救路径，通常不是推倒重来，而是先把话说清楚。
第一步，重新把三方拉到一张桌上——使用方、采购、供应商（或集成商），做一次需求冻结和范围确认。不是再来一轮讨论，是把"要交付什么"白纸黑字定死。
**第二步，划边界。**明确写下来：完整设备 = 视觉算法层 + 机械结构（机架 / 传送 / 定位）+ 电气控制 + 运动控制（伺服 / 节拍 / 上下料）。视觉方案只是其中一块，剩下的三块要么用户补，要么供应商补，不能留白。
**第三步，由具备总包能力的集成商（或视觉厂商作为 AI 视觉总包）补齐机械、电气、运动控制这三块短板，做二次开发和联调。**这一步最费钱也最费时，但躲不掉——早躲的，晚一点加倍还。
**第四步，重新定义验收标准。**不再用"看起来能用"这种模糊话，而是落到具体指标：节拍多少、良率多少、OK/NG 判准准确率多少、上下料连续跑多久不出错，甚至操作界面有哪些布局的要求，都要明确写下来。按指标验收，双方都有据可依。
*启示录：*挽救的代价，本可以在前期用一次三方对齐省下来。大多数翻车，不是技术不行，是前面省了沟通，后面拿钱补。
▲ 以视觉检测平台化软件为例——开发时需要功能越多越好，用户希望界面越简单越好，前面没沟通好，用户很难验收
给使用方：你要的到底是设备，还是模块
如果你的工厂要上视觉检测，几句话先想清楚：
需求必须让使用方进场。
让工艺和质量的人直接参与对接，别让采购一个人传话。他传不来的，恰恰是"检什么、怎么检、卡在哪"这些要命的细节。
写清你要的是"整机设备"还是"视觉方案"。
这两个东西的交付物、预算、周期，差着几倍。模糊写"做个检测"，最后只能被按头模糊验收，用不了，苦的还是自己。
验收标准前置。
在合同里就把节拍、良率、准确率写死，别等货到了再吵"这不算达标"。
给合理预算。
过低的价格一定会牺牲集成和兜底——省下来的那点钱，会变成你产线上没人负责的灰色地带。
先拿样件做 POC。
不确定能不能检、该做成模块还是整机？先送一批样件做可行性验证，跑通了再谈整线。这一步花得最少，踩坑最少。
给供应商：主动了解工艺提示缺口，不要只跟采购谈
反过来，如果你是这个项目的视觉供应商或集成商：
对接必须见终端用户。
只跟采购谈，你拿到的永远是压缩版需求。去现场，看零件，听工艺怎么描述问题，比看十份采购清单都管用。
交付边界白纸黑字。
哪些你做，哪些用户做，写进合同附件。口头说"这个你们自己搞吧"，验收时就是雷。
主动了解工艺，提示缺口。
当用户说"做成一台设备"但你只报了视觉方案时，第一时间把机械、电气、运动控制的缺口摆出来。别默认用户会做——大多数使用方真不会，他以为"买视觉"就是买整机。
用里程碑控风险。
把项目切成几个里程碑，每个里程碑单独验收、单独回款。这样哪怕前期理解有偏差，也能在早期暴露，不会等到最后一起炸。