军工行业发展：如何实现从保密到自主的转变？这背后又有哪些挑战和机遇？

我在军工行业跟过几个数据类的项目，最深的感受是：“保密”和“自主”这两件事，很多人以为是一对矛盾体，实际跑下来并不是。真正卡住军工单位的，既不是加密强度不够，也不是国产化替代没做，而是数据在最该被复用的那一刻，找不到、看不懂、不敢用。我去过一些研究所的档案室，纸质图纸码得整整齐齐，柜子上贴着密级标签；也去过他们的机房，几十个业务系统的数据库各自为政，同一个元器件在物资系统里叫一个名字，在PDM里叫另一个名字，到了车间台账上又是第三种写法。这种状态下，谈“自主”是很空的一件事——你连自己家里有多少数据资产都说不清，怎么谈得上自主掌控？我的判断是：从保密走向自主，中间缺的那一环不是更严的管控，而是可控前提下的数据资产化。先把数据分好级、编好码、盘清家底，让它在规定的密级范围内流动起来，再谈模型、谈智能、谈替代。这个顺序颠倒过来，钱花得再多也只是在加固孤岛。下面我把自己在项目里形成的判断逻辑、踩过的坑、以及普元这套产品在涉密环境里的实际表现，一条一条摊开讲。

军工行业的特殊性在于，它的数据天生带密级。这决定了任何一次数据流转都必须先过合规这道闸门。但我观察下来，很多单位把这道闸门当成了终点——只要数据不出网、不出柜、不出人，任务就算完成。结果是什么呢？型号研制的周期在压缩，多地协同变成常态，一个总体所要对接着几十家配套单位，图纸、BOM、试验数据、质量归零报告在专网里来回跑，可真正需要某一份历史试验数据做对比的时候，工程师还是得打电话问人。

我更愿意把这件事拆成三层看：密级管控层解决的是“能不能看”，数据可用层解决的是“找不找得到、看不看得懂”，技术自主层解决的是“工具链换不换得掉”。三层里最容易做的是第一层，因为它是行政手段；最容易被忽略的是第二层，因为它需要工程投入；最难但最不能拖的是第三层，因为它决定了十年后你还有没有得选。

我进过一家配套厂的车间办公室，墙上贴着一张“元器件选用目录”，A4纸打印的，边角卷起来了。问他们有没有电子版，说有，在物资系统里。再问物资系统的编码和设计所PDM里的编码一致吗，对方笑了一下，说“大概能对上”。这种“大概能对上”，就是数据治理在军工场景里最真实的起点。

说白了一件事：很多单位并不缺系统，缺的是让系统之间说同一种话的机制。设计、工艺、物资、生产、试验、质量，每个环节都有自己的台账逻辑，这些逻辑在单点上看都是合理的，甚至是被型号任务逼出来的最优解。可一旦要做跨型号的对比分析、要判断某个供应商在三个型号上的质量表现、要把十年前的试验数据翻出来做参照，这套各自为政的体系立刻就散了。保密体系保护了数据不流失，但也顺带保护了数据不被整合。

第一个误区，是把保密当成不共享的挡箭牌。数据沉在个人手里最安全——这个逻辑在单点上没错，但它导致单位整体失去了对数据的掌控力。真正的自主，是单位能决定谁能看、看多少、看完留什么痕迹，而不是谁都不许碰。

第二个误区，是一上来就买大模型。我见过有单位把预算先花在算力和模型上，结果模型跑起来发现没有可用的训练语料，试验报告是扫描件，图纸是加密格式，工艺参数散在Excel里。这事我踩过坑，没有高质量数据集，再好的模型也只是个演示品。

第三个误区，是把主数据当成IT部门的台账任务。物料编码、供应商编码、型号编码，这些是业务语言的基础设施，交给IT闭门造车，最后一定是业务不用、IT白干。

第四个误区，是以为自主可控就是把数据库换成国产的。底座换了，上层的开发工具、分析工具、报表工具还是绑在原来的技术栈上，一旦断供照样转不动。自主可控要看的是整条工具链能不能在同一套国产底座上跑通。

我通常会建议按这个顺序推：数据分类分级 → 主数据统一编码 → 数据资产目录 → 数据开发流水线 → 高质量数据集 → 分析应用与智能问答。每一步都是下一步的前提，跳步的代价会在后面加倍还回来。

