AI排产的核心是排产：约束梳理与数据治理才是成败关键

1. 项目背后的普遍痛点：排产不是AI炫技场

做过几个排产项目之后，我有一个越来越强的感受：很多号称AI排产的项目做不下去，不是因为AI不够强，而是因为没人先把“排产”这件事讲清楚。项目标题里这句话我很认同——ai排产，核心是排产，不是ai。它背后的潜台词是：如果生产现场的基础数据一塌糊涂、约束没有梳理清楚，就算把再大的模型接进来，出来的也是一张没人敢执行的漂亮计划表。

先说清楚这篇文章适合谁看。一种是正在做“智能工厂”或“APS高级排产”选型的车间主任、计划员、项目经理；另一种是准备接排产项目的算法工程师、软件开发团队。这两种人经常互相听不懂，前者觉得算法团队不懂现场，后者觉得业务方提的需求像打太极。这篇文章我想站在两者中间，把排产项目里真正决定成败的环节拆开讲，尤其是“为什么核心在排产、AI只是工具”这一层，以及如何按这个思路把项目一步步落地。

我见过太多项目翻车的常见剧情：业务负责人拿着一堆订单和机台清单，想在两周内让AI掏出每日生产计划，结果项目组一头扎进模型训练，每天开会都在讨论应该用强化学习还是大模型提示词。等到要上线了，才发现工艺路线还是Excel里的手工版本，工序工时有的精确到秒、有的干脆没填，连设备日历都没人维护。所以这篇文章不打算给你讲一个花哨的算法案例，而是老老实实复盘：一个不靠运气、能跑起来的AI排产项目，它的正确起点是什么。

1.1 排产这件事，到底在排什么

很多刚接触这个领域的人以为排产就是“把订单分配给机器，时间能排开就行”。真去车间蹲一个月，就会发现事情复杂得多。一个典型的离散制造排产问题，至少要回答四类问题：哪个订单先做、在哪台设备上做、用什么工艺路线做、在哪个时间段做。如果再往细里想，还要考虑模具、刀具、人员班组、物料齐套、设备切换时间、外协工序、质量检验节点，甚至不同车间物料的运输时间。

这些信息组合出来的解空间，规模和难度都不小。举一个相对简单的例子，一个中型机加工车间有30台设备、每天有40个在制订单，每个订单平均走8道工序，如果把每道工序分配到具体设备和时间段，可行方案的数量会膨胀到几乎无法全部枚举。这就是为什么排产值得用系统、用算法来做，而不是靠人拍脑袋。可问题也恰恰藏在这里：正因为现场情况复杂，任何一个环节的数据不准，算法再聪明也算不出可执行的答案。

我经常把排产比作拼拼图，但是一盒画着动态图案的拼图。机器产能是一块底板，订单是各种形状的积木，工艺路线规定了积木之间的先后咬合关系，物料、模具、人员则是你拼图时手里有限的辅助工具。AI能帮你尝试成千上万种摆放方式，但它必须先搞清楚每一块积木的尺寸和咬合规则。如果连形状都不对，AI跑得越快，错得越离谱。

1.2 为什么话要先说死：AI不是万能钥匙

现在市面上但凡带点自动化能力的东西，都爱往“AI排产”这个概念上靠。这里需要做一个特别重要的观念拆分：很多供应商口中的AI，其实指的是数学优化算法，比如遗传算法、禁忌搜索、约束求解、线性规划；而另一部分人说的AI，指的是机器学习或大模型应用。还有一种更常见的AI，其实是给传统规则加了一个漂亮的交互界面。

这三类“AI”在排产项目里扮演的角色完全不同。数学优化算法是真正的排产计算内核，它负责在约束下搜索可执行方案；机器学习更擅长处理预测类问题，比如预测工序工时、识别异常、动态修正参数；大模型则偏向对话交互、方案解释和报表生成，帮助计划员更快理解系统在做什么。如果把这些角色混为一谈，项目大概率会在需求阶段就埋下雷。业务方想要的是机器自动把计划排出来，算法团队却把预算花在了训练一个预测模型上，等于拿菜刀去拧螺丝，最后还要怪螺丝质量不好。

