先修路,再买车:为什么测试厂的AI排产瓶颈在数据采集而不在软件算法

引言

测试厂如今谈AI，谈的多半是"智能排产""动态调度""产能预测"。这些词听起来都指向算法。于是很自然的一种做法是：立项、招标，让IT部门或供应商开发一套AI排产软件，期待它把设备利用率提上去。

这件事情做到后面的结果大概率是：软件做出来了，能跑，界面不差，但给出的排产计划现场不认，用不起来。

原因不在算法。在AI迅速发展的今天，算法本身反而越来越容易借助AI来实现——约束规划、规则引擎、滚动时域优化、强化学习调度，这些过去需要专门团队啃上几个月的求解能力，如今获取门槛已大幅下降。真正稀缺的，是喂给算法的那一层基础数据——设备此刻到底在干什么、这批货卡在哪个环节、换线实际花了多久、腔体还剩几格可用。

现在的问题不是没有好车，这是次要矛盾；而是路还没修通，这才是主要矛盾。

一、把"路"这个比喻说完整

"路"不只是"有没有数据"。它至少包含四层，缺任何一层，车都跑不起来。

第一层：路要存在。 数据得先被采集出来。很多工厂以为自己有数据，实际有的只是"批次进出站记录"——某批货几点进站、几点出站、良率多少。这就像只知道一辆车几点进高速、几点出高速，中间的拥堵、停车、绕路一概不知。设备到底是"在测试""在换线""在等治具"还是"在等程序下载"，如果没被记录，这部分时间在系统里就等同于不存在，也就无从优化。

第二层：路要连通。 数据分散在不同系统，各管一段。MES管工单报工，EAP管设备连接，YMS管程序与良率，STDF归档管测试结果，可靠性实验室还有自己的台账。每个系统都真实，但每个都只有局部。孤立的真相拼不成全局的真相。

第三层：路要有统一标尺。 各系统时钟没对齐，连"谁先谁后"都判断不了。换线花了10分钟还是3分钟，设备是先报警还是先停机，差几秒就足以颠倒因果。基于错序数据算出的节拍、换线时间、OEE，都是看起来很精确的错数。

第四层：路要有护栏。 测试数据带着多家客户的机密，谁能看、何时必须隔离脱敏，这不是可以后补的功能。

算法是车，数据是路，标识统一是路标，时钟同步是刻度，权限隔离是护栏。

还有一样容易漏的——交通规则：什么算换线、什么算停机、利用率的分母是什么。它不是路也不是车，但没有它，路修好了车也跑不顺。这是第四章的主题。

二、为什么算法不再是瓶颈

第一，算法已经商品化。 排产问题在数学上是被研究了几十年的约束优化问题。商业求解器、开源优化库、调度框架都已成熟，中等规模的问题用现成工具就能做到相当不错的求解质量。算法能力的边际提升，对最终效果的贡献正在变小。

第二，算法的产出上限被输入锁死。 算法再聪明，也只能在给定输入上做优化。如果"换线时间"是拍脑袋填的经验值，"设备可用状态"是十分钟前的快照，"治具是否可用"根本不在数据里，那么算法输出的"最优解"就建立在一组虚假前提上。

这里有个不对称值得记住：算法越精密，对错误数据的放大能力越强。 粗糙的规则排产因为决策慢、粒度粗，错了影响也有限；精密的实时优化系统每秒都在基于错误数据做出自信的错误决策，而且因为它"看起来科学"，现场反而更不容易质疑。

第三，算法供应商同质化。 既然算法是成熟供给，各家在算法层面就不会有数量级差距。真正的差异来自谁能把现场数据接进来、接得准、接得实时。这恰恰买不来——它是工厂自己的资产。

三、数据成了瓶颈：四道墙

3.1 第一道墙：数据根本不存在

很多状态从未被采集过：设备细分状态（运行/空闲/等料/等治具/换型/阻塞/故障）往往没有，只有"亮灯"和"不亮灯"；换线的真实起止时间多数工厂从未结构化记录，排产用的是经验值；治具状态——Load Board寿命、Probe Card针次、老化板可用性——常躺在另一个系统甚至Excel里；可靠性实验室的腔体容量、电源通道数、温区占用，经常只在白板上。

这些不是"数据没打通"，而是"数据从未产生"。打通解决不了不存在的问题。

3.2 第二道墙：数据存在，但对不齐

