作者于佳卉晚高峰车机自动调暗灯光、播放音乐——对驾驶者是瞬间的舒适对研发者却是一场牵动座舱、车身、传感器、数十个软件版本的“极限协同”。今天的汽车正从交通工具变成“移动智能空间”每增加一种体验研发链条上就多出一批需求、接口、版本和测试任务。车越来越懂人造车这件事却变得越来越复杂。当产品开发周期从“年”压缩到“月”甚至“周”过去依靠会议、表格和人工确认维持的研发方式开始承压客户需求会不会在层层分解后走样硬件接口改变后软件和测试是否仍在使用旧版本一项变更究竟会影响多少模块、测试任务和供应商在本期《新“智”中国行 AI会客厅》中至顶科技CEO兼总编辑高飞与蜂巢电子科技研发副总经理袁光、IBM中国科技事业部ELM业务总经理王胜航展开对话讨论软件定义汽车时代汽车电子企业如何管理快速迭代的软硬件产品以及AI如何进入需求、开发、测试和制造流程。这场对话指向一个很具体的问题汽车电子企业如何在加快迭代的同时不让复杂度演变为质量和交付风险当开发周期从“年”压缩到“周”哪里最先承压汽车电子企业最先感受到的变化是时间。袁光表示过去一款全新车型的开发周期通常以年计算如今主机厂频繁提出三个月实现SOP、六个月交付新车等要求部分功能的开发周期甚至从几个月压缩到一个月或一周。产品迭代速度提升的同时质量门槛也在提高。过去ASPICE、功能安全和网络安全等能力可能是供应商的加分项如今已逐渐成为进入主机厂供应体系的基本条件。企业不仅要把产品做出来还要证明每项需求经历了怎样的设计、开发和验证每次变更又影响了哪些环节。更大的挑战来自协同复杂度。传统汽车电子产品相对独立仪表、收音机等模块之间的交互有限。随着智能座舱、智能车控、网联和辅助驾驶进入整车不同产品开始与多个域交互。接口、软硬件版本、测试环境及供应商交付只要有一个环节出现偏差问题就可能在联调甚至量产阶段集中暴露。过去比的是能不能把产品做出来今天比的是在软件快速迭代时能否把硬件、软件、测试和安全放进同一套研发体系。这也改变了汽车行业对“自动化”的理解。王胜航表示十年前的自动化更多集中在生产侧通过机器和设备代替重复劳动。今天的智能制造则开始把数据、物联网、算法和AI引入研发、生产和运维的全链路。自动化关注单一工序能否更快、更稳定地运转智能制造则要求整套体系能够感知变化、判断影响并作出反应。汽车电子的研发过程也因此成为智能制造的重要起点。告别“重复造轮子”研发需要一套“共同语言”蜂巢电子主要从事汽车智能化相关产品的研发、生产与销售产品覆盖智能座舱域控制器、辅助驾驶域控制器、显示屏、音响系统、T-BOX和雷达等。随着产品数量、研发团队和客户范围扩大蜂巢电子近几年进行了三次重要的研发管理调整。它们对应着汽车电子企业规模化过程中常见的三个问题项目增多后如何减少重复开发团队扩大后如何形成共同语言工程数据持续积累后又如何转化为组织能力。首先是从项目制转向平台化。早期的软件、硬件和结构开发主要围绕单个车型项目展开。这种方式能够快速响应客户但项目越多重复开发越明显。同样的基础功能可能被多个团队反复实现已有工程资产也难以复用。蜂巢电子随后开始推进平台化研发让不同车型项目共享基础软硬件平台并在需求、结构和软件模块等方面提高复用率。平台化的价值不只是少写一遍代码。车型项目越多复用已有模块带来的时间和成本优势越明显也更有利于团队将精力集中在真正具有差异化的功能上。第二次调整是统一研发体系和工具链。团队成员来自不同企业研发习惯和流程认知存在差异。如果缺少统一的研发语言和标准同一个需求、版本或测试状态很容易在不同团队之间产生不同理解跨部门协作也会因此依赖大量沟通和人工确认协作效率难以提升。蜂巢电子先将流程体系化再把流程固化到研发工具中引入包括IBM ELM在内的工程管理系统让团队尽可能在统一的流程、数据和工具环境中工作。第三次调整指向技术知识管理。一家企业运营多年后会沉淀大量问题分析、设计规范和工程经验。但这些知识往往分散在文档、系统和个人经验中工程师真正需要时未必能找到。在袁光看来AI提供了一种新的可能让模型学习企业内部积累的工程数据把过去“沉默”的知识重新呈现在工程师面前。三次调整指向一个变化当产品和团队规模扩大研发不能再只依赖项目经验和个人能力而需要形成可复用的平台、统一的协作规则和能够持续调用的知识资产。最昂贵的错误为什么总在最后才被发现研发周期越短质量问题越不能留到最后。袁光表示当产品进入最终测试阶段才暴露问题时间和成本往往已经难以挽回。汽车电子研发需要将测试验证前移在需求、设计和开发过程中持续检查产品状态。传统V字研发模型的一侧是需求分解和产品开发另一侧是对应层级的测试与验证。面对快速迭代蜂巢电子开始在大的V字模型中加入多个小型敏捷循环让需求、开发和测试以更短周期反复迭代。用袁光的话说测试不应是最后一步而要为全过程“量体温”。测试前移之后一个基础问题变得更加重要每一项测试究竟对应哪一条需求一项客户需求可能经过系统需求、软件需求和硬件需求多层分解最终转化为不同的测试用例。只要其中一次传递发生偏差最终实现的功能就可能偏离原始意图。版本管理同样复杂。硬件接口已经调整软件和测试环境仍然沿用旧版本问题通常要等到联调时才会暴露。一旦需求发生变化受到影响的设计、测试、缺陷和交付物也很难单靠人工迅速判断。因此工程生命周期管理在这里就变得很重要它承担着建立关系链的角色。王胜航表示通过IBM ELM客户需求如何被分解最终由哪些测试验证发现缺陷后如何关闭都可以沿着同一条工程链路被查询。需求发生变化后团队也能据此判断哪些模块、版本和测试任务需要重新关注。这种追溯关系同时支撑着汽车企业的合规管理。在ASPICE、功能安全等审核过程中企业需要提供研发活动的过程证据。如果日常工作没有留下完整记录项目团队只能在审核前翻找文档、补充表格。通过工程系统持续记录需求、测试和变更证明材料可以在正常研发过程中同步形成。工程师不必额外完成一份“证明自己工作过”的工作。质量与合规也由项目结束前的集中补课转变为研发流程本身的一部分。系统接口通了但业务真的“通”了吗从研发样件走向量产企业还要跨越研发、测试、制造和供应链之间的边界。蜂巢电子在实践中发现最容易出现问题的地方首先是上下游需求不一致。信息经过多个团队传递后发生变化上游已经调整下游仍然沿用原来的要求。另一个问题来自流程中的灰色地带。企业流程不可能一次设计完成随着产品、客户和组织发生变化总会出现原有流程没有覆盖的新情况。此外系统很多数据知识也很多但是系统和系统之间到底哪些数据应该互通要挖掘哪些数据及报表展示没有统一的说法这样就导致了数据孤岛及系统孤岛。王胜航进一步强调不同系统可能采用不同的数据格式、版本规则和业务语义。同一个零件、需求或测试状态在不同供应商和业务部门眼中含义可能也不一致。即使建立了接口数据也可能无法被对方理解和信任。因此从研发成果真正落到制造交付重要的一点是要做好系统之间的互联互通和数据的活用。袁光认为引入多个系统时应从业务的角度出发。系统展示什么、连接什么由真实业务需求定义再通过持续的PDCA循环补齐才能发挥出流程和工具的最大价值。在蜂巢电子的实践中当需求发生变化时系统可以主动提示工程师哪些测试用例需要重新执行哪些任务和版本可能受到影响。工程师减少了充当“传话筒”的时间才能将更多精力投入分析和创新。AI可以放大成熟体系也会放大混乱如今蜂巢电子已经在多个方向探索AI应用。企业内部搭建了虚拟导师将工程数据和知识经验提供给员工在代码开发环节引入AI IDE用于辅助代码生成、低级错误检测和软件单元测试生成通过自研AI Agent对软件缺陷进行分析和自动流转。王胜航表示AI在研发场景中更像一个放大器。企业要先把需求、设计、测试和缺陷之间的关系管理清楚再利用AI提升分析和执行效率。如果研发流程本身没有被结构化灰色地带仍然大量存在AI获得的上下文就不会完整。它可以放大一套成熟体系也可能放大数据缺失、版本混乱和流程不一致。关键还在于AI需要嵌入工程师日常使用的系统和流程而不是成为研发链条外的又一个孤岛。如果工程师完成一项工作后还要把数据手动复制到另一个AI系统中重新处理AI不仅没有减负反而增加了一道流程。真正的智慧研发应当让AI“长”在研发数字主线上在工程师工作的同时理解项目背景。同时企业数据也决定了AI能力的差异。通用大模型可以提供广泛知识却不了解一家企业多年积累的设计规范、问题记录乃至客户要求。模型基础能力逐渐趋同后企业自身的工程上下文将成为决定AI应用效果的重要变量。从“被动响应”到“提前预判”还有多远站在未来三年的尺度上袁光认为汽车电子研发可能从被动响应需求逐渐转向提前预判。企业可以基于已有产品平台、用户反馈和市场数据预测客户需求提前完成一部分技术预研。工程师和专家积累的排故经验、设计规范和项目知识也将进一步转化为系统可调用、AI可学习的企业资产。AI则会批量处理更多规则明确的常规任务工程师将精力转向系统架构、产品判断和创新。研发与制造之间的边界也会继续被打通。研发端的软件版本、测试标准和工艺参数更快地传递到生产线制造端的设备和质量数据再反向进入研发流程。类似的逻辑也可以延伸到生产运维环节。比如先通过Maximo等软件连接设备数据和维护流程再利用AI识别异常、辅助质量检测和预测性维护。但这一转变不会通过一次性建设一个庞大的AI平台完成。王胜航建议企业首先应选择痛点明确、数据基础相对成熟的业务场景例如需求歧义检查、测试用例辅助生成或生产质量检测。场景跑通后再用效率、质量和风险等业务指标验证价值逐步复制到更多环节。软件定义汽车把汽车变成了持续更新的产品也把研发变成了一场永不停歇的系统工程。未来企业间的差距不只在于谁先做出新功能更在于谁能让一项需求在成百上千个版本、团队和供应商之间始终不失真、不走样。当速度成为常态支撑速度的体系能力才是最深的护城河。