这个项目标题真正想说的，其实是“别被AI这个词带偏”。排产的内核是工程问题。只有先把产能模型、工艺约束、目标函数建好，AI才能在它该发挥的地方起作用。否则你很可能得到一套“包装得很智能”但实际上没人敢用的系统。

1.3 为什么先梳理排产业务，反而能更快落地

我曾经在项目启动会上听到计划主管说：“我们不要那些花架子，先把现有的人工排产方式做成系统的逻辑，跑顺了再说。”当时有工程师觉得这是保守，是不愿意拥抱新技术。后来我才意识到，这位主管说的才是排产项目最稳妥的推进路径。

人工排产的经验里，藏着大量有价值的业务规则。比如某个老计划员知道哪台老设备加工某种材料容易出问题，会自动把那类工序绕开；知道某一个供应商的交货不稳定，会给相关物料留出缓冲时间。这些规则未必写在标准作业指导书里，却是系统能不能被现场接受的关键。把老计划员脑子里的隐性规则，先翻译成系统可以识别的业务约束和软优先级，通常比盲目标榜AI算法能解决一切更实际。

所以这篇文章通篇想强调的核心是：AI排产项目在技术选型和模型搭建之前，最起码要把排产问题的边界摸清楚。你没有必要一开始就追求最先进的算法，先把数据模型建扎实、把人和机器的关系定义清楚，整个项目的成功率会提升一大截。下面我用实际做项目的顺序，把这条主线展开说。

2. 吃透排产问题：约束、目标与人工管理的逻辑

如果说AI排产项目的失败案例可以归类，那八成以上的根因都出在问题定义阶段。业务方描述需求时容易说“给我做一套自动排产”，但这是结果不是问题。真正要问的是：你现在怎么排？哪些单子是必须先排的？哪些设备不能同时用？一个晚上到底开几个班组？这些问题不逐条回答，系统设计就没有地基。

2.1 先拆硬约束，再谈软目标

把排产问题写清楚，我习惯先分两类：硬约束和软目标。硬约束是绝对不能违反的底线，比如一道工序必须依赖上一道工序完工后才能开始、一台设备同一时刻只能加工一件产品、某些模具有使用次数限制；一旦突破硬约束，计划落地时一定出乱子。软目标则是在多个可行方案之间比较优劣的指标，比如希望准时交付率高一点，希望设备切换次数少一点，希望各台设备负载均衡一点。

从项目沟通的角度，把硬约束和软目标拆开，能帮双方快速对齐预期。业务方如果说“这两个订单都必须今天完成”，那这是硬约束，你需要在系统里设置deadline并把它们作为排产前提。如果他说“尽量在交期前完成，实在不行差一两天也能接受”，那就当软目标，定时交付率作为优化指标来处理。如果一开始就把所有需求都设成硬约束，算法大概率找不到可行解，系统就会一直提示“无解”，现场看着就想砸电脑。

我在车间访谈时常用一个“约束清单模板”逼大家把所有限制条件写出来。第一列是约束类型，比如前置工序、资源占用、物料齐套、工艺参数；第二列是具体描述；第三列是这个约束的严格程度，分A、B、C三级，A级最不可违反。很多计划员能口头说出大量约束，但你要让他写下来、梳理优先级，他们的思路也会变得更清楚。系统落地后，这套清单还能作为排产结果异常时的排查依据。

2.2 人工排产凭什么还能撑到现在

每次提到排产AI化，总会有人问：既然传统手工排产问题这么多，为什么很多工厂到现在还在用Excel？这里面的原因其实值得尊重。一个熟练的计划员对自家车间的产能状态、订单结构、设备脾气非常熟悉。几十个订单的时候，他脑子里能模拟出大概的方案，再结合Excel里的设备负载表，半小时能排出一个“比较够用”的计划。

问题在于人工排产的上限非常明显。当订单数量从几十个涨到几百个，插单频繁发生、替代工艺路线多了之后，人脑很难全局统筹，结果就是计划员每天都在救火，优先保证最紧急的几单，其他订单只能被动延期。另一个问题是依赖个人经验，老计划员休假或者离职，排产逻辑也跟着断档。系统要替代的并不是这份经验，而是把经验沉淀成可持续优化的规则。

