我们造了一台更快的航空机组求解器，结果它只是败得更快。

我第一次坐在航空公司运营控制中心、亲历一场真实的连锁崩溃时，是凌晨3点刚过，一场冬季风暴数小时前已让一个关键航站关闭。房间前方的视频墙上一片红色越铺越满——一个又一个航班取消——而我记得最清楚的一点是，没有人在用这家航空公司花了数百万美元买来的机组排班求解器。调度员把键盘推到一边，正靠电子表格和一块白板手工处理断裂的机组配对，而这恰恰是那套软件本该证明自身价值的时刻。

正是那一幕最终促使我们构建了面向IROPS恢复的航空机组排班AI——但过程并非我所预想，而且在那之前我押注了错误的解法，眼看着它失败。IROPS，如果你从没有幸领教过，是行业里对不正常运行的称呼：风暴、关闭，以及航班计划瓦解时那种层层蔓延的混乱。据IATA估计，它每年给航空业造成约600亿美元的损失，约占全球航空公司收入的8%。全球大约每五个航班中就有一个受其影响。而我那晚学到的行业隐秘真相是：航空业中最精密的优化软件，本质上被设计成在那些代价最高的事件中毫无用处。

求解器在为一家已不复存在的航空公司做优化

了解传统机组求解器实际在做什么会有帮助。它们运行列生成——一种分支定价优化技术，在为一份已知的航班计划寻找最便宜的合法排班方式上确实堪称精妙。问题就出在已知这个词上。求解器对网络拍下一张快照，冻结时间，然后为那个冻结的世界计算出最优的机组分配。它按批处理周期运行，通常每30到60分钟一次。

在正常运营中，这没问题。两个周期之间世界几乎不动。但在连锁崩溃中，网络状态每隔几分钟就在变。机组在移动。中转在断裂。飞机被困。等到求解器返回一个解，它所依据的输入早已过时——于是答案成了为一家已不复存在的航空公司量身打造的完美方案。

我开始把这称为优化—执行差距：求解器所假设的世界，与停机坪上实际存在的世界之间的距离。在孤立的延误中，这个差距无害。在连锁崩溃中，它是致命的，因为求解器是为效率而造——在一个已知世界里最便宜的航班计划——而凌晨3点你迫切需要的却是韧性：在一个未知世界里能够存活的航班计划。

传统机组求解器最残忍的一点是，在崩溃期间它仍在照常工作——冷静地递给你一份完美的方案，而这份方案针对的那张网络，在它计算的同时已经四分五裂。

我们为什么不能干脆让求解器更快一些？

这是我并不引以为豪的部分，也是真正要紧的部分。

我的团队最初审视这个问题时，我们的诊断是工程师最显而易见的诊断：求解器太慢了。世界每五分钟就在变，而优化器要花三十分钟到一小时，那就把差距补上——让它更快。我们投入了实打实的时间去构建一个更快的恢复引擎，倚重更廉价的启发式方法，在运营决策窗口内拿到一个可行解，而不是等待一个可被证明为最优的解。

它确实奏效了，但只是在返回答案更快这个狭义上奏效。随后我们拿真实的中断数据对它做测试，我眼看着它信心十足地生成一份份恢复方案，而这些方案已经无效，只是无效得更早。我们造出了一台以更高速度为一家幻影航空公司做优化的机器。

错误在于把速度当成瓶颈。它并不是。瓶颈在于输入本身是虚构的。求解器——包括我们的——需要确凿的事实：“Smith机长在丹佛的B7登机口。”但在连锁崩溃期间，Smith机长可能在酒店，可能在员工班车上，可能已经租了车正在开往科罗拉多斯普林斯的半路上。世界的诚实状态是“大概在丹佛”，而列生成求解器对大概束手无策。我们一直在把一个数据本身是垃圾的问题的答案磨得更锋利。

那次失败正是这款产品得以存在的原因。如果我们把那个更快的求解器交付出去，我们就等于卖给航空公司一种更快地犯同一个昂贵错误的方法。

12亿美元的数据黑洞

如果你想看看这个错误在全面铺开时的样子，看看2022年12月西南航空的遭遇就行。那场崩溃令这家航空公司损失约12亿美元，取消了大约16,900个航班，并在假期期间让近两百万名旅客滞留。

流行的说法是“老旧的软件”。真实的故事更具体，也更有用。西南航空的机组排班系统SkySolver遭遇了它无法算通的组合爆炸。但在这之下，这家航空公司弄丢了自己飞行员和乘务员实际身处何处的踪迹。机组位置上报很大程度上要靠电话——滞留在外站的机组打电话给排班中心，而等待时间攀升到数小时。这种延迟制造了我称之为数据黑洞的东西：系统在为一批并不在它以为的位置上的机组生成排班。它在为一张幻影网络做优化，而点对点的航线结构意味着没有枢纽“再生节点”让机组与飞机自然重新汇合，于是爆炸半径就这样一个航站接一个航站地不断扩散。

