把 AI 从需求预测接到生产排程，意味着系统开始承诺机器、人员和交期。同一条建议可能同时占用多个共享资源，单独看合理的任务放在一起却无法执行。本文讨论长期有效的工程与管理方法，不将其包装为近期行业事件；示例均为构造场景，未开展工厂部署实测。
从预测结果到资源承诺，验收对象发生了变化
企业常用预测误差、回答准确率或生成速度评价 AI。一旦输出成为班次计划，真正交付的就是一组互相依赖的动作：谁在什么时间、用哪台设备、完成哪道工序。此时，即便需求预测完全正确，也可能因为资源重复分配、前序未完成或资质不匹配而无法执行。模型能力评估必须接上决策与执行验收。
Smart “Predict, then Optimize” 研究区分预测误差与下游决策损失，并在特定优化模型中讨论面向决策的学习方法。[1] 这里借用的是评价视角，不据此推断任意大模型都能完成工厂排程。对于需求输入如何变成成本判断，可延伸阅读需求预测的分位数与缺货代价；本篇进一步讨论多个动作共享有限资源时的可执行性。
建议把职责分成三层：预测服务估计需求或工时；优化模型表达资源限制并生成候选方案；执行层决定是否承诺并落实计划。语言模型可以帮助整理规则草案、解释差异，但不能因为一句“优先保证交付”就悄悄改写设备能力或放宽安全边界。每个约束都需要可核对的数据来源和业务负责人。
先登记硬约束，再决定允许怎样交换代价
硬约束定义不可接受的方案，例如同一不可并行机器在同一时间只能处理一项任务、工序必须遵循先后顺序、任务只能分配给合格资源、维护窗口不可占用。软偏好则是允许付出代价改变的要求，例如尽量减少换线、减少计划变动或照顾非强制偏好。两者混在一句自然语言中，会让系统在优化时意外交换本来不能交换的条件。
为每条规则保存约束编号、作用范围、输入字段、单位、有效时间、负责人和违反时的处理方式。交期到底是绝不允许延迟的承诺，还是可计入罚分的目标，必须由业务明确。Google OR-Tools 排班示例将覆盖要求、每日分配限制与偏好优化分别表达。[2] 这一建模方式有启发性，但示例不涵盖实际工厂全部工艺规则。
优化目标也需要解释得清楚。把延期分钟、切换次数和变动任务数直接相加，数字大小就可能决定谁被牺牲。若能建立可信的金额口径，可比较总成本并检查重复计费；若不能，可以先满足重要目标的批准阈值，再在余下可行方案中优化次要目标。任何权重调整都应保留版本，而不是藏在提示词中。
时间粒度是另一项业务选择。CP-SAT 使用整数建模。[3] 用分钟或秒表示工时，会影响规模和可表达的边界；随意四舍五入可能把原本冲突的任务变成表面不冲突。上线前要约定最小粒度、区间端点和保守取整规则，并用原始业务时间重新检查关键承诺。
构造算例：便宜的计划可能不可行，维护也可能使问题无解
设有两项不可拆分任务 A、B，均需连续一小时，必须在 09:00—10:00 完成；机器 M1、M2 各只能同时处理一项任务。A 只能使用 M1，B 可用任一机器。为便于说明，假设两项任务都已备料，没有换线时间，也没有其他共享资源。这些是构造假设，不是客户数据。
若系统为了降低 M2 的使用成本，把 A、B 都放在 M1 的同一小时，得到的成本再低也不是可行方案。A 使用 M1、B 使用 M2 则满足本例约束。这里不能用平均设备利用率掩盖局部冲突；每台设备、每个实际时间区间都需要检查。
现在增加 M1 在 09:00—10:00 必须维护的条件，并维持 A 的资格与截止时间。A 没有可用位置，因此这个小问题无解。正确输出应指出冲突的任务、资源资格、维护窗口与交期，而不是自动删除维护条件。业务可以考虑经批准调整交期或增加合格资源，但修改规则后应形成新的问题版本。
反过来，求解器在时间预算内没找到方案，并不能直接宣称业务无解。CP-SAT 区分 OPTIMAL、FEASIBLE、INFEASIBLE、MODEL_INVALID 和 UNKNOWN；UNKNOWN 包含在限制触发前既没找到解、也没证明不可行的情况。[3] 报告应保留原状态及时间限制，只有拿到可行方案才进入后续验收，不能把超时当成取消订单的依据。
用独立检查器验收方案，避免模型漏规则却自证正确
建议交付一份独立于求解目标的检查记录。输入为冻结的订单、资源日历、工艺规则与候选计划；逐项检查任务是否全部出现且没有重复、资源是否合格、区间是否重叠、前置条件是否满足、已锁定任务是否被改变。检查器不必再求一个最优解，但必须能定位到违规任务和规则编号。
所谓独立，不能只是把同一段建模代码再调用一次。应由业务规则清单驱动检查，并保留小规模、人工可枚举的参考案例。模型忘记加入某条规则时，求解器仍可能给出它所理解的最优解；如果检查器也从同一份遗漏模型生成，就会一起放行。开发者与计划负责人应共同确认规则覆盖范围。
目标值另外验算：按计划实际产生的延期、换线和调整计算代价，并与现行可行规则及简单启发式比较。比较时输入、约束和计算时间预算必须一致。FEASIBLE 说明已有可行解，不代表已证明最优；OPTIMAL 也只是相对于当前模型成立，不证明遗漏的现场条件已被满足。
在允许输出空缺任务的设计中，空缺必须显式成为待处理项，不能从统计分母删除。计划完成率、硬约束违规数、总目标值和未分配任务数应分别报告。若只展示已排任务的准时率，就可能通过少排困难订单制造改善。
用扰动回放决定何时自动承诺，何时退回人工
静态可行只证明给定输入下的方案成立。实际工时延长、物料晚到或设备故障后，原计划可能失效。建议在历史可见数据上回放，并构造业务认可的扰动情景，观察哪些订单首先受影响、需要多少重排、是否仍有可执行备用方案。情景测试只能覆盖已设定变化，不能被描述为对所有异常的保证。
重排还要计入执行稳定性。已领料、已通知人员或即将开工的任务可进入冻结窗口；窗外任务才允许按批准规则调整。减少延期与减少变动可能冲突，应由负责人批准取舍。频繁出现小幅目标改善却大规模换班的方案，往往会把算法收益转移为现场协调成本。
发布前再次确认关键资源状态与输入版本；若已变化，重新校验或重排，不能直接提交旧方案。将候选、已检查、已批准、已下达和已执行分开记录，并让下达具有幂等标识。系统超时或检查失败时保留最后已确认计划及人工接管路径，避免重复派工。
最小试点可以选一个边界清楚的班次：先完成约束登记，再离线回放，再以建议方式与计划员对照，最后只对明确满足门槛的范围自动下达。验收同时观察硬约束违规、未分配量、延迟代价、计划变动和人工处理时间。若数据日历不可靠、规则无法说清或异常没有负责人，应先修复这些前提；增加模型复杂度不能替代它们。