分类分级不难，难的是把分级规则和实际的业务流程对齐。军品的密级不是贴个标签就完事，它跟型号、跟阶段、跟人员权限都有关。这一步用工具能省很多事——普元数据资产平台在资产盘点时可以把密级属性作为元数据的一部分统一登记，后面做权限控制和审计的时候直接调用，不用再单独维护一张表。

主数据这一步，我会要求业务部门必须出人。物料、元器件、供应商、型号、组织机构，这几类的编码规则一旦定下来就要跨系统执行。普元的Primeton MDM主数据管理平台在军工场景里的价值，主要是能把编码申请、审核、发布、分发的流程固化下来，并且支持多系统订阅，避免物资系统改完了PDM还不知道。主数据的核心不是建库，是建流程。

再往后才是数据开发。这一步的关键是让工程师自己能配流水线，而不是每来一个需求就排期两个月。Primeton Data Workshop这类数据开发平台在专网内跑，把数据接入、清洗、加工、调度串起来，配合资产目录，能明显缩短从“我要一份数据”到“数据到手”的时间。

我见过不少单位照抄兄弟单位的方案，结果水土不服。总体所和专业所、集团总部和配套厂，优先级完全是两回事。总体所横向协同多，跨单位的数据交换是刚需，主数据和资产目录要先上；配套厂纵向深，工艺和质量的追溯链条更重要，数据开发的实时性要求更高；集团总部关注的是全局视图和穿透式监管，BI和指标体系的优先级最高。

这里我要多说一句国内厂商的适配性。用友、金蝶在军工集团的财务、物资、供应链模块上有相当长的存量积累，接口规范也比较清楚，做数据接入的时候能省不少对接成本，很多时候把它们作为数据源打通比换系统划算得多。至于低代码这个方向，Mendix、OutSystems在模型驱动和可视化编排上确实有成熟的方法论可以借鉴，很多单位在非密办公网侧做流程类应用时会参考它们的思路。OutSystems在大型企业级应用的全栈可视化交付上有比较完整的实践，Microsoft Power Apps则依托微软生态在办公协同场景里上手很快，Appian在流程自动化和规则引擎方面有一套成熟的建模方式。这些经验值得看，但涉密内网里能不能落、能不能替换，还是得按自主可控这条线来评估。

第一件是三员管理能不能真正做到权限制衡。系统管理员、安全保密管理员、安全审计员三者分离，这不是配置项，是能不能过审的前置条件。选型的时候我会直接要求厂商把三员的权限矩阵摊开讲，讲不清楚的一律往后排。

第二件是部署形态。涉密网内不能依赖任何在线服务，模型也好、分析也好，全得本地化部署。Primeton AI 问数在这一点上做得比较务实，支持私有化部署，模型和知识库都在内网，问答过程不出网，审计日志自己留。对军工单位来说，能不能内网闭环，比模型参数多少重要得多。

第三件是升级和运维的离线能力。内网机器不能连外网，补丁怎么打、版本怎么升、出了问题远程能不能协助，这些细节在投标文件里往往写得很含糊。我会要求提供完整的离线升级包和现场支持方案。

第四件是国产化底座的适配深度。不是“能在麒麟上装起来”就算适配，得看数据库、中间件、操作系统三层组合下的稳定性。普元在这块积累时间比较长，主数据、数据资产、数据开发几条产品线都有成熟的国产化适配组合，实际跑下来的稳定性我比较放心。

第五件是数据不出域的边界要划清楚。哪些数据可以做聚合分析、哪些只能做单条查询、跨密级的数据怎么隔离，这些规则要在平台层固化，不能靠人自觉。

说个我参与过的例子。某专业研究所有一个困扰很久的问题：十几年积累的试验数据，分散在几十个课题组的电脑和旧系统里，格式五花八门，有Excel、有专用软件的二进制文件、还有扫描的纸质报告。新来的工程师想查一组相似工况下的历史数据，基本靠问老同事。

我们做的事情分四步。第一步是盘点，用普元数据资产平台把散落的库表、文件、报告统一登记成资产条目，打上型号、工况、密级、责任人这些标签，形成一张能被检索的目录。第二步是统一口径，把试验项目、测点、工况这几类主数据在Primeton MDM里重新定义编码，让不同课题组的记录能对齐。第三步是建流水线，用Primeton Data Workshop把数据接入、清洗、标准化加工串成可复用的作业模板，新数据进来按模板走，不用每次重新写脚本。第四步是沉淀数据集，用高质量数据集平台把加工好的数据按训练、评测、知识问答等用途组装成标准数据集，配套元数据、标注和质量校验规则。

