1. MBSE面试全景与能力地图
很多候选人第一次接触MBSE岗位面试时，会把它当成“画SysML图的考试”。真正进入面试后才发现，面试官关心的不是你会不会拖拽模块，而是你能否用模型驱动的方式，把一个模糊的工程问题收敛成可验证、可追溯、可交付的系统方案。本章先建立一张全景地图：MBSE岗位到底在招什么人、面试考察哪些维度、知识体系如何分层，以及面试流程背后的评分逻辑。
一、MBSE岗位画像：三类角色，三种侧重
招聘市场上的MBSE岗位名称五花八门，但按职责可以归为三类。第一类是建模工程师，核心任务是用SysML或Arcadia等方法论构建系统架构模型，输出需求模型、结构模型、行为模型和参数模型，并维护模型与需求管理工具之间的追溯关系。第二类是系统架构师，侧重在模型之上做权衡分析，比如在质量、成本、功耗、进度之间做取舍，输出架构决策记录。第三类是MBSE方法/工具工程师，负责方法论裁剪、建模规范制定、工具链集成和模型质量检查。
三类角色的面试侧重点不同。建模工程师会被追问建模语法和工具操作细节；系统架构师会被追问架构权衡和接口定义；方法/工具工程师则会被追问方法论落地、模型治理和工具二次开发。候选人需要先判断自己应聘的是哪一类，再决定复习重心。
二、面试考察维度：四层能力模型
综合大量岗位JD和面试反馈，MBSE面试的考察维度可以归纳为四层。
第一层：系统工程基础。包括需求工程、功能分析、架构设计、接口管理、验证与确认的基本概念。面试官常问“需求、功能、架构三者是什么关系”“如何做需求分解与分配”。这一层不过关，后面很难展开。
第二层：建模语言与方法论。SysML的九种图（需求图、用例图、活动图、序列图、状态机图、块定义图、内部块图、参数图、包图）各自解决什么问题，Arcadia、OOSEM、Harmony等方法论的阶段划分和产物。面试官会要求你现场解释某张图的语义，或者给出一个场景让你选择用哪张图。
第三层：工具链与工程实践。常见工具包括MagicDraw/Cameo、Rhapsody、Enterprise Architect、Capella，以及需求管理工具DOORS、Polarion，还有仿真工具Simulink、Modelica。面试官关心你是否真正在项目中用过，而不是只听过名字。
第四层：项目经验与软技能。包括你如何推动团队接受MBSE、如何处理模型与文档的关系、如何向非建模人员解释模型价值。这一层往往通过行为面试题考察。
三、知识体系框架：从概念到落地
把上述维度串起来，可以形成一条主线：需求→功能→架构→接口→验证→追溯。这条主线对应MBSE的核心价值——用模型承载系统信息，并保持信息之间的一致性。
以“无人机避障系统”为例。需求层面，输入是“在5米内检测到障碍物时，无人机应在0.5秒内完成避让”。功能层面，分解为“感知—决策—执行”三个功能。架构层面，分配为激光雷达、飞控计算机、电机驱动三个子系统。接口层面，定义激光雷达与飞控之间的数据格式、周期和精度。验证层面，设计测试用例覆盖检测距离和响应时间。追溯层面，从测试用例反向追溯到需求，确认无遗漏、无多余。
这条主线在面试中会以不同形式出现。面试官可能给你一段需求描述，让你现场画出需求图和活动图；也可能给你一个架构图，让你指出接口定义中的问题。准备时不要只背图符，而要练习用这条主线讲清楚一个完整案例。
四、常见面试流程与评分逻辑
典型MBSE岗位面试分为四轮。第一轮是技术初筛，通常30到45分钟，考察系统工程基础和建模语言。第二轮是建模实操，可能要求你在白板或共享屏幕上画图，或者分析一段已有模型。第三轮是项目深挖，围绕你简历中的项目追问细节。第四轮是综合面试，考察沟通、协作和职业动机。
评分逻辑通常围绕三个问题：你知不知道（知识广度）、你会不会做（实践能力）、你能不能讲清楚（表达能力）。很多候选人败在第三点——明明做过项目，却讲不出关键决策和权衡过程。面试官更想听到“我为什么这样设计”“当时有哪些备选方案”“最后依据什么做判断”，而不是“我用了什么工具、画了什么图”。
五、可直接使用的面试准备检查表
下面这份检查表可以作为面试前的自检工具。每一项按“完全不会、能说概念、能结合案例讲清楚”三档自评，优先补齐“能说概念”但讲不清案例的项。
| 能力项 | 自检问题 | 自评档位 |
|---|---|---|
| 需求工程 | 能否区分利益相关者需求、系统需求、子系统需求，并说明分解依据？ | □不会 □概念 □案例 |
| 功能分析 | 能否用活动图或功能分解图描述一个完整功能流，并说明输入输出？ | □不会 □概念 □案例 |
| 架构设计 | 能否解释逻辑架构与物理架构的区别，并给出分配关系？ | □不会 □概念 □案例 |
| 接口管理 | 能否定义接口的数据、时序、精度和异常处理？ | □不会 □概念 □案例 |
| 验证与确认 | 能否区分验证与确认，并说明模型如何支持验证？ | □不会 □概念 □案例 |
| 追溯关系 | 能否建立需求—功能—架构—测试的追溯链，并说明变更影响？ | □不会 □概念 □案例 |
| 工具操作 | 能否在Cameo或Capella中独立完成一个最小模型？ | □不会 □概念 □案例 |
| 方法论 | 能否说出Arcadia四个工程阶段及主要产物？ | □不会 □概念 □案例 |
使用这份检查表时，建议配合一个自己最熟悉的项目案例。把项目中的需求、功能、架构、接口、验证各挑一个点，写成三分钟的口述稿，录音后回听。如果发现某一段只能说出“我做了建模”，而说不出“我为什么这样建模”，那就是需要重点补强的地方。