夜雨聆风
最近一年，但凡聊到APS，总有人会问：「你们有没有AI？」
而另一些人则反过来问：「你们那个AI排程，靠谱吗？」
两种问法，背后是两种截然不同的认知——前者在追赶风口，后者在心存疑虑。
这篇文章，我们来把这个问题说清楚。
「APS适不适合用大模型AI」，其实是一个被混淆了的问题。
它的背后，隐藏着三种完全不同的技术：大模型（LLM）、优化求解器、规则引擎。
很多人在谈「AI排程」的时候，其实把这三种技术混在了一起说——要么把大模型当成万能钥匙，要么把所有AI都否定了。
正确的方式是：先搞清楚这三种技术各自是什么，能干什么，不能干什么，再来回答APS该怎么用AI。
大模型（LLM）：模式识别与生成
大模型本质上是在做「概率猜测」——根据海量训练数据，预测下一步最可能的答案。它擅长理解自然语言、归纳规律、生成内容，但它给出的答案是「大概率对的」，而不是「数学上可证明是对的」。
这在写文章、做对话、分析报告时完全够用。但在工厂排程里，「大概率对的计划」一旦出错，就意味着工单拖期、设备碰撞、库存爆仓——这些代价是真实的。
大模型的硬伤：没有约束保证。它可能排出一个「很像样」的计划，但这个计划有没有违反工序顺序？有没有超出设备产能？它自己不知道，你也看不出来。 |
优化求解器：在约束内寻找最优解
优化求解器的工作方式完全不同。你告诉它：目标是什么（最小化拖期）、约束是什么（工序顺序、设备产能、交期）、变量是什么（工序开始时间）——它用数学方法在可行域内搜索最优解。
这是有理论保证的计算过程，结果可追溯、可解释。
典型代表：
数学规划（MIP/LP）：适合中小规模、约束清晰的优化问题
约束规划（CP-SAT）：适合复杂约束组合，Google OR-Tools是典型实现
启发式算法（遗传算法、模拟退火）：适合大规模排程问题的工程近似解
商业求解器：精度最高，适合战略层计划
求解器的价值：给定约束，数学上接近最优——这是APS的计算内核，无可替代。 |
规则引擎：透明、快速的条件判断
规则引擎是最「老派」的技术，但在APS里从未过时。它做的是：如果满足条件A，则执行动作B。
订单优先级仲裁
硬约束校验（工序不能倒排、交期不能违反）
插单快速响应（不需要重跑全局优化）
计划结果的业务规则微调
规则引擎的价值：透明、低延迟、业务人员自己能维护。每一条决策都有据可查，不是黑盒。 |
说清楚了三种技术，我们来回答那个核心问题：大模型适合做APS吗？
答案是：适合，但只适合特定的层次，而不是排程本身。
大模型适合做的事有以下4种。
1.自然语言交互层
这是大模型最直接的价值。
传统APS的交互方式是：打开界面→找到功能→填参数→提交执行。
对于很多计划员来说，操作路径既陡峭又低效。有了大模型，计划员可以直接说：「把本周五到期的A产品订单往后推两天，同时重新排一下受影响的工序」——大模型理解这段话，翻译成结构化指令，传给排程引擎执行。
这不是噱头，这是真实的效率提升。
2.需求预测辅助
需求预测是APS上游的关键输入。
大模型可以结合历史销售数据、节假日规律、促销计划、外部事件等多维信息，做比传统统计模型更灵活的预测修正。尤其是面对异常情况（疫情、供应商突然断货、大客户突然砍单），传统时序模型反应迟钝，大模型可以快速整合非结构化信息做出预判。
3.异常识别与根因分析
车间数据里藏着大量异常：某台设备的OEE突然下降、某个班次的达成率持续偏低、某类产品的工序等待时间异常长……大模型可以做异常模式识别，自动生成人类可读的分析报告：「过去两周，3号产线的换型时间比基准值高出40%，集中在A产品→C产品的切换，建议检查换型SOP是否更新」。
这些分析，人工来做需要几小时，大模型几秒钟。
4.计划辅助解释
APS排出的计划，有时候计划员看不懂为什么这么排——「为什么这个订单被推到后天？」「为什么3号设备空转了2小时？」大模型可以读取排程逻辑，用自然语言解释给计划员听，大幅降低使用门槛。
大模型绝对不适合做的事有以下3种：
直接生成排程计划：无约束保证，可能违反工序顺序、超出产能，「幻觉」在排程里是灾难性的
处理硬约束：交期、工序顺序、设备产能——这些不能靠「大概率正确」来保证
实时高频重排：大模型的推理延迟和计算成本，无法满足车间级实时响应需求
如果你在考察APS产品，遇到厂商宣称「用大模型直接做排程」，你可以用这三个问题来判断：
问题一：硬约束如何保证？
Q | 「你的系统如何保证排程结果满足所有硬约束？」 |
如果对方说「大模型会自动处理」，那就要小心了。硬约束必须由求解器来保证，大模型无法做到这一点。
问题二：紧急插单响应多久？
Q | 「能不能给我看一下，遇到紧急插单时，系统多久能重新输出一个合法的排程？」 |
这是测试排程内核性能的直接方法。大模型做不到秒级响应，求解器配合规则引擎可以。
问题三：AI在哪一层发挥作用？
Q | 「你们的AI在哪个层次发挥作用？交互层？预测层？还是排程计算本身？」 |
这个问题会迫使厂商说清楚技术架构，而不是含糊地用「AI排程」来营销。
在真正落地的APS系统里，这三种技术应该是分层配合的关系，而不是互相替代：
用户体验层 — 大模型 自然语言对话 / 异常分析 / 计划辅助解释 |
▼ |
业务规则层 — 规则引擎 优先级仲裁 / 硬约束校验 / 快速插单响应 |
▼ |
排程优化层 — 求解器 CP / MIP / 启发式算法 → 数学最优排程结果 |
▼ |
数据底座 — ERP / MES / WMS 工单 / 产能 / 库存 / 工艺路线 |
求解器是地基，负责数学上的最优化，保证计划的合法性和最优性；
规则引擎是中间层，负责把工厂的业务逻辑翻译成系统行为，保证灵活性；
大模型是界面层，负责降低使用门槛，让计划员更容易驾驭复杂系统。
三层各司其职，缺一不可。
坦率地说，APS行业对大模型的应用，目前仍处于早期探索阶段。
应用方向 | 成熟度 | 说明 |
自然语言交互 | ★★★ 中等 | 已有实际产品落地，但深度有限 |
需求预测辅助 | ★★★★ 较高 | 相对成熟，已有应用案例 |
异常识别分析 | ★★★ 中等 | 有探索，效果参差不齐 |
参数自适应调整 | ★★ 较低 | 学术研究阶段，工程落地极少 |
强化学习做排程 | ★ 极低 | 论文很多，工厂落地近乎空白 |
直接用LLM做排程 | ✘ 不可行 | 工程上不可行，请勿轻信 |
最有可能率先落地的，是「对话式APS」——计划员通过自然语言与系统交互，大模型负责理解意图和解释结果，排程计算仍由求解器完成。这个方向既有技术可行性，又有真实的用户价值。
APS领域的技术演化，从来都不是「新技术消灭旧技术」，而是「新技术填补旧技术的盲区」。
规则引擎解决了透明性问题，但灵活性不足——求解器来补；求解器解决了最优化问题，但交互复杂——大模型来补。
每一层都在解决真实的痛点，没有哪种技术是「万能钥匙」。
真正的难点，从来不在算法，而在约束建模的准确性和数据质量。排程模型建不准，无论用哪种技术都是枉然；数据质量不过关，再聪明的AI也排不出可以执行的计划。 |
这也是为什么，行业里最扎实的APS项目，往往不是技术最炫的，而是把业务梳理做得最深、数据治理做得最认真的。
