软件定义战争：跨越两大软件领域的鸿沟

软件定义战争已成为国家安全的现实图景，推动军事行动重心从硬件向软件转移——软件乃“列装防御之每一武器及配套系统的核心所在”。大西洋理事会《2025年软件定义战争委员会最终报告》将软件定义战争界定为“向既有及未来防御系统持续集成与交付前沿技术及领先互操作软件”的能力。报告强调需借助人工智能（AI）提速，呼吁国家安全机构“采办并维持统一的共享平台，以支撑并加速AI解决方案端到端的开发、部署与治理”。

本文聚焦大西洋理事会报告中指出的软件定义战争两大企业级挑战，探讨软件工程实践如何切实应对。其一为软件流水线、人才与资源的短缺；其二为DevSecOps应用的阻碍。软件工程是对软件赋能系统全生命周期施以“系统化、规范化、可量化方法”的学科。纵观《软件工程知识体系》（SWEBoK）各版本的演进，过去四十年的进展表明软件永无“完工”之时——随着软件能力的持续提升，其面临的挑战与机遇亦同步增长。

软件工程既重代码（功能指令），亦重架构（系统质量属性）。尽管AI系统的机器学习（ML）软件算法独具特性——基于模型、可自主学习新范式、依统计建模产出结果——但其开发与维护过程，本质上仍类同于软件密集型系统的设计、构建、部署与优化。

软件定义战争：一个演进中的概念

陆军部（DoW）长期以来致力于实现软件定义控制。例如，上世纪70年代末开展的软件定义无线电（SDR）研发项目，旨在以可通过软件配置与重构的设备取代互不兼容的旧式电台。笔者曾任纽约州罗马市格里菲斯空军基地空军研究实验室指挥官期间，团队在“简易软件可编程嵌入式架构”（SPEAKeasy）项目中研制出首款开放式架构SDR。SPEAKeasy技术使单台设备即可与陆、海、空三军电台通信，并为后续规模更大的“联合战术无线电系统”（JTRS）奠定了技术基石。

艾伯茨、加斯特卡与斯坦在1999年发布的《网络中心战：开发与利用信息优势》报告中阐述了软件定义网络的概念。近年来，陆军部的“梅文计划”通过将ML应用于海量数据分析，进一步推动了软件定义战争的发展。本十年间，“全域联合指挥与控制”（CJADC2）倡议强调采取综合手段，“跨所有域、联合伙伴”行动，“以相关速度交付信息优势”。当前，陆军部正通过“AI赋能能力开发”加速推进软件定义战争。

尽管软件定义战争需求迫切，但其落地并非必然，高度依赖安全且始终可用的网络连接。战术边缘典型的拒止、中断、间歇与受限（DDIL）环境，使系统易遭网络攻击与运行中断。弹性设计虽常能克服此类挑战，但仍存在其他障碍，如AI模型优质训练数据匮乏、采办流程迟缓、具备相应技能与专业知识的人才短缺，以及文化层面的抵触情绪。

大西洋理事会报告中的软件关切

大西洋理事会该报告的委员涵盖前陆军部官员与软件行业领袖，其在报告中建议陆军部“投资于软件与AI开发的支柱……赋能终端用户高效生成并实战化软件与AI……”。报告列举了实现软件定义战争的七大“现状”级企业挑战，本文重点探讨其中两项：

陆军部各机构现有软件流水线、人才与资源严重不足，难以满足软件定义战争的需求。
陆军部缺乏全部门性的软件中心文化，阻碍了现代DevSecOps的应用——后者本可促进快速迭代与再认证。

大西洋理事会所描述的每种“现状”均对应一个愿景中的“目标”状态，二者之间存在类似杰弗里·摩尔《跨越鸿沟：向主流客户营销高科技产品》所述的鸿沟。摩尔分析指出，鸿沟存在于早期采用者（热衷者）与早期大众（务实者）之间，后者群体更为庞大，是赢得市场的关键。就陆军部与国家安全而言，这一鸿沟体现在科学技术（S&T）研究原型创新与正式列装项目确立之间。本文认为，依托创新的软件工程最佳实践，可有效弥合这两项挑战所对应的“现状”与“目标”状态之间的鸿沟。

弥补软件流水线、人才与资源的短板

若陆军部无法弥补此短板，则将难以构建可复用能力，无法实现软件与AI解决方案的快速、规模化开发、部署、互联与治理。报告所描绘的“目标”状态要求综合施策：开展软件与AI素养培训、定向招募人才、规划职业发展路径，并深化与商业软件企业的合作。

