Boom创始人总结XB-1超音速飞机快速研发经验

Blake Scholl 2025年8月10日 116 11 17 分享 Boom 快速高效开发硬件经验系列文章的第一篇

XB-1 是全球首架独立研发的超音速喷气机，于2025年1月首次突破音障。它由一支仅50人的团队完成设计、制造并成功试飞——相比之下，传统大型 aerospace 公司动辄需要数百甚至数千人。而我们所用的预算，大约只是传统方式所需资金的十分之一。

然而，回顾整个历程，我们意识到，如果从第一天起就拥有现在的认知，我们很可能可以用三分之一预算、三倍速度造出 XB-1。我们正在仔细梳理这些开发经验，用于 Overture 客机和 Symphony 发动机——我们的目标是让这两者成为史上最高效的大型飞机和发动机开发项目。

如何做到？当然，组建一支精干卓越的团队这样的基础要素至关重要——但还有一些不那么显而易见的经验。每一条经验背后，都贯穿着一种重视迭代的设计哲学——致力于降低迭代成本，让我们更快拿到硬件、更快改进设计。

在本系列首篇文章中，我们将深入探讨第一条关键经验：如何自研工程软件，把软件工程师派驻到硬件工程团队中。

大多数 aerospace 设计工具和实践仍停留在1990年代——大量定制工程逻辑被困在 Excel 表格里，工程师之间的交接繁琐费时。一旦某个参数发生变化，重新运行分析既昂贵又耗时，严重限制了快速迭代的能力。

在 Boom，每位工程师都被要求会写代码，并且善用 AI。我们采取了一种非传统的做法：把软件工程师——通常好奇心强但几乎没有 aerospace 经验——直接嵌入硬件团队。

这些团队的文化至关重要，核心是我们称之为“共同创造”的理念。软件工程师需要学习他们所支持的硬件学科，并构建自动化设计工作流的工具。同样，硬件工程师也需要学会写代码，并在软件框架中贡献工程代码。核心目标是降低每次工程迭代的成本，让工程分析易于重复执行。此外，我们把软件工程的最佳实践——如自动化单元测试和持续集成——融入到硬件开发工作流中。

这种紧密协作催生了 mkBoom——我们的自研飞机设计软件。最初为 XB-1 创建的版本较为简单，如今 mkBoom 已大幅演进，成为设计 Overture 客机的关键工具。

mkBoom 全面自动化整机级设计分析，包括重量、推进和气动。我们可以在配置文件中以参数化方式定义一架飞机，然后按一个按钮。几分钟内就能得到整机性能的完整快速分析——mkBoom 会模拟飞机完成一次完整任务剖面（起飞、爬升、加速、巡航、下降、着陆）。过夜运行，mkBoom 可以执行更高保真度的仿真，获得更精确的性能理解。随着工程代码日益成熟，更好的工程分析方法被集成到 mkBoom 中。

这种做法大幅加速了工程进程，让小团队能够快速完成过去需要大团队、长得多的时间才能完成的工作。

但真正的魔力不在于节省时间——它有点像工程界的杰文斯定律：当工程迭代又快又便宜时，就能评估多得多的设计方案，从而发现好得多的设计。mkBoom 不仅让我们设计得更快——还让我们能够探索原本负担不起的设计空间，最终造出显著更好的 Overture。

事实上，正是因为 mkBoom，Overture 上的乘客体验将会有天壤之别。

大约18个月前，负责 Overture 乘客体验的工业设计师们取得了一项突破。他们首次想出了如何将一种非凡的座椅概念（目前仍是高度机密）装入一款细长的窄体超音速客机。但有个问题：这需要对机身做微妙的重新塑形，在关键位置增加几英寸空间……而我们估算这些改动会带来灾难性的1,000英里航程损失。Overture 需要4,000英里以上的航程来服务关键航线，我们承受不起损失1,000英里。看起来这事可能行不通。

但作为乘客，我们都渴望更好的客舱。所以我们挑战自己去找到办法。我们需要把那损失的1,000英里航程找回来。

此时，我们自研 Symphony 发动机的工作正全速推进，我们已经具备了在 mkBoom 中联合仿真 Overture 和 Symphony 的能力。

一架超音速飞机和一台超音速发动机都由无数设计选择构成。发动机风扇该大一点还是小一点？核心机该大一点还是小一点？机翼后掠角该大一点还是小一点？每一个设计选择都会在整个飞行剖面上产生连锁影响。例如，更大的风扇在起飞时更安静，但巡航时燃油效率更低。更大的核心机将拥有更强的跨音速推力——意味着飞机穿越音障（阻力最大的区域）的时间更短——但这以增加重量为代价。如果不测试大量组合，本质上不可能判断哪些设计选择能带来整体最优的飞机。

传统上，飞机和发动机由不同公司制造……这使得飞机/发动机之间的大规模联合设计迭代实际上不可能。但由于 Boom 同时设计飞机和发动机，我们决定放手一搏。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）