1. 从一份兵器重工的建模需求说起第一次听到“兵器重工”这四个字和“LLM驱动建模”放在一起的时候我脑子里冒出来的画面是车间里火花四溅、工程师抱着图纸来回跑的场景。但真正接触下来才发现现在重型装备制造企业的研发部门早就不是那个样子了。他们面对的是动辄几十万个零件、上百个系统交联的复杂产品光靠人脑和二维图纸根本管不住。这也是为什么MBSE基于模型的系统工程这几年在重工行业被反复提起——大家需要一个统一的、机器可读的模型把需求、结构、行为、参数全部串起来。SysML v2就是在这个背景下被推上台面的。相比v1v2最大的变化是它不再只是一个画图工具的语言而是有了正式的文本语法、明确的语义定义、可编程的API接口。说白了v1时代你画完图模型和文本是两张皮v2时代模型本身就是文本文本就是模型这给自动化处理打开了大门。而LLM大语言模型恰好擅长处理文本、理解语义、生成结构化内容两者一结合就出现了“用自然语言描述需求自动生成SysML v2模型”这类实践。这个案例的核心价值在于它把过去需要资深系统工程师花几天甚至几周才能完成的建模初稿工作压缩到了几分钟级别。适合谁来参考我认为三类人最应该看一是重工、航天、汽车等复杂装备行业的系统工程师你们会直接用到这套方法二是做MBSE工具链开发的技术人员你们需要理解LLM和建模语言之间的接口怎么设计三是对LLM落地工程场景感兴趣的技术管理者这个案例能帮你判断投入产出比。2. 为什么是SysML v2而不是v12.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 APIjsonschema用于校验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 常见问题速查表问题现象可能原因排查方法解决措施解析器报语法错误括号不匹配、关键字拼错、中文标点定位错误行检查附近代码规范化标点用模板生成模型缺少某些需求需求提取遗漏、上下文超限对照需求文档逐条检查分块处理增加提示词约束接口类型不匹配LLM理解偏差、类型定义不清检查接口两端的类型定义维护领域本体增加示例生成速度慢模型太大、API限流查看生成日志统计耗时分块生成加缓存并行调用同一概念命名不一致缺少术语表、LLM自由发挥搜索相似名称人工比对建立术语表生成后做命名检查提示这张表建议打印出来贴在工位上遇到问题先查表能省不少时间。7. 我个人的实操体会与后续扩展方向这个案例我跟踪了一段时间也自己动手复现了核心流程。最大的体会是LLM辅助建模的关键不在于LLM本身有多强而在于整个流水线的设计。提示词怎么写、中间格式怎么定、检查规则怎么设、人工审核怎么衔接这些工程细节决定了最终效果。LLM只是一个组件把它放进合适的系统里才能发挥价值。另一个体会是领域知识的注入至关重要。通用LLM对兵器重工的业务理解有限必须通过术语表、示例、微调等方式把领域知识喂给它。这个工作前期投入不小但一旦做好后续所有项目都能受益。后续扩展方向我觉得有几个值得尝试。一是把模型和仿真工具打通生成模型后自动跑仿真验证行为是否正确。二是做增量更新需求变了只重新生成受影响的部分不用全量重跑。三是把LLM用到模型评审环节让它自动检查模型是否符合设计规范减轻人工审核负担。这些方向我还在摸索中有进展再跟大家分享。