软件工程如何缓释风险、加速价值兑现

软件工程通过强调周期时长并确保与既有系统互操作的软件度量指标，加速了AI系统的“价值兑现”进程，从而降低陆军部面临的风险。软件工程可从以下五方面助力缓解流水线、人才与资源的短缺：

倡导全局观。 鉴于基础设施重建成本高昂、干扰大且资源密集，首要步骤是使AI系统需求契合任务需要与运行环境。继而，为AI模型寻求优质、相关且具有代表性的训练数据，并使分析人员与操作人员能够识别并上报错误以改进系统。始终将安全性置于首位，内置“预防、规避或增强对危险抵御能力”的机制，因为缺陷与漏洞可能在复杂的AI供应链中跨供应商模型传播。当AI系统失效时，安全事件响应要求数据提供商、开源库与框架、模型中心、分发平台及第三方AI分销商（即人工智能安全事件响应团队（AISIRT）所提供的各项能力）开展多方协同的漏洞挖掘工作。此外，全局观还需延伸至合作伙伴机构。这些机构需在（理想情况下覆盖全部）以下领域具备专业能力：软件工程、软件系统系统工程、网络安全、计算机科学、AI与机器学习，以及联邦软件采办政策与实践。（“若团队在需求确定环节表现欠佳，则项目、产品或二者均可能面临成本增加、进度延误、中途取消及缺陷频发等困境。”——《SWEBoK》第1章）
度量从首次快照（提交）至生产的周期时长。 通过扩展度量视角——涵盖模型提示、编码、人工或AI代理评审、合并与部署各环节——AI辅助的开发团队可精准定位并解决编程、测试与部署中的瓶颈。然而，若AI系统部署后缺乏持续监测，上述收益将付诸东流。AI系统持续学习，除非进行再训练，否则可能产生错误结果。（测试详情参见《SWEBoK》第5章，软件工程管理参见第9章）
确保可扩展性辅以速度。 可扩展AI是指“算法、数据、模型及基础设施能够适应任务需求在规模、速度与复杂度上的要求”。可扩展AI基础设施——涵盖优质数据、可复用流水线、迭代开发（如DevSecOps）及API部署——能够将AI算力从数据中心导向战术边缘，前提是需通过加固与弹性架构克服DDIL计算环境引发的问题。例如，SEI与卡内基梅隆大学研究人员正探索如何在边缘设备上部署高级分析能力，并将零信任架构延伸至DDIL环境下运行的武器系统。（AI基础设施与软件构建共享“产出可靠、高效系统”的目标——《SWEBoK》第4章）
确保系统互操作性。 陆军部应推动在代码开发中采用灵活标准，并推行模块化架构方法。“未来机载能力环境”（FACE）等标准可确保软件设计的兼容性。一项关键举措是陆军部强制推行“模块化开放系统架构”（MOSA），该架构通过灵活的标凖化实现“即插即用”，允许在不重新设计系统的前提下增改模块，从而增强互操作性并减少供应商锁定。（例如，《ISO/IEC/IEEE 12207（软件生命周期过程）》可确保互操作性被工程化地植入软件密集型系统——《SWEBoK》第2章与第12章）
界定与发展软件能力。 陆军部应制定软件从业人员资质与认证标准，并提供相应的培训与教育机会予以支撑。在此方面，软件工程师与系统设计师可借鉴“总统杯网络安全竞赛”的经验，聚焦于识别与锤炼软件人才。（SEI已发布其连续六年支持该赛事的回顾总结。）此外，陆军部可搭建人才市场，使从业人员能够根据自身技能匹配任务需求。SEI发布的“技能成长”（SkillsGrowth）概念验证平台，允许从业人员基于专业技能构建个人档案。急需相关技能的管理者可利用这些档案精准定位所需的数据/AI人才。通过推广AI素养教育，建立围绕AI的通用话语体系，促进协作并消除对AI能力的误解，可进一步巩固上述努力。（参见软件工程专业实践——《SWEBoK》第14章）

破除软件中心文化的缺失

现探讨另一项“现状”级挑战，即缺乏能有效运用DevSecOps以支持系统开发部署快速迭代的软件中心文化。委员会报告指出，若不扭转此文化，陆军部将无法从DevSecOps投资中获得加速交付、降低成本、产品安全及持续运行授权（cATO）的收益。报告勾勒的“目标”状态愿景包含：持续的职业发展与人才管理、深化的产业协作，以及强有力的软件管理领导力。

