ARTICLE · 1166621
从 AI 建模到工程实现
从 AI 建模到工程实现1999 年 9 月，NASA 的火星气候探测者号在即将进入火星轨道前失联，随后烧毁。这一枚探测器造价 1.25 亿美元；连同同年失事的姊妹任务，整个火星勘测计划近 3 亿美元付诸东流。 事后调查的结论，简单到残酷：地面团队里，一方用“磅力”推算推力，另一方用“牛顿”——两边都以为对方懂自己。一份调查报告，把史上最昂贵的一次工程“沟通事故”，钉在了墙上。 这个结论之所以残酷，是因为它太“低级”了。不是材料不过关，不是算法有缺陷，不是设计有盲区——是两个团队各自在纸面上算对了，却没人发现纸面本身对不上。洛马公司的导航团队按英制单位输出推力数据，NASA 的轨道团队按公制单位读取，软件里没有一行代码问过“你这个数到底是什么单位”。探测器一路飞得好好的，直到进入轨道前的最后一刻，推力比预期小了近五倍，轨道低了近一百公里，大气层撕碎了它。 二十多年后回看，这件事真正该警醒我们的不是单位，而是：当一套系统复杂到没人能独自看懂，“把话说准”就成了工程的生死线。而今天，当 AI 开始介入建模，这条生死线正在被重新定义。 一、你说的“建模”，和工程师说的可能不是一回事 一提建模，很多人想到三维动画、游戏场景、建筑效果图。但工程师说的建模，是给复杂系统画一套“说明书”——重点不在好看，在准确、可共用。 这区别有多大？打个比方：三维动画是给外人看的“宣传片”，工程模型是给内部人用的“施工图”。宣传片里房子漂亮就行，施工图里少标一根承重梁的尺寸，楼就得塌。工程建模的核心不是视觉呈现，而是把系统的结构、行为、需求、约束，用一套无歧义的方式固定下来，让不同团队、不同工具、不同阶段的人，都能读到同一套信息。 现代航天器动辄上百万个零件、几十个团队协作，靠文档已经带不动。一份需求文档写“电源模块应在过载时切断输出”，结构团队理解成加个保险丝，软件团队理解成写段保护逻辑，测试团队理解成测一个响应时间——谁都没错，但合起来可能既没加保险丝、也没写保护逻辑、更没测响应时间。文档的线性结构，撑不起系统的网状关系。 于是有了 MBSE（基于模型的系统工程）：先有模型，后有实物，模型既是图纸，也是沟通的语言，还是验收的依据。传统工程是“文档驱动”——需求写文档、设计写文档、测试写文档，文档之间靠人肉追溯。MBSE 是“模型驱动”——所有信息集中在一个模型里，结构、行为、需求、参数彼此关联，改一处，相关处自动联动，谁漏了什么，工具当场就能查。 SysML 就是这套语言的一种。它不画三维外形，画的是“系统由什么组成、部件怎么连接、满足什么需求、在不同状态下怎么行为”。它借鉴了软件工程里的 UML，但去掉了软件专属的包袱，加上了工程系统需要的硬约束——比如值类型、单位、流属性、约束块。 一句话：SysML 画的是关系，不是长相。 二、同说一种语言，也有人写公文、有人写小说 语言统一了，麻烦没解决。 SysML 解决了“用什么语法画图”的问题，但没解决“画成什么样才算对”的问题。就像一个国家统一了汉语，但有人写公文、有人写小说、有人写诗，互相之间还是可能读不懂。同一个“电源模块”，结构团队理解成供电盒，软件团队理解成一段程序，测试团队理解成一个待测对象——谁都没错，但图纸对不上，卫星上天那天就是事故通报那天。 更隐蔽的问题是“同词不同义”。A 团队说“接口”，指的是物理插头；B 团队说“接口”，指的是软件 API；C 团队说“接口”，指的是数据格式。三个人坐在一起开会，各说各话，会议纪要写得满满当当，回去各做各的，做出来的东西拼不到一块。这种问题不靠“多沟通”能解决——沟通只能暴露分歧，不能消除分歧。消除分歧得靠规范。 美国太空系统司令部把这个问题的解法写成了一部规范：SSC SysML 风格指南。61 条规则、10 个大类，从命名、定义、接口，一直管到状态机、需求、活动图。它不管你怎么说，只管你说得一致不一致。 
这部指南的诞生背景也很有意思。它不是某个理论家拍脑袋写出来的，而是美国太空系统司令部在多个卫星项目里踩了足够多的坑之后，把“血泪教训”一条条固化下来的。哪类错误反复出现，就立一条规则；哪条规则能用机器查，就标上“可机检”。它本质上是一部“工程沟通的错题本”。 如果说 SysML 是“汉语”，这部指南就是“公文写作规范”——保证一百个工程师画出来的图纸，另一百个工程师能零偏差地读懂。它不追求文采，只追求一致；不追求创新，只追求可靠。在工程领域，可靠比创新值钱得多，因为创新错了可以重来，可靠错了就是 3 亿美元。 三、61 条规矩，防来防去就三种病 把 61 条逐条翻开，会发现它们翻来覆去，只在防三种毛病： 第一种，“没写完”。 建了一半没删的半成品——活动没有定义、注释是空话、终点没有来路。半成品比不存在更可怕：不存在的东西没人惦记，半成品会被后人当宝贝继续用。你建了一个“电源管理”活动，名字起好了，图也画了一半，然后你去开会了。三个月后，另一个团队看到这个活动，以为它是正式设计的一部分，照着它往下做，做到一半发现它根本没有定义、没有输入输出、没有连接任何实际模块。这时候返工，成本已经是当初删掉它的几百倍。 第二种，“对不上”。 接口、类型、方向错配——物流进出的型号对不上，代理端口没挂接口规格书，接线两端方向相反。A 团队以为这个口出电流，B 团队以为进电流，当年就是这么出事的。这种错误最阴险的地方在于：每个团队单独看自己的部分，都是对的；只有把两部分拼在一起，才能发现对不上。而复杂系统里，拼在一起往往是在集成阶段，那时候改一个接口，可能意味着改十几个模块、重跑几十个测试。 第三种，“假删除”。 图上删了，模型还在。从图里删掉一个元素，它仍躲在模型里被别的元素引用——实物照着一条幽灵引用造出来，查到那天就是惊吓。这种问题在多人协作的模型里尤其常见：A 删了一个块，B 的图里还引用着它，工具不报错，因为模型里这个块确实“存在”。直到生产部门拿着图纸去采购，发现这个零件根本没有供应商，因为它的定义早被删了，只剩一个空壳引用。 归纳成三句话：起好名字、写清定义、别自欺欺人。 这就是 61 条的内核。其中 16 条，还能用 OCL（对象约束语言）写成机器可执行的检查——规范一旦变成代码，就从“倡议”升级成了“门禁”。（61 条逐条详解与 16 条 OCL 原文，见文末附录。） 四、规矩的下一站：从纸面，到机器，到 AI 这套规矩的进化走了三步：语言标准化（SysML 让大家说同一种话）、文风标准化（指南让大家用同一种方式说）、检查自动化（OCL 让机器当场拦错）。 第一步解决“能不能对话”，第二步解决“会不会误解”，第三步解决“靠人查还是靠机器查”。每一步都在把“人的自觉”替换成“系统的约束”。这不是不信任工程师，而是承认一个事实：再专业的工程师，在赶工期、跨时区、换项目的时候，也会忘、会漏、会想当然。把规矩变成机器可执行的检查，不是降低对人的要求，而是把人从重复劳动里解放出来，去做机器做不了的事——判断、权衡、创新。 今天，第四步正在发生：AI 开始画图了。 大模型和智能体已经能通过 MCP（模型上下文协议）操作 MagicDraw 这类专业建模软件，自动创建模型元素。过去几小时的模型骨架，AI 几分钟铺好——这是好事，但也抛出一个尖锐的问题： AI 画的图纸，守不守规矩？ 人会翻规范、过评审；AI 不会。规矩如果只印在 PDF 里，AI 和人一样会忘、会漏、会自由发挥。更麻烦的是，AI 的“忘”和人的“忘”不一样：人会因为疲劳、疏忽而漏掉一条规则，AI 则可能因为训练数据里就没有这条规则，而系统性地、稳定地、每次都不守这条规则。人犯错是随机的，AI 犯错是结构性的。要让 AI 画得对，就得把 61 条规矩从纸面搬进它的能力里——不是写在提示词里提醒它，而是变成它操作建模软件时绕不过去的约束。 五、把 61 条规矩，搬进 AI 的能力里 总得有人先把这件事做出来。 我们做了这样一个尝试：开源项目 mcp-mbse，通过 MCP（模型上下文协议），把专业建模软件 MagicDraw 的建模能力开放给 AI 智能体——并且从设计上，就对着 SSC 指南那 61 条规矩来。 MCP 在这里扮演的角色，可以理解成“AI 和建模软件之间的翻译官 + 门卫”。AI 说“建一个块”，MCP 不是简单地把这句话转发给 MagicDraw，而是先检查：名字给了吗？定义写了吗？类型定了吗？检查通过，才真正执行创建操作。换句话说，规矩不是事后检查，而是事前约束——AI 在“伸手”的那一刻，就已经被规矩框住了。 在这里，AI 不是“自由发挥地画图”，而是被约束着“按规矩画”： · 命名：建任何元素，强制起名，不留无名的半成品（SSCSG-15）。 · 定义：建“块”、类、模型的同时，直接写下它的定义说明书（SSCSG-39 等定义类规则）。 · 定型：部件、值属性、引用属性，必须定好类型——部件不能是信号，值必须由值类型或枚举定型（SSCSG-288 / 116 / 182）。 · 约束：能建“约束块”，用 OCL 写下机器可执行的规则（SSCSG-43 / 47 / 322）。 · 删除：删元素用“销毁”而非“从图上拿走”——连同引用一并清除，删前还会提示它还被谁引用。 拿一颗小卫星看效果——AI 能一口气搭出这样的合规骨架：一个“航天器”块，带三个属性：busMass（质量，用“质量”值类型定型）、powerMode（电源状态，用“关 / 开 / 待机”枚举定型）、mainPayload（主载荷，部件属性）；外加一个“质量上限”约束块，OCL 写着 self.busMass <= 2000，还带一个 limit 参数。 注意这套骨架：命名、定义、部件定型、值类型定型、约束块的定义与参数——指南里这几类要求，在元素创建的那一刻就已经满足，而不是等建完再回头补。这意味着 AI 生成的模型，从一开始就是“可进入工程链路”的，而不是“看起来像那么回事”的演示品。 规矩不再只是印在 PDF 里等人遵守，而是变成了 AI 一伸手就够到的能力。61 条里，命名、定义、属性、约束这几大类，已经从“纸上要求”变成了“创建时即有”。这还只是开始——随着更多规则被翻译成机器可执行的约束，AI 能独立完成的合规建模比例会越来越高，工程师的角色也会从“画图的人”变成“定规矩的人”和“审结果的人”。 写在最后 回到开头那 3 亿美元。如果当年两支团队之间有一份共同的图纸规范，有一个能自动校验“磅力对牛顿”的门禁，那枚探测器，也许就在火星轨道上了。 从一张建筑图纸，到 SysML，到 61 条风格规则，再到机器可执行的 OCL——人类花了一百年想明白一件事：复杂的东西，从来不是被某个天才“想明白”的，而是被无数普通人“说明白”的。图纸的规矩，就是让普通人能够协作的语法。 今天，AI 加入了协作。规矩的意义也随之升级——它不再是束缚人的教条，而是让 AI 别在同一个坑里，再摔一次 3 亿美元的保险。人可以从“记住所有规矩”里解放出来，去判断哪些规矩该改、哪些规矩该加、哪些规矩已经过时。机器负责一致，人负责进化。 把“差不多”量成“差多少”，再把“差多少”补成“进步了多少”——这大概就是一份好规范，能走的最远的路。 以下附录供想深入的读者查阅：附录一逐条讲完 61 条规矩（含义 + 类比），附录二给出 16 条可机检规则的约束与大白话，另附延伸阅读。 附录一：61 条规矩详解 这里用人话 + 生活类比把 61 条一条条讲清楚——回答“这条规则是什么意思、为什么这么定”。其中 16 条标了「可机检」；它们机器实际检查的精确约束（OCL）另见附录二，两处不重复：附录一讲“为什么”，附录二给“机器怎么判”。 A1.1 活动与活动图规则（19 条）：流程图的交通规则 活动是“系统做一件事的流程”，活动图就是工艺流程图。这 19 条规则，本质上是给流程图立“交通规则”：哪能分叉、哪能汇合、货物流怎么接、信号怎么发。核心思想只有一句：图上看着一气呵成，模型里不能暗礁遍布。 SSCSG-32 调用行为要点名 调用某个流程，必须写清调用的是谁。就像代码里调函数却不写函数名。最常见的成因：被调用的流程已经删了，调用还留着——图上看着挺忙，模型里全是断线。可机检。 SSCSG-35 调用操作要指名 同上，但调的是“操作”（一个块对外提供的功能项）。半成品的调用就是悬空引用，查到那天就是惊吓。 SSCSG-2 接受事件要有输出口 “收到信号”这个动作，必须有个出口把收到的数据交出去。收到东西没地方放，这个动作就白设计了。例外：信号本身没内容、且不需要拆包时，一条控制流就够了。 SSCSG-8 岔路口必须写路牌 从决策节点分出的每条路，都必须写清“什么情况走这条路”（守卫条件或概率）。不写路牌的岔路口，等于把走向交给猜。地铁出口不标方向，每个出站的人都是探险家。 SSCSG-68 终点必须有来路 每个“到此为止”的节点，至少要有一条流进来。没有来路的终点毫无意义——这通常是“从图上删了、模型没删”留下的孤儿。可机检。 SSCSG-98 物料流必须接对接口 源是动作的物流，两端必须接在“针脚”（引脚）上，不能直接糊在动作上。全模型统一“针脚对针脚”，软件才能自动分析，错误检查也才严格。 SSCSG-99 物流型号要对上 流进去的东西和流出来的东西，类型必须对得上（允许子类、父类）。发票数据不能冒充账单——运单写的和包裹里的不是一回事，分拣中心当场瘫痪。 SSCSG-139 发信号要写收件人 发送信号动作必须指定发给谁（目标引脚）。没有收件人的短信发不出去。例外：内容为空的信号，不需要指定收件人。 SSCSG-333 汇合、合并只能一个出口 汇合节点、合并节点只能有一条出流。多个出口，别人分不清你是“兵分两路”还是“该做个判断”。三岔路口和收费站，功能不能混。可机检。 SSCSG-334 分叉、决策只能一个入口 反过来：分叉节点、决策节点只能有一条入流。多个入口，分不清是“两路汇成一路”还是“路被复用”。（有一种例外：决策节点可选的 decisionInputFlow。）可机检。 SSCSG-339 参数节点不许挂空档 活动边界上的参数（系统进出系统的口子），至少要连一条流。漂着的参数十有八九是意外——门口修了条不接路的台阶，谁上都尴尬。（缓冲节点除外。） SSCSG-343 分叉、汇合不能混流 进出分叉、合并节点的流必须同一类型：全是物流，或全是控制流。电流和信号不能混接，混插会烧设备。可机检。 SSCSG-346 发信号类型要对 发送的信号类型，必须和输入引脚定的信号一致。寄包裹，包裹品类得和运单写的对上，不然快递员按运单分拣全乱。 SSCSG-347 收信号要拆得对 不拆包接收时，收到的信号类型必须和输出引脚一致（或是它的父类）。收快递，箱子上贴的品类得和里面的货对得上。 SSCSG-350 仓库不能空转 缓冲区、数据存储必须至少连着一条物流。没有货物的仓库，建它干嘛？十有八九是模型出了错。 SSCSG-381 定时器必须上弦 时间事件必须设置触发条件。不定时间的闹钟，永远不会响——“到点提醒你”却不设几点，等于没设。 SSCSG-552 汇合有货出货 汇合节点的入流里只要有物流，出流就必须是物流。进货是货，出货也必须是货，不能偷偷变成控制信号。 SSCSG-553 汇合纯令出令 入流全是控制流，出流就必须是控制流。进出同构，语义才干净。 SSCSG-556 拆包要拆得齐 拆包接收时，输出引脚必须和信号属性一一对应：类型、顺序、数量全对上。一个包裹三个字段，就得拆出三个口，少一个、错一个，分拣都错。 A1.2 块（系统组件）规则（5 条）：零件本身要定义清楚 块是系统的“零件”，是结构的基本单元。这 5 条只管一件事：零件放进模型之前，先自报家门。 SSCSG-48 约束要挂在公式块上 约束属性必须由约束块定型。没有参数和公式的约束块，约束就是一纸空文——贴着“此处有规定”的纸条，翻开背面什么都没有。 SSCSG-116 零件不能是信号 部件属性不得由信号定型。信号是喊话，不是硬件。这条专门防新手把“消息”当“零件”装进架构——喊话不能当砖头砌墙。 SSCSG-182 数值要有单位出身 值属性必须由值类型（或 «ValueType» 枚举）定型，最好取自单位库。还记得开头那个“磅力当牛顿”的故事吗？火星事故的病根，从这一条就开始防：模型里的每个数字，都必须交代自己的单位。 SSCSG-288 零件必须认祖归宗 所有部件属性必须定型。零件不说自己是什么，等于没说。招聘简历上“姓名：不详、经历：不详”，HR 只能默拒。 SSCSG-322 公式块不能没变量 约束块至少要有一个参数。没有变量的公式是病态的，多半是建错了。一道题里一个已知量都没有，这题没法解。 A1.3 定义规则（13 条）：每个元素都要写“说明书” 这是指南里条数第二多的一类，核心思想一句话：光有名字不够，还得有文字定义。 为什么这么狠？因为指南看透了一件事：简化名称通常不足以传达意图。“电源模块”四个字，在不同团队嘴里可能是完全不同的东西。客户和工程师之间最关键的沟通工件，值得投入精力写清楚。 SSCSG-7 活动要有定义 所有活动必须有文字定义。例外：作为操作方法或用例行为的活动——操作和用例自己的说明书已经够了，不必重复。 SSCSG-20 参与者要有定义 参与者（actor，系统外部的角色）必须有定义。演员表里每个人都要附小传，不然观众不知道他是谁、来干嘛。 SSCSG-26 批注要锚在东西上 问题、依据类批注，必须挂在至少一个模型元素上。没有锚点的便签是含糊的——贴在墙角的一张“注意此处”，谁知道“此处”是哪处？ SSCSG-38 注释不能是空话 注释、问题、依据的正文不得为空。建了又不写完，是给后人埋雷。这条的立法理由和命名规则如出一辙：防止“建了一半没删”的半成品。 SSCSG-39 系统上下文的块要有定义 给系统上下文定型的那些块——也就是描述“我们这套系统是什么、对外有哪些接口”的块——必须有定义。这是客户与工程师之间最关键的沟通工件，写！就像药品必须附说明书，只印药名你敢吃吗？ SSCSG-43 约束块要有定义 约束块（装公式的盒子）必须有定义，说清公式的意图和使用限制。 SSCSG-47 公式不能空白着 约束规格不得为空。公式栏空白的约束，摆着好看吗？顺手还能靠它抓出模型里别的空值错误。 SSCSG-100 不透明动作要有正文 用原生语言直接写死的动作，正文不得为空。留白是艺术，不是工程。 SSCSG-101 操作要有定义 操作（块对外提供的功能）必须有定义。功能是定义系统行为的关键工件。 SSCSG-142 信号要有定义 信号必须有定义。信号是关键工件，别名“系统之间的喊话内容”，得说清喊的是啥。 SSCSG-157 构造型要有文档 自己定制的构造型（stereotype，给元素贴的自定义标签体系）必须写文档。全模型要一致使用，定义要向用户传达这个标签的意图——自创黑话可以，但得随书附词典。 SSCSG-166 标签定义要有文档 标签定义（tag definition）必须有文档。（标为私有的标签除外。自用暗号可以不公开。） SSCSG-176 用例要有定义 用例必须有定义。用例是客户与工程师沟通的关键工件。 A1.4 接口规则（7 条）：国界必须白纸黑字 接口是两个团队的国界：A 团队以为这个口输出电流，B 团队以为输入电流，卫星上天那天就是事故通报那天。这 7 条规则，把“我以为”全部变成“白纸黑字”。 SSCSG-76 有零件的块要有内部接线图 拥有带端口部件属性的块，必须画内部块图（IBD）展示内部接口、连接和流。给了零件不告诉怎么装，等于给了一箱乐高不给图纸。 SSCSG-77 接线图要归块所有 内部块图必须挂在它所描述的那个块下面。图纸归零件管，才不容易丢、不会看错视角。档案柜里东一张西一张的图纸，是事故的种子。 SSCSG-96 参数不能按接口块定型 参数不得由接口块定型（行为端口例外）。接口块只负责定义“插口规格”，不管别的。 SSCSG-113 零件不能是接口块 部件属性不得由接口块定型（代理端口例外）。接口块是规格书，不是零件本身。想让接口显示内部结构？用嵌套端口，每个端口各配各的接口块——规格书可以引用规格书，但别把规格书当设备。 SSCSG-127 代理端口必须接口块定型 代理端口必须由接口块定型。插口光有名字不算数，必须挂规格书——否则兼容性无从检查。名字对得上、插头插不进去的插口，要它何用？可机检。 SSCSG-257 物流方向要标 流属性必须指定方向（进、出或双向）。就像 USB 要分正反，流的“正反”也要标——出口对进口，才能接上。 SSCSG-264 接线两端要匹配 连接器连起来的两端，流属性的类型和方向必须相容。一头出、一头进，才能流通。 A1.5 命名规则（1 条）：万物皆有名 SSCSG-15 所有元素必须命名 模型里 13 类元素必须有名字：活动、参与者、块、图、状态机进出口点、操作、包、正交状态的区域、信号、状态、状态机、用例、值属性。 听起来像废话？但它的“立法理由”很直白：防止有人建了个东西，既没建完，也没删掉。 半成品比不存在更可怕——不存在的东西没人惦记它，半成品会被后人当成宝贝继续用。这像代码里的变量名：x1、temp、data2 也许今天省了三秒钟，三个月后就是凌晨三点的加班。模型里的每一个名字，都是写给三个月后的自己看的。 A1.6 需求规则（3 条）：甲方的要求，一个字不能丢 需求是设计必须遵守的行为与运行约束。这 3 条规则管的是需求的“三要素”。 SSCSG-133 需求要有名字 需求元素必须有非空的名称。很多需求视图默认显示名称，不填名，视图就是一片“无题”。可机检。 SSCSG-554 需求要有编号 需求元素必须有非空的 ID。没有编号的需求，怎么被引用、被追溯？快递没单号，丢都没法查。可机检。 SSCSG-555 需求要有正文 需求元素必须有非空的文本。需求元素存在的意义就是捕获需求文本——空着的需求，多半是意外创建或建了一半。可机检。 A1.7 序列图规则（1 条）：剧本里不能有路人甲 SSCSG-361 生命线必须有“户口” 序列图上的每条生命线，必须由块、部件或参与者表示。剧本里的角色，必须是结构模型里登记在册的块或参与者——路人甲没有档案，说了什么都不算数。 A1.8 状态机与状态机图规则（10 条）：红绿灯不能两个方向同时绿 状态机定义系统的“状态相关行为”：待机、充电、飞行、故障……这 10 条规则保证状态之间的切换逻辑严密。 SSCSG-143 信号事件要指明信号 状态机里“收到某信号就切换”的事件，必须定义是哪个信号。“听见哨声就出发”——什么哨？得说清。 SSCSG-152 状态不变量要门当户对 序列图上某条生命线所处的状态，必须属于给它定型的块。块只能待在自己定义过的状态里——没登记的状态硬塞给它，会出乱子。可机检。 SSCSG-161 子状态机接口要对 连接点必须引用与拥有者调用的同一个子状态机。插头插座一一对应，子状态机的进出才接得上主状态机。可机检。 SSCSG-168 选择分支要写条件 从“选择”节点出来的每条迁移，都必须定义守卫条件，必要时用 [ELSE] 兜底。红绿灯不能两个方向同时绿，else 就是那条“以上都不符时走”的路。可机检。 SSCSG-373 子状态机出口要登记 子状态机的出口点，必须与拥有状态的连接点关联。楼里的消防通道，出门必须接到楼外，不能通进死胡同。 SSCSG-374 连接点要有迁移 连接点引用至少要连一条迁移（进或出）。没有来路的门永远打不开，没有出路的目的地永远到不了。可机检。 SSCSG-375 定时迁移要上弦 时间事件触发的迁移，必须定义时间表达式。“过一会儿就走”不行，得写“过 5 秒走”。闹钟不设定时，等于没设。 SSCSG-376 条件迁移要写条件 变更事件触发的迁移，必须定义变更表达式。“天变了就走”不行，得写“温度低于 0 度就走”。条件不写死，机器没法执行。 SSCSG-379 状态要有来路 简单状态和最终状态至少要有一条入迁移。每个房间都要有门，不然是黑牢——进了出不去，或者根本进不去。 SSCSG-558 终点要有入流 最终状态和终止伪状态必须有入流。没有入流的终点毫无意义——又是“删图不删模型”的经典案发现场。可机检。 A1.9 结构关系与关联规则（1 条）：模型只画“我们和外部” SSCSG-19 演员之间不直接对话 参与者不得与其他参与者关联。模型的范围，只画“外部角色 ↔ 我们系统”的关系，不画“外部 ↔ 外部”——甲方和乙方怎么勾肩搭背，不在我们的图纸里。真要展示，画在系统上下文内部块图里。 A1.10 用例规则（1 条）：加戏要写明加在哪一场 SSCSG-63 扩展要挂扩展点 扩展（extend）关系必须分配到至少一个扩展点。“双十一给购物流程加个促销环节”——加在哪个环节之后？必须写清楚。没有扩展点的扩展用例，是没插座的电器。可机检。 附录二：16 条“可机检”规则的约束与大白话 附录一已用大白话讲了全部 61 条；这里只聚焦那 16 条可机检规则，给出机器实际检查的精确约束与 OCL——是附录一的“机检版”补充，不重复讲“为什么”。 这 16 条规则的约束是用 OCL（对象约束语言）写的——不是写给人的，是写给检查程序的。规范一旦变成代码，就从“倡议”升级成了“门禁”。 名词卡【OCL】 OCL（Object Constraint Language，对象约束语言）：一种写给机器看的精确语言，用来表达“模型必须满足什么条件”。规则用 OCL 写出来，计算机就能自动检查，不需要人瞪大眼睛逐张看图。 以需求类规则 SSCSG-133（需求必须有名字） 翻译成大白话：“翻遍所有需求，一个一个查，谁的名字是空的，谁就不及格。” 16 条一览： 规则 约束的大白话 SSCSG-32 调用行为动作，被调行为必须恰好一个 SSCSG-35 调用操作动作，被调操作必须恰好一个 SSCSG-68 流终止/活动终止节点，入流必须至少一条 SSCSG-333 汇合/合并节点，出流必须恰好一条 SSCSG-334 分叉节点入流恰好一条；决策节点入流一或二条、出流至少一条 SSCSG-343 分叉/合并节点所有边必须同为控制流或同为对象流 SSCSG-127 代理端口的类型必须是接口块 SSCSG-133 所有需求的 name 不得为空 SSCSG-554 所有需求的 id 不得为空 SSCSG-555 所有需求的 text 不得为空 SSCSG-143 信号事件必须引用一个信号 SSCSG-152 状态不变式所引用状态必须属于定型该生命线的块 SSCSG-161 子状态机的连接点必须引用其自身的入口/出口伪状态 SSCSG-168 选择伪状态的每条出迁移都必须有守卫条件 SSCSG-558 最终状态与终止伪状态的入流必须至少一条 SSCSG-63 扩展关系的扩展点必须至少一个 注：表中“对象流”即对象流/物流；完整 OCL 原文可结合 SSC SysML 风格指南与项目仓库中的约束文件查阅。 延伸阅读 · SSC SysML 风格指南（SSC SysML Style Guide） · MBSE（基于模型的系统工程）与 SysML 入门资料 · OCL（对象约束语言）规范 · 开源项目 mcp-mbse：把 MagicDraw 建模能力通过 MCP 开放给 AI 智能体