不过这也意味着，项目团队要尊重现有的手工表格。很多算法工程师最烦的就是Excel，但Excel里往往藏着最真实的业务数据流。最初几次调研里，我建议把现有Excel模板完整要过来，逐一字段追问来龙去脉。比如“工单完成时间”到底是谁填的、一天更新几次、有没有每道工序拆分的时间记录。这些细节决定了系统的数据粒度，也决定了后面算法能解决什么程度的问题。

2.3 排产的效果好坏，靠什么指标来衡量

排产系统上线之前，必须定义清楚“好计划”长什么样。这里最忌讳的是一句话需求“排得越快越好”——快和好经常互相冲突。有的企业最关心准时交付率，那么系统会尽量压缩高风险订单的排队时间；有的企业最关心减少设备切换成本，那么系统会倾向于把相同类型的产品安排在一个批次里连续生产；还有的老板关心缩短制造周期，系统就会倾向于把等待时间压到最低。

面向同一个车间，三个目标同时满足几乎不可能。准时交付率提升，往往意味着为紧急订单频繁切换设备，切换次数和成本会上升；追求设备产能利用率最大化，则可能造成在制品堆积和交期不稳。所以排产的项目需求评审里，目标优先级必须由业务最高负责人拍板，而不是由IT部门或算法团队自己猜。我常用的做法是拉一个指标对照表，把交付率、设备利用率、切换次数、平均制造周期、库存周转天数等指标放一起，让管理层明确哪些是红线、哪些可以妥协。

一旦目标定清楚，算法就不再是无头苍蝇。后面不管是用规则启发式还是更复杂的搜索算法，本质上都是在寻找“让关键目标更优”的可行解。这也是排产和AI话题绕不开的原因：AI算法本身只是一个搜索工具，真正定义它往哪个方向搜索的，永远是业务目标和约束。

3. 打牢数据地基：工时、资源日历与规则优先级

不少项目把实施周期的大部分都花在了数据清洗上，这个比例听起来夸张，但完全是正常的。一个排产系统能不能算出能执行的计划，数据质量比算法先进程度重要得多。我见过一个项目，算法模型只调了一周，剩下两个月都在和车间一起校准工时和维护资源日历。所以这篇文章要花一整节来展开数据到底该怎么准备。

3.1 工序工时：别掉进“精算到秒”的陷阱

让排产结果被车间认可，最重要的数据就是工序工时。很多做系统的团队一到现场就发愁：某个零件的车削工序到底应该算8分钟还是12分钟？他们花大量时间推动业务方进行秒表测时，试图做出一个标准工时库。这当然有作用，但实际项目里，标准工时做得越精确，维护成本往往也越高，因为材料批次差异、设备新旧程度、操作工熟练度都会导致工时波动。

如果企业有历史工单数据，一个更务实的办法是取近三个月每个工序的实际加工时间，剔除异常值后用中位数或者偏保守的分位数作为默认工时，再保留一个“工时系数”用来应对生产波动。比如系统预设某道工序标准工时是10分钟，但计划员清楚这批材料毛坯余量大，需要乘以1.2的系数。这种设计比强行要求业务方给出一个所谓的精准数字要灵活得多。

还有一个容易忽视的坑：工序工时并不仅仅指“机器加工时间”。完整的一道工序通常包含装夹时间、对刀时间、首件检验时间和拆卸时间。如果系统里只填了纯加工时间，排产计划看起来产能很满，但实际设备根本不可能那么快周转。这时候计划员就会发现系统给出的计划过于乐观，等全部做完得拖班，信任感立刻崩掉。所以在数据清洗阶段，一定要确认每个工时字段的口径是“纯加工”还是“包含准备和收尾的完整占用时间”。

3.2 设备和日历：把“产能”真正建模出来

设备数据永远是排产系统的重头戏。最基本的设备档案包括设备编号、所属车间、可用状态、加工能力。但光有设备还不够，必须有日历，也就是这台设备哪天开机、哪几天保养、平时开几班。国内很多加工车间的排班和工厂整体班次不完全一致，有的设备跟着订单走，周末加班也常见，所以把设备日历做成可视化且可调整的模块会比写死在配置文件里更实用。