软件工程如何促进持续改进

陆军部旨在维持战略优势，这意味着其必须比对手“进化更快、适应性更强”。为此，需有效化解其辉煌历史、庞大规模及传统系统工程方法论积淀所带来的潜在掣肘。陆军部自1789年以来便融入美国历史，而陆军、海军及海军陆战队的历史更可追溯至1775年《独立宣言》发表之前。这段悠久历史印证了其在保障国家安全方面的成功。再者，当今美军现役、预备役及文职人员总数逾280万，系美国最大雇主。历史悠久的大型组织往往难以保持敏捷，易陷入“创新者的窘境”。克莱顿·克里斯坦森1997年的著作深入剖析了成功企业为何在面对颠覆性技术（如现代软件实践与AI）时可能折戟。大型企业倾向于忽视那些初期仅吸引小众市场（如热衷者）的创新。然而，当这些创新演进至足以成为主流选择时，若老牌组织未能自我革新并采纳创新，则将丧失先机。

为在软件中心的技术格局中提升组织敏捷性，陆军部可考虑采取以下四项行动：

为AI子系统演进软件采办路径（SWP）并设立专项子路径。 正如负责采办与保障的陆军部副部长办公室及首席数字与人工智能办公室所倡导，设立SWP的AI子路径将加速最小可行能力版本的部署。在SEI组织的2025年6月AI采办研讨会上，与会专家亦建议扩展SWP以涵盖AI采办。（《SWEBoK》第9章论述了软件工程管理的关键考量，包括采办。）
培育全部门性数字生态系统。 陆军部的产业伙伴采用“左移”策略，以“相关速度”交付“弹性软件能力”。《国防部软件现代化战略》及大西洋理事会报告均呼吁构建全部门性数字生态系统，以推广2019年《国防创新委员会软件采办与实践报告》所推动的各项进展。由此，实现软件定义的陆军部将在采办、开发、部署及维护响应新兴威胁的系统方面展现敏捷性。（软件工程运营与方法详见《SWEBoK》第6章与第11章）
验证流程。 SEI研究人员通过牵头构建专业的AI工程学科，推进陆军部关于创建可行、可信、可扩展AI系统的愿景。该学科将软件流程的重点重新聚焦于AI系统开发与运行的迭代式持续改进。AI工程立足于三大支柱：稳健与安全、可扩展、以人为本。三者合力推动AI系统开发从研究原型迈向服务于国家安全的可靠安全系统。（《SWEBoK》第10章详述了软件开发与部署涉及的各类技术与组织流程。）

此外，SEI研究人员还参与了另外两项强调AI与安全性的认证模型开发。其一为与埃森哲联合创建的“AI采纳成熟度模型”。该模型拓展了成熟度与能力概念，助力组织更安全地应用AI技术——鉴于AI系统扩大了攻击面并招致新型攻击。鉴于应对新型威胁至关重要，SEI与陆军部联合约翰斯·霍普金斯大学应用物理实验室共同开发了“网络安全成熟度模型认证”（CMMC）。CMMC强制要求国防工业基础（DIB）企业通过验证其对模型安全要求的依从性，以保护受控非密信息（CUI）与联邦合同信息。详细规定CMMC的《联邦法规汇编》第32篇第170部分，明确要求多数作为AI平台的云服务提供商（CSP）须获得FedRAMP授权。

构建对AI系统的信任。 尽管AI仍是提速的关键驱动力，但可信度仍是一大挑战，原因在于AI模型本质上是统计近似，且算法具备持续学习能力。部署期间，这些特性叠加大型AI模型固有的不透明性，阻碍了可用性、透明度与可解释性可靠指标的获取。人类需要这些指标以确信AI提供的信息。此外，SEI一项研究发现，大语言模型“易出现事实错误、幻觉（即捏造新信息）、过度自信，且易受对抗性攻击”。SEI受陆军部研究与工程副部长委托，试点成立了“可信测量与评估中心”（CaTE），旨在建立评估操作员信任度的方法，并确保AI系统的可信性。该倡议发布了《致命性自主武器系统（LAWS）伦理行为保障参考架构》及《促进LAWS可信度的CaTE开发与测试、评估、验证、确认（TEVV）指南》。（《SWEBoK》第3、4、12及13章涉及软件可信性的相关层面。）

软件定义战争与国家安全的有效体系

针对软件定义战争的健全软件工程实践，能够通过安全供应链确保弹性AI系统的交付。由此形成的系统将具备以下特质：