ARTICLE · 1096618
整车功能开发系列(9)--从“离线文档”到“在线体验”:功能原型如何重构汽车开发
整车功能开发系列(9)--从“离线文档”到“在线体验”:功能原型如何重构汽车开发
图1：功能开发流程示意图 汽车，本质上是多个复杂系统的组合。如果从控制链路看，一个完整的车辆功能通常可以抽象为三个基本环节：输入、决策与执行。随着汽车功能不断增加，车辆需要处理的输入越来越多：既包括开关、屏幕、语音和手势等用户指令，也包括传感器、车辆状态和外部环境等系统输入。人与车之间的交互，因而不再只是功能之外的一层“界面”，而是逐渐成为功能本身的重要组成部分。如果从完整的用户体验看，还应在“输入—决策—执行”之后再补充一个环节：反馈。用户不仅要能够发出指令，还需要知道系统是否理解、是否执行，以及为什么没有执行。由此，一个完整的汽车功能实际上形成了“输入—决策—执行—反馈”的闭环。 以大灯控制为例，一个完整的功能单元，不仅包括用户如何打开、关闭和调节灯光，还包括系统收到指令之后，如何结合电源模式、车辆状态、电量、环境亮度以及相关控制策略进行判断，最终驱动灯具模组完成点亮，并将执行状态反馈给用户。因此，大灯功能至少包含两类逻辑： 交互逻辑：用户从哪里发出指令，系统如何提示、反馈和处理异常； 控制逻辑：系统在什么条件下允许执行，如何协调相关控制器并驱动执行机构。 从组织分工和专业能力看，将交互设计与控制逻辑设计分别交给不同团队，本身并没有问题。真正的问题在于：这两条开发链路往往缺少一个共同的、能够运行和体验的功能原型。 在当前不少OEM的开发流程和工具体系中，功能交互逻辑与控制逻辑仍然相对独立。 当功能方案锁定到某个版本后，交互团队开始设计界面、动效和操作流程；功能开发团队则依据需求文档开展控制逻辑、信号接口和软件实现。两边看似依据同一份需求出发，实际上很快就会形成各自的开发分支。 在漫长的开发过程中，交互入口、状态定义、控制条件和信号接口都可能发生变化。任何一侧的调整，都可能影响另一侧。但由于双方主要依靠PPT、表格、原型图和需求文档进行传递，变化往往不能被对方立即感知。 最终，问题常常要到软件集成甚至实车测试阶段才暴露出来： 界面已经提供了操作入口，控制端却不支持对应状态； 控制逻辑已经改变，界面提示仍沿用旧版本； 两边对异常工况、功能降级和状态反馈的理解不一致； 单个模块测试都通过，组合到整车上却无法形成完整体验。 随后，各团队只能重新对齐需求、修改方案、开发软件并再次验证，整个链路被迫返工。造成这一问题的核心原因，并不是交互团队与功能团队进行了专业分工，而是整个开发过程仍然采用一种典型的**“离线开发”**模式：控制逻辑存在于一份文档中，交互逻辑存在于另一份文档中；只有等双方分别开发完成并进行集成时，功能才第一次真正“运行起来”。 只要开发周期足够长，中间又经历多次变化，两边最终出现偏差几乎是必然的。 功能开发真正应该解决的问题是：能否在功能开发初期，甚至在功能策划阶段，就让产品团队、开发团队和用户直接体验功能，而不是只能对着PPT讨论？只有当功能真正运行起来，人们才能判断： 这个需求是否真的存在； 功能触发时机是否合理； 操作路径是否自然； 控制逻辑与交互反馈是否一致； 场景切换时是否存在冲突； 它究竟为用户创造了什么价值。 笔者在2017年开始思考快速功能原型时，受限于当时的视野、工具和技术条件，能够想到的方法，是在一个简易台架上粘贴纸张，配合Pad、实体开关和简单模型进行体验。 现在回头看，这种原型几乎没有真正的系统互动，只能完成最基础的概念演示和体验评价。但它仍然有一个重要价值：让功能在进入正式开发之前，第一次从文字变成了可以被感知的东西。 今天，随着Unity等实时3D引擎进入汽车研发体系，VR、AR与XR设备的性能快速提升，功能原型的实现方式已经发生了根本变化。特别是在体验过Apple Vision Pro之后，笔者更直观地感受到：高分辨率显示、空间定位、手眼追踪和自然交互能力，正在让空间计算设备成为功能原型评价的重要工具。 研发团队可以在虚拟环境中构建车辆、座舱、道路和用户场景，将交互界面、控制状态机、车辆信号和执行效果连接起来，再让评价人员通过XR设备进入场景，完成接近真实状态的体验。 这意味着，在一辆真实样车尚未制造出来之前，很多问题就可以被提前发现： 屏幕、灯光、声音和车辆动作是否协调； 界面位置、信息层级和操作方式是否合理； 场景触发是否自然，用户能否理解系统意图； 功能在不同环境和异常工况下如何表现； 交互逻辑与控制逻辑是否真正形成闭环。 在汽车仿真和混合现实的实践上，沃尔沃等企业很早就开始了探索。 沃尔沃曾与Unity及Varjo合作，通过高精度车辆模型、实时3D环境和XR头显，将虚拟内容叠加到真实车辆和真实道路中，用于评估原型、设计方案、车载交互以及主动安全技术。研发人员甚至可以在封闭测试环境中驾驶真实车辆，同时观察虚拟交通参与者、危险场景或尚未安装到车辆上的功能效果。 这类实践的价值，并不是简单地把汽车“搬进VR”，而是将真实的人、真实的车辆操作与可快速修改的虚拟世界结合起来，从而在保证安全的前提下，反复验证现实中昂贵、危险或尚不具备实施条件的场景。 
图2：构建功能原型 
图3：搭建车辆与环境模型 
图4：在XR设备中进行场景体验 视频1：沃尔沃混合现实仿真 感兴趣的读者可以查看原视频：沃尔沃功能仿真。从方法上看，基于实时3D与XR的功能原型开发大体包括以下几个步骤： 工具的意义，不只是让原型变得更加逼真，更重要的是改变开发方式。 在Unity等实时开发环境中，设计人员可以调整交互流程、界面位置或状态表现，评价人员几乎可以同步在设备中看到变化；功能开发人员修改控制条件后，也可以立即验证交互端是否正确响应。 在这里，“在线开发”并不是指连接互联网，而是指： 交互逻辑与控制逻辑运行在同一个可执行模型中，开发过程中的每一次变化都能被立即体验、同步验证并持续集成。 这样一来，功能原型便不再是开发前期用完即弃的演示材料，而可以逐步成为连接产品、交互、控制、软件和测试团队的“共同语言”。高质量的原型工程还可以向下游沉淀交互资产、状态机、信号定义、场景用例和自动化测试输入，成为一种可执行的功能规格和数字样件。当然，原型工程不能简单等同于量产软件。量产代码仍需满足实时性、可靠性、功能安全、网络安全、资源约束和软件架构等要求。但如果原型中的状态、接口和场景能够被结构化继承，就可以大幅减少下游团队对静态文档的二次理解和重复开发。 工欲善其事，必先利其器。未来，随着空间计算、全息显示、体感设备、数字孪生以及实时仿真技术继续发展，汽车功能的早期评价手段会更加丰富。 而AIGC的加入，可能进一步改变功能原型的生产方式。产品人员通过自然语言描述用户场景，系统便可以辅助生成车辆环境、交互界面、状态机、测试用例，甚至模拟不同用户的操作行为。 也许未来，产品经理只需要清楚地讲明白：谁，在什么场景下，遇到了什么问题，希望车辆如何响应，一套能够运行和体验的功能原型就可以被快速生成。 但工具越强大，越要求功能开发者能够准确判断用户价值、产品边界和安全底线。AIGC可以帮助我们更快地“做出来”，却不能替代我们回答：为什么要做，以及什么才算做好。 汽车功能开发正在从“用文档描述一个未来的功能”，走向“让所有人提前进入未来的功能”。当交互、控制、场景和评价都能在同一个可执行环境中持续迭代时，功能设计就不再是一场基于PPT的想象，开发也不必等到实车集成阶段才第一次面对真实体验。真正的功能原型，不只是一个看起来很酷的演示，而应该成为统一产品目标、打通专业边界、提前发现问题并向量产开发传递信息的数字载体。 从离线文档走向在线体验，改变的不只是一种工具，更是整套汽车功能开发方式。 案例参考：Volvo Cars与Varjo的混合现实原型评价实践；Volvo Cars混合现实驾驶仿真。
一、一个大灯功能，远不只是“点亮”
二、问题不只是“两条线”，而是整个过程仍在离线开发
三、功能原型，应该在开发开始前就能被体验
四、实时3D与XR，让功能从“被描述”走向“可体验”
五、沃尔沃的探索：把真实车辆与虚拟世界叠加
关注
重播 分享 赞
构建车辆、座舱和人机界面的数字模型； 构建目标用户场景与关键测试用例； 接入功能控制逻辑、交互状态与必要的车辆信号； 在XR设备或虚实结合台架中进行人在环体验； 根据评价结果实时调整，再次体验并形成迭代闭环。