洛克希德联手 OpenAI 应对 F-35 挑战，但验证才是真正的考验

洛克希德联手 OpenAI 应对 F-35 挑战，让这家 AI 公司与负责复杂数学、物理和先进传感器的 F-35 工程师并肩合作。这项合作只是更大规模试验的一部分。Lockheed Martin 表示，该公司目前在业务中使用 55 个大语言模型，而非将运营全面押注于单一供应商。

Lockheed Martin 技术与战略创新高级副总裁 Sarah Hiza 在 2026 年 10 月 2 日一次关于先进国防 AI的采访中介绍了这种与模型无关的策略。她表示，公司会在部署前测试 AI，并将不同模型用于内部工作、工程问题、自主系统和军事系统。

关键并不只是某家国防承包商又采用了一款 AI 助手。洛克希德正在探究，前沿模型能否为工程决策提供支持——在这一领域，错误造成的后果远比一份有瑕疵的办公摘要严重得多。这让 OpenAI 的推理能力接受 F-35 项目在验证、安全和可靠性方面要求的检验。

这也揭示了国防技术领域更广泛的一场较量。通用 AI 模型承诺带来更快的问题解决速度和更广泛的知识覆盖；任务专用系统则优先考虑可预测的行为、受控的数据和广泛的测试。洛克希德的做法试图同时利用两者，而不将任何一方视为单独足够的方案。

洛克希德联手 OpenAI 应对 F-35 挑战，纳入 55 个模型的战略之中

洛克希德将 OpenAI 视为一名专业协作者，而非整个公司的智能层。

Hiza 的披露为这项合作提供了一个更具体、也更有价值的框架。据报道，OpenAI 人员正与 F-35 团队合作，处理与先进传感器能力相关的高难度数学和物理问题。洛克希德尚未公开涉及哪些模型、具体的传感器问题是什么，或由此产生的任何成果是否会进入实际飞机的软件系统。

这些未披露的信息很重要。“并肩合作”可能对应多种参与层级。OpenAI 可能帮助工程师探索方程、审查代码、生成候选方案、整理技术文献，或加快仿真速度。这与将商业大语言模型置入飞机内部，或允许其作出飞行决策并不相同。

公开描述中没有任何信息表明，OpenAI 模型控制 F-35 传感器、处理机密作战数据或作出目标打击决策。现有证据支持一个更审慎的结论：洛克希德正将前沿 AI 作为工程辅助工具，在一个严格受控的项目中进行测试。

这种区别很容易被忽略，因为国防项目如今已出现多种形式的 AI。大语言模型在从大量训练数据中学习模式后，生成或分析语言、代码和其他结构化信息。相比之下，自主飞行系统会感知环境，并在既定任务约束下选择行动。

两者都属于广义的 AI，但所需证据并不相同。一个能为工程师给出有用推导的模型，并不会因此自动具备部署到安全关键飞机上的资格。其结果仍须经受数学审查、仿真、硬件测试、网络安全检查，以及 F-35 项目既有审批流程的检验。

洛克希德使用 55 个模型，表明其认识到这种分工。适用于文档检索的模型未必适合源代码分析。获准用于非机密行政工作的系统，可能被禁止访问敏感工程材料。在标准化数学题上表现良好的模型，也仍可能在异常传感器行为面前失效。

公司的模型无关立场也降低了对任何单一供应商的依赖。洛克希德可以比较输出结果，按敏感程度分配任务，并在其他选项表现更优时替换模型。在模型能力、许可条款、安全控制和政府要求都可能迅速变化的市场中，这种灵活性颇具价值。

不过，使用更多模型也会带来自身负担。每个获准系统都需要评估、访问控制、监测，以及管理其数据的规则。模型多样性能够避免供应商锁定，但如果洛克希德未能维持统一的验证标准，也可能造成碎片化环境。

因此，这项备受关注的合作只是更广泛运营模式中的一次测试。洛克希德并未押注 OpenAI 能解决所有国防问题。它正在检验 OpenAI 能否帮助专家处理一类定义明确的难题，同时由人类保留验证结果的责任。

