百厂之中,一基之重 · 集团软件工厂建设指南-夜雨聆风

百厂之中,一基之重 · 集团软件工厂建设指南

作者 · Daniel · 长期关注软件研制如何从「工具堆叠」走向「运行体系」——聚焦 DevOps / DevSecOps 与软件工厂在装备与 JG 领域的实践与反思,围绕组织、流程、工具、视图四类关键要素

秒读完版(忙的话只读这里)

软件工厂建设有三阶段成熟度——零散期 / 集中期 / 联邦期。多数集团目前处于零散期,头部集团已开始走向集中期(总厂 / 分厂模式),联邦是集中期的成熟形态——三阶段不是替代关系,是演化关系。
美军 50+ 工厂走的就是联邦——Platform One 共享底座 + 军种工厂集群 + 数百个 Tiger Team;底座、工厂、交付小队三层各司其职。
集团做底座,不做工厂:国产加固镜像仓 + DevSecOps 参考架构 + 多级密分接入规范 + 三合一合规接口(GJB 5000B + 等保 2.0 + 新网安法 2026)+ 共享代码 / 模型 / 数据集仓。
院做领域工厂:在集团底座上加本院特殊工具 + 维护「型号 × 平台」模板库——雷达 / 卫星 / 导航 / 舰船各领域各建,不是各院各建。
所派 Tiger Team,不建独立工厂:6—15 人小队接入院级流水线,聚焦型号交付。所级独立建厂是”看似自主、实则孤岛”的最大陷阱。
联邦能不能跑通,看接口契约——集团 → 院、院 → 所、院 ↔ 院三组接口必须清晰且强制;任何”绕过”必须升级到上一层,这是联邦底线。

上一篇文章里,这一系列用了一句话给文化课收尾:「制度课定方向,文化课定下限」——制度上对了方向,文化上不到位,体系还是塌。这一篇接着回答另一个比”方向”和”下限”都更上游的问题:整个体系长在什么形状的骨架上?

这件事,几乎一定不是技术决策者一个人能拍板的——它是关于”谁出钱、谁说了算、谁负责”的政治架构决策。在中国军工的语境里,这件事的决策者是集团一把手 + 集团 CIO + 总工程师——上下篇的读者主要是技术决策者和技术管理者,这一篇要面向他们的上一层。

这一篇要回答的核心问题只有一个:集团 / 院 / 所三层,软件工厂应该怎么分布?——是集团建总厂、院和所建分厂?是院和所各自建?还是有第三种走法?

我们见过的真实案例里,前两条路都失败过。这一篇讲第三条——联邦模式:它已经被美军 50+ 工厂验证过 5 年以上,也是中国军工 2026 年起最值得参照的架构。

软件工厂建设的三阶段成熟度——你目前在哪一阶段?

软件工厂的建设不是一次性工程,而是阶段性演化。识别清楚自己目前所在阶段,比直接奔向”理想架构”更重要——把还没到的阶段当成现在的目标,代价是前一阶段的奠基也做不扎实;把已经过去的阶段当成现状,代价是该有的演化错过窗口。

下面这三个阶段,是中国军工集团软件工厂建设可观察的客观演化曲线——没有时间表,但有清晰的阶段边界。

图 1 · 软件工厂建设的三阶段成熟度——零散期 / 集中期 / 联邦期。每一阶段都有它的合理性,也有它的边界;阶段之间不是替代关系,而是演化关系

阶段 0 · 零散期 — 多数集团目前所处的现状

各院 / 所独立建设软件能力,集团层无统一标准、无共享底座、无横向接口。每个院 / 所根据自己的型号需求和信息化基础,各自选工具、各自部署、各自维护。

零散期的合理性,在于”贴近一线”——单一院 / 所的工程师团队对自己的型号最熟悉,他们做出的工具选择往往是当下最合理的。这一阶段的代价不在工程层面,而在集团层面:

重复造轮子的成本累积:国产 CI/CD 工具链联调、SBOM 自动生成、涉密多级网络接入、合规证据自动留存——这五件事每个院都要单独做一遍。横向复用本可以把总成本压到三分之一。

