从俄乌到美伊：软件工厂必须建在一线，而不是“换汤不换药的软件外包”

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

几场局部战争把一件事打明了：软件与 AI 已是战斗力的直接构成。俄乌的 DELTA、美伊的算法化打击，都在逼问同一个组织问题——我们的软件工厂，到底该建在哪？美军正用行动回答：告别固定建制、把能力嵌进作战单元。反过来说，若只是给传统外包换个“软件工厂”的牌子，等于新瓶装旧酒，战场上必然掉队。

一、战场已经变了：软件是战斗力，不是后台

先看两场战争给出的硬证据：

共同结论就一句：谁能在战场边缘快速迭代软件、把 AI 用到位，谁就握有主动权。软件不再是“交付即终点”，而是“边打边改、越用越强”。这是组织问题的总前提。

二、美军的答案：软件工厂告别固定建制，能力前出

美空军 Kessel Run（2017 年建）本是标杆软件工厂，早已在真实行动中立过功：2021 年阿富汗撤离的规划与态势感知、2022 年拉姆施泰因第 603 空中作战中心用 KRADOS 套件每天做空袭计划。但它所代表的“大建制中央厂”模式，正在被调整。

近期美军的一记调整很有信号意义：软件工厂正从“养一个固定建制的大厂”转向“把软件能力嵌入作战单元的小队”——编制在退，能力在前出。

为什么？固定建制意味着招人慢、流程重、与商用技术节奏脱节；而嵌入式小队贴近用户、端到端拥有交付、能随部队机动。这恰好印证了上期结论：工厂要下沉一线，而不是囤在中央规划部门。连美军都在“去建制化”，我们更没有理由把工厂做成一座远离战场的衙门。

三、对照：什么是“换汤不换药的软件外包”

最危险的陷阱，是给传统外包贴个“软件工厂”的牌子，本质一点没变：需求经多层转译、人员在远端、责任稀释、按人月计费、验收看文档。前几期讲过银行业的病灶（需求失真、责任稀释、归属感低、堆人不提质），若军软工厂只是“挂名工厂、实质外包”，会原样复刻。

战场的教训最狠：这种模式下的软件迭代速度是“采购周期”级的，而现代冲突要的是“战场节奏”级的——差的就是几个数量级。俄乌双方在无人机 AI 上的你追我赶，靠的就是贴着前线改。把工厂当外包办，等于主动认输。

四、为什么必须建在一线

“一线”就是作战部队的身边。建在这里，理由有三：

一是AI 编码让写码变便宜，瓶颈转向“懂需求、能验收”——这只能在一线。Claude 等大模型、Copilot 类工具，让生成一段代码不再是门槛；真正稀缺的是懂作战、能判断“这版能不能要”的人，而他们在前线。

二是一线有真实数据、真实痛点、真实用户。软件在用户身边生成、试用、验收，才能“边打边改、越用越强”。乌克兰的 DELTA 就是前线部队自己用出来、改出来的；美军把士兵编入软件工厂学手艺，鼓吹 “warfighter as co-developer（作战人员作为共同开发者）”。

三是随部队机动。嵌入式小队跟着任务走，软件随战斗力一起部署，而不是等一个中央厂排期。

五、Claude 等大模型带来什么，又带来什么坑

一句话判断：大模型放大你既有的流程。流程贴用户，AI 就贴着用户造好软件；流程脱离用户，AI 只是加速造垃圾。它不会替你回答“用户到底要什么”——这个问题只有一线能答。

六、给我们的启示：建真工厂，上一线，拒假外包

把几期结论收口：

编制思维要变——不必都养大厂，把能力以嵌入式小队前出，告别对固定建制的依赖。组织落点要变——论证机构退为治理（标准、架构、安全认定），工厂小队贴用户。素养要兜底——提升一线一员软件工程化素养（需求表达、配置变更、测试验收、安全保密，对应 GJB 2786A、GJB 3206B、GJB 5000B、GJB 439B）。监督不缺位——军代表仍要管（接前两期）：审流水线质量门、复核技术状态、确认作战适用性。

七、结语

俄乌与美伊告诉我们：软件与 AI 的代差，就是战场的代差。建软件工厂，若只换牌子不换脑子，把外包当工厂，必在战场上付出代价。真正的软件工厂，建在一线、长在用户身边、随部队机动——那里，才是战斗力生成的地方。