LLM+SysML v2：复杂装备建模的智能化落地实践

做MBSE这几年，我见过太多团队从“全面铺开SysML建模”到“模型画了一堆，最后没人维护”的滑落过程。复杂装备领域的模型动辄几百个模块、上千条需求、几十份接口清单，靠人工维护一致性基本是体力活。所以当“LLM驱动的SysML v2建模实践”这个题目出现在我面前时，我第一反应是：终于有人把大模型用在正地方了。SysML v2带来的文本化模型表示法，让LLM从“只能聊天的助手”变成了“能直接写模型草稿的实习生”，而重工装备那种大量、重复、规则明确的建模工作量，恰好是LLM最擅长的场景。这篇内容适合正在做MBSE落地的工程师、架构师，以及数字化研发平台的技术负责人，我会把技术路线、实操步骤和踩过的坑都拆开讲。

1. 为什么是“LLM + SysML v2”这个组合

1.1 传统SysML v1建模的三座大山

先聊聊为什么SysML v1时代没人敢这么干。SysML v1是图形化建模语言，所有信息都画在图上。图的问题在于：它很难进版本管理、很难做自动比对、很难让机器去读。一个需求改了，你得手动去状态机图、活动图、块定义图里逐个检查影响，这个动作极其依赖人的经验和细心。而在兵器重工这种复杂装备场景里，系统层级深、专业域多，一辆底盘、一个火控装置背后可能挂着几十张图，任何一张图没跟着改，后续设计和仿真就可能建立在错误模型上。这是第一座山：图件一致性维护成本极高。

第二座山是工具锁定。SysML v1时代，换工具等于换格式，模型迁移靠手工重画，团队切换到新平台往往需要半年以上。第三座山是语义歧义，同一个“接口”在不同工具里的实现方式不一样，不同建模者画出来的模型风格差异大，Review时争论的往往不是设计本身，而是“你画的是不是标准语法”。

这三座山叠加起来，导致多数团队的SysML模型最后变成了“应付评审的PPT”，而不是真正驱动研发的数字资产。

1.2 SysML v2到底改了什么

SysML v2近几年定稿后，最核心的变化不是“更好看”，而是把模型语言从“图形优先”变成了“文本优先”与“语义优先”。它引入了规范的文本表示法（Textual Notation），模型可以用接近代码的形式写出来：包结构、部件定义、需求模块、状态定义都是可文本化的。这带来的连锁反应是革命性的：

• 模型可以像源代码一样纳入Git管理，每次变更都能diff。
• 工具之间有了标准API，模型可以被脚本读取、写入、校验。
• 模型语义更严格，类型化、量纲化做得更彻底，机器能理解“这个端口是电信号，不是液压信号”。

用个生活化的类比：SysML v1像是用Word画架构图，SysML v2像是用结构化代码写架构。代码一旦变成文本，LLM就有了用武之地——大模型对文本的解析、生成、改写能力远比“从图里理解信息”成熟得多。这就是标题里“LLM驱动”能成立的前提。

1.3 LLM在建模链路里的三个角色

我把LLM在SysML v2建模中的定位分成三类，大家可以根据团队现状选择切入。

第一是“翻译官”，把自然语言的需求文档、评审纪要、甚至Excel接口清单，翻译成SysML v2文本模型草稿。这个工作不需要LLM做创新设计，但需要它理解领域术语和建模语法之间的映射关系。

第二是“解释员”，给定一段模型文本，让LLM生成面向非建模人员的设计说明、变更影响分析、模型摘要。这个角色是低风险高回报的，适合第一批试点。

第三是“质检员”，让LLM辅助做一致性检查。比如需求模块里的文本是否与上游需求文档一致，状态机里是否有不可达状态，端口类型是否匹配。这个场景需要严谨设计提示词，因为LLM的“判断”不能全信，但可以极大缩小人工审查范围。

2. 技术路线设计：从“LLM画图”到“LLM写模型”

2.1 三条路线怎么选

我在实战中把LLM驱动SysML v2建模的落地方式归纳为三条路线，团队按自己的风险承受能力选。

第一条路线：LLM直接生成SysML v2文本模型。这是收益最大的路线，也是风险最高的。风险在于模型文本一旦有语法错误或语义幻觉，导入建模工具时会卡住。第二条路线：LLM作为语义助手，做模型解释、摘要、评审辅助。这条路线几乎零风险，因为它不产生正式模型，只产生阅读材料。第三条路线：基于RAG的模型库问答，把历史项目的模型文本向量化，建一个“模型知识库”，设计人员可以问“以前XX系统是怎么定义接口的”，LLM从历史模型库中检索并回答。

我用一个表格对比一下：

我个人建议：团队第一次试点千万不要直接上路线A，先让LLM写几份模型审查报告，让工程师感受一下“机器能看懂我的模型”，建立信任之后，再逐步开放“生成草稿”的能力。从我观察到的实际情况看，卡住团队的不是LLM不会生成模型，而是工程师不敢把LLM生成的模型导入正式模型库。

