美军砸了重金的软件工厂,正在被自己人用一张PPT＂杀死＂

2017年美国空军启动"Kessel Run"以来，已建立约50家软件工厂。但截至2025年，能持续交付真实成果的只有一小部分。本文分析美军软件工厂的运行现状与深层困境——不是技术问题，而是文化问题，并探讨对我军建设的核心启示。

从表面上看，美军软件工厂的质量管理体系设计得相当完整。其核心是DevSecOps（开发-安全-运维一体化）方法论，强调"安全左移"——把安全防护贯穿软件从设计到部署的全生命周期。

具体实现路径包括三条并行的钢轨：

第一，引入DORA指标作为绩效硬约束。DORA即DevOps研究与评估团队，隶属于谷歌，建立了业界公认的软件交付四大黄金指标：部署频率、变更前置时间、变更失败率和故障恢复时间。美军主张将使命效能（mission impact）作为软件的最终衡量标准，拒绝用自报数据粉饰业绩。

第二，构建自动化工具链保障质量。美军要求各软件工厂在一体化平台上实现自动化构建、测试与部署，通过标准化的代码仓库、容器编排、持续集成/持续交付（CI/CD）流水线和自动安全扫描来把关质量，减少人为干预造成的错误。其陆军软件工厂通过"CReATE"平台将软件研发交付压缩到100天以内，已研制发布20多个应用程序供46000多名士兵使用。空军"Platform One"平台则提供一站式DevSecOps支持，将安全授权周期从数年缩短至90天。

第三，通过政策文件明确质量责任制。美军发布了一系列战略文件和指南，要求所有新采办项目必须采用敏捷开发模式，将软件开发速度提升至与作战需求相匹配的水平。2025年还进一步发布了《软件现代化实施计划2025-2026》，试图用制度保障软件质量交付。

这套体系乍看之下十分漂亮。如果仅凭这一层逻辑下结论，答案会是肯定的——美军的软件工厂不仅有质量管理体系，而且设计还很"高端"。

可为什么运行效果却不如人意呢？

先看一组数据。2022-2023年美国政府问责办公室审查发现，这些软件工厂虽然数量激增，但关键武器系统的软件升级周期没有同步缩短。F-35第4批次的软件交付持续延误，空军多项指控项目因返工频繁、系统不稳定而备受批评。2025年报告进一步显示，24个主要信息技术项目中有一半存在成本超支，超支范围从610万到8.155亿美元不等，另有7个项目出现最长四年的进度延迟。

问题的根源在哪里？答案非常扎心：美军软件工厂的问题不在技术，而在文化——是根深蒂固的"硬件中心"制度文化与"软件敏捷"开发模式的激烈碰撞。美军推进软件工厂发展最被低估的挑战，就是原有的硬件工作模式与软件敏捷模式的"文化适配"，而这个坑至今没有被成功填平。具体来说有三点：

第一，"创新剧场"代替了真正的成果交付。许多软件工厂将主要精力投入搭建内部平台和制作精美的汇报演示材料，以"看起来创新"来争取资源和关注，实际交付的软件少之又少。正如一篇报告直言道："它们交付的是PPT，而不是软件。"

第二，硬性绩效指标与现实脱钩。不少软件工厂虽然建立了DORA指标，但关键绩效往往由团队自报数据，缺乏独立验证，导致指标变成了另一种"数字游戏"。数据显示，有75%的项目声称在6个月内完成交付，但大多数项目根本没有追踪软件是否真正解决了作战问题，也不问是否提升了使命效能。效率不等于效能，方向做对了比效率更重要。

第三，致命的人才结构问题是核心痛点。软件工厂的理想是培养出一批"穿军装的程序员"，让懂作战的人写代码。但现实中，真正能写高质量代码的现役军人少之又少。Kessel Run的长期内部矛盾就来自这里：开发工作高度依赖承包商，军方人员更多承担管理和沟通工作，而开发经验丰富的承包商能拿到的合同常常不够灵活，导致留不住人。

软件工厂被内部人员吐槽"走了回头路"——Kessel Run正从"现役军人与承包商混合开发"模式，转向由承包商负责编码、政府人员负责管理的传统模式。原本最有价值的内生动力——让作战人员直接参与代码迭代——正在逐步流失。

这三个困境叠加，使得美军软件工厂虽然名字里带"工厂"，却越来越像一个"表演舞台"——而不是真正的软件制造车间。

