Sight Machine：用 AI 优化高频生产排程

计划刚发出就过期的工厂

饮料装瓶是典型的高混合生产：同一条线上要轮换多个 SKU，每次换型都意味着清洗、调机和重新爬坡。某大型饮料制造商正是在这种节奏里运转——官方案例没有公开这家企业的名称，只说明它是一家大型装瓶商。它的排程职能看上去属于计划，实际上更接近每天的损失控制。

排程要做的事本身很朴素：根据客户需求和原料供应，把具体的作业和数量分配到具体的机器上。难点不在第一版计划，而在计划发出之后。机器降速、订单变更、来料延迟，任何一件都会让排班表失效；而能支撑判断的数据散落在互不连通的系统里，等它传到需要决策的人手上，计划已经错了。这份工作因此常被直接称作"重排"。

Sight Machine 联合创始人兼首席 AI 官 Kurt DeMaagd 的说法很直接：最大的挑战是现实从不按原计划走，机器会慢、维护会出问题、客户订单会改、来料会晚，制造商只能不断适应。他还有一句补充——制造业在一致性中运转得最好，但现实是总有东西在变，每一次扰动都会在整条运营链上产生连锁反应。

在这家装瓶商，重排会议每周要开 10 到 15 次。产线一慢或者新订单进来，排程员就得临时把工厂经理、工程负责人和运营团队拉到一起，在不牺牲产出目标、不增加停机的前提下改计划。排序本身还叠了一层复杂度：产品顺序排错，清洗时间变长、生产变慢，质量风险跟着来。

更难替代的是人。随着有经验的工艺工程师陆续接近退休，几十年的排程判断存在个人脑子里，而不在任何别人能调用、能继续建设的系统中。这才是"现在必须改变"的真实压力：不是缺少一套更聪明的算法，而是缺少一个能承载这些判断、并且在条件变化时还能继续算下去的载体。

决策冲突：继续依赖会议，还是降低建模的门槛

数学优化模型早就是更聪明排程的现成路径，真正卡住落地的是翻译成本。把现实中的制造约束写成优化模型，传统上需要专门的运筹背景，而每一家工厂、每一条线的约束都不一样。于是团队面前只有两条路：继续用人的经验和跨职能会议顶着，或者找到一种让"描述约束"这件事成本骤降的方法。

转折点来自 Microsoft Foundry 团队介绍的 OptiMind。这是 Microsoft Research 开发的小语言模型，把用日常语言描述的业务问题转成优化软件需要的数学形式；不再要求专家逐条手工编码排程约束，而是根据自然语言输入动态生成混合整数规划代码。DeMaagd 对这一步的描述是：他们研究排程问题很久，难点在于每个制造环境的约束都不同，而现在可以用文字把问题说清楚、连上真实运营数据，模型就能动态地生成出来。

Sight Machine 没有直接推向生产。团队先用客户的生产数据测试这项技术，确认它在真实约束下站得住，才判断值得规模化，随后与 Microsoft 团队协作把 OptiMind 集成进自己的制造工作流。这个先验证再集成的顺序，是整个项目里最容易被忽略、却最决定成败的一步。

官方案例配图

Sight Machine 在 Microsoft 官方客户案例中的场景标识

三层结构：数据底座、模型生成、实时重算

系统按三层运转。最底下是 Sight Machine 的数据基础，它把工厂里的每一类数据源——IT、OT、云和边缘——连起来并持续结构化，为排程提供现实输入：每个 SKU 的产线速度、换型时间、爬坡时长和实时生产状态。供应链与需求预测工具的数据也接进来，优化范围还可以纳入能源、人力或成本这类因素。

中间一层是 OptiMind。它接收这些运营输入，加上客户订单、既有排程和自然语言指令，生成能表达完整排程问题的 MIP 代码，再交给优化求解得到候选排程。这一层的价值不在算得多快，而在约束可以被改写：业务侧换了一个排序规则，不需要重做一套模型工程。

最上面一层是重算。现场条件变化时，实时工厂数据会触发重新优化：产线降速或设备意外离线，团队会收到一份基于当前优先级和预计停机时长的修订排程，不必再召集一次跨职能会议。DeMaagd 把这个变化描述为，过去这个过程可能要几个小时、牵动一大群人，现在可以在几分钟内完成。

围绕这三层还有两类扩展能力。任何团队成员都能用日常语言做 what-if 试算，在扰动发生之前评估维护事件、需求变化或产能限制的影响；Sight Machine 同时用 Azure Machine Learning 构建的预测模型，帮制造商在降速影响产出目标之前提前预判。运营数据由 Microsoft Fabric 集中，团队还在探索把 Foundry 中的智能体和 Microsoft 365 Copilot 扩展进来，让操作人员在日常工具里直接获取排程与运营信息——这部分官方明确写的是"正在探索"，不是已上线状态。

