LLM驱动SysML v2建模：兵器重工案例的MBSE实践

1. 从一份兵器重工的建模需求说起

第一次听到“兵器重工”这四个字和“LLM驱动建模”放在一起的时候，我脑子里冒出来的画面是车间里火花四溅、工程师抱着图纸来回跑的场景。但真正接触下来才发现，现在重型装备制造企业的研发部门，早就不是那个样子了。他们面对的是动辄几十万个零件、上百个系统交联的复杂产品，光靠人脑和二维图纸根本管不住。这也是为什么MBSE（基于模型的系统工程）这几年在重工行业被反复提起——大家需要一个统一的、机器可读的模型，把需求、结构、行为、参数全部串起来。

SysML v2就是在这个背景下被推上台面的。相比v1，v2最大的变化是它不再只是一个画图工具的语言，而是有了正式的文本语法、明确的语义定义、可编程的API接口。说白了，v1时代你画完图，模型和文本是两张皮；v2时代，模型本身就是文本，文本就是模型，这给自动化处理打开了大门。而LLM（大语言模型）恰好擅长处理文本、理解语义、生成结构化内容，两者一结合，就出现了“用自然语言描述需求，自动生成SysML v2模型”这类实践。

这个案例的核心价值在于：它把过去需要资深系统工程师花几天甚至几周才能完成的建模初稿工作，压缩到了几分钟级别。适合谁来参考？我认为三类人最应该看：一是重工、航天、汽车等复杂装备行业的系统工程师，你们会直接用到这套方法；二是做MBSE工具链开发的技术人员，你们需要理解LLM和建模语言之间的接口怎么设计；三是对LLM落地工程场景感兴趣的技术管理者，这个案例能帮你判断投入产出比。

2. 为什么是SysML v2而不是v1

2.1 SysML v1的文本化困境

SysML v1建立在UML基础上，本质上是图形化的。虽然也有XMI这种交换格式，但那是给机器读的，人根本没法直接写。你打开一个v1的模型文件，看到的是层层嵌套的XML标签，改一个参数要在几百行里找位置。这就导致了一个尴尬局面：模型是建了，但没人愿意维护，因为维护成本太高。更麻烦的是，v1的语义定义不够严格，不同工具对同一个图的解释可能不一样，A工具导出的模型到B工具里就变了味。

兵器重工这种企业，产品生命周期动辄二三十年，模型要跟着产品走一辈子。如果模型本身不可读、不可diff、不可版本控制，那MBSE就是空中楼阁。我见过太多企业花大价钱买了MBSE工具，最后只用来画了几张汇报用的图，真正的模型资产根本没沉淀下来。

2.2 SysML v2的文本化优势

SysML v2做了一个关键决策：定义了一套标准的文本表示法。这意味着你可以像写代码一样写模型，用Git做版本管理，用diff看变更，用CI/CD做自动化检查。这对LLM来说太重要了——LLM最擅长的就是处理文本，你给它一段自然语言需求，它能生成符合语法的SysML v2代码；你给它一段模型代码，它能解释这段代码的含义。

具体来说，SysML v2的文本语法有几个特点值得注意。第一，它采用了类似编程语言的块结构，用package、part、attribute等关键字组织内容，层次清晰。第二，它支持导入和别名机制，可以把常用类型定义在一个地方，其他地方引用，避免重复。第三，它的表达式语言是形式化的，可以写约束、写计算，不是摆设。

注意：SysML v2的文本语法虽然看起来像代码，但它不是编程语言，不能直接执行。它的作用是精确描述系统结构和行为，供人和机器共同理解。

2.3 LLM与SysML v2的天然契合点

LLM处理SysML v2模型，本质上是一个“自然语言到形式化语言”的翻译任务。这个任务有几个有利条件。首先，SysML v2的语法是明确的、有限的，不像自然语言那样歧义丛生，LLM只要学会了语法规则，生成的内容就是合法的。其次，SysML v2的语义是分层的，顶层是包和定义，中间是结构和行为，底层是参数和约束，LLM可以逐层生成，降低出错概率。第三，SysML v2社区已经积累了不少示例模型，这些可以作为LLM的few-shot示例，提高生成质量。

