作者：于佳卉
晚高峰，车机自动调暗灯光、播放音乐——对驾驶者是瞬间的舒适，对研发者却是一场牵动座舱、车身、传感器、数十个软件版本的“极限协同”。今天的汽车，正从交通工具变成“移动智能空间”，每增加一种体验，研发链条上就多出一批需求、接口、版本和测试任务。车越来越懂人，造车这件事却变得越来越复杂。
当产品开发周期从“年”压缩到“月”甚至“周”，过去依靠会议、表格和人工确认维持的研发方式开始承压：客户需求会不会在层层分解后走样？硬件接口改变后，软件和测试是否仍在使用旧版本？一项变更究竟会影响多少模块、测试任务和供应商？
在本期《新“智”中国行 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平台完成。
王胜航建议，企业首先应选择痛点明确、数据基础相对成熟的业务场景，例如需求歧义检查、测试用例辅助生成或生产质量检测。场景跑通后，再用效率、质量和风险等业务指标验证价值，逐步复制到更多环节。
软件定义汽车，把汽车变成了持续更新的产品，也把研发变成了一场永不停歇的系统工程。未来企业间的差距，不只在于谁先做出新功能，更在于谁能让一项需求，在成百上千个版本、团队和供应商之间，始终不失真、不走样。当速度成为常态，支撑速度的体系能力，才是最深的护城河。
热门跟贴