工程师无法跨院流动:每个院的工厂是独立技术栈,X 院的平台工程师跳到 Y 院,要重新学一套工具链——工程师被绑死在原院,军工工程师圈的整体能力流动停滞。

模型 / 数据集 / 安全规则隔离:每个院有自己的模型仓 / 数据集仓 / SAST 规则——跨院共享几乎不可能。这一点在 AI 时代尤其值得关注。

零散期不是错误,是任何集团软件能力建设的早期形态;但长期停留在零散期,集团层会出现「无任何公共可信资产」的结构性问题——这是 2026 年很多集团一把手已经感知到的问题。

阶段 1 · 集中期 — 头部集团已经开始走的方向

集团出力建总厂、院 / 所建分厂、所有院 / 所统一接入集团总厂。集团总厂提供 DevOps 平台、流水线引擎、代码仓 + 制品仓、安全扫描;分厂在总厂的标准下做本地交付。

目前国产软件工厂平台的代表(如 Gitee 推出的”软件工厂”产品)所提供的形态,正是这种「集团版 + 子公司版」——它把零散期收敛成集中期,建立了第一份共享标准、第一份合规接口、第一份安全规则。这是任何集团软件能力建设都绕不过的奠基阶段——集中期是值得每一个仍在零散期的集团尽快推进的下一步。

但集中期也有它的边界——

业务领域跨度大:一个集团下可能同时有雷达、卫星、导航、电子对抗、舰船等多个领域,总厂的工具链、流水线、安全规则,难以同时合适所有领域。最终结果是总厂被迫做”最小公约数”,每个院都觉得它”不够专”。

响应速度有上限:集团离一线远,院级的工程问题要走集团审批——快则两周,慢则两月。在型号节点逼近时,院 / 所有压力会绕开总厂自己写脚本。

领域文化适配难:每个院有自己的工程师文化——电子对抗讲求快速响应、卫星讲求极端可靠、雷达讲求精度——总厂只能是文化的最大公约数。

这些边界不是集中期的”错误”,而是集中期”成熟之后必然遇到的成长瓶颈”——它在告诉集团:到该向下一阶段演化的时候了。

阶段 2 · 联邦期 — 头部集团下一阶段的目标

联邦期是集中期的成熟形态。它做了一次关键的角色重定义——

集团从”做工厂”转变为”做底座”:不再直接交付型号软件,而是为各院提供共享底座——加固镜像仓、DevSecOps 参考架构、多级密分接入规范、三合一合规接口(GJB 5000B + 等保 2.0 + 新网安法 2026)、共享代码 / 模型 / 数据集仓

分厂从”被托管”升级为”领域工厂”:在集团底座之上,加入本院的领域特殊工具(雷达仿真 / 卫星地面站 / 导航测试 / 舰船控制等),维护本院的「型号 × 平台」模板库

所级派 Tiger Team 接入领域工厂:不建独立工厂,以 6—15 人小队接入本院领域工厂,聚焦型号交付

这不是推倒重来,而是把已经搭起来的总厂 / 分厂”打开”——让集团这一层做减法、让院这一层做加法、让所这一层做交付。三层的角色变了,但已经投入的工程资产、合规建设、人才培养,都得到保留并被进一步放大。

美军 50+ 工厂走的就是这条路——下一节展开。

判断你目前所在阶段的三个问题

回到读者自己的语境,问自己三个问题:

集团是否有统一的加固镜像仓 + 共享代码仓?——没有 → 阶段 0;有 → 至少阶段 1

院 / 所是否在集团统一标准下做交付?——没有 → 阶段 0;有 → 阶段 1 或 2

集团是否自己直接交付型号软件?——是 → 阶段 1(总厂模式);否,集团只提供底座 → 阶段 2(联邦)

阶段判断完之后,后面七节给的是从你目前所在阶段到下一阶段的演化路径——而不是一份”理想架构”的蓝图。任何集团都不是从零跳到联邦,都是从零散经过集中再到联邦;清楚自己在哪一站,比知道终点在哪更重要。

后面七节的安排:第二节展开美军 50+ 工厂的真实结构——这是联邦模式最成熟的参照系;第三、四、五节分别讲集团、院、所三层各自做什么;第六节讲三层之间的接口契约——这是联邦能不能跑通的工程心脏;第七节讲启动顺序和三种常见错配;第八节讲治理——谁有权说「通过」、「卡住」、「绕过」。