标识不统一是最大的隐形障碍。同一台设备，MES里一个编号、EAP里另一个、设备台账里第三个；同一个测试程序，版本在不同系统里各说各话。没有一物一码的主数据体系，跨系统关联就只能靠模糊匹配和人工核对，既不准也不可持续。

粒度也不匹配。STDF是芯片级结果，颗粒极细、体量极大；排产要的是站点级、批次级状态。把海量测试值直接灌进业务系统只会把系统拖垮——它需要分层：高频遥测、业务事件、结果归档各走各的道。

3.3 第三道墙：数据对得齐，但不及时

轮询还是事件驱动，是实时性的分水岭。轮询是系统定时去问设备"你现在什么状态"，实时性被周期锁死，还产生大量无效请求；事件驱动是状态一变就主动上报，这才是近实时调度的基础。

很多工厂的"实时数据"其实是分钟级甚至批次级的延迟快照。用过期快照做实时排产，等于拿着昨天的地图在今天开车。

3.4 第四道墙：数据"存在"，但是人工喂出来的

这是3.1的另一面——人工喂的字段，本质上就是没被自动采集的字段。 单独列出来，是因为它比3.1更隐蔽：3.1一眼能看出"没数据"，这一类却常被误判为"我们已经有数据了"。

很多系统演示时非常漂亮：流程走得通、报表出得来、字段齐全、逻辑闭环。但往下追一层会发现，支撑这套自洽的关键字段，是靠人手填进去的——设备状态由班组长点选、换线时间事后补录、治具寿命从Excel导入（能从Excel直接导入的已算好的，更麻烦的是另一种：Excel里明明已经有一份，还要人再一个个敲进系统）、腔体占用靠白板拍照上传。

第一，它的自洽是界面层的，不是事实层的。 人工填的数据格式都对、数值都在合理区间，系统永远不会报错。它只是不一定是真的。空字段会触发警报，填错的字段不会。

第二，它记录的是"应该发生的"，不是"实际发生的"。 换线标准工时30分钟、实际47分钟，补录时人大概率填30或35——他填的是流程要求的，不是真实发生的。这种数据喂给AI，AI学到的就是标准工时本身，等于什么都没学，还白耗算力。

第三，数据一旦关联考核就会被污染。 没人故意造假，但人人都会下意识选对自己有利的记法——停机算设备故障还是算等待物料，边界模糊时答案取决于谁填。

第四，人工维护不具备扩展性。 一个人维护一个站点勉强可行，全厂几十台设备、几百个腔位，成本线性上升，人一流动就断档。

判断只需要一个问题：

这个字段如果没人填，系统自己会不会知道？

会，就是自动采集；不会，就是人工装饰。

它的精度上限是人的记忆精度，更新频率上限是人的空闲程度，真实性上限是填表人的利益立场。 三条标准，没有一条能满足工业决策的要求。

最糟的结果：为了上AI而批量造表

更糟的是下一步——为了强行推动AI排产，专门造一批表格让人填。

逻辑通常是这么走的：AI要上线，发现缺数据；缺数据怎么办？先做张表让现场填。于是出现一批看上去极其严谨的表：字段面面俱到、逻辑环环相扣、下拉选项一应俱全、审批一步不缺。评审会上人人点头，因为它确实"很有逻辑"。

然后它就开始失效。设备一分钟前刚换的状态，表里还是两小时前的；夜班没人填，白天批量补；换线没结束，时间先填了；忙的时候先干活，表攒到周末一起填。生产按分钟走，表格按班次甚至按周走——它永远追不上实际节奏。

于是就出现了那个画面：

一条坑洼破旧的土路上，几个人弓着身子，用绳子拉着一辆高级跑车在跑。

三层荒谬，值得逐层拆开。

第一层：跑车比走路还慢。 跑车的自重、轮胎、空气动力学套件，全是为在平整路面上被发动机驱动而优化的。改成人力牵引，这些"高级"配置全变成额外负担。越高级的系统对数据质量要求越高，人工维护负担就越重——精致的表格比粗糙的表格更难填，字段越多、校验越严、补录越痛苦。本来不填表还能干活，现在活没多干，表先填满。

第二层：拉车的人还得假装车在跑。 表填了、流程走了、报表出了、会上汇报了，所有人都表现得好像AI在运转。但实际没有发动机在驱动，只是被拖着移动。报表是齐全的，决策依然靠老师傅喊一嗓子。

