以下以智能座舱车控App中一个典型功能——“一键休息模式”（用户点击后，系统自动调节座椅至休憩位置、关闭车窗、调节空调温度、播放舒缓音乐）为例，对国际车企传统开发流程与中国OEM新型双模型流程进行逐阶段对比。

一、整体流程框架对比

阶段	传统瀑布模型（国际车企）	“大瀑布+小敏捷”双模型（中国OEM）
需求定义	一次性冻结全部需求，SSTS文档数百页	主干需求前置锁定 + 分支功能渐进完善
UX/UI设计	设计完成后方可进入开发，串行推进	低保真原型先行验证，高保真与开发并行
开发实施	全部需求编码完成后进入测试	2-4周短迭代，每轮产出可交付增量
集成测试	开发完成后集中集成，问题集中爆发	持续集成，每日构建+自动化回归
验证反馈	实车测试为主，问题反馈周期周～月级	SiL/云端仿真前置，小时级反馈
发布部署	年更/半年更OTA，全量推送	月更甚至更短周期OTA，灰度渐进推送

例如长城汽车已明确引入“大瀑布+小敏捷”模式，在整车架构层面保留瀑布式开发的严谨性，在应用层和用户体验功能层面采用敏捷迭代的灵活性。

二、需求定义阶段

2.1 传统瀑布模型

• 流程：产品经理在车型开发初期即撰写完整的需求规格说明，全部需求需经过多方评审并一次性冻结。对于“一键休息模式”，需明确定义座椅调节角度、空调目标温度、车窗关闭逻辑、音乐播放列表等全部参数，所有细节锁定后才能进入设计阶段。比亚迪早期软件开发也主要沿用这一线性流程——需求分析→设计→编码→测试→部署。

• 痛点：需求从冻结到实车验证间隔6-12个月，市场环境和用户偏好在此期间可能已发生显著变化。后续任何需求变更都需经过繁琐的变更控制流程，成为高成本的“工程变更”。

2.2 中国OEM双模型

• 主干需求前置锁定：与安全、法规、整车电气架构强相关的需求（如车控指令的下层执行接口、功能安全等级定义）在瀑布模型中前置冻结，确保架构稳定性。

• 分支功能渐进完善：用户体验层面的功能需求（如“休息模式”的具体参数、交互方式）采用渐进式定义。产品经理先定义最小可行产品（MVP）——如“仅实现座椅调节+空调调节”，后续迭代再叠加“车窗控制”“音乐联动”“用户个性化记忆”等增强功能。长城汽车通过采集线上线下用户舆情与诉求启动软件研发设计，并采用敏捷迭代模式。比亚迪也根据用户反馈迅速调整开发优先级，实现“用户需要什么，我们就开发什么”的敏捷响应。

三、UX/UI设计阶段

3.1 传统瀑布模型

• 流程：设计师产出完整的高保真交互原型，包括所有页面、所有状态、所有动效，经多轮评审确认后方交付开发团队。设计交付后若需调整，须走正式的设计变更流程。

• 痛点：完整设计交付耗时4-8周，且静态效果图缺乏真实交互体验，设计与实车效果之间常出现偏差。

3.2 中国OEM双模型

• 低保真先行验证：设计团队快速产出低保真原型（使用ProtoPie等工具），在虚拟座舱环境中模拟真实交互，让产品经理和用户在早期即验证交互逻辑合理性。蔚来在开发流程中已引入ProtoPie作为加速创新、简化流程以及推动敏捷迭代的关键工具。

• 高保真与开发并行：低保真验证通过后，设计与开发并行推进——开发基于设计规范先行搭建技术骨架，设计团队同步打磨视觉细节。

• 设计资产直接转化为代码：部分中国OEM已采用低代码工具，支持系统级UI主题定制，实现从设计到代码的自动化转换，释放开发资源并实现跨车型平台的统一品牌呈现。

四、开发实施阶段

4.1 传统瀑布模型

• 流程：开发团队在需求与设计完全交付后集中编码，全部功能开发完成后才进入集成测试阶段。开发周期通常持续3-6个月。

• 痛点：开发与测试之间形成“批次效应”——大量代码一次性提交，问题集中爆发，返工成本高。跨团队（座舱应用层、车控底层、云端服务）的协调依赖正式接口文档和定期对齐会议。

4.2 中国OEM双模型

• 短迭代开发：比亚迪在DiLink车载操作系统开发中采用Scrum框架，设立跨职能团队（包含硬件、嵌入式、UI/UX、测试等角色），每两周进行一次Sprint迭代，确保功能模块可快速验证并及时调整方向。同时通过每日站会同步进度，使用Jira进行任务跟踪。

• 跨职能团队并行：车控App开发涉及前端UI层（Android/Linux应用）、车控服务中间件层、底层车身域控制器三层技术栈。中国OEM组建跨职能团队，各层工程师在同一Sprint中并行开发，通过动态服务总线在迭代中期即可进行端到端联调。

• AI辅助加速：蔚来智能座舱部门已有近400名成员使用通义灵码，AI生成代码占比达30%以上，在“天探”项目中业务增量代码AI生成占比最高可达70%-80%。AI还支持智能单元测试生成，根据当前代码变更批量生成测试用例并自动编译、运行和报错修复。蔚来智能座舱团队中约40%的人员已主动申请使用通义灵码，AI工具在代码开发、代码维护、单元测试生成及问题排查等场景中全面应用。

五、集成阶段

5.1 传统瀑布模型

• 流程：各模块开发完成后集中集成，通常需处理大量接口不匹配、时序冲突、信号不一致等问题，集成周期长达2-4周。