美军 50+ 工厂的真实结构——一个底座 + 三层结构

要理解联邦模式怎么落地,最具参照价值的是美军——他们走过这条路超过 5 年,从 2018 年的 Kessel Run(空军第一个软件工厂)起步,到 2025 年公开披露的工厂数量已经超过 50 个。没有任何”一个 DoD 软件工厂”,而是「一个共享底座 + 多个工厂集群 + 数百个 Tiger Team」的联邦结构。

图 2 · 美军三层联邦结构——底座层 / 工厂层 / Tiger Team 层,每一层服务不同的复用粒度

底座层 · Platform One 提供共享能力

Platform One是美军软件工厂网络的底座——它不交付任何作战软件,只提供工厂们用的工具集和标准。它的核心产品是四件套:

Iron Bank:加固容器镜像仓库,数千个签名 + 漏洞扫描通过的镜像,供所有工厂直接拉用

Big Bang:DevSecOps 参考架构(Kubernetes + Istio + ArgoCD + Vault 的开源栈)

Party Bus:多账户 IL2 / IL5 / IL6 隔离环境,对应不同密级的工程能力部署

Repo One:代码与制品托管,所有工厂的开源贡献回流入口

外加CDAO 办公室 + DSOP(DevSecOps Office)做政策、参考架构、合规模板——这是治理层而非工程层。

底座层最重要的认知:它是工厂们的”基础设施 + 标准”,自己不出任何成品。一旦底座层开始”做工厂”,联邦就退化成总厂模式。

工厂层 · 按使命域而非按部门划分

底座之上是 50+ 个工厂——但不是按行政部门划分,而是按使命域划分。代表性的工厂包括:

空军:Kessel Run(加油机 / 空中作战)、Kobayashi Maru(后勤)、LevelUP、Section 31(太空)、Forge、Bespin

陆军:Army Software Factory(2021 年建)

海军:Black Pearl

DoD 跨军种:Bravo(数据 / AI)、Tron(网络战)、Argos

每个工厂复用 Platform One 的底座,自己加上本使命域的特殊工具和团队——比如 Kessel Run 有专门的飞行任务规划工具,Section 31 有专门的轨道仿真工具。同一个空军下面,Kessel Run 和 Section 31 是两个独立工厂,而不是一个总厂下的两个分厂——它们之间的资源共享靠底座,业务实现靠各自的工程团队。

工厂层最重要的认知:工厂的边界是使命域,不是行政归属。强行按行政归属合并工厂,会回到总厂模式。

Tiger Team 层 · 6—15 人小队跑具体任务

每个工厂下面是数十到上百个Tiger Team / Squad,每个小队 6—15 人,负责一个具体的型号或作战任务。Tiger Team 不是独立的”工厂”,是寄生在工厂里的交付小队——复用工厂的全部底座、流水线、规则,只对自己的任务负责。

Tiger Team 的存在,让美军软件工厂能够”小步快跑”——一个新作战需求出现,工厂在两周内就能组建一个 6 人 Tiger Team 投入,而不是启动一个新工厂的整套基建。

这个结构为什么能跑五年还在演进

四个原因:

使命多样性:加油机软件 ≠ 太空作战软件 ≠ 后勤软件——一个总厂解决不了所有问题

密级隔离:不同工厂有不同安全边界,无法集中在同一个物理或网络空间。Party Bus 多账户隔离正是为了在底座层支持各工厂的独立合规边界

速度:集中化 = 瓶颈。50+ 工厂同时演进,最佳实践会自然在工厂之间流动

文化适配:每个使命域有自己的文化,工厂要贴合,不能一把抓

把这一切翻译到中国军工集团 / 院 / 所三层结构,接下来三节分别讲集团、院、所做什么。

集团层做什么:做底座,不做工厂

集团做底座、不做工厂,是联邦模式最核心的角色重定义。这一节讲集团应该做什么、不应该做什么,以及现有总厂如何向底座转型。

图 3 · 集团 / 院 / 所三层职责矩阵——每一层各司其职,联邦才能成立

