04. MBSE: the Unfinished Journey | Engineering as Code

摘要

Model-Based Systems Engineering（MBSE）曾被寄望于用统一模型终结专业壁垒，但二十年的实践留下的是昂贵的模型仓库、不可执行的 SysML 图、专有工具锁定，以及大量"为了建模而建模"的组织仪式。本文认为，MBSE 的挫折远非执行懈怠，而是一场治理理性的缺血：它试图用静态模型替代可计算、可追责的代码，却又始终没有回答那个更根本的问题——谁有权力定义"规格"，谁用能力担保"合规"，谁以刚性代价承担"失败"？

本文分三个层次剖析这一困境。第一层是技术：SysML 有语法无运行时、模型与实现断裂、工具锁定下的格式税，以及 SysML v2 虽向文本靠拢却仍是一次未完成的跳跃。第二层是产业制度：通过建筑业的"僭主制"与汽车业的"仁慈独裁者"作为比较案例，揭示 MBSE 困境在产业尺度上的同构镜像——权力与能力的断裂，导致没有人愿意为可以被自动验证、违约即遭追责的可执行规格埋单。第三层是出路：对照半导体产业通过寡头互赖与可执行契约达成的 Engineering as Code 制度，提出 MBSE 必须自我升格为一场改变权力与能力关系的社会构造运动。

MBSE 的未完成之路，不是等待一个更好的建模语言，而是必须回答：当规格成为可执行的判据，谁来背书、谁去验证、谁为失效支付代价。

1 承诺：从文档危机到模型救世

复杂系统的传统工程文档正在崩塌。一架现代飞机的需求、接口、状态机、安全分析散布在数万份 Word、Excel、PDF 中，彼此引用如蛛网，变更传递靠邮件和会议。任何一次设计修改都可能引发连锁追溯噩梦。

MBSE 的愿景与此高度同构：用统一的系统模型取代文档。模型是结构化的、可视化的、可追溯的。SysML 提供了需求图、用例图、活动图、状态机图、内部块图、参数图……理论上，系统的所有关键信息都可以被编码进同一个模型，一处修改、处处联动。这正是 EaC 所倡导的方向——把工程知识从非结构化的自然语言文档，迁移到可计算、可协作的形式化媒介中 [1]。

然而，实践却走上了岔路。

2 现实：模型作为新的官僚体制

2.1 一门无法运行的语言

SysML 最大的悖论在于：它有语法，却没有运行时。

C 语言可以被编译成机器码，Python 可以被解释执行，SystemVerilog 可以被仿真器运行。但 SysML 图——即便画得再标准——本质上仍然是静态描述。你可以检查它是否遵循了 SysML 规范，却无法让它"跑起来"以验证系统行为是否满足需求。

这导致一个致命后果：SysML 中的规格无法成为"判据"。一个状态机图画得对不对，最终还是要靠人眼去审，或者靠下游实现后的测试去间接验证。所谓"早期验证"仍然依赖于人类法官的审查会。这直接违背了 EaC 的核心原则：工程规格必须是可执行的，才能将"需求是否被满足"变成 CI 流水线的自动判据 [1]。

2.2 模型与实现的断裂

MBSE 的另一个承诺是"从需求到实现的完整追溯"。实践中，这个追溯链在模型边界处断裂。

系统工程师在 SysML 工具中绘制架构、定义接口和功能分配；机械、电子、软件工程师则各自在 CAD、EDA、IDE 中工作。模型不是他们的真源，他们也不会从模型直接生成可交付物。久而久之，模型成为设计阶段的一次性仪式，而实现端的真实设计意图保存在各自的专业工具链中。

当产品进入迭代，实现端的变更是真实的、紧迫的、有商业压力的；而模型更新是缓慢的、可选的、常常被视为额外负担。久而久之，模型与实际产品分道扬镳，成为昂贵的数字遗迹。

2.3 工具锁定与格式税