2.2 提示词工程与领域知识注入

要让LLM稳定输出规范的SysML v2文本，提示词里必须给出三样东西：语法样例、命名规则、禁止事项。

语法样例最关键。SysML v2的文本表示法仍在快速演进，LLM训练语料里的SysML v2内容本来就少，不给样例，它就会按自己的理解“编一个像但不是”的语法。我习惯的做法是：在系统提示词里固定贴上三段核心样例，分别覆盖需求模块、部件定义、状态转换的写法，再告诉LLM“严格模仿这个结构，不要发明新语法”。

命名规则要写成硬约束。比如所有需求模块以“REQ-”开头，所有端口命名结尾带“Port”，不允许出现空格和中文标点。这些看起来琐碎的规则，直接决定LLM输出的模型能不能通过工具的语法解析。

禁止事项也要写上。我见过LLM在生成需求模块时，自己脑补出原文根本没有的性能指标；也见过它把需求自动“升级”成了设计约束。所以我通常在提示词末尾加一句：“严格基于给定信息建模，不要添加原文不存在的内容。”这一步虽然简单，但能把幻觉率降低一半以上。

领域知识注入方面，路线C的效果最明显。把历史项目的模型文本做清洗和分块后向量化，再配合RAG，LLM的回答就从“泛泛而谈的SysML知识”变成“你们企业自己的模型经验”。这里有一个补充说明：RAG知识库建设需要花时间清洗，但这是长期收益，越早建越划算。

2.3 数据安全与私有化部署

复杂装备研制单位的数据管控等级有多高，经历过的人都懂。涉密项目的需求描述、接口定义、状态逻辑，任何一条流到公网都是事故。所以LLM服务的部署方式没有第二个选项：必须是内网私有化部署。

实操层面给大家一个参考：第一批试点不需要上几百B的旗舰模型，7B到13B量级的开源模型在“文本转模型”这种结构化任务上已经能达到不错的准确率，关键是提示词设计和后处理校验。一台双卡服务器基本够用，比很多人想象的成本低。历史模型语料入库之前一定要做脱敏处理，把型号、编号、特殊参数值替换成通用占位符，既保护数据安全，也不会影响LLM学习建模模式。

3. 核心建模场景实操拆解

3.1 场景一：需求文本自动转成需求模块

这是我认为最值得推广的场景。复杂装备的需求文本往往以Word文档形式存在，几百条需求散落在几十页文档里，建模人员要手工逐条提取属性、分配ID、确认验证方法。这个工作的特点是规则明确、重复量大、附加值低，完全适合LLM承担。

具体流程我是这么设计的：

第一步，清洗需求文本。用脚本把Word里的编号、标题层级、段落提取成纯文本，去掉页眉页脚和图表干扰。

第二步，按需求粒度切分。这一步很关键，一条合格的需求应该只描述单一能力。LLM天然适合做粒度切分，但需要在提示词里明确：“如果一段文本包含多个独立能力，请拆分为多条需求。”重工领域的需求经常一句话里包含“既能……又能……”，拆得好坏直接影响下游追溯。

第三步，提取需求属性。让它生成SysML v2的需求模块，结构类似这样（示意语法，具体以工具实现为准）：

package RequirementModel { requirement def VehicleSpeedReq { id = "REQ-SPEED-001"; name = "车辆最大行驶速度要求"; text = "车辆在平直路面上最大行驶速度不低于60km/h"; verifyMethod = "TEST"; } }

第四步，人工审查。工程师只需要审查LLM的提取结果，而不是从零开始写模型，工作量至少下降70%。我实测的效果是：规则类的性能需求、接口需求，LLM的提取准确率能到85%以上；而涉及主观判断的约束性需求，需要人工重点看。

3.2 场景二：Excel接口清单转成端口与接口模型

重工装备里有海量的电气接口、液压接口、机械接口。这些接口信息通常维护在Excel清单里，列名、数据类型、单位五花八门，而SysML v2要求端口必须绑定类型化的接口定义。人工逐条迁移的做法效率极低，LLM在这个场景里简直就是“格式转换神器”。

我给的提示词框架会包含三个部分：原始Excel行的内容说明、SysML v2端口定义样例、映射规则（列名到属性的对应关系）。例如，要求LLM把“信号名称、方向、数据类型、单位、备注”映射为端口定义中的对应属性，数据类型统一转换为SysML v2标量类型，单位统一转换为标准单位并保留换算因子。

实际操作中我保留了一个LLM不擅长的工作：数据清洗后的编号唯一性检查。LLM有可能把两行相似接口内容合并，或漏掉一行。我的解决办法是：让LLM输出结构化JSON，再用Python脚本比对原Excel行数和模型数量，数量对不上就自动拦截。这是纯规则校验，比让LLM自己检查自己可靠得多。