为什么 F-35 传感器工作提高了对 AI 推理的标准

如果工程师无法证明一个更快的答案为何正确、又会在何处失效，其价值便会消失。

F-35 旨在将多个传感器的信息整合为一幅连贯图景，供飞行员使用。这一过程通常被称为传感器融合，它整合各项观测结果，使飞机能够识别、跟踪并确定相关目标的优先级，而无需飞行员独立解读每个传感器。

先进传感器的开发涉及物理学、信号处理、软件、概率学和硬件约束。工程师必须从噪声中分辨有用信号，处理不确定观测，并评估系统在初始测试未覆盖条件下的表现。

前沿模型可以在这一工作中发挥作用。它能提出推导过程、将想法转换为代码、识别技术文档之间的联系，或生成测试案例。但它同样可能给出听上去令人信服、却包含细微数学错误的答案。

后一种可能性构成了核心约束。大语言模型基于已学习的模式预测输出。它们不会自动保证某个方程守恒了正确的量、某项仿真反映了物理现实，或生成的代码能在所有相关条件下安全运行。

答案并不是拒绝这项技术，而是将模型置于证据链之中。工程师可以将其输出与既有计算进行比较，使用独立工具复现结果，并在进行任何硬件评估前于仿真中测试候选方法。

洛克希德具备构建这类测试流程的经验。在另一项 F-35 工作中，该公司表示，其作战识别试验在飞行期间使用了一种战术 AI 模型，为飞行员显示器生成独立的识别结果。公司将这一活动称为 Project Overwatch，并表示飞行员仍处于决策流程之中。

这一案例并不能验证 OpenAI 合作的有效性，但它展示了洛克希德如何将 AI 生成的评估与采取行动的权力区分开来。系统贡献了另一项信息来源，测试则衡量其行为，而人类仍对作战决策负责。

工程辅助工具也需要类似的分离。模型可以加快探索，但不应成为最终权威。只有当领域专家能够复现相关工作，并将其与实测性能联系起来时，模型的贡献才具有可信度。

尚未解决的问题是，洛克希德如何评估这类贡献。公开模型基准提供的指导有限，因为它们很少复现机密传感器要求、异常运行条件，或错误结果带来的后果。洛克希德需要围绕实际工程工作流构建测试。

有用的衡量指标包括：通过专家审查的输出比例、修正后节省的时间、细微错误的发生频率，以及在陌生问题上的表现。评估人员还必须警惕自动化偏见，即人们过度信任机器生成建议的情况。

因此，“洛克希德联手 OpenAI 应对 F-35 挑战”不应被解读为聊天机器人正在独立设计飞机的证据。更准确的理解是，前沿 AI 已进入工程工具链。接受其工作成果的标准，仍由物理规律、测试和可追责的人类判断决定。

通用模型遇上国防级验证

主要的较量并非 OpenAI 与另一家模型公司之间的竞争，而是模型速度与可靠军事系统所需严谨纪律之间的对比。

商业 AI 开发强调快速迭代。供应商发布新模型、收集反馈，并提升其在广泛任务类别中的表现。国防项目则遵循不同节奏，因为系统变更必须满足安全性、互操作性、可靠性和任务要求。

洛克希德由 55 个模型构成的组合，试图在这两种环境之间架起桥梁。团队可以采用专业能力，而无需等待单一企业模型满足所有要求。与此同时，洛克希德必须防止快速试验绕过敏感项目所附带的控制措施。

数据处理是一条显而易见的边界。F-35 工程信息可能包含受出口管制、专有或机密的材料。洛克希德尚未公开说明 OpenAI 人员或模型可以访问哪些信息。读者不应推断，这项合作包含对敏感飞机数据的不受限制访问。

部署环境同样重要。通过公共云服务访问的模型，与运行在隔离且获政府批准环境中的模型，带来的风险不同。模型权重、提示词、日志、用户权限、保留设置和软件依赖关系，都会影响安全评估。