资源建模的复杂度通常在“一机多人”或“一人多机”的场景中爆发。比如一个熟练工人同时看两台数控机床，那排产时就要避免把两台机床的加工时间重叠但都绑给同一个人。处理这类问题不能只在设备维度排，要把操作人员也作为约束资源参与计算。类似的情况还包括模具、刀具、专用吊具、检验仪器等辅助资源，它们在特定工序里会成为真正的瓶颈。

在给车间做资源数字化梳理时，我会用“资源-工序关联表”来做承载。每个工序除了关联设备组，还要定义该工序需要哪些辅助资源、准备时间是多少、是否允许替代资源组。比如某道铣削工序优先使用立式加工中心，若负荷过高，可以允许转到卧式加工中心，但这个替代会增加20%的加工时间。把这样的规则写进数据模型里，算法才能真正在“为订单寻找可用路径”时拥有足够弹性。

3.3 业务规则优先级怎么放进系统

资源数据管“能不能做”，业务规则则管“先做哪个、谁更优先”。大多数车间都有一套自己的订单优先级判定方法，最常见的是按交期先后、按客户重要度、按订单紧急插单标识。系统要做的是把这套优先级判定转成明确的算法规则，让计划员不需要再靠Excel和记忆来反复调整。

一个成熟的排产规则体系往往是多级的。比如第一级看订单是否属于VIP客户，第二级看承诺交期是否临近，第三级看物料是否齐套。系统在生成计划时会逐级过滤：先保证最紧急的VIP订单获得优先资源，再处理交期相近的普通订单。这种多级规则虽然简单，但很符合现场计划员的日常逻辑，上线后更容易被接受。

还有一类规则比较隐蔽，就是“最小生产批量”和“最大等待时间”。有的工序换型成本很高，业务上要求同类订单尽量合批生产，减少换模次数；有的工序则要求半成品不能在机台前积压太久，否则会氧化或者变形。这类约束不写清楚，AI排产结果大概率会在成本或品质上出问题。我在项目交付时会把所有业务规则整理成一张优先级总表，与管理员逐条确认后固化到系统规则引擎中。

4. 选对方法：从规则引擎到混合优化算法的落地路径

数据准备得差不多之后，算法设计才真正开始。这段我会把从基础到进阶的技术路线讲清楚，也回答一个所有人都关心的问题：排产到底要不要上复杂的AI算法？我的答案一向是：从最接近现状的方案起步，留出优化空间，而不是一步跳到黑盒AI。

4.1 先把规则引擎做出来，形成“可追责”的初始计划

任何一个排产项目，第一版建议都别上遗传算法或强化学习，而是先把计划员的经验固化成规则引擎。最经典的是“优先级排序+设备分配”的两步法。第一步，把所有待排工序按照订单优先级、交期紧急程度、工艺先后顺序排成一个队列；第二步，从队列头开始，依次为每道工序寻找最早可用的设备时间段并分配下去。

我在实现这一步时，常用一个简单的贪心框架：

• 读取订单和工艺路线，拆分到工序粒度；
• 按交期升序和优先级降序生成工序队列；
• 遍历队列，为每道工序找当前所有可用设备中完工最早的一台；
• 占用该设备的对应时间段，更新时间轴；
• 若物料或模具未齐套，则工序挂起并记录依赖原因。

这种方法通常能在几十秒内给出一版完整计划，虽然未必是最优，但和人工计划放在一起对比时，往往已经能打个平手甚至更好。更重要的是，这版计划完全可解释，每一道工序为什么排在这一天这一台设备上，都能追溯到一条具体规则。业务方看到系统不是一拍脑袋决定的，信任感会大幅提升。

4.2 引入搜索算法：在初始计划基础上做迭代优化

规则引擎能解决“有没有计划”，但要回答“计划好不好”，就需要引用搜索算法去不断改进。以遗传算法在车间排产中的常见用法为例，它把一组候选计划当作一个种群，每个计划用一串编码表示工序的顺序和对设备的分配选择，然后通过选择、交叉、变异，让计划在目标函数方向上不断迭代。