集团应该做的五件事

国产加固镜像仓(对标 Platform One 的 Iron Bank)。集中维护一份所有院 / 所都可以拉用的加固容器镜像库——每个镜像经过签名 + 漏洞扫描 + 合规审视。各院 / 所不再单独构建基础镜像,大幅降低重复劳动和合规盲区。
DevSecOps 参考架构(对标 Big Bang)。集团提供一份”参考实现”——包含完整的 CI/CD 流水线、安全门禁、SBOM 生成、签名验证、合规证据自动留存的端到端范本。各院在此基础上裁剪适配,不再从零搭建。
多级密分接入规范(对标 Party Bus)。涉密 / 非涉密多级网络的统一接入接口、单向网闸规范、跨级数据流转的合规协议——这是集团必须定的标准,任何单一院 / 所都定不出(因为它需要跨院共识)。
三合一合规接口。GJB 5000B 过程域 + 等保 2.0 + 新网安法 2026 三套合规要求的统一证据接口——任何工厂只要按这个接口产生证据,自动满足三套合规框架。这件事是集团最高价值产出之一,因为它把合规从负担变成了可工程化的协议。
共享代码 / 模型 / 数据集仓。集团级的代码托管、模型仓、数据集仓——所有院 / 所的非涉密成果都可以横向流通。这件事在 AI 时代尤其关键:一个院训练好的模型,可以被另一个院直接复用,而不是”看到了用不了”。

集团绝不应该做的三件事

不要直接交付型号软件。集团一旦开始做型号交付,就和院 / 所产生竞争关系——而集团既不懂任何具体型号,又有最大的话语权。结果是底座建设被边缘化、型号交付质量下降两头都失。这是阶段 1 的总厂模式之所以有边界的根本原因。
不要本地化部署。集团做底座,提供的是接口和标准,不是部署。任何”我帮你部署一套”的承诺,都会让集团团队被 100 个院 / 所的部署事务拖垮。底座是公共资产,不是私有部署。
不要强制业务管控。集团对底座有权,对业务无权。任何”这个工具必须用、这个流程必须走”的强制管控,都会被院 / 所规避或形式化执行。让底座做得好用,是让人愿意接入的唯一长期手段。

现有总厂如何向底座转型

如果集团目前已经投入了总厂建设(阶段 1),向阶段 2 转型不需要推倒重来,而是在现有总厂基础上做”减法 + 加法”:

减法:把目前总厂里”直接做型号交付”的部分剥离,交还给院 / 所

加法:把目前总厂里”工程能力”沉淀成可复用的接口——加固镜像、参考架构、密分规范、合规接口、共享仓

对外姿态变化:集团不再说”接入我的总厂”,而是说”接入我的底座”——接入门槛降低,可定制度提升

这种转型的最佳信号,是集团团队的 KPI 从”型号交付数”变成”被多少个工厂复用”——KPI 一变,团队的工作重心自然从”做工厂”转向”做底座”。

院层做什么:建领域工厂,服务一类装备

院层是联邦模式里最有专业深度的一层——它既懂集团的标准,也懂所的型号,是两端的翻译员。一个集团可能下辖 5—15 个院,每个院在联邦里建一个本院的”领域工厂”。

院级领域工厂的五件事

在集团底座上部署本院专用实例。每个院在集团底座之上,部署一个本院专用的工厂实例——复用集团的加固镜像、参考架构、合规接口,加上本院的特殊配置。这一步是”接底座”的核心动作。
加领域特殊工具。不同领域有不同的工程特殊性——

雷达院:雷达仿真 + 信号处理仿真 + 多目标跟踪测试工具链

卫星院:轨道仿真 + 星间链路测试 + 地面站接入测试

导航院:多源融合算法测试 + 误差注入测试 + 抗干扰场景仿真

电子对抗院:对抗场景仿真 + 频谱分析 + 自适应博弈测试

舰船院:海况仿真 + 实时控制系统接入 + 机舰联合测试

这些领域特殊工具,集团做不了(因为太专),所级单独做不起(因为成本太高)——只有院级是合适的载体。