此外还有可复现性问题。同一提示词在不同模型版本或重复运行时可能产生不同答案。这种变化或许有助于头脑风暴，但会使工程记录和认证更加复杂。团队需要知道哪个模型生成了输出、它接收了哪些信息，以及审查人员如何确认结果。

模型更新带来另一项挑战。新版本可能提高总体基准分数，却改变其在某项狭窄任务上的行为。因此，洛克希德不能将批准视为永久有效。每项实质性变更都需要针对具有代表性的工程案例进行回归测试。

该公司此前的 AI 工作表明，测试是其战略核心。洛克希德曾介绍训练 AI 智能体协助飞行员，并将其置于研究人员能够研究信任、工作负荷和人机协同的环境中。其人类-AI 训练工作关注的是操作人员如何理解和监督机器行为，而不只是算法能否完成任务。

类似原则同样适用于使用语言模型的工程师。技术能力过硬的用户必须知道何时应质疑输出、可用哪种独立工具验证，以及如何记录任何模型辅助完成的工作。培训应涵盖失效模式，而不只是提示词构建。

模型无关的方法在这里带来了切实优势。Lockheed 可以在同一套内部评估集上比较多个系统。如果某个模型擅长代码、却在数学一致性方面表现不佳，就可以将其限制在更狭窄的角色中。如果另一个模型擅长技术检索、却无法满足数据控制要求，它就可以被排除在敏感工作流之外。

但仅靠模型选择无法解决信任问题。多个模型可能会重复同一种误解，尤其是在它们的训练数据存在重叠时。让第二个模型审查第一个模型，可能会制造出相互印证的表象，却无法提供真正独立的证据。

国防级验证需要采用与被测模型运作方式不同的工具。形式化分析、传统数值求解器、受控仿真、硬件测量和专家审查能提供更有力的检验，因为它们并不依赖同一种概率生成过程。

OpenAI 仍可在这一框架内创造实质价值。模型无需拥有最终决策权，也能节省工程时间。它只需足够频繁地生成有用的候选成果，使验证成本低于所节省的时间或获得的洞见。

这一计算将决定合作是否扩大。出色的演示可以启动一项实验。能够在经验证工程工作中带来可重复改进的成果，才能将实验转化为基础设施。

自主武器让人类控制问题更加棘手

Lockheed 的办公 AI 实验与其自主系统属于同一战略，但不应以同一风险标准评判。

Hiza 的评论将内部 AI 采用与自主能力及有人—无人协同日益增长的作用联系起来。有人—无人协同使人工操作的平台能够与自主或远程监督的载具协调行动。这一概念可以扩展机组的感知范围、分配任务，或让无人系统处于更危险的位置。

Lockheed 已经展示了这一未来的部分能力。在美国陆军演习中，该公司测试了可共享信息并协调任务的空中和地面系统。一项协同演示中，无人机为一套在城市环境中导航的机器人地面系统提供了监视引导。

Skunk Works 也在战术航空场景中测试了 AI。2023 年的一次演示中，两架有人驾驶的 L-29 飞机在模拟任务中充当无人载具的替代平台。Lockheed 表示，这项研究将为未来的自主能力和协同作战飞机开发提供参考。

这些项目有助于说明，为何与 OpenAI 的合作意义不止于生产力软件。更好的工程工具可以缩短从技术问题到候选自主能力之间的路径。它们可以帮助团队分析测试结果、编写软件、构建仿真，并更早发现设计冲突。

这种关联并不意味着大型语言模型将控制武器。公开证据并不支持这一说法。更直接的联系在于：AI 辅助工程能够影响 Lockheed 最终开发的系统、接口和自主软件。

这种影响仍值得审视。如果审查者过快信任生成内容，设计阶段引入的错误可能会延续至后续阶段。如果数据边界不清晰，敏感信息可能泄露。工具也可能影响工程师界定问题的方式，使其偏向于训练数据中频繁出现的方法。