端到端系统结构

从工厂数据到修订排程，以及触发重算的反馈路径

谁在什么时候介入，人和系统各拿哪一半

实施顺序可以还原成四步：先把工厂现实接入模型，把产线、订单、需求、供应链和设备状态整理成能实时使用的数据基础；再用客户真实生产数据试跑 OptiMind，验证生成的模型在现场约束下成立；确认可行后与 Microsoft 团队协作，把它集成进 Sight Machine 已有的制造工作流；最后把重算变成系统行为，让现场变化直接触发重新优化，而不是等一次跨职能会议。

角色分布同样清楚。Sight Machine 一侧由联合创始人兼首席 AI 官 Kurt DeMaagd 代表技术方向，团队负责数据底座与产品集成；Microsoft 一侧，Foundry 团队引入 OptiMind，模型本身出自 Microsoft Research；客户一侧的排程员、工厂经理、工程负责人和运营团队原本是重排会议的参会人，在新流程里变成修订排程的接收者与确认者。

人机分工的分界线落在"翻译与计算"和"判断与承担"之间。AI 承担把自然语言约束转成数学表达、生成 MIP 代码、在条件变化后重新求解；人依旧负责把业务约束和排序规则说清楚、判断候选排程是否符合工艺现实、确认当前优先级与停机估计，并决定是否执行。what-if 试算把这条界线往前推了一步：判断可以发生在扰动之前，而不只是发生之后。

再往细处走，官方材料就停住了。模型生成的 MIP 约束如何经过工程与安全复核、由谁签字、排程在什么条件下需要人工推翻或退回上一版、数据与系统之间的权限边界如何划分、这套能力的基础设施成本是多少，官方材料未披露。DataHub 判断，这几项恰好是同类项目最容易出问题的地方：语言生成的约束一旦漏掉一条工艺限制，排程在数学上仍然最优，在车间里却不可执行。要复现这类项目，值得先把约束回归测试集、越权改动的拦截点、以及"系统给出但人不接受"时的回退路径定义清楚——这些是应当验证的事项，不是这家装瓶商已经采用的做法。

实施顺序与人机协作

四个阶段里，三方团队与 AI 系统各自承担什么

四个数字分属两个层级，别把它们并成一句

落到这家装瓶商身上的结果有两项：非增值生产时间减少 75%，生产能力提升 5% 以上，并且是在没有扩建生产设施的前提下取得的，同时每周省下数小时的人工计划工作。另外两项写在更高的层级上：官方称这套通用方法带来整体工厂生产率提升 10% 或更多，排程时间减少 75%。前者是单一客户的运营结果，后者是方法层面的表述，把四个数字并列成一句"该企业实现了四项提升"，就已经偏离了原文口径。

"10% 或更多"是下限式表述，不是平均值，也不是行业基准；把它当成同类工厂的期望值缺少依据。排程时间减少 75% 与非增值生产时间减少 75% 数值相同但对象不同：一个是做计划这件事花的时间，一个是生产过程中不产生价值的时间，任意一方都不能替另一方作证。

更需要克制的是因果推断。排程加速与产能提升在同一时间窗内出现，但官方同时提到预测分析模型、数据集中化等并行能力，无法据此判定产能变化由排程重算单独造成。观察周期、涉及的产线数量、基线如何定义、有没有对照，官方案例都未给出；客户名称也没有公开，意味着无法回到企业自身的公开披露去交叉核对。这些数字也没有附带投入信息，任何 ROI 换算都会是外部添加的假设。

结果口径与证据边界

哪些是客户结果、哪些是方法层结论、哪些不能推出

什么样的工厂能照着做

这套做法成立的前提相当具体：排程重做的频率高到值得系统化（这家装瓶商是每周 10 到 15 次），约束又足够复杂到难以用固定规则表达；同时企业已经有能实时供给产线速度、换型时间和设备状态的数据底座。缺了后一半，语言转模型再顺畅也没有输入，模型只会在错误的现实上求出漂亮解。

真正被降低的是建模的边际成本，不是判断的责任。约束从代码变成语言之后，改一条规则的门槛低了，写错一条规则的门槛也一起低了。DataHub 判断，迁移这套方案时最该先建的不是模型能力，而是约束的验收机制：谁有权改约束、改动如何被测试、生成的排程在什么条件下必须由人推翻。

至于效果，可参考的部分是流程形态——把跨部门会议换成系统重算，把老工程师脑中的排序经验沉淀成可调用的约束描述。数值本身不宜直接搬用：客户身份、观察窗口和对照都不在公开范围内，同类企业在自己产线上重跑一遍才是唯一可靠的验证方式。