MBSE 工具——如 MagicDraw、Rhapsody、Capella——通常以专有格式存储模型。这些格式不是开放文本，无法被通用 diff、merge、lint 工具处理。团队无法像审查代码那样审查模型变更，无法像管理 Git 仓库那样管理模型版本。

这与 BIM 的 Revit 中央文件问题同构：真理之源被锁在厂商的专有数据库中。协作不再是"克隆仓库、创建分支、提交 PR"，而是"谁检出了哪个包、模型是否同步、导出导入有没有丢信息"。模型本应消除的格式税，以新的形式卷土重来。这直接破坏了 EaC 的支柱之一：文本优先的真源与 Git 工作流 [1]。

2.4 SysML v2：未完成的跳跃

MBSE 社区并非没有意识到上述问题。SysML v2 的出现，本身就是对 v1 缺陷的一次系统性反思：它引入了一套基于 KERML 的文本语法，试图将语言规范与工具实现解耦，并提供标准化的 API 和数据交换格式。方向正确，SysML v2 隐约看见了 Engineering as Code 的轮廓。

但它仍然是一次未完成的跳跃。

首先，它本质上仍是一门建模语言，而非编程语言。它可以精确描述结构、接口和约束，却无法像代码那样被普遍执行。一个状态机、一条需求断言、一个接口契约，在 SysML v2 中仍然主要是"被阅读和被分析"的对象，而不是"被运行和验证"的对象。

其次，它承袭了 MBSE 的图优先文化。文本语法虽然存在，但多数工程师和工具仍然以图形视图为主要交互界面。文本沦为图形的序列化备份，而不是治理流程的第一公民。只要图形仍然是工作的中心，Git 工作流、CI/CD 就很难真正嵌入。

再次，生态成熟度严重不足。SysML v2 的工具链、培训体系、社区实践都还在早期。大量组织刚刚在 SysML v1 和配套工具上完成投资和人员培训，迁移成本极高。即便 v2 在技术上更优越，它也可能像许多更好的标准一样，被困在采纳曲线的谷底。

SysML v2 证明了社区意识到必须向 EaC 靠拢，却尚未完成那一跳。真正的跳跃不是"让模型更像文本"，而是"让工程规格成为可执行、可版本化、可被 CI 强制执行的代码"。

3 疤痕组织：方法论层面的路径依赖

MBSE 的挫折在行业内部留下了一层疤痕组织——不是一次性的失败，而是一套被内化为"正常"的补偿机制。

模型审查会取代了真正的验证。 因为模型不可执行，组织发明了越来越多的"模型走查"仪式。资深专家围坐在投影前逐图审查，把本应由机器完成的工作重新变成人肉过程。
建模团队与实现团队的双轨制。 组织设立了专门的"系统建模工程师"岗位，与实现团队平行运作。这种分工让模型更精致，也让模型更远离真实工程。
工具投资形成的沉没成本壁垒。 一旦购买了昂贵的 MBSE 工具许可证并培训了人员，组织就被锁定。即使模型效果不佳，也很难承认失败并切换路线。
对"可视化"的过度崇拜。 MBSE 强调框图之美，但复杂系统的真源往往藏在参数、约束、断言和测试用例中。漂亮的图掩盖了不可计算的知识。

这些疤痕组织共同说明：MBSE 没有完成它许诺的范式转换，而是把旧范式的文档官僚制，搬进了新范式的模型仓库。

4 更深层的溃败：产业结构的"制度真空"

上述技术缺陷只是表征。MBSE 的真正困境，在于它不自觉地假设了这样一种组织模式：一个单一的、全能的中心能够定义一切规格，而其他参与者会忠实地按模型执行。这一假设在绝大多数工程领域都不成立，甚至正是问题的根源。

4.1 建筑业的"僭主制"：权力与能力的断裂

建筑行业呈现一种"僭主制"格局：拥有权力的人不具备工程能力，而拥有能力的人毫无话语权。

业主的建设行为是脉冲式的、高度外包的，根本没有动力去积累专业知识；设计费占比极小，无法控制实现过程；施工方掌握最精确的建造数据，却依赖多层级"委托式指挥"，信息链层层断裂；末端劳务高度非正规化，连参与沟通的能力都受限。