维护本院”型号 × 平台”模板库。本院下属的所做不同型号,但很多型号有共性——比如同一个雷达院下的不同雷达型号,大量的开发流程、安全规则、测试用例可以复用。院级的”型号 × 平台”模板库就是这种共性的沉淀,让新型号 1 周内能接入,而不是从头来一遍。
培养本院的平台 / 安全 / MLOps 工程师。这三类新角色(在系列下篇里详细讲过)在院级建设——他们既理解本院领域专业,又懂工程效能与安全,是联邦能跑通的关键人才。所级的 Tiger Team 工程师由院级老角色带出来。
维护院级的合规证据接口。本院的合规证据按集团统一接口产生,但具体的领域特殊合规要求(比如某些型号有额外的特殊审视要求)在院级实现。这是”通用合规 + 领域特殊合规”的合理分层。

一个领域 = 一个工厂,不是一个院 = 一个工厂

这是 Article 3 最容易被误解的一句话:「院建领域工厂」中的「领域」指的是技术领域,不是行政院。

如果一个集团下面有 3 个雷达相关的院(比如 X 院、Y 院、Z 院都做雷达),联邦模式建议这三个院共建一个”雷达领域工厂”——而不是建 3 个雷达工厂。让领域专业聚焦,而不是行政归属。

这件事会带来组织上的张力——X 院的人和 Y 院的人怎么共建?谁来出钱?谁来主导?——但工程价值远大于组织成本。联邦模式在这一点上必须比行政归属更强势。

所层做什么:Tiger Team 跑型号,不建独立工厂

所级在联邦里不建独立工厂——这是 Article 3 最反直觉但最重要的论点之一。

为什么所级不应该建独立工厂

所级是直接的型号交付方,第一直觉是”我自己建一个工厂,贴合我的型号”。但在联邦模式下,这种思路有四个问题——

所级体量小,无法支撑独立工厂的运维。一个独立工厂需要至少 5—10 人的平台 / 安全 / MLOps 团队来维护——但一个所通常只有 30—80 人的总规模。让所拿出 10% 的人去建工厂,等于让所放弃型号交付能力。
所级专业窄,工程师无法跨型号流动。所通常专注一两个型号,独立建工厂会让平台 / 安全 / MLOps 工程师被”绑死在一两个型号上”——他们的能力得不到充分锻炼,也无法在所之间流动。
所级独立工厂会和院级工厂重复。所属于院,所建工厂会和院级领域工厂直接重叠——两套工具链、两份合规接口、两个模型仓——重复造轮子的成本不可接受。
所级独立工厂在 5 年后会变成”僵尸工厂”。独立的所级工厂,5 年后通常无法演进——人撤、不维护、合规不更新、和上层底座失联——成为最难处理的技术债。

所级应该做的事:Tiger Team 模式

所级的正确姿态是接入院级领域工厂,以 Tiger Team 模式跑型号:

小队规模:6—15 人,跨职能(开发 + 测试 + 安全 + 合规对接)

接入路径:复用院级流水线、模板库、合规接口——不需要自建任何工程基础

聚焦内容:具体型号的需求理解 / 设计 / 编码 / 测试 / 部署 / 运营 / 监控

能力成长:小队成员可以在不同型号 Tiger Team 之间轮动,能力随轮动加深

Tiger Team 模式让所级真正聚焦交付——不是分散精力建工程基础,而是把全部资源投在型号成功上。

Tiger Team 的成熟态:跨所流动

Tiger Team 的最高形态,是跨所之间的流动——一个 Tiger Team 在 X 所跑完一个型号,可以整队转到 Y 所跑下一个型号。这种流动让平台 / 安全 / MLOps 工程师的能力不断在”实战”中增长,也让最佳实践自然在所之间扩散——这是联邦模式的”集团内部知识网络”。

三层接口契约:集团 ↔ 院 ↔ 所之间的「高速公路」

这一节是 Article 3 最具工程价值的一节——决策者最关心的不是各层做什么,而是三层之间怎么衔接。

图 4 · 三层接口契约——集团 → 院、院 → 所、院 ↔ 院三组接口必须清晰且强制

接口一 · 集团 → 院

集团对院提供的是底座接口,具体包括五类:

加固镜像 API:院级工厂从集团镜像仓拉用加固镜像,带签名验证