这并不是人人早已修复的陈年旧事。2024年7月，精神航空的排班系统为其可用飞行机组的43%生成了相互冲突的分配，估计造成5000万至1亿美元的事件，因为该系统缺乏在中断期间干净利落地重新分配机组的灵活性。这一模式一再重演，是因为底层架构——优化一张冻结的快照、要求确定的输入——在整个行业中都是同一套。

值得肯定的是，西南航空以砸钱作为回应：2024年在技术上投入约17亿美元，作为一个更大的多年期计划的一部分，一次大幅削减其数据中心占用规模的AWS迁移，以及一套速度提升约30%的排班算法。这个直觉是对的。但同一套架构的更快版本——正是我们自己差点掉进去的陷阱——补上了速度差距，却让数据确定性差距依旧大敞着。

如今当一次延误超过三小时会发生什么？

在航空业历史的大部分时间里，缓慢的恢复让你付出的是商誉的代价。愤怒的旅客、糟糕的舆情、一些代金券。这笔账在2024年10月28日改变了。

那一天，美国交通部的自动退款规则生效——史上首个强制性自动退款要求。任何超过三小时的国内延误（国际为六小时）如今都会触发一笔现金退款，在七个工作日内支付，甚至无需旅客开口索要。不是代金券。不是改签。是现金。

为一家每天执飞300个航班的中型航空公司算算这笔账。在真正糟糕的一天里，哪怕只有六分之一——50个航班——滑过三小时这条线，按平均票价280美元、每个航班150名旅客计算，你面对的将是约单单一天就产生210万美元的强制退款敞口。缓慢的IROPS恢复曾经是个声誉问题。如今它成了一笔当周就会兑现的账目。

如今，你的恢复每落后一小时都有一块计价表在走动，而自去年10月起，它以现金自动向它触及的每一名旅客支付。

这正是为我重新定义了整场对话的部分。优化—执行差距的代价不再抽象。它以美元累积，对着一只在风暴开始那一刻就启动的时钟。

增强求解器，而不是替换它

以下是界定我们方法的那个决定，它刻意地毫不花哨：我们不替换你的求解器。

在位的求解器编码了数十年航空公司专属的领域知识，而它们周边的领域正在整合，而非崩塌。Jeppesen——行业标准，拥有一百多家航空公司客户——于2025年4月由波音以105.5亿美元出售给Thoma Bravo，是航空航天史上规模最大的技术资产剥离之一，此后推出了Stratosphere，一个用于预测性中断管理的AI层。IBS Software的iFlight平台正在赢得现代的云原生部署——大韩航空于2026年初上线，Aeroitalia以及Groupe Dubreuil旗下的航空公司等运营方也在迁往该平台——背后有与AWS的联合工程合作作为支撑。Optym的CrewSolver在规划侧实现了有据可查的3%至7%的机组成本降幅。

这些都不是敌人。但请注意它们各自的强项：规划阶段的优化和预测性分析——那个已知的世界，被计算得漂亮无比。实时的、输入不确定的恢复问题，才是那个始终敞开的差距。全面替换平台还是一个为期12到18个月的项目，没有哪位运营负责人愿意为了修好一年中出问题的15天，去拆掉那套一年350天都在正常工作的系统。对于真正签合同的CIO来说，这笔账比日历更糟：拆掉一套编码了数十年运营方专属集体谈判协议逻辑的系统——恰逢Jeppesen自身的所有权刚以105.5亿美元易手、其长期路线图尚是未知数之际——是大多数技术组织不会去下的赌注。坐在既有安装环境的旁边，消费它的数据流而不替换它的架构，才是他们唯一会放行的集成方式。

于是我们构建了一个由ML驱动的IROPS恢复引擎，它并排坐落在既有的Jeppesen或IBS安装环境旁，处理核心求解器无法应对的事情：机组位置不确定的连锁中断、全网范围的爆炸半径分析，以及在几分钟内产出的恢复方案，而人工恢复通常要花4到12小时。区域案例数据表明，自动化可以把这段恢复时间缩短约78%。重点不在于比在位者更聪明，而在于在在位者从未被设计去应对的那些确切条件下派上用场。

教会一个模型与“大概在丹佛”共处

一旦我们不再试图让求解器更快，真正的工程问题便清晰起来：构建一个在不确定性中茁壮成长、而非被它噎住的东西。

