AI将载着MBSE驶向哪里？从前台工具转向工程语义与验证层

 前言 

基于模型的系统工程（MBSE）是一种以模型组织需求、架构、接口、行为与验证关系的工程方法。随着大语言模型具备需求抽取、模型片段生成和文档编制能力之后，人工建模在MBSE流程中所占用的时间和人力正逐步减少。当模型生成的成本显著下降后，MBSE是否仍然具有价值？

笔者认为，AI正在降低候选方案的生产成本，但工程结论的确认仍需要证据、版本和责任关系。MBSE若要继续发挥作用，需要把价值重心放到生成之后的确认环节。

● 模型生成成本下降但仍需工程确认

大语言模型可以在较短时间内生成架构方案、需求条目、接口说明和评审材料。然而，方案的生成并不等于工程结论的成立。接口是否冲突、参数单位是否一致、性能是否满足约束、模型版本是否对应、发生变更后仿真是否需要重跑，这些问题仍需通过规则、计算、试验或人工评审进行逐项确认。

随着大模型的进步和对应Agent的面世，生成系统方案所需的时间正在快速缩短。与此形成鲜明对比的是，确认方案是否可信仍需投入大量的成本。看似可信的候选方案增多后，工程团队仍要逐项回答：哪些方案被充分验证，哪些风险尚未暴露，哪些工程节点可以进入下一阶段。

代码生成速度提高后，版本管理、编译、测试、代码审查和持续集成的重要性并没有下降，变更频率的上升反而提高了对这些环节的要求。对于跨专业的复杂系统设计流程，模型校验、仿真分析、验证证据等环节仍然承担着重要的作用。

随着AI生成能力的逐渐普及，模型创建将成为工程软件的基础能力。产品之间的差异将更多地来自其能否保存工程状态、控制变更并组织验证。这些能力会随着生成系统设计候选方案的成本降低而变得更为必要。因此，AI缩短了方案生成所需的时间，但工程验证的工作量却没有同步减少，瓶颈落在了方案的确认环节。

● 模型的价值在于保存工程状态

Agent工具的对话界面可以提高需求梳理、方案讨论和文档编制的效率，但某一次对话的输出并不会天然地具备工程所需的版本、依据和责任关系。对话结束后，AI仍未厘清当前哪个接口仍然有效、哪个需求已经废弃、哪次仿真对应哪个模型，以及其他变更信息的确认。因此，模型需要具有稳定的标识、版本和关系，并记录工程执行中的变化过程，包括提出、修改、评审、批准、验证和废弃。每一步都需要保留对象、依据和责任人。另外，系统设计的验证也不能仅依赖于生成过程对自身的解释。规则校验、行为仿真、物理求解、试验数据和人工批准在验证的过程中也承担着不同职责，共同构成对系统设计的确认链条。

华望系统科技构建的可信工业 AI 平台正是沿着这一思路展开的。平台以本体和知识图谱来约束事实来源，并保留规则校验、推理路径、人工确认与审核记录，使智能体的输出能够回到具体依据和工程状态。工程验证的责任仍由人和组织承担，AI生成的结果则更适合作为可追溯的工程候选产物。

此外，不同专业、工具和智能体需要对部件、接口、需求、行为和验证形成一致的理解，并明确参数单位、归属及证据来源。当系统的规模扩大后，结构化的理解难以由更长的自然语言的上下文替代。模型的主要作用则是将复杂系统压缩为可查询、可比较、可执行和可复核的结构。因此，模型保存的内容不仅包括最终答案，也需要包括形成这一答案所依赖的工程状态。

● 文本执行使模型进入验证链条

当模型可以用文本表达并被解析时，文本不再只是对人类需求的描述，也可以成为工程系统的执行输入。

笔者设计了一种可行的工程化路径，可让SysML V2的文本模型直接进行执行。依据执行规范，每次执行时将保留一份结构化的trace（执行轨迹记录），记录模型版本、执行入口、输入绑定、事件序列、参数前后值和判定结果。轨迹回放、覆盖与约束检查、异常定位和报告可共用同一份记录。trace还可导出为结构化的文本，供Agent或其他工具继续处理。

