搞了近十年生产制造相关的系统实施和优化我有个越来越强烈的感觉凡是把“智能排产”当作AI项目来立项的大概率会走一段弯路凡是先把排产本身吃透、再回头把AI当工具用上去的反而更容易出效果。这话听起来像绕口令但几乎每个失败案例都能归结成同一句话——排产的复杂度根本不在AI而在排产。这个标题我已经用了很多年每次给企业做分享也会翻来覆去讲AI排产核心是排产不是AI。不是因为AI不重要而是排产问题本身的抽象程度、数据要求、规则复杂度远超大多数决策者最初的想象。你不把排产这件事先想清楚再强的模型扔进去也只是在错误的地图上开导航。1. 先拆掉“AI排产”这顶帽子失败项目教我的第一课1.1 一个“算法豪华但进不了车间”的项目复盘前年我以顾问身份参与过一条汽车零部件产线的智能排产改造。团队配置很体面算法工程师三位数据科学家一位仿真环境也搭得漂漂亮亮甚至用主流的开源求解器跑出了阶段性结果。项目汇报的时候高管看到甘特图上一片整齐的色块觉得这事快成了。但真正上线时问题一个接一个。业务侧交上来的工单数据里将近20%的工序与工艺路线对不上10%的工时数据是空的还有几十条老产品压根没有维护工艺路线。算法工程师花在清洗数据和对齐规则上的时间远远超过了训练和调模型的时间。最讽刺的是等到项目临近验收车间排产员又回到了Excel手动排产。为什么因为算法一直在跑但没人告诉它“哪些工单必须插单”“哪个模具正在维修”“夜班哪些岗位没人盯”。算法给出的计划很“数学正确”但进不了车间。后来我硬是让团队停下手里的模型先花两周把手动排产逻辑完整梳理出来定义清楚优先级规则再让算法按这个框架跑结果反而第一次被老师傅接受了。这个项目让我定了条规矩任何排产项目启动时先别聊AI模型选型先聊数据现状和业务规则清单。这些没定算法就是空中楼阁。1.2 排产是组合优化不是模式学习很多企业管理者对AI的认知来自图像识别、语音助手、大模型对话这类应用。这些场景的本质是“模式识别”和“内容生成”——给模型足够多的样本它就能学会找规律。但排产这件事完全不是这个逻辑。排产要回答的不是“图片里是猫还是狗”而是A订单和B订单谁先上B产品在C设备上加工需要多久D模具晚上能不能装上夜班有没有具备资格的操作员盯这台机器几点开始、几点结束、中间穿插哪张换型单最划算这是一个典型的离散组合优化问题在成千上万种可行排序里找到同时满足所有约束、且目标函数尽可能优的一个方案。它和运筹学的关系比和大模型的关系近得多。深度学习当然可以在局部环节发挥作用比如预测设备故障、估计工时、识别异常工况但直接让神经网络端到端输出一套排产方案目前在工业现场还没有普适的成熟路径。换句话说别指望AI“一学就会”。排产的本质是搜索和决策哪怕用最简单的规则引擎只要业务规则梳理到位效果往往都会比一个不接地气的AI算法好。2. 把排产问题翻译成数学模型前先摸清三类业务骨架2.1 离散制造、流程制造、流水线制造同叫排产约束结构完全不同很多项目一上来就套算法框架这是最大的误区。不同制造形态的排产根本是不同的问题结构。离散制造比如机加工、电子装配、机械装备特征是物料按BOM逐层加工装配工序多、路径分叉多、物料齐套影响大。这类排产的核心变量是“工序在哪个设备上做”“哪一刻开始”要重点考虑等待时间、搬运时间、齐套时间。流程制造比如化工、涂料、食品饮料特征是物料在连续产线里走批次一旦开始就不能随便中断清洗和换型时间往往很长。这类排产的核心变量变成“批次怎么混合”“清洗顺序怎么排”颜色切换、品种切换这些规则会成为模型里最重的约束。流水线制造介于两者之间节拍和工位平衡更重要。你得先搞清楚你的现场属于哪一种再决定决策变量的设计不然模型一开始就画错边界。2.2 时间颗粒度怎么定太细会指数爆炸太粗指导不了执行排产的时间颗粒度是建模中最容易拍脑袋的环节。有人习惯把时间设到秒级觉得越精细越好有人直接按天排结果排出来根本没法指导产线。我想强调一个原则时间颗粒度必须和瓶颈资源的实际加工周期匹配。如果一个工序动不动要几个小时那排到分钟级已经足够指导执行了如果瓶颈是十几秒一台的冲压机秒级才有意义。颗粒度越细组合空间膨胀得越厉害求解时间不可控反而得不偿失。我一般建议先找到瓶颈设备和瓶颈工序以它的最小加工时间或者最小换型单元作为时间基准。其他非瓶颈工序可以放宽到半天甚至一天。不要试图在同一个模型里对所有工序统一精度——那只会让算法做大量无用搜索还会把真正重要的约束给稀释了。2.3 隐性资源往往才是真正的瓶颈模具、工装、人员技能排产建模时大家习惯把设备产能当成唯一的稀缺资源。可实际上我见过太多案例真正的瓶颈根本不在设备而在模具、工装、刀具、人员技能这些“隐性资源”。举一个真实场景某装配车间的SMT贴片线并不紧张但后端的AOI检测只有一位高级质检员具备白班资格每天有效工时也就六个小时。如果模型里没有“人员技能”这个约束排产系统会把AOI当成无限产能来用排出来的计划到了白天必然积压晚班又没人能操作。隐性资源还包括同一模具在同一时刻只能装一台设备、特殊产品需要指定工装、某些工序只有特定班组能做、清洗和烘干环节占用时间但不占用设备号等等。这些约束必须在需求调研阶段逐条找出来落到数据表里否则算法怎么优化都是在优化一个与现场无关的简化模型。3. 排产算法的现实分工精确求解、元启发式和深度强化学习各管哪段3.1 约束规划和混合整数规划小规模精确最优的首选当问题规模不大、约束结构清晰时约束规划CP和混合整数规划MIP是最靠谱的选择。像Google OR-Tools里的CP-SAT、商业的Gurobi、开源的SCIP在实际项目里都很常见。这类求解器的优势是能证明最优性找到的解有质量保证。如果工序数量在几百以内约束清晰又有明确的优化目标它们基本就是天花板级别的工具。我在一些单车间、单瓶颈场景里用过效果非常干净甚至可以做到实时重排。但它的毛病也很明显随着工序数量、资源数量增加求解时间会指数级上升。有些问题一旦超过某个规模等它出结果的时间比人工排产还慢那就没有任何实际意义了。所以我的习惯是先估计问题规模如果预估超过求解器可接受的上限就直接跳到启发式方法。3.2 遗传算法这类元启发式工程中最耐用的“主力马”遗传算法、模拟退火、禁忌搜索这些元启发式方法在工业排产里被用了二十多年至今仍然稳稳占着主力位置。原因很简单它们不追求绝对最优而是在可接受的时间里给出足够好的近似解同时能灵活塞进各种五花八门的业务规则。遗传算法里最有讲究的是编码方式和适应度函数。一条染色体可以理解为一套完整的排产方案种群就是一批不同的方案。每一代通过选择、交叉、变异产生新方案适应度高的更容易留下来。适应度函数通常是目标函数加惩罚项def fitness(schedule): total_tardiness compute_tardiness(schedule) # 总延期 changeover_cost compute_changeovers(schedule) # 换型成本 soft_violation compute_soft_penalty(schedule) # 软约束违反 return -(total_tardiness changeover_cost soft_violation)实际做项目的时候我建议用EDD最早交期优先、SPT最短加工时间优先这些经典规则生成初始解让种群一开始就别太离谱。交叉变异也要针对排产场景定制比如用顺序交叉法保证基因里不出现重复订单再用局部搜索做修复否则很容易生成一堆不合法的排产方案。碰到几千上万道工序、设备超过几十台的大型车间元启发式仍然是工程上最稳妥的选项。它能做全局搜索又不像精确求解那样卡在“最优性证明”上。3.3 深度强化学习值得关注但别把注全压在上面深度强化学习DRL在学术paper里刷Job-shop基准测试很猛经常能跑出很漂亮的对比曲线。但我要诚实说一句在工业现场真正落地、稳定运行的核心排产逻辑里DRL的占比还很小。原因不是DRL本身不行而是工程代价太高。状态空间、动作空间、奖励函数这三个东西任何一个设计有偏差算法学的目标就和车间实际目标不一致。车间稍微改一条工艺路线模型往往就要重新训练。而且DRL输出的方案可解释性很弱计划员问“为什么这批先做、那批后做”系统答不上来信任感一旦崩塌后续就很难推进。我见过还不错的DRL应用基本都是拿它做局部决策比如在某个瓶颈设备前决定下一个加工哪个工件或者配合仿真环境做策略预演。它们和整体排产引擎是“合作关系”不是“替代关系”。如果你现在要启动一个排产项目我的建议很直白先把精确求解器和元启发式用好用透DRL可以放在实验室里继续养着等它能解释“为什么这么排”的时候再拉下车间的闸刀也不迟。4. 从“算出一版最优计划”到“车间愿意用”滚动重排机制才是胜负手4.1 静态最优解为什么在现场经常失效很多排产项目的验收标准是“算法能算出一个最优解”。但实际上车间运行从来不是稳定输入。设备故障、物料晚到、急单插队、人员请假、质检异常每天都在发生。静态最优解在这个环境下非常脆弱。你把未来五天的计划算得再漂亮三个小时后一台关键设备停机整个计划链就得重排。如果系统不具备快速响应和重排机制算法算出来再“优”对你来说也只是一张过期地图。我经常和客户讲一句话排产不是拍一张婚纱照而是开车时的实时导航。出发时的路线再合理中途一个路口封了导航必须能在几秒内给出新的路线同时尽量不推翻已经走过的行程。4.2 周期性重排与事件触发重排什么时候重新跑算法滚动排产是成熟APS的标配机制。我通常把它分为两类周期性重排和事件触发重排。周期性重排比较好理解。每两个小时、每个班次、或者每天固定跑一次全量算法基于最新的工单、库存、设备状态重新生成一版计划。周期越短计划越贴近现实但算法和数据的调用成本也越高。事件触发重排则针对异常情况插急单、设备宕机、物料短缺、人员缺勤任何一项发生系统就要判断是否值得触发一次重新计算。我建议设置一个“重排阈值”比如插单的影响超过当前计划中某个订单的交期风险才触发重排。否则频繁重排会让整个计划的稳定性变差——从系统角度看不差但车间执行端会疯掉。同时已经开始执行的工序一定要锁定。算法重排时只能调整未来尚未开工的部分已经做了一半的工单不要随意挪动。这既是尊重现场实际也是减少计划员的审校负担。4.3 差分调度与人工审查让计划员看到“这次改了什么”重排之后最容易出现的问题之一是算法把上一版计划改得面目全非。计划员打开甘特图满屏都是变动等于要重新审核全部内容很多人干脆就放弃新计划继续按旧计划走。解决这个问题必须做差分调度。系统重新排完后只高亮显示与上一版计划不同的部分并且明确标注变化类型哪些工序新增了、哪些顺延了、哪些提前了、哪些换线了。计划员只需要看差异清单就能快速判断新计划是否合理而不是从头到尾再核一遍。我见过不少项目的排产算法本身并不差但因为没有差分展示上线后计划员依旧默认用旧计划。后来加上差异高亮和变更理由说明使用率和异常处理速度同时明显提升。这个投入非常小但回报非常大。5. 排产项目的实施顺序和数据陷阱给后来者的几个建议5.1 不要跳过手工数字化直接上算法现在很多企业一谈排产就想上AI但连基础的MES数据都没打通。这个顺序我个人非常不推荐。我的建议是分四步走。第一步把全流程数字化工艺路线、BOM、设备台账、工单执行、物料库存都变成在线数据。第二步梳理标准工时和换型时间建好标准工时库。这是很多企业最容易卡壳的地方工时数据不准后面一切免谈。第三步先把现有手工排产规则固化用规则引擎做一个可运行的排产模块配合人工微调让车间先用起来这个过程主要是采集真实约束和校验数据。第四步等规则模块稳定运行再叠加遗传算法或其他优化算法做全局寻优。跳过前两步直接上算法基本等于在沼泽地上盖楼。5.2 主数据、工单状态和物料齐套三个最容易被低估的数据坑排产项目里干净数据是生命线。第一个坑是主数据。BOM不准、工艺路线缺失、工时虚高是三个最常见的主数据问题。做排产之前一定要先做一轮主数据专项治理哪怕只针对排产涉及的核心物料和核心机型都行。第二个坑是工单状态不准。很多MES系统里工单已经干完了但报工没点或者报工了但系统状态还是已下达。这种数据延迟会让排产算法拿到的是“已经过期的产能占用”结果自然离谱。第三个坑是物料齐套。这话说出来很多IT同事会觉得不以为然觉得系统里明明有库存数。但我实际调研过很多工厂的库存账和实物账对不上特别是工序间在制品的数量系统里几乎没有准确数据。物料齐套不解决排产算法排得再合理生产线照样会因为缺料而停下来。物料齐套这一环必须靠扫描验收和库存盘点把数据做实。5.3 把“解释能力”当成排产系统的一部分来设计经验丰富的计划员扫一眼甘特图就能看出方案合不合理。如果算法给出的顺序违反了他认定的安全边界他不会思考是不是自己经验过时了而是直接认定系统不靠谱。所以排产系统一定要有解释能力。无论用什么算法最终输出都必须能够回答为什么这批订单排在前边为什么不安排在当前设备上为什么这次重排把某道工序延迟了如果模型里维护了软约束优先级就要在界面上把这些优先级显示出来让计划员能追到“是交期压力、换型成本还是客户权重导致的排序变化”。我的一个习惯是算法输出的每个关键变更都附带一条可读的规则说明。哪怕只是给出“因为客户A的优先级高于客户B”或“因为换型时间缩短了两小时”都要让人看得懂。有了这层解释计划员才会把系统当队友而不是对手。说实话排产项目做到最后会发现真正决定成败的往往不是算法模型有多先进而是你对现场的理解和数据的基础有多扎实。我现在做任何项目都会先把“排产规则清单”和“主数据健康度报告”摆到桌面上再聊要不要上AI。排产理顺了AI是锦上添花排产没理顺算法只是大屏上的演示动画。