3.3 场景三：状态机建模辅助与一致性校验

状态机建模是LLM参与感最强、但最容易翻车的场景。让LLM根据测试用例或时序描述生成状态机草稿，它的表现令人惊喜；但一旦涉及并发状态、嵌套状态，它经常画出逻辑上自洽但与系统约束冲突的图。

我的做法是把LLM定位成“建模辅助”：输入是已有的文本化状态机定义和系统约束，输出是潜在问题清单。举个例子，LLM可以检查是否有从未进入的状态，是否有状态迁移缺少触发事件。但不能让它“直觉式”地推断新状态，那会把模型引向错误方向。

这个场景有一个很实用的技巧：把状态机的可执行验证交给工具，而不是LLM。LLM生成状态机后，我用脚本把模型文本导入建模工具，借助自带的语义检查能力跑一遍，确认无误后再合并。LLM负责“想得快”，工具负责“查得准”，两者互补。

3.4 一套完整的混合工作流

我们把上面的场景串起来，就得到一套可落地的混合工作流：需求文档进入系统后，LLM先做需求切分与属性提取，生成需求和用例模型草稿；接着，针对接口清单，LLM生成端口与接口定义草稿；再通过建模工具的标准API，把草稿导入临时模型库；系统跑一遍自动校验脚本，拦截格式错误和一致性冲突；最后，由建模工程师在工具里人工精修，确认后合并到正式模型库，并以版本标签记录变更。每一步都有人的审查位，LLM始终被限制在“草拟者”的角色上，不给它直接改正式模型的权限。这套工作流我们内部叫“人工在环的AI辅助建模”，听起来朴素，但实用。

4. 落坑实录：那些文档里看不到的事

4.1 最大的坑：LLM的“伪精确”

做这套实践以来，我踩过最大的坑不是语法问题，而是LLM输出看起来“完全正确”但实际是错的。它会给需求加上一个根本不存在于原始文档中的约束值；会根据命名习惯“推断”出根本没在代码里定义的接口；甚至会为了满足模型完整性，自动创建一个缺失的部件并取个看似合理的名字。这类错误单独看每一条都不致命，但累积起来，会让模型慢慢偏离真实设计，最后变成“看起来很美，但不能用来做仿真分析”的假模型。

我现在的硬性防线有三道：正则规则校验（如需求ID格式、数量核对）、建模工具内置语义检查、以及最笨但最有效的人工抽查。每一批LLM生成的模型文本，抽取15%到20%做人工与原文对照。抽查比例看起来不高，但已经足够拦住系统性问题。

4.2 上下文窗口的紧张问题

SysML v2文本模型行数一旦多起来，token消耗速度远超预期。一个包含三十个部件定义、若干状态机的包，可能轻松超过两万token。如果一次性把整个包丢给LLM让它“继续补全”，模型很快就会偏离开头的要求，甚至开始重复内容。

我的解决方案是“分块建模”：按照包和模型层级切分任务，每次只让LLM处理一个小规模的模型元素集合。需求就按章节分，接口就按子系统分，状态机就按状态域分。分块生成后由脚本做合并。这样做的好处不仅是绕开上下文限制，还能让每一块的审查更聚焦，问题定位更精准。

4.3 多人协作时的版本冲突

当模型文本进入Git后，新问题立刻出现。两个人同时基于LLM草稿修改同一个包，提交时必定冲突，而SysML模型的冲突合并比代码冲突更难处理——因为模型元素之间的关系网是隐式的，文本上的两行合并可能破坏模型语义。

我的建议是：把模型库的分支策略收紧。不是一个分支随便提，而是“模型提交必须走评审”。每个PR对应一次架构评审，LLM只是起草者，发布级模型只能由核心建模人员合并。这个办法让模型变更速度变慢了，但模型质量明显提升，团队对LLM的信任感就是这么建立的。

4.4 常见问题速查表

4.5 话糙理不糙的经验

系统做了几个月后，我的体会是：LLM在SysML v2建模里最大的价值不在“自动画图”，而在“把设计约束变成机器可读、可审查、可追溯的文本流”。它最适合处理那些工程师骨子里觉得枯燥但实际上又很重要的翻译工作——从需求文档到需求模型，从Excel清单到接口模型，从评审纪要到变更建议。这些工作不涉及真正的设计权衡，却占据建模人员大量时间。而真正的设计决策、模型仲裁、质量标准，还是得靠人。

最后分享一个我一直在用的小技巧：每次让LLM生成模型文本前，我都会在提示词的最后一行加上一句“请以一名严谨的系统建模工程师的标准审查以上输出，并剔除冗余内容”。这个简单的动作，能让输出更干净，也更好用。工具永远只是杠杆，但用对了杠杆，也确实能撬动不少之前搬不动的石头。