军用软件工厂：该谁来干，军代表还要不要管？

装备质量编辑部 · 军代表履职科普

外军软件工厂搞得风生水起，我军也在加紧建。但一个根本问题常被绕开：软件工厂到底该承制单位干，还是军队单位自己干？军队单位再把活包给承制单位，还算软件工厂吗？更关键的是——不管谁干，军代表还用参与质量监督吗？今天把这三问一次讲清。

一、先搞清：什么是“软件工厂”

软件工厂不是一栋楼、一群码农，而是“人 + 流程 + 工具链”的工业化持续交付能力：DevSecOps 流水线、CI/CD、自动化测试、标准化环境与发布通道。它的核心不是“写代码快”，而是能持续、可信、按需地把软件送到部队手里。

一句话——硬件工厂产出装备，软件工厂产出“可随时部署的战斗力”。理解了这一点，后面“该谁来干”才有谈的基础。

二、外军怎么干的（软件工厂发展）

美军的拐点在一次著名的失败之后。空军耗资十亿美元的 ECSS（后勤现代化系统）烂尾，反过来催生了 Kessel Run（2017，空军）——一支小 Agile 团队，几周就交付了能用的作战软件，后升格为 PEO Digital。此后各军种纷纷建厂：

外军有一条共识理念：“You can't buy agility”（买不到敏捷）——你能买到一套软件，但买不到“持续交付、持续迭代”的能力。所以工厂的能力本体要有机（军队自有），但大量使用承制单位工程师作为嵌入式增援，在工厂流程内干活。能力有机、人手混合，是外军的现实答案。

三、该承制单位干，还是军队单位干？

这不是二选一，要拆成“本体”和“活计”两件事来看：

结论很清晰：军队单位持有工厂能力（平台、权限、标准、放行），承制单位作为工厂的有机组成部分或承接非核心部分——既能保住交付主权，又能借力产业效率，是最优解。

四、军队单位包给承制单位，还算软件工厂吗？

这是最锋利的一问。区分两种“包”，结论完全不同：

判据就一条：谁掌握“交付主权与持续部署能力”。包出去≠不算工厂——只要你掌握平台、权限、标准与验收放行，承制单位在你流程里干活，它仍是你的工厂；一旦从需求到上线全包出去、自己只盖章，那就退回了传统采购，不是工厂。

五、不管谁干，军代表还用参与质量监督吗？

答案：要，而且监督形式必须升级。

软件早已武器化，一行缺陷就是一处战斗力风险。GJB 9001C《质量管理体系要求》、GJB 5708A-2023《装备采购合同监管通用要求》、GJB 5710A-2023《装备订购合同监管要求》的监视与合同监管，同样覆盖软件。上期讲过——军代表是用户的眼睛；对软件，部队关心的是“好用、安全、顶用”，不是“代码完成”。即便工厂是军队有机自建，也不能“自己考自己”，仍需独立验收与作战试验（呼应上期 DOT&E 独立 OT 逻辑）。

监督从“终端检验”转向“持续监督”，重点落在四处：

军代表不写代码、不跑流水线，但必须：复核技术状态变更（接上期“不批变更、但要盯变更后质量”）、见证独立测试、确认质量门确实有效、把用户验收标准嵌进工厂流程。软件标准族里，GJB 5000B《军用软件能力成熟度模型》、GJB 438B《软件开发文档通用要求》、GJB 439B《军用软件质量保证通用要求》、GJB 2786A《军用软件开发通用要求》都是抓手。

六、外军监督启示

美军即便有机软件工厂，也逃不开监督：安全认定走 RMF（风险管理系统），并推行 cATO（持续授权）——信任流水线内置的安全门，实现持续部署；而独立作战试验仍由 DOT&E 及军种 OT 社区执行，专从使用者角度验作战效能。

这恰好印证了上期的用户代表逻辑：工厂负责造，独立监督负责替用户验。无论工厂有机还是混合，军代表就是那双“替用户看、替用户说”的眼睛。

七、结语

软件工厂建在谁手里，决定的是交付主权；军代表在不在场，决定的是用户利益有没有人守。工厂可以有机，也可以混合——但用户的眼睛不能闭。无论代码出自军营还是厂房，军代表的监督，一个都不能少。