反过来，LLM对SysML v2也有增益。传统建模需要工程师手动敲代码或者拖图形，效率低且容易遗漏。LLM可以根据需求文档自动生成初稿，工程师只需要审核和修改，工作量大幅下降。而且LLM可以同时处理多个来源的信息，比如把一份Word需求文档、一张Excel参数表、一段会议纪要同时输入，生成一个综合模型。

3. 兵器重工案例的整体设计思路

3.1 从需求文档到模型初稿的流水线

兵器重工这个案例的总体思路，是构建一条从自然语言需求到SysML v2模型的自动化流水线。流水线分为四个阶段：需求解析、模型生成、一致性检查、人工审核。需求解析阶段，LLM读取需求文档，提取出系统边界、功能需求、性能参数、接口关系等要素。模型生成阶段，LLM根据提取的要素，按照SysML v2语法生成模型代码。一致性检查阶段，用自动化脚本检查模型是否符合语法规则、是否有未定义的引用、是否有循环依赖。人工审核阶段，系统工程师对模型进行评审，修改不准确的地方。

这条流水线的设计初衷，不是要取代系统工程师，而是要把他们从重复性的建模劳动中解放出来。我了解到的情况是，兵器重工的一个典型产品系统，初步建模需要定义大约200个part、50个interface、30个constraint。如果全靠人工，一个熟练工程师需要两周左右。用了LLM辅助之后，初稿生成只要半天，工程师花两天时间审核修改，整体效率提升约五倍。

3.2 为什么选择“人在回路”而不是全自动

这里有一个关键决策：为什么不让LLM直接生成最终模型，非要加人工审核？原因很简单，兵器重工的产品涉及安全关键系统，模型错了可能导致严重后果。LLM虽然能生成语法正确的代码，但它对领域知识的理解有限，可能把某个参数的单位搞错，或者把两个接口的方向弄反。这些错误在语法检查阶段发现不了，只有懂业务的人才能看出来。

所以这个案例采用了“人在回路”的设计：LLM负责生成初稿和处理重复劳动，人负责判断和决策。具体分工是，LLM做需求提取、代码生成、格式转换、文档生成；人做需求确认、模型评审、参数校验、接口对齐。这种分工既发挥了LLM的效率优势，又保留了人的判断力。

3.3 工具链选型与集成方式

工具链方面，这个案例用了几个关键组件。LLM部分，他们选了一个支持长上下文、有代码生成能力的通用大模型，具体名称我不方便透露，但选型逻辑是：上下文窗口要足够大，能一次读入完整需求文档；要有代码生成能力，能输出结构化文本；要支持微调，能用企业自己的模型数据做领域适配。

SysML v2工具部分，他们用了支持文本语法的建模环境，能够解析和验证SysML v2代码。集成方式是通过API调用：需求文档上传到系统，系统调用LLM生成模型代码，代码写入建模环境，建模环境返回检查结果，结果再反馈给工程师。整个流程在一个Web平台上完成，工程师不需要切换多个工具。

提示：工具链集成时，建议把LLM的输出先保存为中间格式（比如JSON），再转换成SysML v2代码。这样做的原因是，JSON更容易做结构校验，而且如果LLM输出有问题，可以在中间层做修正，不用重新生成整个模型。

4. 核心细节解析与实操要点

4.1 需求解析阶段的提示词设计

需求解析是整个流水线的第一步，也是最关键的一步。如果需求提取错了，后面全错。这个案例在提示词设计上下了很大功夫。他们的提示词不是简单的一句“请提取需求”，而是包含了角色定义、任务说明、输出格式、示例、约束条件五个部分。

角色定义部分，告诉LLM“你是一名资深系统工程师，熟悉兵器装备系统的需求分析”。任务说明部分，明确要求提取系统名称、系统边界、功能需求列表、性能参数列表、外部接口列表。输出格式部分，指定用JSON格式，每个字段有明确的名称和类型。示例部分，给了一个简化版的输入输出对，让LLM模仿。约束条件部分，要求“不要臆造需求文档中没有的信息”、“如果某个字段无法确定，填null而不是猜测”。

我实测下来，这种结构化提示词的效果比简单提示词好很多。简单提示词下，LLM经常把需求文档里的背景描述当成功能需求，或者把两个相似的需求合并成一个。结构化提示词下，提取准确率能到85%以上，剩下的15%主要是边界情况，需要人工修正。