作战自主性又增加了一层不确定性。军事系统必须在通信受损、传感器信息不完整，以及对手蓄意实施欺骗的情况下运作。在协作型测试环境中表现良好的模型，在对抗条件下可能会有不同反应。

人类控制依然至关重要，但这一说法可能掩盖实际问题：如果系统行动速度快到人无法理解，如果其解释具有误导性，或者一名操作员监管了过多自主资产，人就无法提供有意义的监督。

Lockheed Martin 首席技术官、曾任美国国防部首席数字与 AI 官员的 Craig Martell，强调的是人机协作，而非完全独立的机器认知。在 2026 年 3 月关于军事 AI 团队的讨论中，他描述了一种未来：飞行员与能够协助保护有人平台的自主飞行器协同工作。

这一愿景代表了一种角色分工。机器可以处理传感器输入、导航或执行有边界的任务。人类设定目标、解读情境、管理升级风险，并对需要判断的决策继续负责。

困难之处在于证明这种分工在压力下依然成立。测试必须涵盖模糊输入、相互冲突的指令、网络攻击、通信中断，以及正确行动是停止的情形。当罕见故障可能带来严重后果时，平均表现并不足够。

Lockheed 的公开演示显示了协调和飞行自主性方面的进展，但并未解决问责或部署规则问题。同样的谨慎也适用于其与 OpenAI 的合作。这项合作证明了严肃的实验投入，而非每一项技术和治理问题都已得到解决。

压力落在国防承包商和 AI 供应商身上

Lockheed 的方法迫使传统承包商和前沿模型公司证明，它们能够跨越彼此的制度边界开展运作。

对成熟国防承包商而言，压力来自行动更快的软件公司和自主系统专家。Anduril 和 General Atomics 等企业推动了模块化系统、快速飞行测试和以软件为中心的开发。它们的工作帮助使自主飞机和协同作战系统成为未来兵力规划的核心。

Lockheed 具备不同的优势。它了解飞机、传感器架构、任务系统、客户需求，以及 F-35 等项目的漫长生命周期。它能够将有前景的模型连接到真正了解难题所在的工程团队。

其挑战在于速度。55 个模型的组合能够鼓励实验，但大型组织可能难以将成功试点纳入获批的生产工作流。即使技术表现良好，安全审查、合同规则、碎片化数据和项目边界也可能放缓采用进程。

AI 供应商面对的是相反的问题。它们行动迅速，提供能力广泛的模型，但国防客户需要的不只是基准测试领先。供应商必须支持访问控制、可追溯的模型行为、稳定接口、严格测试，以及适配敏感环境的部署选项。

OpenAI 与 F-35 团队的合作让这些要求变得尤为清晰。成功的衡量标准，不是模型能否在演示中回答一个令人印象深刻的物理问题，而是工程师能否反复使用它，同时不削弱安全性或验证机制。

这项合作也可能给其他模型提供商带来压力。Lockheed 的模型无关政策为多家供应商留下空间，其中包括商业、开放权重和内部开发系统的提供商。每个模型都必须通过任务表现和运营适配性证明自身价值。

这种竞争对 Lockheed 有利，因为它可以在拥有选择权的地位上进行谈判。它可以避免围绕单一提供商重构所有工作流，并降低模型退役或政策变化造成的扰动。它还可以将内部系统保留给不适合使用外部服务的任务。

竞争对手也会寻求类似组合。国防公司已经在投资数字工程、自主能力、仿真和 AI 辅助分析。真正的差异化因素，将是把这些要素连接为可审计流程的能力，而非员工可使用模型的数量。

政府客户同样面临压力。采购官员需要既能识别软件更快开发周期、又能保留保障措施的评估方法。他们必须决定哪些模型变更需要重新测试，以及哪些证据能够支持在不同风险类别中的使用。