• 痛点：集成阶段是传统瀑布模型中的“风险集聚点”——前期隐藏的所有问题在此集中暴露，导致测试资源在短期内严重过载。

5.2 中国OEM双模型

• 每日构建+持续集成（CI）：比亚迪搭建了CI/CD流水线，集成单元测试、接口测试、性能测试脚本，实现每日构建+自动回归测试，缩短测试周期约40%。

• 接口解耦先行定义：敏捷架构通过明确定义各领域的接口协议，将接口作为“开发合同”，允许硬件团队与软件团队并行工作——硬件团队按接口标准推进设计与测试，软件团队基于接口模拟环境开发功能，待实体硬件就绪后快速联调，大幅缩短研发周期。

• SiL/云端仿真前置集成：理想汽车通过世界模型构建精确仿真环境，2023年实车测试每公里成本约18元，到2025年上半年通过仿真测试成本降至每公里0.5元，测试质量反而更高。理想依托世界模型的仿真测试累计里程已突破4000万公里，每日测试里程峰值可达30万公里。

六、测试与验证阶段

6.1 传统瀑布模型

• 流程：依次完成单元测试→集成测试→系统测试→实车验收，每一层级测试需等待前序完成方可开展。HiL台架是稀缺资源，需预约排队，完成一轮完整回归测试需5-7天。

• 痛点：测试周期长、自动化率低（行业数据显示超过67%的企业在测试环节存在自动化程度不足的问题）。实车测试成本高、场景覆盖面有限。

6.2 中国OEM双模型

• 左移验证：将测试环节“左移”至研发早期，通过台架测试、模拟器验证、样车实测等方式提前暴露问题，避免后期返工。

• 自动化测试全覆盖：比亚迪建立了覆盖需求、设计、编码、测试、发布全阶段的质量控制机制，所有软件需求必须由产品经理、架构师、测试负责人三方签字确认；基于MISRA C等工业标准制定内部编码规范，配合SonarQube静态扫描工具自动检测潜在漏洞。

• AI驱动的智能测试：Testin XAgent能够实现汽车ECU/域控软件从需求理解、测试规划、环境部署、执行验证到故障自愈的端到端全自主闭环，显著提升OTA迭代中的验证效率。

• 双循环验证架构：小周期（小时/天级）通过云端SiL仿真完成核心场景快速验证；大周期（周/月级）通过物理HiL和实车完成全场景系统级验证，二者并行开展。

七、发布与部署阶段

7.1 传统瀑布模型

• 流程：整车软件版本每年更新1-2次，全量OTA推送，一旦出现严重问题回滚成本极高。对市场反馈的响应以季度为单位。

• 痛点：功能从开发完成到用户手中平均延迟3-6个月。2025年丰田座舱OTA更新仅8次、大众5次，远低于中国头部OEM水平。

7.2 中国OEM双模型

• 月更OTA节奏：2025年，比亚迪为海洋、王朝两大系列推送约200次OTA升级，实现了“月更”甚至更高频的迭代。其核心支撑是全栈自研能力——从硬件到软件，从底层架构到应用生态的垂直整合，能够根据用户反馈迅速调整开发优先级。

• 灰度渐进推送：OTA升级包并非一次性全量推送，而是先在内部车辆→员工车辆→小范围用户→全量用户逐层扩大，每层推送后监控功能表现和用户反馈，异常时快速阻断回滚。

• 数据驱动的迭代闭环：中国OEM普遍建立了“用户使用数据采集→行为分析→需求提炼→功能迭代→OTA推送→效果验证”的数据闭环。比亚迪作为全球新能源汽车领导者，拥有庞大的车辆保有量，这意味着每天都能收集到海量的用户行为数据和车辆运行数据，这些数据成为产品优化的指南针，帮助工程师团队精准定位用户痛点。长城汽车也通过数据买点实现数据闭环，以此判断用户需求的真伪。

八、核心流程环节耗时对比总结

以“一键休息模式”从概念到推送用户为例，各阶段耗时对比如下：

流程环节	传统瀑布模型	中国OEM双模型	速度差异
需求定义与评审	4-8周	1-2周（MVP）+ 持续迭代	缩短60%+
UX/UI设计	4-8周（完整交付）	1-2周（低保真）+ 并行高保真	缩短50%+
开发实施	12-20周（全部功能）	每2-4周交付可工作增量	迭代频率提升3-5倍
集成验证	2-4周（集中集成）	每日构建 + 小时级仿真反馈	反馈速度提升10倍+
测试与验收	4-8周	自动化+左移，2-3周	缩短50%+
发布部署	季度～半年度	月更（部分头部OEM周更）	迭代频率提升3-6倍
从概念到用户	6-12个月	4-8周	缩短70%+

九、双模型模式的关键成功因素

1. 架构层面：软硬件解耦、接口标准化先行。在整车架构定义阶段即明确接口协议，作为各团队并行开发的“合同”。

2. 流程层面：主干需求前置锁定确保安全和架构稳定性，分支功能敏捷迭代支撑用户体验快速优化。长城汽车的“大瀑布+小敏捷”模式是典型实践。

3. 工具链层面：CI/CD流水线自动化、云端仿真集群建设、AI辅助开发工具，是实现高频迭代的工程基础。比亚迪通过CI/CD流水线缩短测试周期约40%；蔚来通过AI辅助使增量代码AI生成占比达70%-80%。

4. 组织层面：跨职能团队打破部门墙，产品、设计、开发、测试在同一Sprint中协同。比亚迪设立包含硬件、嵌入式、UI/UX、测试等角色的跨职能团队。

5. 数据驱动层面：建立从用户使用数据到产品迭代的闭环。比亚迪的OTA策略体现了深度的用户思维，每次升级的功能都直击用户日常用车场景。