越航787慕尼黑擦机尾之后，我翻了三份历史事故报告

大家下次坐飞机的时候可以留意一下起飞那个瞬间。

发动机轰鸣，推背感把人按在座椅上，窗外的跑道标线一道道飞掠而过。发动机开到了最大？

其实未必。

只要跑道足够长、天气和载重都允许，航司几乎都会主动把起飞推力往下收一收。这个行话叫减推力起飞，图的就是靠这个来延长发动机寿命。

减推力起飞省下的是真金白银。高压涡轮里那些昂贵的单晶叶片，磨损跟工作温度的关系非常紧密，温度哪怕只压低一点，叶片寿命的延长幅度就比想象中要大得多。少推一点油门，叶片就能用得更久。

一台航空发动机大修一次动辄上千万美元，一支几十架宽体机的机队，光靠起飞少推一点这个操作，省下的维护费就是相当可观的了。

这笔账，全球各大航司都在算。

但是，当这笔精明的账遇上一个低级的错误，事情就可能在十几秒内出大问题。

在 2026 年 8 月 15 日，德国的慕尼黑，越南航空 VN34 航班，一架波音 787-9，在 4000 米长的 26L 跑道上起飞时出了个大问题。据 BFU（德国联邦航空事故调查局）确认，飞机抬轮明显偏晚，起飞过程中发生了机尾擦地，跑道末端区域有该机留下的轮胎痕迹。

图注：慕尼黑机场航拍全景。

据初步信息和影像分析，起落架可能碾过了跑道尽头的安全区甚至是进近灯光设施。

好在机上的 287 人全部安全落地，飞机放油盘旋近两小时后返航慕尼黑。但黑匣子里的数据解出来之前，这件事已经引出了一个问题：

起飞那一刻，发动机的推力到底用了几成？万一背后的数字算错了，会怎样？

一、慕尼黑 26L：BFU 目前确认了什么

先把官方确认的事实和各方猜测分开来看。

德国联邦航空事故调查局（BFU）已经依据 ICAO 附件 13 启动正式调查，截至目前确认的事实是：

• 2026 年 8 月 15 日 13:57（当地时间），VN34 航班从慕尼黑 26L 跑道起飞，飞机抬轮明显晚于正常时机。

• 起飞过程中发生了机尾擦地（Tail Strike）。

• 跑道末端区域发现了可归属于该机的轮胎痕迹。

• 飞机于 15:58 在 26R 跑道安全着陆。

• 飞行数据记录仪（FDR）和驾驶舱语音记录仪（CVR）已提取，数据正在分析中。

• 技术因素、人为因素和组织因素均在调查之中，尚未确定原因。

越南民航局（CAAV）官方确认：起飞后出现机尾触地和轮胎压力相关警告，机组放油后返航。

此外，根据对机组初步报告的转述：滑跑过程中，空速在跑道中段附近停滞了差不多两秒，随后才恢复，达到决断速度 V1；但是在过了 V1 之后，空速再次出现波动。机组判断剩余跑道已经刹不住了（无法执行中断起飞 RTO），便一把推到底（TOGA）继续起飞。

这就是我们目前知道的全部。实际输入了什么起飞重量、假定温度设定了多少、推力一开始设在什么档位——这些最关键的数据还没有公布，要等调查组分析完记录器数据才能还原。

网上流传最广的猜测是机组在电子飞行包里输错了起飞重量，导致算出来的推力和起飞速度都偏低。

从历史经验看，这也是完全有可能。但也要注意，现有影像中跑道上似乎有制动痕迹，制动系统的工作状态也可能是调查方向之一。

在 BFU 给出正式结论之前还不好作判断。

慕尼黑这件事，引出了一个值得聊的话题，当减推力起飞遇上算错的性能数据，到底会发生什么？我们不需要靠猜，其实历史上已经有调查完毕的事故，把整个过程记录得清清楚楚。

二、一笔省钱的账

我们先来聊聊减推力起飞到底是怎么一回事。

航空发动机全推力起飞（TOGA）时，高压涡轮的工作温度比巡航时要高得多。

图注：NASA 能效发动机计划中的两件式单晶高压涡轮叶片

我们在前面说过，叶片的磨损跟温度的关系非常紧密，所以只要是跑道够长、飞机不太重、天气也还行的时候，没必要每次起飞都把温度拉到最极限。

具体怎么减，最常见的办法叫假定温度法（空客叫 FLEX，波音叫法不同，原理是一样的）。

图注：假定温度法使用一个经性能计算确认的更高温度作为控制输入

做法是在性能计算软件里输入一个高于实际外界温度的假定值。比如慕尼黑当天实际气温约 33 度，这个系统软件会根据跑道长度、飞机重量和安全余量反算出一个上限，哪怕外面是 55 度，这架飞机在这条跑道上也还是能飞得起来，那就把 55 度输进系统，发动机就按这个温度把推力往下收。

另一种办法叫固定减推力（Derated Thrust），发动机出厂时就认证了几个低于最大推力的固定档位（如 TO-1、TO-2），机组按需选用。