采购措辞将影响市场。对数据来源、模型监控、人类授权、事件报告和独立测试的要求，可能决定哪些供应商能够参与。模糊的要求可能鼓励令人印象深刻的演示，却无法产出可靠的作战系统。

在商业 AI 与国防工程边界日益模糊之际，Lockheed 借助 OpenAI 解决 F-35 挑战。该合作让 OpenAI 接触到要求异常严苛的技术问题，也让 Lockheed 获得另一种推理和软件能力来源。

双方都不会自动获得优势。OpenAI 必须证明，通用模型能够在限制严格、后果重大的工作流中作出贡献。Lockheed 则必须证明，大型承包商能够迅速评估这些模型，同时不降低自身工程标准。

结果的影响将超出一架飞机。如果合作带来经过验证的改进，其他承包商和政府项目将有更充分理由扩大前沿模型试验。如果相关工作带来高验证成本或安全担忧，专用且内部受控的模型将获得更多支持。

三个信号将显示合作是否奏效

下一阶段应通过披露的验证、可重复的部署和明确的运营边界来评判，而不是通过关于 AI 领导力的更宽泛说法。

第一个信号是具体、可由独立人士理解的工程成果。Lockheed 无需披露机密传感器细节，但可以说明工作类别、验证方法和可测量的改进。一项有价值的披露可能会说明，模型辅助分析缩短了某个明确工作流，同时产出的结果通过了与传统工作相同的技术审查。

没有这些证据，这项合作仍只是一项有趣的实验。经验证的结果将强化前沿模型能够为先进航空航天工程作出贡献的说法。反复修正、输出不一致，或无法记录收益，都将削弱这一说法。

第二个信号，是从孤立合作转向获批、可重复的工作流。这需要明确的模型访问规则、版本跟踪、评估标准和人工审查。最有力的证据将是多个工程团队在同一控制框架下采用该工具。

单纯的扩展并不能证明技术成功。公司可能在尚未完全理解工具价值前就将其分发。读者应关注更广泛使用与专家验证后可衡量的接受率相结合的情况。

第三个信号，是工程辅助与作战自主性之间更清晰的边界。Lockheed 的 AI 组合涵盖办公任务、设计工作、仿真、感知和无人系统。公开沟通应区分哪些模型为人提供支持、哪些算法操作设备，以及人类在哪些环节保留决策权。

未来的飞行演示将提供其中一部分证据。Lockheed 在一体化空中优势方面的工作已涵盖数据共享、无人机控制，以及对政府自主系统项目的支持。若测试纳入通信受损、对抗性条件和操作人员工作负荷等因素，将使该公司关于人机协同的主张更具可信度。

这些信号也能揭示 OpenAI 在其中的定位。该公司可能仍将重点放在工程分析，而非已部署的自主系统上。这依然是重要角色，因为设计决策、软件开发和测试结果解读，早在飞机起飞之前就已塑造作战能力。

因此，审慎解读最具参考价值。Lockheed 已为前沿 AI 进入全球最严苛的航空航天项目之一开辟了一条严肃路径。但它并未证明通用模型能够绕过传统工程控制机制，也未声称它们应当这样做。

对开发者而言，启示是模型质量只是采用过程的一部分。可追溯性、评估设计、安全的数据处理和人工审核，共同决定 AI 输出能否转化为可用成果。企业采购方应询问供应商如何处理模型变更，以及如何在其自身任务上验证结果。

知识工作者面临的是同一问题中没那么戏剧化的版本。AI 可以加速研究和起草，但只有重新与可靠证据建立联系，其输出才具有价值。通过可搜索的知识库整理源材料，有助于团队保留从主张到验证的完整链条。

“Lockheed Taps OpenAI to Solve F-35 Challenges”这句话很吸引眼球。真正的故事，是围绕这些挑战建立的验证体系。请关注有据可查的工程成果、可重复的受控部署，以及对人类权限起止边界的精确说明。这三个信号将表明，这项合作究竟会改变航空航天工程，还是仅停留在一场前景可期的试验。