参考架构包:院级工厂从集团获取 DevSecOps 参考架构(IaC 形式),做适配后部署

合规证据 API:院级工厂产生的证据,按集团统一接口上报,自动满足三合一合规

代码 / 模型 / 数据集 API:院级跨院共享通过集团仓,带访问控制

多级密分接入 API:涉密 / 非涉密环境之间的数据流转,走集团统一规范

这些接口的强制性很关键——接入集团底座必须走这些接口,不允许”特殊处理”。一旦允许特殊处理,联邦在第一年内就会退化成各自建模式。

接口二 · 院 → 所

院对所提供的是领域工厂接口,具体包括四类:

流水线接入规范:所级 Tiger Team 接入院级流水线,有标准的接入文档 + 模板代码

模板库使用规范:所级 Tiger Team 复用本院”型号 × 平台”模板库,有版本管理和变更流程

领域工具 API:所级 Tiger Team 调用本院特殊工具(雷达仿真等),通过统一 API

异常升级路径:Tiger Team 遇到流水线 / 工具 / 合规无法处理的异常,有清晰的升级路径(到院级平台 / 安全 / MLOps 工程师)

这些接口的自服务性很关键——所级 Tiger Team 不应该需要每次都通过工单找院级团队,而应该自助接入。这是 Internal Developer Platform(IDP)的核心思路。

接口三 · 院 ↔ 院(横向)

最容易被忽略但最重要的是院与院之间的横向接口:

模型仓共享规范:不同院之间的模型,如何标准化、如何共享、如何溯源

数据集互通规范:数据集如何脱敏、如何标注、如何在多个院之间流转

工程师跨院流动路径:平台 / 安全 / MLOps 工程师在不同院之间轮岗的机制

跨院最佳实践流通:某个院发现的工程最佳实践,如何流通到其他院

横向接口在联邦初期最容易被”先放一放”——但 5 年后,横向接口的成熟度直接决定联邦能不能形成网络效应。一个孤岛的工厂联邦,和一个互联的工厂联邦,价值差 10 倍。

启动顺序 + 三种常见错配

这一节给的是从你目前所在阶段到联邦的可执行路径。

图 5 · 启动路线图四步走——每一步都有清晰的产出和过渡判据,过渡判据决定能否进入下一步

启动顺序四步走

第一步 · 集团做底座 MVP。对标 Platform One 早期形态,先做加固镜像仓 + DevSecOps 参考架构这两件事——这是联邦的最小可行底座。其他底座能力(密分接入、合规接口、共享仓)在第二步逐步加。过渡判据:有 1—2 个院能从底座拉到加固镜像并跑通构建。
第二步 · 挑 1—2 个先行院。选择信息化基础好、有真实交付压力、有关键人物支持的院,作为”先行院”——在集团底座上建第一个院级领域工厂。先行院不需要完美,需要”跑通”。过渡判据:先行院在底座上完成第一次完整版本交付,合规证据通过审计。
第三步 · 先行院的所级开始接入。先行院下属的所,选 1—2 个试点型号,组建 Tiger Team 接入院级流水线——先行院 + 试点所 + Tiger Team 三层串通,这是联邦最小完整循环。过渡判据:Tiger Team 在新流水线上稳定交付 ≥ 6 个月,无重大事故。
第四步 · 横向复制 + 底座演化。先行院的成功复制到其他院;同时集团底座持续演化(加合规接口、共享仓、多级密分接入)——横向 + 纵深同时推进。这一步没有终点——联邦是一个持续演化的形态,底座永远在升级,工厂永远在新增。

三种常见错配

错配一 · 集团想做总厂,所有事都集团说了算。表现:集团团队的 KPI 还是”上架了多少工具”,而不是”被多少院复用”。解法:KPI 重设——从”上架率”改成”复用率 + 接入院数”;集团绝不直接交付型号软件。

错配二 · 院 / 所各自建,无横向复用。表现:各院 / 所在没有底座的情况下自建工厂,5 年后发现底座建不起来——因为各家方言已经成形。解法:集团必须先建底座,再让院 / 所在底座上建本地实例——次序不能颠倒。