第三层：土路还是那条土路。 人力全耗在拉车上，没有一分钱、一小时用在修路上。而且因为"车已经在跑了"，修路的紧迫性反而被消解——投入被占用，问题被掩盖，还顺手堵死了正解。

这类表格的本质：不产生任何新信息，只是把已发生的事实用人力重抄一遍。 现场已经实实在在发生过一次的事件，因为没被自动记录，就需要人再"重演"一次。纯粹的净损失。

还有一个隐蔽代价：它消耗的是最稀缺的资源。 填表的往往是班组长、工艺、设备这些最懂现场的人。他们的时间本该用在定义口径、判断异常、改进流程上——也就是本该修路的时间，现在用来拉车。最懂现场的人没空修路，路就永远修不好。

判断一项新增工作是修路还是拉车，只需一句：

这件事做完之后，数据的产生方式变了吗？

变了——从手填变成设备自动上报——就是修路。没变——只是多一张表、多一道审批、多一次录入——就是拉车。

四、被忽略的第三个要素：口径定义权

全文到此是"数据 vs 算法"的二分。但现场真正卡死的地方，常常是第三样东西——口径定义权。

4.1 有一类问题，既不是采集问题，也不是求解问题

换线从哪个动作开始算？从前一批最后一颗下料起算，还是从设备停机起算？停机算设备故障还是算等待物料？设备"可用"是通电就算，还是程序已加载、治具已就绪才算？利用率的分母是日历时间、计划开机时间，还是计划生产时间？

这些问题，采集系统答不了——它只负责记录；求解器也答不了——它只负责在给定定义上优化。中间"这个数叫什么"这一层，没人负责。

4.2 定义权本质是人和人的谈判

同一台设备停了20分钟，设备部记"设备故障"、制造部记"待料"、计划部记"计划停机"。三个部门都没错，因为"停机"这个词根本没有全厂统一的定义。

而且这不是技术问题，是利益问题：停机归谁，直接影响谁的绩效。所以口径定义权的争夺，和第六章的数据权力争夺，是同一场仗的两个战场。

判据很简单：同一个数字，两个部门算出来不一样，就是口径没定义。 这个现象在多少工厂是常态，就有多少工厂的AI项目建在流沙上。

4.3 定义不先行，采上来的都是合法但无用的数

这一点在审核里最常见：所有字段都填了、格式都对、校验全过，但拼出来的结论是错的，因为各部门对同一字段的理解不同。

自动采集也好、AI模型也好，都救不了这个。采集只会更快、更稳定地把口径冲突固化下来。定义错了，采集越自动化，错误固化得越牢固、越难回头改。

4.4 结论

原则只有三条：先定口径再建采集（采集是花钱的，口径是免费的，但口径错了采集的钱全白花）；口径必须有唯一仲裁人（协商永远达不成一致，得有被授权的层级拍板）；口径要带版本（定义一改，历史数据的可比性就断了）。

一句话：数据决定AI效果的天花板，算法决定你离天花板有多近，而口径决定这块天花板到底存不存在。

五、测试厂的路为什么格外难修

这不是管理不善，是结构性的。三条，各一段带过。

设备是多个年代采购的叠加。 同一厂里可能并存不同代的测试机、探针台、分选机，通信能力从以太网到串口、GPIB，还有只写日志不吐状态的"哑设备"。半导体行业虽有SECS/GEM这类通信标准提供共同框架，但标准允许厂商自定义状态变量和报警集合——统一了语法，没统一方言。加上大量老设备不在标准覆盖内，改造成本是实打实的。

各系统服务于不同目的，天然不关心彼此。 MES关心工单流转，YMS关心良率和程序版本，EAP关心设备控制。每个系统都把自己的事做对了，但没有一个系统对"全局实时状态"负责。这是分工的结果，不是谁的失职，也因此不可能靠升级某一个系统来解决。

实验室是路最烂的一段。

其一，它是项目制，不是流水式。 一个项目进来，样品数量、试验条件、设备组合、中间读点安排各不相同，几乎没有两个项目是一样的。这种高度非标，恰恰是AI最该发挥作用的地方——但要发挥作用，前提是每个项目的资源需求能被结构化地描述出来。