这里最大的坑是“只顾进化，不管合法性”。如果交叉和变异后生成的新计划违反了工艺顺序或设备占用时间，算法输出的结果再漂亮也没用。所以在编写遗传算法的时候，必须额外设计“修复机制”，每次生成新个体后都要检查约束，必要时把非法个体修正回可行解。这一步非常容易拖慢计算速度，但也是算法能不能在真实车间落地的关键。

另一种同样常用且实现起来更稳妥的是“邻域搜索”思路。给定一个初始可行计划，尝试对工序进行小幅调整，比如把某道工序从设备A换到设备B，或者把两个订单的加工顺序互换，再判断调整后的计划是否让关键目标变得更优。这种调整在业务上非常直观，计划员也很容易理解系统为什么这么改。近几年工业排产中很多厂商用的所谓“智能优化”，底层其实是这种邻域搜索框架的变种。

4.3 算法参数怎么定：实例与调参经验

说到参数，新人容易陷入“为了调参而调参”的误区。拿遗传算法举例，种群大小、交叉概率、变异概率、迭代次数，每一个参数都影响搜索效果和耗时。但工业项目最重要的是“在规定时间内返回一个足够好的可行解”，而不是在校验集上刷分。比如一个车间有200个订单、1200道工序，我的经验是设置种群规模60~100个，迭代200~300代，配上10分钟的时间预算，足够找到一个明显优于人工计划的解。

还有一点值得强调，排产的运行节奏很关键。如果你做的是周计划级别的排产，每天晚上全量重排一次是可以接受的，跑十几分钟没关系。如果你做的是班次级别的调度，比如计划员希望每2小时根据现场完成情况滚动更新一次计划，算法的单次运行时间就不能超过几分钟。所以选算法时不要看单点效果，要看在限定时间内的稳定产出。

为了验证算法效果，我们通常会把算法排产结果和当期人工排产结果拿来做回测对比。选定一个没有大异常的历史周，把同一批订单交给系统重新排，然后比对准时交付率、总切换次数和机台负载差异。如果新系统连历史场景都比不过人工计划，那就说明问题定义、数据或算法方向有偏差，先回头找原因，再谈优化。

4.4 排产方案怎么让人工介入：沙盘与固化流程

系统给出的计划能不能一锤定音？实际上很难。现场情况总在变化，设备可能故障、物料可能迟到、临时插单天天都有。所以不要把排产系统设计成一个自动下发的黑匣子，要给它加一个“人工确认与调整”的环节。更实际的做法是提供一个计划沙盘界面，让计划员可以手动拖拽工序、锁定某道工序的时间段，再让系统在剩余范围内自动重排。

这类交互看起来只是用户体验问题，却直接影响系统能不能真正跑起来。再准的算法，如果计划员不能随时干预，他就不敢对执行结果负责；而一旦他有了调整能力并且系统会记录所有调整痕迹，他会把系统当成自己的高级参谋。锁定与解锁机制要设计得很细，比如一张订单被锁定了开始时间后，其他相关工序是否能跟着自动联动，这些都需要和业务人员反复打磨。

5. 大模型和智能体在排产项目里到底能用在哪

聊到这里，有些读者可能会问：按你这么说，AI重要吗？当然重要，但它的价值和大多数人的想象不太一样。大模型、智能体这些新技术在排产项目里不是没有空间，只是它们的位置更像外围的决策支持，而不是核心计算引擎。搞清楚这个边界，你才不会被喧嚣的热词带着跑。

5.1 大模型最适合做的事：解释排产方案

一个非常现实的场景是：计划员看到系统给出的计划后，第一反应往往是问“为什么这里把我的订单排到三天后？”如果系统只能给出一张甘特图，计划员得自己对着图找原因，效率很低，也很容易产生不信任。