第一块是机组位置智能。我们不再要求一个确定的位置，而是向模型输入概率性的位置——把现有的一切实时信号与历史行为融合起来，让系统去推理某个机组很可能身处何处，而不是苦等一通已在等待队列里排了四小时深的电话。那单单一次转变——从“确定或什么都没有”到“概率分布”——正是让一份恢复方案能在与真实连锁崩溃的接触中存活下来的东西。

第二块是把网络当作一张图，在故障传播之前就分析它们将向何处蔓延——那个爆炸半径，映射到这家特定航空公司的航线结构上，让你能看清哪个航站的关闭正悄悄地在两小时后取消掉下游的六个航班。

第三块是一个场景模拟器，实际上是运营的一个数字孪生，让运营团队能够预先演练一个冬季风暴场景，在没有真实风暴、也没有真实时钟的时候测试恢复策略。在数据丰富之处，航空业已经信任数字孪生——汉莎航空的AVIATAR平台每天在34个航空公司集成中摄入23.7太字节的数据，在维修故障预测上达到93.6%的准确率。机组与排班的孪生仍处于萌芽阶段，而这恰恰正是机遇所在。

贯穿这一切的是约束引擎。每一条建议都必须在FAA第117部疲劳规则下合法——8到9小时的飞行时间上限、9到14小时的执勤时段——并且在航空公司的工会合同下合法，而工会合同往往比法规更严格。大多数供应商把这些规则当作“配置”。而我们把编码一家运营方按机队、按驻地划分的具体集体谈判协议，视为核心工程，因为一份违反了CBA条款的恢复方案根本不是方案——它是一份申诉。

我们为什么先在影子模式下运行

这个行业里的人不信任一个黑箱在凌晨3点告诉他们该如何调动飞行员，这是对的。所以我要告诉你我听到最多的那种反对意见，因为我自己也曾有过。

早期有一位运营副总裁大致对我们说，他们刚从在位供应商那里授权了AI中断附加组件，看不出为什么还需要我们。合情合理。然后下一场风暴来了，那个附加组件给了他们预测，却给不出可执行的机组恢复，调度员又回到了白板前。那次对话教给我的区别是：面向旅客对话的智能体AI——2026年会议巡回圈的时髦词——与就机组和飞机做出运营决策的AI，两者之间有着天壤之别。一个为旅客重新安排行程的聊天机器人是件好东西。但它与恢复一张网络不是同一个工程问题。

这就是为什么任何一家航空公司第一次运行我们的引擎时，它并不触碰运营。它以影子模式运行：我们模型的建议摆在人类调度员实际决策的旁边，而我们一天又一天地在这家航空公司自己的中断事件上衡量二者的差距。信任不是在一份销售演示稿里断言出来的。它是在一张对比表上、在没有运营风险的情况下挣来的，直到运营团队自己认定这些建议比白板更好。

你无法靠一份基准测试就赢得为别人的飞行员改航的权利。你靠的是准确无误，安静地，在一个人身旁，持续数周，早在任何人不得不相信你之前。

老实说，正是在观察影子模式的时候，我才明白我们真正在卖的是什么。不是一个优化器。不是速度。我们卖的是一种途径，让一位运营负责人能在他们一年中最糟糕的那个夜晚相信一台机器——而这种相信必须在风暴之前建立，而不是在风暴当中。

那15天究竟值多少

如果你经营一家中型航空公司的运营，你的机组求解器一年350天都运转良好。我不是来反驳这一点的。问题在于它不灵的那15天会发生什么——而正是那些日子催生了十亿美元级的头条、43%机组被误分配的审计，以及如今自去年10月起、按小时计价的自动现金退款。

整个行业一犯再犯的错误——也是我自己率先犯下的错误，带着我那个更快的求解器——是把那15天当作一个用更狠地计算就能解决的速度问题。它们不是。它们是一个确定性问题，而你无法靠向一个正在主动瓦解的世界索要更多确定性来解决一个确定性问题。你解决它的方式，是构建一个在不确定性下进行推理、在灾难到来之前演练它、并在被光明中信任之前先于阴影中自证的东西。那就是我们构建的引擎，它在我们的航空机组排班AI解决方案中有完整的描述。

今夜某处有一个运营控制中心，那里的视频墙一片平静与绿色，一台机组求解器正如设计般在它的批处理周期中嗡嗡运转。我们所做的工作，是为了那个房间转红的夜晚——当电话打不进来，配对断裂得比任何人记录的速度都快，一名调度员伸手去够白板，因为那套软件所要求的确定性已悄然离场之时。整件事的全部意义，就是要确保在那个夜晚，这台机器仍然诚实地推理着一家它已无法完整看清的航空公司。