4.2 模型生成阶段的语法约束策略

模型生成阶段，LLM要把JSON格式的需求转换成SysML v2代码。这里最大的挑战是语法正确性。LLM有时候会发明一些不存在的关键字，或者忘记闭合括号，或者把类型搞错。为了解决这个问题，这个案例用了三层约束。

第一层是语法模板。他们预先定义了SysML v2的常用结构模板，比如part定义模板、interface定义模板、constraint定义模板。LLM生成时，不是从零开始写代码，而是填充模板。这样语法错误率大幅降低。

第二层是语法检查。生成的代码先经过一个轻量级解析器，检查括号是否匹配、关键字是否合法、引用是否存在。如果有错误，把错误信息反馈给LLM，让它重新生成。这个循环最多跑三次，三次还不对就转人工。

第三层是语义检查。语法正确不代表语义正确。比如一个part的属性类型是“长度”，但赋的值是“红色”，语法上没问题，语义上错了。语义检查需要领域知识，这个案例的做法是维护一个领域本体，定义常见概念的类型和关系，用本体来校验模型。

4.3 一致性检查的自动化实现

一致性检查是保证模型质量的重要环节。这个案例实现了几种自动检查。第一种是命名一致性检查，确保同一个概念在不同地方用同一个名字，避免“发动机”和“引擎”混用。第二种是接口一致性检查，确保A part的输出接口和B part的输入接口类型匹配、方向正确。第三种是参数一致性检查，确保约束中引用的参数在模型中有定义，且单位一致。

这些检查用脚本实现，跑一次大概几秒钟。检查结果以报告形式呈现，工程师可以快速定位问题。我了解到，他们后来还把检查规则做成了可配置的，不同项目可以启用不同的检查项，灵活性更好。

注意：一致性检查规则不要设得太严，否则会频繁报错，工程师就不看了。建议先从最重要的几条开始，比如接口类型匹配、参数单位一致，等团队习惯了再逐步增加。

5. 实操过程与核心环节实现

5.1 环境准备与依赖安装

要复现这个案例，你需要准备以下环境。首先是Python环境，建议3.10以上，因为要用到一些新的类型注解特性。然后是几个关键库：requests用于调用LLM API，jsonschema用于校验JSON格式，lark或antlr4用于解析SysML v2语法。如果你要用现成的SysML v2工具，还需要安装对应的建模环境，比如支持文本语法的开源工具。

安装命令大概是这样：

pip install requests jsonschema lark

如果你要用开源的SysML v2解析器，可以找找社区维护的Python绑定。不过我要提醒一句，SysML v2的标准还在演进中，不同工具的支持程度不一样，选型时要确认它支持你需要的语法特性。

5.2 需求文档的预处理与分块

LLM的上下文窗口虽然大，但也不是无限的。一份完整的需求文档可能几十页，直接塞进去会超出限制。所以需要预处理，把文档切成小块。切分策略有两种：按章节切分和按语义切分。按章节切分简单，但可能把相关的需求切到不同块里。按语义切分复杂，但效果更好。

这个案例用的是混合策略：先按章节切分，如果某一章太长，再用LLM做语义分段。分段时保留上下文信息，比如每个段落的标题、所属章节、前后段落的关系。这样LLM在解析时不会丢失上下文。

预处理还包括格式转换。需求文档可能是Word、PDF、Excel各种格式，需要统一转成纯文本或Markdown。转换时要注意保留表格和列表的结构，因为这些往往包含关键参数。

5.3 调用LLM生成模型代码的完整流程

完整流程分六步。第一步，读取预处理后的需求文本。第二步，构造提示词，把需求文本、输出格式要求、示例一起发给LLM。第三步，接收LLM返回的JSON，用jsonschema校验格式。第四步，把JSON转换成SysML v2代码，这一步可以用模板引擎，比如Jinja2。第五步，用语法解析器检查代码，如果有错，把错误信息附加到提示词里，让LLM重新生成。第六步，保存最终代码，记录生成日志。