把大模型接入到解释模块里，就可以把调度结果自动翻译成自然语言说明，比如“该订单的原材料预计下周二上午到齐，前一道工序在立式加工中心排队较多，最早可开始时间是下周三下午”。这种能力在业务侧非常受欢迎，几乎所有计划员都愿意用。它并不直接参与排产计算，却显著降低了系统的使用门槛。实际开发中，我们需要先把排产结果的各类字段和关键约束打包成结构化数据，再通过大模型生成叙述。要注意的是，大模型偶尔会一本正经地胡说八道，所以生成内容必须由前端的业务模板兜底，不允许自由发挥出系统记录之外的结论。

5.2 智能体在异常管理与滚动重排中的应用

车间的生产过程是高度动态的。设备故障、来料检测不合格、人员临时缺勤，这些异常每天都会发生。如果每次异常都要计划员打开排产系统手动调整，系统再智能也会被拖垮。智能体的落地价值正好体现在这里：它负责监控现场反馈的数据信号，当某台设备报故障或者某道工序延迟开工超过阈值时，自动触发重新排产任务，并把影响范围发送给相关人员。

这种场景可以拆成多个自动步骤：异常检测、影响范围评估、触发重排、方案审批、结果通知。每一步都可能由不同的规则或模型负责。真正要把流程跑通，关键痛点不是大模型的聪明程度，而是数据接口的稳定程度。如果系统连工单完工上报都不及时，智能体就永远在一个已经过期的数据上做决策。此时再谈什么无人工厂，都只是空中楼阁。

5.3 机器学习和预测模型在排产中的位置

预测类AI在排产中可以有更实质的贡献，比如对工时偏差、订单交付风险和突发性设备故障进行预测。以工时偏差预测为例，系统可以根据历史数据、当前工件批次、设备运行状态，提前预判某道工序实际完工时间是否可能比基准工时超出预期。这类信息如果能回灌进排产搜索目标中，系统就会自动为高风险订单多留缓冲。

不过，预测模型做得再准，也不能替代排产计算本身。预测结果是给“排产内核”输入额外的动态参数，而内核仍然是一个优化问题。有些项目为了显得技术含量高，硬要把一个时序预测模型包装成“AI排产主引擎”，结果等于在要求模型去做数学搜索，模型不仅算不准，连可解释性也丢了。正确的分工非常明确：预测负责改善输入和感知异常，优化算法负责搜索和输出计划，大模型负责解释和交互，三者组合起来，才是一个完整的、有竞争力的AI排产系统。

6. 现场踩坑记录与问题排查速查表

写完方法路径，我照例把多年项目中踩过的典型坑整理出来。这些坑单个看都不起眼，但组合起来足够让项目上线日期一拖再拖。下面这些内容不是教科书上的标准答案，而是来自真实项目交付现场的经验总结。

6.1 典型问题与排查技巧

排查这些问题的基本原则是：先检查数据，再检查约束，最后才怀疑算法。大多数情况都不是算法不收敛，而是数据里藏着看不见的脏值。比如设备编号在工单和档案里不一致、日期格式混用、工单状态没有及时关闭，这类问题在排产上线前就会表现为各种逻辑矛盾，只有彻底把数据流捋顺，算法层面的问题才会暴露出来。

6.2 排产项目上线后的一个实用小技巧

系统真正上线后，我还有一个一直坚持的做法：每周复盘一次“系统建议计划”和“实际执行计划”的差距，把差距归因成三类：数据不准、规则不完整、现场异常扰动。不要一有差距就认为是排产系统不行。你会发现，很多差距在数据刷新后能自动消失，还有一些差距需要把新的业务智慧沉淀成新规则。这个过程，实际上就是企业从“人工经验排产”走到“数据驱动排产”最难但也是最有价值的一段路。

如果你正在负责一个AI排产项目，我的建议是想办法先说服业务团队和领导层把项目目标收敛到三个可量化指标上，然后围绕这三个指标去设计数据、规则和算法，不要把时间花在“我们到底该用大模型还是强化学习”这种概念之争上。等计划员愿意对着系统界面说“这个计划还可以，但我需要把三号订单提前”，项目就已经成功了一大半。排产系统的终局不是替代计划员，而是让每个计划员的经验通过数据和算法放大，解决以前靠人脑顾不过来的全局优化问题。