做复杂装备系统工程的同行应该都体会过SysML v1时代那种“图越来越重、人越来越累”的感觉。模型画了一大堆内部接口对不上需求变更一来牵一发动全身维护成本高到让人怀疑建模这件事本身的意义。我在兵器重工参与系统建模工具链建设的那段时间正好赶上SysML v2标准出来又赶上LLM的能力被大家重新认识于是我们就试着把两者放到一起用LLM去驱动SysML v2建模。这个方向听起来新做起来其实有非常清晰的路径也有不少让人哭笑不得的坑。这篇文章把我们的整体思路、落地框架和踩过的坑都梳理出来给正在评估这条路的团队一个参考。为什么是SysML v2从“画图语言”到“机器可读语义”的关键升级1.1 SysML v1在重工场景下的三个老大难问题我在项目里天天和需求文档、接口定义、行为逻辑打交道对于既往的建模方式感受最深的是三个痛点。第一SysML v1是图形化语言一切操作都依赖建模工具的画布模型的本质是“图元”不是“数据”。兵器重工这类产品往往是复杂装备一个整车级系统拆到子系统、部件模型图动辄上百张图与图之间的引用关系靠人工维护一个参数改了关联图不知道哪里没跟上最后不一致的地方越积越多。第二工具之间的互操作基本靠XML文件交换但不同厂商工具实现的SysML v1方言并不完全一致换个工具链就要做转换转换过程还会丢信息。第三SysML v1对需求到设计到验证的追溯支持是有的但用起来很绕繁琐到很多项目组干脆只画架构图追溯矩阵用Excel手工维护那建模的实际价值就打了大折扣。这三个问题堆在一起导致很多复杂性高的研制项目里模型更像是“汇报材料”而不是真正驱动研发的数据底座。工具也有责任但更根本的是语言本身缺乏语义完整性。SysML v1标准侧重于图符语法底层没有规范的语义模型来约束元素之间的关系所以工具实现五花八门模型交换自然就难。1.2 SysML v2到底改了什么为什么对LLM如此友好SysML v2最核心的变化是从“图符为中心”转向“语义为中心”。它引入了一个底层语义库模型KerML所有SysML v2的建模元素都有明确的语义定义。同时SysML v2提供了标准文本表示法也就是可以用类似编程语言的结构化文本来描述模型图形视图则变成对语义模型的一种“投影”。再加上标准REST API和查询语言整个语言具备了当代软件工程该有的基础能力。这三个变化对工程实务的意义非常大。语义模型保证了数据的机器可读性图只是视图数据始终保持一致。文本表示法意味着建模不再被锁定在某个工具的画布里可以用纯文本方式编写和交换模型。API和查询语言让模型可以被外部程序检索和分析。对LLM来说这简直是量身定做的变化。LLM本质是处理序列和文本的模型SysML v1那一堆图形符号和画布交互LLM根本无从下手。而SysML v2的文本语法跟代码生成是同一类问题LLM看到的是一段结构化的、有明确语法规则和语义约束的文本训练数据和推理方式都匹配。我们内部当时有个判断SysML v2出现之前LLM做建模最多只能辅助写写需求文档SysML v2出现之后LLM可以直接参与到模型主体的创建和迭代。后来实践下来这个方向判断是对的。1.3 为什么选择“LLM驱动”而非完全自动化这里先说清楚一个理念问题。我们不是想把建模工程师替代掉LLM驱动建模的目标是解决重复劳动和低层级的体力活不是取代人对系统架构的判断。兵器重工的研制链条里每一个设计决策都关联到安全性、可靠性和总体性能没有人敢让模型在没有人工签审的情况下直接进入下游流程。所以我们从一开始就把LLM定位成“资深建模助理”它的产出是草稿和建议决策权始终在工程师手里。这个定位决定了后面整个架构设计的方向既要让LLM尽量放开手脚生成内容又必须在关键节点留出人工确认和系统校验的环节。LLM驱动建模的整体框架需求文本到有效模型要过的四道关口2.1 一级处理需求文本的清洗与结构化解构需求文档是我们项目里最常见的输入它可能是自然语言段落、表格条目甚至是从历史文档里扫描出来的片段。文本越杂乱LLM生成模型的准确率越低所以第一步不是直接让它建模型而是让LLM先把需求文本拆解成结构化条目。我给这一步取名叫需求解析。实际操作中我们会把整段需求文档切分成以“单条需求”为单位的文本块然后让LLM逐条抽取关键属性需求编号、需求类型功能、性能、接口、外部约束等、涉及的部件或子系统、可量化的指标参数、关联的前置条件。比如原始需求是“整车在满载状态下从初速100km/h到完全停止的制动距离不大于45m”解析后变成一条结构化记录包含部件对象是整车指标项是制动距离工况是满载基准值是45m。这个环节有两个容易被忽略的细节。一是术语统一兵器重工内部对同一对象有多种叫法比如“车体”“上装”“平台总成”在不同文档里混用如果不做归一化后面生成的SysML v2元素会出现重复和语义分裂。二是量值和单位的识别需求文本里的“不大于45m”和“≤45米”要能被LLM识别为同一个能用于模型约束的数值属性否则后续校验无从谈起。2.2 二级处理概念映射把自然语言落到SysML v2语义上需求解析完成后得到的是结构化文本还不是模型。第二步要做概念映射也就是把自然语言表达的专业概念对应到SysML v2定义的元素类型上。比如一句话里提到“系统在运行中对外部环境提供某种功能”这对应的可能是SysML v2里的ActionUsage或FunctionUsage“设备之间通过物理接口连接”对应PortUsage和Connector而“操控软件和火控软件之间传递目标数据”对应Message或ItemFlow。这一步LLM表现出了远超预期的能力因为SysML v2的语义模型和自然语言的对应关系对于有足够训练语料的LLM来说是相对容易把握的模式尤其在我们给了一些内部术语词典之后映射的精确度明显提高。但这一步也是最需要人工介入的地方。同一个需求文本在不同建模风格下可能被映射成不同类型元素选择哪个取决于团队既定的建模规范。所以我们在概念映射之后加了一个“建模意图确认”环节把LLM的映射结果以清单形式返回给建模工程师由快速确认或修正。实测下来这个环节每次大约需要40秒到2分钟成本可控但能防止后面全链路偏差。2.3 三级处理模型片段生成从结构化描述到SysML v2文本概念映射得到的是“该建什么元素”的结论接下来的问题是怎么用SysML v2文本语法把这个元素正确表达出来。这就是LLM最擅长的工作相当于根据结构化描述写代码。以一条需求为例映射结果确定了需求元素类型、所属包路径、关联的对象、约束属性LLM需要生成一段符合SysML v2语法定义的需求声明。如果是一个接口还要生成端口定义和连接关系。我们会刻意把这一步的生成范围限制在“单个模型片段”级别例如一次生成一个包或一个part的完整定义而不是让LLM一次性输出整个系统的模型。原因很简单生成范围越小LLM越容易遵循语法和约束错误排查也越简单。2.4 四级处理校验修复模型的语义合法性检查与反馈闭环LLM生成的模型片段不会直接入库必须经过校验环节。我们实现了一个校验服务底层用了SysML v2参考解析器以及自定义的建模约束检查。校验服务发现的问题会以错误清单形式发回给LLM让它重新生成修改后的版本。整个处理链路从需求解析开始经过概念映射、模型片段生成、校验修复最后进入人工签审才算完成一次真正的建模动作。刚开始的时候我们发现越到后面的环节越关键前几步做得再好如果第四步把关不严模型库里积累的垃圾模型只会比人工作业时更多因为LLM生成速度太快垃圾也在加速生成。关键实现SysML v2文本语法生成与RAG知识增强的配合3.1 一个直观的SysML v2文本语法示例先用一个最简单例子直观说明SysML v2文本语法是什么样的。假设我们要表达一条整车制动距离需求package VehicleRequirements { requirement def reqBrakingDistance { doc 整车在满载状态下初速100km/h至完全停止的制动距离不大于45m; id REQ-BD-001; subject 整车制动系统; satisfies 目标值45m; } }这段文本定义了名为reqBrakingDistance的需求元素包在VehicleRequirements里doc是描述id是编号subject是对象satisfies是满足的约束。SysML v2的模型就是由各种类似这样的语义块组成再通过组合、引用、泛化关系构成复杂模型。对LLM来说这种文本语法远比图形符号容易生成。但语法容易生成不等于语义正确LLM经常生成形似而神不似的代码比如satisfies的表达式写错或者引用的元素未在包内定义。这也是为什么必须在生成链路里加入严格校验。3.2 RAG知识库不只喂规范还要喂企业自己的建模模式让LLM生成SysML v2模型前一个简单做法是直接把SysML v2规范文档丢给它。但我们很快就发现不够因为标准规范描述的是“语言本身能表达什么”而企业实际建模需要的是“在这个项目里应该怎么用这个语言表达我们的产品”。后者是规范里没有的必须靠企业自身的建模模式库。我们给RAG知识库灌了三层内容。第一层是SysML v2标准语法指南和示例模型这部分保证LLM的基本语法能力。第二层是兵器重工内部的建模规范包括元素命名规则、包结构划分方式、需求追溯标记规范、端口和接口建模约定等。第三层是历史优秀模型片段我们把过去人工建模中质量较高的模块拆分出来去标识化处理后作为few-shot示例让LLM在生成类似结构时能模仿已有良好实践。知识库作用最明显的是端口和接口建模。重工产品的接口非常复杂液压、电气、机械、通信各领域接口语义不同标准SysML v2端口定义比较通用但企业内部有明确的分类约定。RAG检索到相关模式后LLM生成的接口模型会自动带上企业要求的分类标记和物理特性字段避免了大量返工。3.3 提示词设计的几个讲究我们在做提示词的时候踩过不少坑最终沉淀了几条规则。最关键的是“一次只做一件事”。如果你让LLM同时完成“解析需求、识别接口、生成包结构、定义端口约束”四个任务它的输出质量会明显下降。拆分后每个任务指令明确输出稳定。第二是必须有输出模板约束。SysML v2语法比较严格如果让LLM自由发挥它可能生成标准之外的方言或者混入解释性文本。我们在提示词里给出严格的输出结构框架——目标包名、元素类型、关键字段、完整文本代码——并明确要求不要输出额外解释。第三是few-shot示例要跟待建模场景接近。一个用于车辆制动需求的示例对航电接口建模的帮助远不如一个端口定义示例。所以我们的提示模板按建模类型分成了需求建模、结构建模、接口建模、行为建模四类每类单独维护few-shot会话。第四错误修复时要把错误信息原样传回。校验服务产生的错误往往带有行列号和规则编号把这些信息连同错误片段交回给LLM就能完成精准修复。反之只说“你生成了错误模型”LLM完全无从下手。模型语义校验比语法检查更重要的落地闭环4.1 语法校验以外还必须做语义一致性检查SysML v2文本语法很像代码解析器能识别语法错误但语义层面的非法情况需要额外的校验规则。举个例子一个Part定义里引用了另一个包内的元素但忘记声明import语法上能解析通过语义上这个引用是无效的。如果让LLM生成、只做语法检查就入库这类问题会大量潜伏。我们除了参考解析器外还维护了一份自定义的语义约束规则库。规则来自两方面一是SysML v2规范里的语义约束二是企业内部从型号研制要求中提取的建模约束。比如“所有需求元素必须关联至少一个实现它的部件元素”“每个端口必须指定方向类型”“任何跨层级引用必须通过连接器而不是直接引用内部变量”。这些规则用查询语言和脚本实现在每次模型生成后自动执行。4.2 校验结果驱动LLM修复的循环机制校验不是终点我们的流程是校验之后自动进入修复循环。错误清单会作为新的上下文和原始需求结构化描述、错误模型片段一起交给LLM。LLM需要理解错误原因、修正语法或语义表达重新输出模型片段。这个循环通常只需要一到两轮就能收敛。比较常见的错误是引用的元素未定义、端口方向缺失、约束表达式格式不正确。我印象最深的是有一类错误反复出现LLM生成的连接器两端端口类型不匹配这属于语义校验才能发现的深层问题语法完全正常只有规则库能抓出来。修复这类错误时我们会在错误清单里附带两端端口的类型定义LLM就能意识到不匹配并自动修正。需要强调校验修复最多只能做到“机器视角的合规”不能代替工程师的领域判断。所以流程里设置了一个强制节点经过校验的模型片段必须由包有经验的建模工程师签审后才能合入基线。这个节点运行下来发现问题不多但一直保留因为它是体系对模型质量的最终保险。从试点到推广团队踩过的坑和协作上的心得5.1 踩坑记录一让LLM大包大揽整个生成质量崩盘试点初期我们犯过一个错误把某个子系统的完整模型生成任务一次性交给LLM期望它能输出一个结构完整、接口齐全的包。结果是它确实生成了内容但引用关系错乱、元素命名重复、包结构不符合企业规范修复成本比人工建模还高。复盘后我们把生成任务拆到模型片段级别一次一个包、一次一组接口质量立刻明显提升。生成范围控制在能放进一个Jupyter笔记单元内的体量是我们在实践中总结出来的稳定条件。5.2 踩坑记录二企业术语缺失导致的语义漂移项目里有一个比较隐蔽的坑。需求文本中有大量企业特有术语比如某种测试工况、某种保障任务SysML v2标准里没有直接对应物。刚开始LLM会把它们映射成通用功能或通用约束导致模型失去了领域特征。后来我们建了一个企业术语本体把需求用语和SysML v2元素类型之间的推荐映射做成结构化词典喂给LLM语义漂移问题大幅缓解。这个字典的质量直接决定了概念映射环节的准确率建议团队在启动阶段优先投入。5.3 从建模团队到全流程的收益变化试点项目跑通后我们的收益主要体现在三个层面。一是需求建模效率原来手工梳理需求并建立需求模型按条目计大约每人每天处理二三十条现在LLM生成加人工修订同样时间能完成上百条速度提升三到四倍。二是模型的一致性和规范性语义校验规则保证了入库模型的统一质量模型库不再是风格各异的“手工作品”。三是需求变化后的响应能力一旦需求变更LLM能快速生成变更模型片段追溯影响范围这在以往是最耗时的环节。5.4 适配套才推广别在存量模型上硬来我们的经验是LLM驱动SysML v2建模最适合新研项目的早期建模那时候需求正在形成模型也在从零搭建LLM可以带着从需求解析到模型生成的完整链路进入工作流程。存量模型已经维护了很多年数据不干净、规则不一致直接拿LLM去洗数据反而可能把旧问题放大。所以有团队问我路径建议我一般说两条先选一个边界清晰的新研子系统做试点把企业内部术语规范和建模规范梳理到位再大规模推广。这套实践做到现在我的整体感受是SysML v2把建模语言变成了机器能理解、能生成、能校验的数据结构LLM又正好补上了从自然语言到这种结构的翻译能力两者结合是系统性工程建模工具链演进比较确定的方向。整个过程最不能少的始终是工程师在关键节点上的判断LLM负责把体力活扛掉人来把握方向。最后分享一个小经验项目启动时别急着上大模型、大知识库先找几条有代表性的需求用最轻量的方式把“需求解析-概念映射-模型生成-校验修复”闭环跑通让团队成员亲眼看到这条链路的价值后续推广的阻力会小很多。