由此，模型生成从一次性动作成为可回放、可比较的过程。执行记录为AI生成的模型增加了检查依据，但模型的有效性取决于执行语义是否完整、记录字段是否充分以及结果能否关联需求、模型版本和专业工具。下图为华望SysML V2 软件中文本模型执行与回放的界面图。

● SysML需要与多专业模型协同完成验证

SysML适合承担系统需求、结构、接口与关系的语义骨架。对于复杂系统的研制设计而言，仅依靠系统模型还不足以完成全部物理性能、专业分析和形式化性质的验证，需要与各专业模型建立稳定的关联。

需求管理工具保存需求基线、架构工具保存结构和接口、仿真工具保存物理模型、形式化工具证明特定性质、试验系统保存真实数据。这些模型的表达方式、验证规则和专业责任并不相同，即使合并到同一个文件中也无法自动统一。

可行的方式是建立相互校验的模型网络。各专业保留其权威模型，通过稳定标识、接口契约、参数映射和证据关系建立相互连接。系统的语义骨架无需成为所有专业信息的唯一表达方式。

在该网络中，一个需求可追溯到对应架构和行为；一个仿真结论可对应模型版本、输入条件和执行记录；一次设计变更可定位受影响的需求、接口、仿真和试验。模型文件仍可按专业分布保存，需要统一的只是引用关系与验证口径。

● MBSE的使用重心将从用户前台移到工程后台

随着自然语言和智能体成为与AI交互的入口，用户可以直接从业务流程或智能体界面发起模型查询、影响分析、仿真配置和结果检查。专业建模的界面将更多承担的只是深度编辑、模型治理和专家决策的职能。

然而，界面作用的变化绝不意味着MBSE退出系统工程舞台。模型仓库、语义关系、变更控制、验证执行和证据记录仍然需要长期保存。用户日常面对的主要是任务入口和结果说明的界面，模型仓库、变更控制、验证执行和审计记录等通常位于后台。笔者认为，MBSE较为可行的发展方向是前台接受自然语言和智能体任务，后台保存系统状态、依据规范组织的多种模型、完成验证并留下的执行过程。

总之，SysML可以描述结构与关系，物理模型可以承担计算，形式化工具可以证明关键性质，试验数据则用于检验模型与现实的一致性。每个关键结论都应能找到对应模型、执行过程和责任人。自然语言界面可以降低使用门槛，但其可靠性仍取决于后台能否提供可检查的模型、执行过程和检验证据。

● 产品价值与评价指标需要调整

当模型生成逐渐成为MBSE工具的通用能力时，建模功能的差异化空间会有所收窄。产品的价值需要更多体现在模型治理、跨专业协同、验证执行和证据形成方面，并与用户已有的工程流程保持连续。

具体来说，MBSE产品的价值会更集中地体现在工程状态保存、变更影响控制及可验证产物的组织上。评价指标也应更多用于衡量工程的效率，例如需求变更后可识别完整影响范围所需的时间、模型修改后形成可复现验证证据所需的时间，以及方案决策能否追溯到当时的模型、数据和批准记录。

在中低复杂度或低风险场景中，知识检索、文档辅助和轻量模型往往更有成本优势。随着验证责任和跨专业依赖的增强，MBSE及其语义、验证和证据能力将成为更高的优先级。因此，MBSE的应用重心更可能向复杂工程环节集中。

  结语  

模型生成效率提升只是AI可以发力的一种场景，工程组织通常不会减少验证工作，反而会面对更多的候选方案和更高的确认要求。笔者认为，解决验证效率和验证链路的问题是MBSE能够继续发挥作用的关键点之一，主要价值在于其可以保存具有版本和责任关系的工程状态，并组织规则、仿真、试验及人工评审形成独立的验证。

复杂系统的构建通常包含多种权威模型。试图以一个覆盖所有专业的更大模型完成模型整合，往往难以同时兼顾维护成本、专业自治和验证一致性。MBSE的整合作用应落在稳定的语义关系和验证证据上，使不同专业的模型能够相互引用、相互校验。在此基础上，MBSE的产品形态将从用户前台逐步转向工程后台，相关的软件评价标准，也应从建模产出转向工程验证。

未来，MBSE+AI仍需进一步探究智能体在修改模型时的权限边界、跨模型证据的统一表达方式，以及人与AI共同承担工程责任时的记录过程。上述问题仍是MBSE作为一种工程基础设施需要持续研究的长期课题。