这些都是经过适航当局批准并且写进运行手册的标准做法。在数据正确的前提下，这套方法的安全记录经过了充分验证。

具体减多少没有一个适用于所有航班的固定比例，每次起飞的重量、跑道长度、气温和飞机构型都不一样，推力设定必须按当次条件计算。坐在客舱里凭推背感或是发动机声音，也判断不出发动机此刻出了多少力。

前提就是数据得输入正确。

三、当数字出错：墨尔本的一堂物理课

2009 年 3 月 20 日，阿联酋航空 EK407 航班，一架空客 A340-500，从澳大利亚墨尔本飞往迪拜，当时机上有 275 人。

这是澳大利亚交通安全局（ATSB）调查报告 AO-2009-012 的主角，也是这类事故调查中最常被引用的报告之一。

图注：EK407 擦尾后，A6-ERG 机腹后段留下的连续擦伤

图注：EK407 越过跑道末端时撞坏的进近灯架

图注：EK407 事件后 A6-ERG 机腹检查

副驾驶往电子飞行包里录入起飞重量时把数字打错了。飞机实际起飞重量361.9 吨，加上 1 吨临时变动余量，应该输入362.9 吨。结果倒好首位数字直接错了，362.9 被输入成了262.9，直接少了整整 100 吨。

机长在交叉核对时也没有发现这个错误。

系统按照 262.9 吨来算，给出的推力设定和起飞速度全都严重偏低，在它看来，这架飞机比实际轻了一百吨，四台发动机的推力自然被大幅压低。

飞机在墨尔本 3657 米长的跑道上加速滑跑。空速到了计算出的抬轮速度，副驾驶拉杆，机头抬了起来，但是飞机没有离地。就是因为这个速度是按 262.9 吨算的，可是飞机实际有 361.9 吨，机翼在这个速度下产生的升力根本托举不起这个真实的重量。

飞行员继续拉杆，机头仰角越来越大，直到机尾撞上跑道，一路拖出了一条清晰的擦痕，连跑道尽头外的好几组进近灯和 ILS 天线也给一起整坏了。

眼看跑道已经到头，机长一把推到全推力（TOGA）。飞机在跑道末端外的草地上才勉强离地，ATSB 的报告写道，飞机几乎是贴着机场围界设施的顶部飞过去的。

不过还好 275 人全部平安。

ATSB 的调查报告列出了两项主要因素（primary factors）：一是输入和检查环节都没有发现错误的起飞重量；二是起飞滑跑的性能异常，机组直到很晚才察觉。

报告还分析了背后的人因链条，当时该机用的是便携式 EFB，不跟飞机系统联网，数据是要靠人工来转录的；信息从好几个来源经过好几道手；机型、航线和载重频繁变化，机组很难建立起一个稳定的经验参照范围来做粗略的合理性校验。

一架满载 275 人、要飞 14 小时洲际航线的 A340-500，起飞全重不可能只有 262 吨，想想这架飞机光空重就超过 170 吨，但是机组没觉得这个数字有什么不对。

四、同一类错误，不止发生了一次

EK407 不是孤例。

2004 年 10 月 14 日，MK 航空 1602 号航班，波音 747-200F 货机，加拿大哈利法克斯机场。

加拿大运输安全委员会（TSB）的调查报告 A04H0004 认定：已经连续值勤近 19 小时的机组，在算哈利法克斯这一段的起飞数据时，"很可能"使用了上一航段（布拉德利）较轻的起飞重量（约 240 吨）。

TSB 的重建显示，机组使用的 Boeing Laptop Tool（BLT）性能软件有一个回退功能，上一航段的重量数据很可能被软件自动带回到性能计算页面，但是当时机组没有发现。

图注：TSB 使用 Boeing Laptop Tool 重建出的Bradley weight at Halifax界面

飞机在哈利法克斯装货加油后，实际重量已经到了约 353.8 吨，差了也快 110 吨了。

四台发动机的推力严重不足，机组在拉杆后，飞机的机尾剧烈撞地，机身后段在高速摩擦中断裂解体起火，冲出跑道坠毁。

机上 7 人不幸全部遇难。

图注：MK1602 事故现场及主要残骸位置分布

这是 ATSB 在其全球回顾研究中记录的，此类错误导致后果最严重的一起事故。

TSB 指出，连续值勤近 19 小时的极度疲劳，对 BLT 软件的培训不足以及未严格执行交叉核对程序等多个因素共同参与了这条事故链。

2017 年 7 月 21 日，日晖航空（Sunwing Airlines）的一架波音 737-800（注册号 C-FWGH），北爱尔兰贝尔法斯特国际机场。

英国航空事故调查局（AAIB）的调查报告 AAR 2/2018 记录了另一种错法，这次搞错的不是重量，是温度。

机组往飞行管理计算机（FMC）里输入外界大气温度（OAT）时，把实际的+16°C 直接打成了 -52°C。

温度差得天南地北，算出来的减推力设定自然也是错得离谱，发动机的起飞推力只有额定值的约60%（N1 仅 81.5%，正常应为 93.3%）。

飞机在跑道上加速得很慢，机组在快逼近跑道的尽头时才意识到不对劲，但是已经来不及中断起飞了。飞机越过跑道末端时撞上了尽头外 29 米处的一盏进近灯。