这样一条权力与能力截然割裂的产业链，根本不可能生长出类似半导体业的可计算接口契约。设计模型沦为各方免责的仪式，而不是可追责的法律凭据。BIM 推行遇阻的根源正在于此：不是技术不成熟，而是没有人愿意为一份可以被自动验证、违约即遭追责的"可执行规格"埋单。

4.2 汽车业的"仁慈独裁者"：权力吞噬能力的恶果

汽车行业似乎提供了一个反例：主机厂极为强势，深度掌控动力总成等核心技术，像一个仁慈而全能的独裁者。这种高度垂直整合的模式，在过去技术路线稳定时效率卓著。

可一旦面临锂电池、电机、高压架构、域控制器等颠覆性模块，曾经的优势便逆转为僵硬的重负。子系统过度定制、紧密耦合，任何外部冲击都会引发整车"整体震动"——传统巨头挣扎转型，连特斯拉这样的新贵也在 4680 电池、Cybertruck 量产上延期，在智能座舱的迭代速度上落后。

原因无它：仁慈独裁者模式下，系统耦合被推向极致，缺少类似 Fabless-Foundry 分离后的模块化解耦。主机厂的权力遮蔽了它在新领域的能力不足，同时压制了供应商成为独立能力寡头的可能。当技术范式发生跃迁，独裁者无法快速吸纳外部的卓越能力，而原本被压制的供应商又没有足够的权力去反推整车架构的更新。

作为对比，半导体产业在同一时期经历了 EUV 光刻、FinFET 到 GAA 的器件革命、Chiplet 与先进封装（CoWoS、HBM）、背面供电、硅光工艺集成，乃至功率半导体的金刚石衬底探索；与此同时，工艺-芯片-推理 Infra-模型架构的 DTCO 链条也在多条战线上同时推进。挑战之密集、范式跃迁之频繁，远超汽车产业。但半导体并未被这些冲击压垮——恰恰相反，它仍然是全球进步速度最快的工业领域。原因正在于，寡头互赖与可执行契约的解耦机制，让每一个技术冲击都能被限定在对应模块内消化，而不必引发整条产业链的"整体震动"。

4.3 半导体为什么成功：寡头互赖与刚性 Sign-off

半导体产业的实践提供了最清晰的参照。在 Fabless-Foundry 分工模式下，没有任何一方是绝对的独裁者。台积电、新思、Cadence、高通、ARM——它们每一个都是各自领域的寡头，彼此互相需要却又互相锁定。

代工厂的 PDK 必须被 EDA 工具广泛支持，EDA 工具必须通过代工厂的认证，设计公司则希望工具与工艺多样化以避免被单一绑定。这种均势迫使它们将接口固化为可计算的、有法律刚性的契约——PDK、设计规则、Sign-off 流程——任何一方若歪曲输入或掩饰问题，都会在代码化的证据链中暴露，并承担商业上的毁灭性代价 [2]。

这正是 MBSE 所缺失的。MBSE 从来没有属于自己的"PDK 时刻"：它没有在产业链的各个专业玩家之间建立起一套可执行、可验证、且与责任绑定的接口标准。系统模型更多地是向上游（如政府、军方）交付的"象征性文件"，而不是向下游和同级传递的"可执行法律"。

5 本可更好的路径：MBSE as Code

因此，重新想象 MBSE，不能只停留在"模型本身是否 as Code"，而必须从技术实践和产业治理两个层面同时发力。

5.1 技术层面的 EaC 实践

在工具与方法层面，MBSE 应当朝以下方向迈进：

文本优先的系统描述。 系统架构不再以专有模型文件为真源，而以开放文本格式——如 DSL、声明式配置、可执行规格脚本——为真源。图可以从文本生成，但文本才是不可篡改的底层。