其二，约束是多维组合，不是单一设备占用。 排一个试验要同时满足：腔体容量、温区、电源通道数、老化板的板位与剩余寿命、样品封装与Socket是否匹配、读点时间窗、样品在预处理—试验—读数—失效分析之间的流转，以及失效分析资源本身。这是典型的多维装箱加时间窗问题，人工极难排好，AI极有价值——前提同样是这些约束得先变成数据。

其三，也是最致命的：设备杂、系统孤岛，最后全靠人搬。 实验室的设备类型远比FT段分散——温箱、老化炉、电源、X光、SAT、开封机、显微镜、推力拉力设备等等。它们要么根本没有数据接口（老设备和机械类设备尤甚），要么自带一套独立软件，自成一套台账与数据库，与外界不通。要用MES去管控实验室排产，最常见的做法就是让人把这些独立系统里的状态手工抄进MES。

这正是3.4所说的那种情况，而且是重灾区，于是实验室成了"人拉跑车"最集中的区域——部分设备本身具备结构化输出能力，但那份能力没有接进任何系统，人就在两个系统之间反复搬运同一批数字。

六、数据打通不只是技术问题，更是权力问题

只把它理解成技术工程，十有八九推不动。因为它同时是一次权力与利益的重新分配。

6.1 数据为什么等于权力

数据即解释权。 "这台设备为什么停了""这批货为什么延误"，答案取决于以谁的数据为准。打通意味着某个系统不再是唯一真相来源，权威性被稀释。

数据即考核权。 一旦自动采集且全厂透明，原来可以协商的数字变成硬数字，直接影响绩效。这是抵抗最强的来源。

数据即职责边界。 系统割裂往往已固化为部门地盘：MES归制造，EAP归设备，YMS归工程或质量。打通就要重新划界，而没有一个部门会主动缩小自己的边界。

数据即工作量。 收益在全厂，成本集中在具体部门——要盘点、要改流程、要配合联调、要背数据质量指标。成本集中、收益分散，理性的部门选择就是拖。

6.2 一个完美的拖延闭环

抵抗很少以"我不同意"出现，它通常以最正当的理由出现："这个数据不准。"

而它往往是对的。于是形成闭环：

因为数据不准，所以不能用 → 因为不能用，所以没人认真修 → 因为没人修，所以一直不准 → 因为一直不准，所以打通项目被判定为不成熟。

厉害之处在于，每一句话都是事实，每一步都合乎逻辑，最后结果是永远停在原地。 想打破它，不能靠证明"数据其实够准"，只能靠改变考核方式。

6.3 一个反直觉的现象：技术越容易，政治越难

技术障碍其实为拖延提供了正当理由。设备没接口、协议不开放、老设备改造成本高——客观、体面、无可指摘。

反过来说，技术上最容易打通的系统，往往最难打通。因为它没有技术借口可找，一推不动，剩下的解释就只剩利益，冲突会变得非常赤裸。

这也解释了那个奇怪现象：最难接的老设备反而接上了，最好接的现代化系统却迟迟推不动。

6.4 破解的方向

方法论层面只需明确两条原则。

其一，权责层级要对等。 让IT去协调平级部门交数据，本质是让没有权力的人去做需要权力的事。这件事必须由能够重新分配考核权和职责边界的层级牵头，否则技术能力再强也只能在部门墙外打转。

其二，激励方向要先调。 顺序不能反——如果考核口径不变，自动采集必然被抵抗，而且抵抗得有道理。可操作的方向是：先公开承认现有数据不可信，把考核暂时从结果数字转向改进动作，等基线可信后再恢复数字考核；同时让配合部门先从自己痛点上受益，用他们的需求换他们交出数据，比下命令有效得多。

此外，话要说得中性。"你们部门的数不准"会立刻激发防御；"现有数据口径在系统间不一致"是中性表述，更容易达成共识。政治问题要用非政治的语言谈。

七、修路本身就是回报最高的投资

修路要花钱，这也是项目常被砍掉的理由——它看起来是成本，不像买一套AI软件有明确交付物。

但这个看法把账算反了。

第一笔收益：让浪费现形。 当设备细分状态、换线时间、等待原因第一次被真实记录，几乎必然会发现一批此前看不见的损失：设备大量时间耗在等治具而非测试、换线比经验值长一倍、某台腔体长期半空载。看不见的损失，是永远不会被优化的损失。

