关注「电动车公社」
和我们一起重新思考汽车
大家好，我是社长。
「电动车公社」之前有过一些真实车主内容，没看过的同学可以戳链接：
《我买了辆比亚迪，王传福亲自来4S店交车！》
《1公里7分钱，油都快放过期了！零跑全新C11车主真实采访！》
《开了1个月蔚来ES6，我准备卖掉家里2台油车！》
《为什么都在喷增程，又都在买增程？》
这些内容一经推出，在公众号及各大平台都受到好评，很多网友私信我说，在这样一个到处都是水军贴、媒体收钱不敢说话的时代，希望能更多地看到这样跟车相处最久的真实车主的内容。
当然，如果你从事的是汽车相关行业，不管是各类工程师还是各家销售、技术专家还是设计师，也都可以私信我，加入我们的智囊团，一起推动汽车行业的这场伟大变革。
关注车圈的朋友们应该发现了，今年不仅是全民智驾时代的“元年”，更是“全民AI时代”的元年。
不仅Deep Seek、元宝、豆包这类AI对话工具进入了每一个普通人的生活，就连车企也在深耕AI领域。无论是座舱还是智驾，都在依赖AI大模型来提升用户体验。
那么，AI究竟是怎么借助汽车这样的产品，深入我们每个人的日常生活的？AI到底是会带来更美好的生活，还是一把双刃剑？
今天，社长就给大家找来了一位研发工程师朋友“胖哥”，目前在海外某豪华品牌任职。这次他会用最犀利的语言，和大家聊一聊车企研发中那些不为人知的秘密。
（以下内容会有些干，更适合硬核技术党。看不懂也没关系，社长会用“就是加了一层隔音棉”这种大白话给大家讲明白，可以放心食用
）
声明：
为保证内容的真实性，以下内容为车主亲笔所写，公社仅做编辑整理
遇事不决问AI，已经是这些年科技界的主流。就好比车企如果不搭载车载LLM（大语言模型）跟车主尬聊，不搭载端到端自动驾驶就要被扫进历史的垃圾堆一样。
老黄还是那个爱穿皮衣的老黄，但时代已经变了。
01. 现在的车企怎么造车？
在开聊之前，胖哥需要先和大家铺垫三个毫不相关的背景知识：车企的V开发流程，DevOps开发流程和IPD管理架构。
V流程开发是比较传统的汽车研发（尤其是软件研发）流程，整体流程大概是这样式儿的：
很多专业术语看不懂？没关系，咱换个说法——
先像乐高积木一样想象出一款产品，然后把它一项项拆分，最终细化到每一个具体的零部件；再把零部件一步步拼成一台整车，并在每一个环节加以测试。大功告成！
说白了，在V流程里，不管是乐高做一台积木汽车还是车企造一台真车，其实都是从整体到部分，再从部分到整体的思路。
V流程，是汽车正向开发中比较线性而且可靠（就是用了很久没出什么bug）的一套成熟开发流程。
它的特点是步步为营，从整体到局部，开发设计输入和测试验证反馈贯彻在全流程中，不容易出错。
但是，V流程的问题也比较明显：任何一个环节出错的时候，要一步一步地推到最底层流程去进行修正，对于相对高层次/整体化的产品研发需求变更响应速度较慢。
翻译成人话就是，领导层拍脑袋换思路的时候，底层小兵调整起来比较麻烦。
那么为了能快速响应用户的需求（比较能卷），敏捷开发的概念就被引入了汽车开发流程中，也就是DevOps开发流程。
看不懂？没关系，还有东北话版：
相对于V流程，DevOps会更参考产品运营阶段的意见（也就是用户反馈），并且根据反馈迅速迭代产品研发计划，提升软件OTA和车型换代的效率。
这尤其新势力这种相对小规模、但是需要快速更新产品的车企，毕竟小团队比较能卷。
那么，销量突破百万级的大型车企又怎么实现效率上的提升呢？就是今天要说的第三点，IPD（集成产品开发）管理架构了。
简化之后，差不多是这样式儿的：
胖哥给大家举个例子。
假设你现在是车企的一名研发工程师，同时需要向两个领导汇报——
一个管团队的领导，负责你在具体事业部中的位置，着重培养提升你在专一工作技能上的发展；
而另一个管项目的领导，负责整合你的具体技能在项目开发中发挥的作用，带领你和其他团队成员合作完成产品开发工作。
如果还不明白的话，差不多就有点像是下图这样，或者说得更简单点：一个管人不管事，一个管事不管人。
好了，和AI无关的基础背景就介绍到这里，下面我们来说说和AI有关的两件事情。
02. AI和车企的困局
第一点，是AI的不同分支——机器学习和端到端在目前汽车开发中的应用；
第二点，是车企开发过程中经常遇到的“卷不动了”类型的内耗问题。
在汽车开发的过程中，经常遇到的一个问题就是物理模型和实际测试的结果总有偏差。
随着研发要求的提升，就需要精度更高，物理结构更复杂的模型。但是更复杂的模型需要更长的研发周期和算力，又进一步提高了研发成本。
在具体的项目中，既要考虑性能又要考虑效率，经常是难以两全的。
就比如空气动力学模型和轮胎模型，就是两个常见的需要测试团队和模拟团队互相妥协的系统，懂的都懂。
所以研发人员要用大量的测试数据，去训练基于各种机器学习算法的物理模型，试图让机器自己通过算法来优化具体的拟合结果。
这些方法在目前的研发过程中已经大量应用，但是由于工程师自己也不知道具体成百上千个参数优化成什么样，导致模型的复用性很差。
换句话说，就是假如测试团队稍微调整了测试硬件，模拟团队就要花大量的时间和算力重新训练模型，团队之间经常因此产生巨大的沟通成本和时间消耗。
另外就是端到端在自动驾驶方面的应用。举个最简单的例子就是复杂车流下的并线：
虽然现在的隐式端到端，已经可以综合多模态的信息感知输入，并且有大量的实际驾驶员数据作为训练素材。
但是出于安全考量，大多数端到端算法在面对复杂路况的时候普遍比较怂，处理方式也比较单一，就是减速、停车、让行。
（比如面对突然窜出的外卖小哥，变道不打方向灯硬挤的并线，一年两箱油的马路三大妈，还有公路上的百吨王，高阶智驾都是以避免发生碰撞为第一目的）
尤其是随着法规要求，智驾车辆必须亮起青色指示灯的时候，很可能会有更多的人类驾驶员产生“这车是智驾模式，随便干他，他不敢撞你”的心态。
甚至有相关研究，基于当前的L2级自动驾驶技术，开启智驾的车辆越多，道路通行效率反而越低：毕竟有了智驾，开车玩手机的比例反而比之前更高了
。
所以哪怕算力已经堆到了很高的冗余，当下的端到端算法依然存在不少问题，需要车企一步步解决。
另外，车企还要面临开发过程中的内耗，就是刚才提到的V流程以及DevOps流程在测试端和开发端的沟通问题，激情对线那都是日常基操（请勿对号入座）。
但是没办法，V流程的左右两边，Dev组和Ops组的矛盾永远都在。就算是到了管理层，也经常会出现项目主管和团队主管为了管人还是管事吵得天昏地暗不可开交。
所以，AI到底能帮车企做什么？
答案已经呼之欲出，就是基于AI的LLM和大算力的虚拟开发中心。
大家还记得我在文章一开始提到了黄仁勋吧。老黄在CES2025上提到了如何用AI协助计算机图形学开发人员快速实现视频渲染——
比如同样的一个建模，开发人员通过自然语言描述需要的场景，AI可以快速生成出基于该建模的贴图以及渲染方案。
因此，车企可以通过大量的算力，训练出针对不同应用环境的模型。这些模型可以针对本团队设计出特定的研发目标，也可以综合其他团队建立综合优化目标。
就比如对于硬件研发团队，面对浩如烟海的标定和选型，工程师通过自然语言以及一些确定的参数输入给AI，由AI辅助工程师进行优化，确定方案，完成硬件研发。
同时这个模型还可以和供应链管理部门的AI模型进行对接，同时综合优化生产以及采购成本，在完成性能优化的同时也实现了成本上的降低。
这在各部门分头工作，各自为政的传统矩阵式IPD管理模式下，几乎是不可能实现的。
同样在开发的前期，市场部门的AI可以根据当前企业的产品线和市面上的竞品，协助市场开发人员通过自然语言的描述，来优化出新产品线的性能指标和价格区间。
与此同时，产品开发部门的工程师也可以根据市场部门的AI数据来制定具体的开发目标，藉由训练好的另一套不同的AI来协助指定各子系统的细化性能指标。
这种输入甚至是可以非常高层次，非常自然语言的，夸张一点的话比如说：
同样，如果有AI在其中，作为将自然语言的主观驾驶感受量化到标定/软件开发的工程师具体的研发细节，就可以极大的减少测试组与研发组的沟通成本。
而且如果AI能够训练得足够智能，那么基于AI的研发执行层就好比一个个工程师在背后处理着来自不同领导，不同项目组的工作。
这样一来，就不再会有（或者至少是减少了）企业的内耗，以及“卷不动了”的情况出现，打工人也不会再为难打工人。毕竟，打工人现在为AI服务。
而这，就是未来车企组织架构的发展方向：基于AI的虚拟研发中心。
那么问题来了，到底AI能够做到什么程度才值得我们在IPD管理模式中增加一个新的维度？
这里胖哥更想用另一个维度的方式来描述这个话题，那就是——到底AI在用什么样的视角看待这个世界。
03. 我，机器人
众所周知，AI生成的图片不会画手。
更众所周知，AI生成的视频很可能违反物理定律。
就像刚刚胖哥提到的，在实际的产品研发过程中，永远会有“物理模型的细节”和“数据模型的不准确”之间取舍的问题。
毕竟所谓基于机器学习的模型，工程师也不知道具体模型里的参数是怎么优化的，模拟结果是怎么拟合的。
很多传统的工程师很反感这种描述结果的建模方式，他们认为只有更高精度的物理模型才是在计算机上设计汽车的康庄大道。
然而，如果我们换个视角来看待这个问题，那就是：
AI不理解世界，AI只描述世界。
同样，如果我们各个研发部门有了AI辅助的研发中心后，相对于工程师们日常的工作，这个虚拟研发中心要做的工作是：
我，机器人，根据你们人类的语言/数据输入和设定的边界条件，描述出符合你们人类要求的汽车设计方案。
AI不理解汽车，但是AI可以描述汽车！
这种研发方式，是之前基于项目，或者基于团队的管理方式，都无从管理的研发体系。
管理团队更需要带领AI工程师了解所有产品研发/测试/市场/供应链部门的具体需求，通过他们已有方案的输入输出来优化自己的AI模型，让模型的输出结果尽量接近已有的工程开发方案，从而让虚拟研发中心的解决方案能够更有效地作为人类工程师开发结果的参考。
虚拟研发中心这项工作，将是一个长期而艰巨的过程。
就像端到端自动驾驶，需要大量的数据和茫茫无边的优化来不停的实现更加可靠，更加接近人类驾驶行为的自动驾驶模型。它不需要理解什么是纯视觉方案什么是LIDAR，但是它会描述人类世界的驾驶环境。
同样，虚拟研发中心一定从V流程的最低端开始，一定从DevOps最小的敏捷开发迭代循环开始，将AI首先尝试用在简单的模型上，用在基础的非线性多目标优化问题上。
之后随着研发数据越来越多，逐渐强化AI的功能，实现多个部门的协同AI工作，而这就是虚拟研发中心的雏形。
或许有一天，执行层的工程师更多的需要AI帮助他们解决建模，仿真，优化的工作，而甚至他们自己都无法得出AI那样优美的结果。
但工程师永远不会失业，因为AI不理解汽车，AI只能描述汽车。真正理解汽车的，还只能是广大的人类工程师们。
大人，时代变了，时代似乎又没变。
点击一下👇不错过更多深度内容