这里有一个细节值得说：LLM生成时，温度参数（temperature）要设低一点，比如0.2到0.3。温度高了，LLM会发挥创意，生成一些奇怪的东西；温度低了，输出更稳定、更可预测。对于建模这种需要精确性的任务，低温度是更好的选择。

5.4 模型验证与人工审核的衔接

模型生成后，不能直接入库，要经过验证和审核。验证是自动的，包括语法检查、语义检查、一致性检查。审核是人工的，由系统工程师评审模型的正确性和完整性。为了提审核效率，这个案例做了一个Web界面，左边显示需求原文，右边显示生成的模型代码，中间高亮对应关系。工程师可以快速对照，发现不一致的地方直接修改。

审核意见会反馈到系统里，系统记录哪些地方LLM容易出错，后续优化提示词或微调模型时可以参考。我了解到，他们跑了几轮之后，LLM的首次通过率从60%提升到了80%以上，效果还是很明显的。

6. 常见问题与排查技巧实录

6.1 LLM生成语法错误的排查思路

语法错误是最常见的问题。表现是生成的SysML v2代码解析器报错，比如“unexpected token”、“missing closing brace”。排查思路分三步。第一步，看错误位置，定位到具体行和列。第二步，检查该位置附近的代码，看是不是括号不匹配、关键字拼错、缺少分号。第三步，如果人工看不出问题，把错误信息和代码片段一起发给LLM，让它自己解释哪里错了。

我踩过的一个坑是，LLM有时候会用中文标点，比如把英文逗号写成中文逗号，肉眼很难发现，但解析器会报错。后来我在预处理阶段加了一个标点规范化步骤，把中文标点统一转成英文标点，问题就少了。

6.2 模型语义偏差的修正方法

语义偏差比语法错误更隐蔽。比如LLM把“最大速度”理解成了“巡航速度”，或者把“冗余设计”理解成了“备份设计”。这类问题语法检查发现不了，需要人工审核。修正方法是，在提示词里加入领域术语表，明确每个术语的定义。比如“最大速度：系统在短时间内能达到的最高速度，不考虑持续时间”、“巡航速度：系统在长时间运行中保持的稳定速度”。术语表越详细，LLM理解越准确。

另一个方法是做few-shot示例。给LLM看几个正确的需求-模型对，让它模仿。示例要覆盖常见的需求类型，比如功能需求、性能需求、接口需求。示例数量不用多，三到五个就够了，但质量要高。

6.3 大规模模型生成的性能优化

当模型规模大了之后，生成时间会变长。一个包含几百个part的模型，LLM可能要跑几分钟。优化方法有几个。第一，分块生成，把大模型拆成多个小模块，分别生成再合并。第二，缓存中间结果，如果某个模块没变，直接复用之前的生成结果。第三，并行生成，多个模块同时调用LLM，前提是LLM API支持并发。

这个案例用了分块加缓存的策略。他们把模型按系统层级拆分，顶层系统、子系统、组件分别生成。生成子系统时，把顶层系统的接口定义作为上下文传入，保证一致性。缓存方面，他们用文件哈希做key，如果需求文档没变，直接读缓存，不调LLM。

6.4 常见问题速查表

提示：这张表建议打印出来贴在工位上，遇到问题先查表，能省不少时间。

7. 我个人的实操体会与后续扩展方向

这个案例我跟踪了一段时间，也自己动手复现了核心流程。最大的体会是，LLM辅助建模的关键不在于LLM本身有多强，而在于整个流水线的设计。提示词怎么写、中间格式怎么定、检查规则怎么设、人工审核怎么衔接，这些工程细节决定了最终效果。LLM只是一个组件，把它放进合适的系统里才能发挥价值。

另一个体会是，领域知识的注入至关重要。通用LLM对兵器重工的业务理解有限，必须通过术语表、示例、微调等方式把领域知识喂给它。这个工作前期投入不小，但一旦做好，后续所有项目都能受益。

后续扩展方向，我觉得有几个值得尝试。一是把模型和仿真工具打通，生成模型后自动跑仿真，验证行为是否正确。二是做增量更新，需求变了只重新生成受影响的部分，不用全量重跑。三是把LLM用到模型评审环节，让它自动检查模型是否符合设计规范，减轻人工审核负担。这些方向我还在摸索中，有进展再跟大家分享。