错配三 · 跳过院级,集团直接管所。表现:集团 → 所跨度太大,没有”领域专业层”;一旦出问题,中间没有人能斡旋。解法:院级必须存在——它的价值不是”管理层级”,而是”领域专业枢纽”。

治理:谁有权说「通过」、「卡住」、「绕过」

联邦不是无政府——它有一套清晰的”三类权力分配”。这一节最短,但最关键。

三类权力的分配

通过权——决定一个动作能不能放行——

集团对底座有通过权(允许哪些镜像入库、哪些工具上架)

院对型号有通过权(允许哪些型号在本院领域工厂上跑)

所对 Tiger Team 内部决策有通过权(团队内部的工程决策)

卡住权——决定一个动作必须停止——

集团对违反安全规则 + 合规规则的可以卡住(任何工厂、任何型号)

院对违反工程标准的可以卡住(本院范围内)

第三方审计对违反任何规则的可以卡住,通过抽查机制实现

绕过权——这是联邦的底线——

绕过权:谁都没有。

任何”绕过”动作必须升级到上一层。所级 Tiger Team 想绕过院级流水线,必须升级到院级决策;院级想绕过集团合规接口,必须升级到集团决策。绕过权不是个人权力,是机制安排——所有的”绕过”都被记录、被审计、被复盘。

这一条是联邦能不能跑通的底线。一旦”绕过权”在任何层级被默认允许,联邦就退化成各自建模式;一旦”绕过权”被收得过严(任何例外都不允许),联邦就退化成总厂模式。让”绕过”被允许但被记录,是联邦权力分配的核心智慧。

结语:三个判断 + 三个动作

写到这里,这一篇文章给了三阶段成熟度、美军参照、三层职责、接口契约、启动顺序、治理设计——和系列上下篇一样,如果只能从中带走六句话,我希望是下面这六句:三个判断说清楚架构课的真实形状,三个动作落到下个季度就能开始。

判断一 · 联邦不是另起炉灶,是已有总厂 / 分厂的成熟态。你今天投入的总厂建设没有错,它是通向联邦的必经奠基。让总厂从「做工厂」转变为「做底座」,让分厂从「被托管」升级为「领域工厂」——三层角色一旦重定义,联邦就成立。

判断二 · 联邦能不能跑通,看接口契约,不看口号。集团 → 院、院 → 所、院 ↔ 院三组接口的清晰性和强制性,比任何”我们要建联邦”的会议决议都重要。接口好,联邦自动成形;接口烂,联邦永远停在 PPT 上。

判断三 · 制度课定方向,文化课定下限,架构课定形状。上篇讲制度——决定要去哪里;下篇讲文化——决定能不能走到那里;这一篇讲架构——决定整个体系长在什么形状的骨架上。三件事缺一不可,没有先后但有系统。

动作一 · 识别你目前所在阶段——零散期、集中期、还是联邦期。用第一节的三个 yes/no 问题做自检,这是任何架构演化的起点。

动作二 · 如果在零散期,先把集中期推进起来。集中期是联邦的奠基,不要跳过——目前国产软件工厂平台已经能支撑集中期建设,选一个对标产品扎实做一年。

动作三 · 如果在集中期,开始想”如何把总厂打开为底座”。不是推倒重来,是角色重定义——KPI 从”上架率”改成”复用率”,团队工作重心从”做工厂”转向”做底座”,一年后总厂自然演化为联邦底座。

军工软件工厂的建设,从来不是工具的堆叠,而是运行体系的搭建。三部曲——制度课、文化课、架构课——讲的都是同一件事:让”工具”长成”运行体系”。

这是这一系列文章一直想说清楚的核心。

2026 年的窗口期,真正稀缺的不是工具与技术,是动手的决心与节奏。而决心一旦动起来,真正考验你的,是制度、文化、架构的同步演化——三课都到位,体系才能真正”运行起来”。

关于作者

Daniel · 关注软件工程如何在复杂约束环境中真正”运行起来”。长期聚焦 DevOps / DevSecOps 与软件工厂在装备与 JG 领域的实践与反思,围绕组织 · 流程 · 工具 · 视图四类关键要素,探索软件研制从「工具堆叠」走向「运行体系」的路径。