第二笔收益：资本开支规避。 测试设备单价高，那么"把现有设备利用率提几个百分点从而少买一台"的账，远比"省几个人头"划算。实验室更是如此——腔体利用率哪怕只提5%，往往等价于少采购一台价值数百万的设备。

第三笔收益才是AI。 顺序不能颠倒：路修通了AI才有可用输入，而不是买了AI再指望它倒逼数据变好。后者几乎从未成功——AI项目有交付期限，数据治理没有，压力下必然是数据让步。

7.1 算例的结构

立项时不缺比喻，缺一个能填的数字。这个算例的结构极简：站点规模乘以利用率提升幅度，得到等效释放的产能台数；再乘以本厂设备实际采购单价，得到资本开支规避金额；与采集改造投入相比，即为回收期。

举例而言，某FT段有30台测试机，利用率从62%提到67%，等效释放约1.5台产能，按本厂该机型实际采购单价折算，即为可延后或取消的资本开支；再对照采集改造的投入，回收期可以直接算出来。

这里有三条口径必须守住：利用率的分母要先定死（第四章），否则提升前后的数字没有可比性；提升幅度不能抄行业经验值，只能来自本厂基线观测，没观测就先观测，不要倒推；单价必须用本厂最近一次实际采购价，行业均价是别人的账，厂长只对自家预算负责。

7.2 这笔账该怎么讲

用"产能投资"的语言，而不是"IT项目"。 前者对应资本开支规避和产能释放，有明确回报口径；后者是最容易被砍的预算科目。同样的钱，讲法不同，命运往往不同。

八、最常见的六种"先买车"错误

一、先买昂贵的APS授权。 排产软件的前提是产能、约束、状态可信。数据不可信时，它只会更快地输出错误方案。

二、先建数字大屏。 没有可信的实时事件源，大屏播的就是美化过的延迟数据。危害不只是没用，而是制造"已经数字化了"的错觉，让真正的采集改造被继续搁置。

三、先建大而全的数据中台。 场景没跑通之前建中台，容易变成高成本、低复用的平台——管道建好了，却不知道往哪里输水。

四、先做定制化深度学习模型。 在质量未经治理的数据上训练复杂模型，学出来的主要是噪声。

五、以为打通是技术任务，交给IT或供应商。 跨部门整合本质是权力调整，没有厂级授权，技术团队只能在部门墙外打转。

六、用人工表格填补数据缺口。 常被包装成"过渡方案""先跑起来再说"。过渡方案不设退出期限，就会变成永久方案。

共同点是：它们都产出了看得见的东西，所以容易通过立项；修路的产出是"数据变准了"，看不见，所以容易被推迟。

九、推进的顺序原则

方法论层面，需要恪守的只有四条顺序。

其一，先定口径，再采集，再优化。 口径是免费的，先谈定；然后把真实节拍、换线时长、停机原因、OEE连续观测三到六个月形成可信基线；这一步不产出"智能"，但决定后面所有智能的可靠性。跳过它直接上AI，等于在没有地基的地方盖楼。

其二，先做样板间，再全厂推广。 选一个瓶颈最痛的场景打通从采集到优化的完整闭环。全厂一次性铺开失败率极高，因为各站点数据状况差异很大，统一方案必然在某个环节失速。样板间的价值不只是验证技术，更是建立组织信任。

其三，工程定义、IT实现、共担质量。 IT擅长建管道，但"这台设备算故障还是算等待""换线从哪个动作起算"，只有制造和工程答得出来。把这件事当成IT项目，最常见的结局是管道建好了，里面流的是错的数据。

其四，护栏与路同步建。 客户数据隔离与脱敏必须前置设计。测试厂同时服务多家客户，程序与结果都是机密，这套权限不在地基阶段装好，后期补的代价远高于一次建对——今天买的设备就是十年后要改造的老设备，采购合同里写清数据接口要求，是成本最低的一次修路。

还有一条可以立刻执行而不需要预算：投任何算法之前，先盘一遍关键字段哪些是人填的。用 3.4 那条标准筛一遍，优先级清单当场就有。自动采集一个关键字段，比训练十个模型的价值都高。

最后，立项文件里除技术方案外，还要写清政治账：涉及哪些部门、谁的考核口径会变、谁要额外投入工作量、他们能得到什么。技术问题写不清项目会失败，政治问题写不清项目根本启动不了。

结论

测试厂推进AI排产，真正的顺序是：

先修路，路通了再买车；而修路的钱，本质上是省下来的买设备钱。