制造业 AI 项目为什么卡在 POC 之后:验收标准该怎么定

制造业的 AI 项目有个很常见的结局:POC 阶段演示得很漂亮,领导点头,预算批了,一年之后打开后台发现日活是零。

问题通常不在技术。真正让项目死掉的,是三件在 POC 阶段就已经埋下的事。

一、指标选错:演示指标不等于生产指标

POC 阶段最容易被选的指标是「准确率」。它在演示里最好看,也最没用。

原因很简单:POC 的测试样本是精挑过的。挑出来的样本里,光照正常、角度标准、单据清晰;而生产环境里,二成样本是手机拍的、反光的、折角的、手写潦草的。

一个在干净样本上做到 95% 的模型,到了真实产线上可能只有 78%。而现场的操作工不接受 78%——因为剩下 22% 要他来兜底,等于多了一份活。

二、数据边界没划清

POC 时用的数据,往往是「人工整理过的一小份」。真正上线要的是全量、增量、实时。

这三件事在 POC 阶段几乎不会暴露,因为量小。等上线了才发现:历史数据有 30% 的字段是空的,ERP 那边一天只同步一次,MES 的接口还限流。

所以做 POC 时,一定要用「没有清洗过的原始数据」跑一遍。难看,但是这个难看越早出现越好。

三、没有人接手

这是最常见也最隐蔽的一条。系统上线了,但改一个提示词要发邮件给供应商,加一份知识文档要等排期,看效果要供应商出报表。

这种情况下,业务部门用两周就会放弃——因为任何调整都太慢,慢到不如用回原来的 Excel。

能力没有留在客户这边,系统就只是一个更贵的摆设。

验收标准该怎么定:三层指标

一份能落地的验收标准,至少要有三层,缺一层就会留后患。

层级 回答什么问题 举例 谁来认
业务指标 这个岗位的工作发生了什么变化 单据录入岗日均处理量、平均响应时长、返工率 业务部门负责人
过程指标 系统在真实流量下的表现是否稳定 日均调用量、人工干预率、异常工单数 一线班组长
技术指标 技术底线是否守住 接口响应时间、可用性、数据不出域 IT / 信息中心

三层里最重要的是第一层。它必须是一个「基线值 → 目标值」的形式,比如「单据录入岗平均每天处理 180 单,上线后不低于 260 单」。没有基线值的指标,验收时一定会吵。

写进合同的四句话

  1. 验收以一个已经测过的基线值为起点,基线值由甲乙双方在项目启动会上共同确认并签字。
  2. 验收数据从生产系统取,不采用演示环境或人工构造的样本。
  3. 验收由使用该系统的业务岗位参与,不是只由 IT 部门签字。
  4. 交付包含能力移交:文档、源码或配置、培训,以及移交后客户方可独立完成的三项操作清单。

这四句话不涉及任何技术细节,但它们决定了这个项目最后是「上线」还是「上线然后死掉」。

一个简单的检验办法

如果你不确定验收标准定得对不对,把它念给一线的班组长听。

他能听懂、并且同意这就是他关心的东西——那这份标准是对的。他听不懂,或者听完说「这跟我没关系」——那这份标准是写给领导看的,不是给项目用的。

小结

制造业 AI 项目的失败,很少是算法不够好,多数是 POC 阶段就把「什么算成功」定义错了。

把指标定在业务上、把数据用真实的跑、把能力交到客户手里,这三件事做到了,剩下的才是技术问题。

关于具体怎么在两周内完成一次可信的验证,可以看2 周 POC 执行清单。