图注：FMC OPS U12.0 检出 OAT 偏差后，删除假定温度和起飞速度，并在 CDU 上显示告警

起落架勉强掠过灯座之后，飞机靠着不足的推力继续爬升，一直到跑道末端约 4 公里外、高度约 800 英尺时，机组才推到全推力。

AAIB 在报告中特别指出：

该机 FMC 的软件版本（U10.8A）没有自动对比功能，不会拿机组手动输入的温度去跟外部探头的实测温度核对。而更新版本的软件（U12.0）早在 2016 年就已经向运营人发布，具备自动交叉检查：如果手动输入的温度跟探头实测值偏差超过 6°C，系统会删除已录入的温度和减推力参数，并在 CDU 屏幕上显示警告信息。但是事发时这架飞机没有装。

三起案例，三种不同的输入错误，重量输入打错首位数字、软件自动带回上一航段旧数据、温度输入严重偏差。但是后果惊人地一致，推力严重不足，飞机在跑道上加速太慢，在跑道末端擦尾、弄坏设施后勉强升空，或者直接坠毁。

五、防线已经到了什么程度？

这类错误这么致命的话，难道就没有系统能自动拦一下？

答案肯定是有的，事实上也是一直在改进，只是目前覆盖的机型还远远不够。

空客在自家机型上已经装了好几层起飞监控。

最早是 2009 年 A320 家族上的 TOS1（起飞构型监控），后来扩展到 A330/A340，主要检查襟翼、配平这些构型有没有设错。

到了 2018 年，检查项更全的 TOS2 先装在了 A350 上，现在 A320 家族和 A330 也能用了。

同年 A380 上装的 TOM（起飞加速度监控，现也用于 A350）也是更直接，飞机滑跑只要是超过 30 节，系统就开始拿实际加速度跟理论曲线逐秒对标。

如果到 90 节时偏差超过 15%（意味着推力不足、飞机超重或异常阻力），屏幕上会直接跳出 T.O ACCELERATION DEGRADED（起飞加速度恶化）警告，让机组在 V1 之前决定是否中断起飞。

波音方面，贝尔法斯特事件后 AAIB 提出了安全建议，推动运营人将 FMC 软件升级到具备温度交叉检查功能的版本。

EASA 也随之行动了起来，在 2025 年发布的 NPA 2025-01 提出了部分大型飞机必须安装起飞性能监控系统（TOPMS），覆盖新机型和部分仍在产的老机型。截至我这篇文章发稿之前，这项提案还在走立法程序，尚未正式生效。

图注：起飞构型监控、加速度监控、FMC 温度交叉检查和监管提案分别覆盖不同风险，且取决于机型、软件与改装状态。

行业一直在做，工程防线也确实在一代代加强，可是现实是这些防护到今天还只覆盖了特定制造商的特定机型，离全行业标配还差得远。

在技术防线还没覆盖所有机型的当下，人工交叉核对仍然承担着最后一层残余风险。ATSB 在 EK407 的调查里分析了为什么这一层容易失守，飞行员飞的机型多、航线多、每次的重量和构型都在变，很难建立起一个稳定的"经验参照范围"来凭直觉判断数字对不对。

六、回到慕尼黑

那么 VN34 到底是怎么回事？

说实话，现在还不知道。

BFU 已经提取了记录器数据，正在分析。这些数据最终会告诉我们：发动机到底出了几成力？性能计算的输入到底对不对？空速停滞那两秒钟里，飞机到底处于什么状态？

调查结论出来之前，根据公开信息能做的，也就是列一列目前可能的方向：

• 性能计算参数错误（重量、温度或其他输入出错，导致推力和起飞速度设定过低）；

• 制动系统相关因素（公开影像中跑道上疑似有起飞阶段留下的制动痕迹，但来源和性质尚未确认）；

• 其他技术或操作因素（BFU 明确表示技术、人因和组织因素均在调查范围内）。

最终答案，只有 BFU 能给了。

但不管慕尼黑这一次的具体原因是什么，EK407、MK1602 和贝尔法斯特这三起案例早就把一件事讲得很清楚了：

现代民航在发动机、液压、飞控这些硬件上搭起了层层冗余，偏偏在起飞前录入数据这一步留了个漏洞。软件校验、构型监控、加速度比对——工程防线正在一代代补强，但在所有机型全面覆盖之前，程序、软件、人机界面和人工核对之间的缝隙，仍然是整条安全链上最薄的一环。

这是减推力起飞这笔精明的经济账背面，用最小字号写着的一行免责声明。

本文关于 VN34 相关事实以德国 BFU 官方通报和越南民航局 CAAV 公开信息为依据。

机组初步报告的详细滑跑序列来自对机组初报的转述，BFU 正式调查报告尚未发布，所有技术方向以正式报告为准。

历史案例引用来源：ATSB 报告 AO-2009-012、加拿大 TSB 报告 A04H0004、英国 AAIB 报告 AAR 2/2018。

参考：Airbus Safety First 技术说明、EASA NPA 2025-01。