很多人可能认为，"先建设、后补体系"是合理的建设路径，毕竟"先把事情做起来再说"。但美军软件工厂的运行教训给出了一个截然相反的答案：没有质量管理底蕴，软件工厂越快交付、交付得越多，安全隐患和系统失效的风险就越早爆发。

美军问题的实质不是技术建设慢——从DevSecOps的角度看速度其实很快——而在于组织始终缺乏一套能够"内生驱动、持续改进"的质量管理文化。一个缺乏质量内驱力的组织，无论引进多先进的技术，最终都会被制度和惯性"拉"回传统的轨道。Kessel Run已经深刻警示了这一点——它虽然证明了敏捷开发可以改变军方软件生态，却没有成功把这种质量管理文化内化到组织制度中。一旦核心推动者（如空军部几位高水平技术官员）离职，改革就迅速停滞甚至逆转。

此外，如果一个软件工厂没有建立健全的质量管理和绩效追踪体系，就无法客观评估什么软件是有作战价值的，也无法识别研发过程中的瓶颈和缺陷来源。这会导致资源被消耗在大量无效迭代上，最终走向"软件烂尾"。

所以，对于"没有质量管理底蕴的军队软件工厂有前途吗"这个问题，答案是：没有质量管理，软件工厂只会是一个加速生产"烂代码"的流水线。美军用真金白银和数年的教训，替我们证明了这一点。

当然，写这篇文章不是要嘲笑美军。相反，兵者诡道。在软件定义战争的今天，我军建设自己的软件工厂是大势所趋。但如何建设，美军的经验教训非常有借鉴价值。

启示一：从顶层设计开始，把质量管理"内嵌"进软件工厂的DNA。质量管理不是软件工厂的"附加模块"，而必须是整个体系的核心基础设施。建议将质量管理体系从传统的"由监督方评定"转变为内嵌全流程的"工程化自动化质量保障机制"——从一开始就与DevSecOps流水线深度融合。同时，还应将软件工程的成熟度评估标准（如GJB 5000系列）与软件工厂的工程技术平台有机绑定，实现从需求分析、设计开发、测试验证到持续交付全过程的标准化与可追溯。

启示二：注重质量管理文化的培育，从依赖"能人"转变为依靠"体系"。美军软件工厂成败过于依赖少数技术官员。一旦这些关键人物离开，改革成果就面临倒退风险。我军应以体系化制度代替"关键少数"，即便团队或领导有所变动，质量管理体系依然能稳定运行。文化建设的过程较漫长，但从长远看是最有回报的投资，它将决定软件工厂能否真正融入军队的日常。

启示三：构建适合军队的复合型软件人才梯队体系。美军暴露的人才问题提醒我们，单靠现役军人学习编码是不够的。真正的差距在于现代软件工程的管理和采购人才极度短缺，而且很少有现役军人能快速补上现代软件工程师的角色。我军在软件工厂建设中应考虑引入文职技术人员、合同制软件工程师以及加强军民通用人才培养，形成可持续的人才梯队，确保质量管理体系有能力落实。

启示四：建立以"作战效能"为核心的绩效评价闭环，拒绝"形式主义创新"。美军软件工厂最核心的失败之一，就是没有把软件交付跟"作战效能"硬性挂钩，导致大量代码交付没有解决真实作战问题。每一行代码都要回答一个问题：它为打赢战争做了什么贡献？以结果为导向的效能评估，才是软件工厂的核心灵魂。

如果让我用一句话来概括这篇文章的核心，那就是：软件工厂要真正管用，质量管理就不能只是写在墙上的标语，而是刻在代码里的基因。

它必须像美军设计DevSecOps的初衷那样——把安全嵌入每一个代码迭代环节；但更要像美军始终没能做到的那样，把组织文化和制度同步嵌入质量管理体系，使其能持续生长、自我修复。技术可以引进，文化不能嫁接。美军用了50家软件工厂和数万亿美元的账单验证了一件事：任何不改造底层制度和质量管理文化的"软件工厂"，都无法摆脱滑向"创新剧场"的命运。

对我军来说，这是一次宝贵的先发"预习"机会。我们不需要重蹈美军覆辙，也不必把质量管理工作看作是"外加的负担"，而应从第一天起就把它当作这场军事信息革命里最根本的战斗力要素之一，用最高标准去构建软件工厂的质量管理体系。

软件定义战争的今天，每一行代码都在重新定义胜负的天平。你说质量管不管理？