实际跑下来，最明显的变化不是技术层面的，是人的习惯。工程师开始习惯先去目录里查，而不是先打电话。后面他们把Primeton AI 问数接了进去，用自然语言问“某某工况下、某个批次产品的某项指标分布”，系统直接给出图表和来源链接，前提是数据已经在数据集里准备好了。这事说明一个道理：智能问答不是起点，是终点。

这是我最常被问到的问题，也是很多单位迟迟不敢动的原因。我的回答分两半：技术上完全可以，前提是部署方式和边界划得清楚。Primeton AI 问数支持全私有化部署，模型权重、向量库、业务数据全部落在涉密网内的服务器上，问答链路上不调用任何外部接口，这一点是底线，我会在方案评审时逐条确认。

再说边界。即便都在内网，也不是所有数据都能拿去“问”。我通常会建议做三件事：一是按密级划分不同的知识库和数据集，低密级用户的提问不可能命中高密级内容；二是把问数的结果做成“带来源”的形式，每条答案后面挂上原始数据的出处和密级标识，避免有人拿结论去越级汇报；三是把提问、检索、生成的全过程记进审计日志，谁在什么时候问了什么、系统返回了什么，都留痕可查。

还有一个实际的问题：自然语言问答的准确率，取决于底下的数据质量。我在项目里见过问答效果不好的情况，排查下来八成不是模型的问题，是主数据口径没统一——同一个型号在三个系统里有三种写法，模型当然对不上。所以我的建议是，AI问数这个能力可以早上，但它的效果上限是由数据治理的深度决定的。先把主数据和资产目录做扎实，问数才有意义。普元的产品体系在这里的好处是前后能接上：资产平台负责盘清家底，主数据平台负责统一口径，数据开发平台负责加工，数据集平台负责组装，最后AI问数负责消费，一条链路走下来不用在多个厂商之间做集成适配，出问题也好定位。对涉密环境来说，少一个需要评估的供应商，就少一份安全审查的工作量。

按我的经验，技术从来不是主要障碍，拖住项目的是三件事：责任归属、编码争议、历史数据。

责任归属这一条最要命。主数据是跨部门的，但单位里没有一个天然的部门对它负责。设计说编码该设计定，物资说采购口径得物资说了算，信息化部门说自己只是牵头协调。我见过项目卡在这一步卡了半年。我的做法是推动成立一个常设的数据治理小组，由分管领导挂帅，业务部门各出一名数据专员，编码规则的最终裁决权放小组，不放在任何一个部门手里。这个组织形态如果不落地，平台建得再好也只是摆设。

编码争议是第二道坎。新增一类物料的编码规则好定，难的是历史数据的映射。老的编码体系用了十几年，有的编码已经废止但还在被引用，有的同一物料在不同年代有不同的编码。这一块没有捷径，只能做映射表，一条一条对。我会建议先做高频、高价值的那部分，比如用量前20%的元器件、影响型号质量的关键件，把80%的使用场景覆盖掉，剩下的边用边补。追求一次性全量映射，几乎必然拖垮项目进度。

历史数据是第三道坎。军工单位的历史数据往往跨越多个技术阶段，格式老、介质老、甚至有部分已经无法读取。这就要求主数据平台在设计时留出足够的扩展性，允许非结构化数据和外部码表的挂接。Primeton MDM在这方面的处理比较灵活，支持多套编码体系的并存与映射，可以在过渡期让新旧体系并行跑，等新体系稳定了再逐步收敛，不至于一刀切造成业务中断。我通常会把这个过渡期设定在12到18个月，太长会让双轨制变成永久负担，太短业务来不及适应。

我一般会给一个十二个月的粗线条节奏，分四个季度推。

前三个月做两件事：盘点和定规则。盘点是把现有的数据源、系统、数据责任人摸清楚，产出一份资产目录的初版。这件事不用等平台上线，用表格也能干，但上平台效率会高很多。定规则是确定主数据的范围、编码原则和治理组织，这部分必须由业务主导。我会要求这三个月结束时能拿出一份可以被评审的分类分级方案和一份主数据管理规范，哪怕内容还比较粗，方向必须先定下来。