可执行的规格与接口契约。 需求不是图中的条目，而是可自动运行的断言。接口不是框之间的连线，而是带有类型、前置条件、后置条件、协议状态机的形式化契约。状态机不是画出来的，而是可以被模型检查器或仿真器执行的代码。

Git 工作流与 PR 评审。 所有系统资产纳入 Git 仓库。变更以分支和 PR 进行，评审人在 diff 中审查接口变化、需求影响和验证结果。建模不再是独立团队的专职，而是每个工程师的日常协作行为。

CI/CD 中的分层验证。 每次提交触发静态检查、接口兼容性检查、模型仿真、需求覆盖度分析。昂贵的高保真仿真保留在夜间或发布节点运行。验证结果成为合并的硬门槛。

模型作为代码的投影。 SysML 图、架构视图、追溯矩阵不是真理之源，而是从代码化规格自动生成的产物。就像软件工程中的文档从代码注释和类型定义生成一样，所有工程视图从可执行规格生成。

这是克服当前模型官僚制的必要技术步骤——SysML v2 已经迈出了第一步，但还远远不够。

5.2 制度层面的 EaC 构建

但仅有技术更迭，无异于在僭主制或独裁者模式下引入更新款的绘图软件。要避免重蹈建筑与汽车的覆辙，MBSE 必须自我升格为一场社会构造运动：

培育或识别能力寡头。 将当前庞大的系统拆解为若干具备对等专业能力的模块供应者，让它们之间形成相互审查、彼此锁定的结构。例如在航空领域，推动发动机、航电、飞控等领域的供应商形成独立的、基于形式化规格的交付能力，而不是由单一集成商包揽所有关键定义。

建立刚性 Sign-off 节点。 将系统模型的评审节点改造为具有商业法律责任的签核仪式。每一次接口变更、需求分配下调，都必须附带自动化验证的结果和可追溯的签名，使"模型走查"从主要判据退化为辅助手段。

引入外部锚点。 在没有自然寡头互赖的领域（如建筑），需要政府、保险联盟或超大型业主联合体充当"制度基础设施"的建设者，强制推行开放、可执行的数字交付标准，并赋予其合规刚性。新加坡的 ACCC 强制审批正是此类尝试的先声。

5.3 解耦的艺术：让权力与能力重新对齐

实质上，EaC 的哲学核心是"用可计算契约实现解耦" [1]。在半导体中，代工厂不必知道芯片如何设计，设计方不必亲手操作光刻机，只要严格遵循 PDK 和 Sign-off 契约，黑盒两端便可自由创新。

MBSE 若想成功，也必须致力于在机械、电子、软件、人因等学科之间，在主机厂与供应商之间，在业主与设计-施工联合体之间，建立类似的可执行接口契约。这意味着主动肢解过度的垂直整合，让能力重新回到其最擅长的地方，并赋予其相匹配的权力与责任——而这，远不止是建模工具的改进，而是一场产业政治的重构。

6 结论：MBSE 是 EaC 的未完成之路

MBSE 的未完成之旅，不仅昭示了"模型"如果不能达到"代码"的治理标准就会沦为新的官僚体制，更暴露出大多数传统工程领域在治理理性上的匮乏。

建筑业的僭主制让模型沦为摆设，汽车业的仁慈独裁者让系统僵化成铁板，而半导体业用寡头互赖与可计算契约闯出了一条生路 [2]。

Engineering as Code 不是 MBSE 的升级版，而是 MBSE 本应该成为的样子——不只是工程师手中的一门技术，更是重塑产业权力结构与责任法则的制度纲领。完成这一旅程，意味着我们必须停止追问"有没有更好的建模语言"，开始逼问"谁负责为这段规格背书，谁有能力验证它，谁又会为它的失效支付代价"。

只有当 MBSE 真正把自己活成那场迟来的制度革命，它才能从"未完成"的遗憾，变成"刚刚开始"的希望。

参考文献

[1] 《Engineering as Code: a General Method to Manage Complexity》，本系列第一篇。

[2] 《Silicon as Code: the Oligarchs' Waltz》，本系列第三篇。