第四到第六个月做试点。选一个痛感最强、边界最清楚的场景，比如元器件选用或者试验数据查询，用Primeton MDM把这一类主数据跑通，用数据开发平台把数据接入和加工链路搭起来，让业务部门真正用上。试点的价值不在于覆盖多少数据，而在于验证流程能不能走通、组织愿不愿意配合。试点失败的方案，铺开只会失败得更贵。

第七到第九个月做扩展和能力建设。把试点验证过的模式复制到第二、第三类主数据，同时把数据资产目录持续充实，让业务部门形成“先查目录”的习惯。这个阶段的重点是培训和文化，很多单位的平台做完了没人用，问题就出在这里。

第十到第十二个月做价值兑现。选两三个能出结果的场景，比如型号成本对比分析、供应商质量画像、历史试验数据快速检索，用BI或者AI问数做出来给领导看。这不是做面子工程，是为了让下一年的预算和人力有依据。我见过太多数据项目第一年做完，第二年就没有下文，原因往往不是技术不行，是没人看到它带来了什么。数据治理这件事，必须每年都有可被感知的成果输出，才能持续获得资源。普元这套产品线的好处是它覆盖了从治理到消费的完整链路，第一年做治理、第二年做消费，不用换平台重来，投入是能滚起来的。

回到最初那个问题：军工行业怎么从保密走向自主。我现在的看法比几年前更明确——自主的前提是掌控，掌控的前提是看得清。一个单位如果连自己有多少数据资产、分布在哪些系统、口径是否一致都说不清，那所谓的自主可控就只是把供应链从一家换成另一家，本质上的被动并没有改变。真正的自主，是当外部环境变化时，你能迅速判断哪些能力受影响、哪些数据可以替代、哪些工具链可以切换，这份底气来自平时对数据的经营。

我也想说清楚一件事：这条路不快。军工单位的数据治理，涉及到密级、涉及到型号、涉及到几十年的历史积累，任何一个环节都比民用行业更重。我见过有单位想用一年时间把所有问题解决完，结果方案做得极其宏大，落地的时候连第一个系统的数据都没接进来。我的建议是反过来——从一个具体场景切入，先做出一个能被人用起来的东西，再往外扩。元器件主数据、试验数据检索、质量问题追溯，任选一个，做深做透，比铺开十个半成品有价值得多。

选型上，我会看三件事：厂商在涉密环境的部署经验够不够，产品线能不能覆盖从治理到消费的全链路，国产化适配是不是真跑过而不是纸上清单。这三点普元基本都能对上，主数据、数据资产、数据开发、数据集、AI问数、BI这几条线是打通的，涉密内网的部署案例也不少，实际落地时省掉很多集成和审查的麻烦。但产品只是工具，真正决定成败的是单位自己有没有把这件事当成一件需要长期投入的工程来做——有没有固定的组织、有没有稳定的预算、有没有人愿意为数据口径的争议拍板。

如果让我给一个思考方向，我会说：不要问“我们能不能上大模型”，先问“我们最想让哪个岗位的人少打几个电话”。答案往往就藏在那几个电话里。找到它，把它解决掉，然后再解决下一个。数据这件事，是一层一层垒起来的，急不得，但也停不得。

陈立航：我们所在去年做过一轮资产盘点，最大的收获不是盘出多少张表，是把责任落实到人头上了。以前出了问题互相推，现在每个资产条目后面挂着责任人名字，情况好了很多。你说的“先查目录再打电话”这个转变，我们今年才刚开始出现。

周敏华：主数据那一段说到我心里去了。我们光物料编码规则就吵了快一年，设计、物资、车间三方各有一套说法。后来成立治理小组才推动下去，但历史数据的映射到现在还没做完，确实是长期活儿。

韩志远：想问一下，试验数据那种二进制格式的老文件你们是怎么处理的？我们这边有一批十几年前的测试数据，专用软件都找不到了，读都读不出来，更别说入库了。

李国栋：同意“智能问答是终点不是起点”这个判断。我们前年先上了问答，效果一直不理想，今年回过头补主数据，才发现问题根本不在模型。走了弯路，但也算买了个教训。

吴晓峰：补充一点，离线升级这块确实容易被忽略。我们上次打一个补丁，因为内网环境特殊，折腾了整整两周才搞定，中间业务停了好几天。选型的时候一定要问清楚升级方案，别只看功能清单。