当我们谈论智能汽车的进化时，我们习惯于谈论芯片性能的提升、算法模型的增大、传感器数量的增加。这些都是智能汽车看得见的”大脑”和”神经”，但有一个维度却常常被我们忽略——那就是支撑这一切的”骨架”。

就像在生物体中，骨架不仅仅是支撑身体的坚硬结构，更是肌肉附着、运动协调、生长发育的基础。没有一个不断进化的骨架，再强大的大脑和神经也无法发挥作用。同样，在智能汽车中，”骨架”——也就是硬件与软件的连接架构、接口定义、资源分配机制——正在经历一场静悄悄的革命。

这场革命的核心是什么？传统汽车的骨架是”机械浇筑”出来的，一旦定型就终身不变。现代EEA架构下的骨架是”数字预制”的，通过标准化接口实现一定程度的灵活性。而在AI驱动的数字生命体中，骨架正在变成**”AI赋形”**的——软件不断学习，重新定义硬件的连接方式，整车逐渐形成属于自己的”肌肉记忆”，随着使用不断进化。

这就是我们今天要探讨的主题：软件如何重新定义智能汽车的”骨架”，AI又如何赋予这副骨架真正的”肌肉记忆”能力。

一、从机械骨架到数字骨架：被忽略的架构革命

要理解这场骨架进化，我们需要先回到起点：汽车的骨架从一开始就是什么样的？它经历了怎样的演变？

1.1 机械时代：钢铁浇筑的静态骨架

在传统燃油车时代，汽车的骨架毫无疑问是机械骨架。各个部件之间主要通过机械结构连接，一旦组装完成，连接方式、相对位置、功能分工就都固定下来了。

比如，发动机就是发动机，变速箱就是变速箱，它们之间通过传动轴和连杆物理连接。这种连接一旦完成，就不可能在使用过程中改变。你不能开着开着就让发动机突然变成发电机，也不能让变速箱改变传动比的物理实现方式。

这种机械骨架有它的好处：结构简单、可靠性高、成本可控。但缺点也同样明显：完全没有灵活性。任何功能变更都需要物理改装，升级几乎不可能。汽车卖出去是什么样，就一直是什么样。

这种静态性，在燃油车时代不是问题。因为用户买的就是一部”会跑的机器”，机器本来就是固定的。但进入智能电动时代，用户开始期待汽车像手机一样持续进化，机械骨架的局限性就越来越明显了。

1.2 EEA转型：开始出现数字韧带

当汽车进入电子电气时代，特别是分布式架构向域集中架构演进，我们开始看到数字骨架的雏形。

什么是数字骨架？简单说就是把原来很多分散的机械连接，替换成标准化的数字接口。比如，原来各个零部件都有自己专属的连接线和通信协议，现在统一换成以太网，用标准的SOME/IP协议进行通信。

这个转变的意义是什么？原来零部件之间的连接是”硬连接”，现在变成了”软连接”。功能不再完全绑定在物理硬件上，而是可以通过软件重新定义。

我把这个阶段称为”数字韧带”的出现。骨架还是那个骨架，但连接骨架各个部分的”韧带”从机械变成了数字。这给了骨架一定的柔韧性。

比如，现在的域控制器架构，车身域、座舱域、智驾域各自分离，通过以太网连接。如果座舱域需要更多算力，理论上可以通过软件调度，让智驾域在空闲的时候分享一些算力过来。虽然现在还没有真正实现，但架构上已经具备了这种可能性。

但是，我们也要清醒地认识到：现阶段大部分所谓的”软件定义汽车”，还停留在**”软件配置骨架”**的阶段。也就是说，骨架的形状和连接方式在工厂里就配置好了，出厂之后基本不变。OTA主要是更新算法和功能，很少触及骨架层面的改变。

就像搭积木，厂家在出厂前帮你把积木拼好了，你可以在这个基础上换一些积木块，但整体结构不变。真正的骨架进化，应该是积木的连接方式本身都可以在使用过程中不断改变。

1.3 AI时代：为什么骨架需要重新定义？

当AI开始深度进入汽车，特别是大模型和生成式AI技术上车后，我们发现现有的数字骨架还是不够用。为什么？

第一个原因：AI对算力的需求是动态波动的，而且波动非常大。

传统的EEA架构是”静态分区”的——座舱多少算力，智驾多少算力，都在设计阶段就分配好了。但AI大模型的算力需求完全不是这样。当你在用语音助手聊天时，需要的算力可能不小；当你在用大模型做导航规划时，需要的算力又不一样；当自动驾驶在高速巡航时，和在复杂城市场景下，算力需求也差很多。

如果按照峰值算力分配每个域，大部分时间算力都是浪费的。如果按照平均分配，高峰时候又不够用。怎么解决这个问题？需要骨架本身能够动态调整——哪个部分需要更多算力，骨架就自动把更多硬件资源连接过去。

第二个原因：AI带来了很多新的交互方式，这些方式无法预先定义。

比如，现在的人车交互，基本都是预先定义好的——你按哪个按钮，就触发哪个功能。但AI大模型带来了自然语言交互、手势交互、甚至情感交互，这些交互方式很多是使用中才会涌现出来的，无法在设计阶段就全部定义好接口。

骨架需要具备弹性——能够随着新交互方式的出现，自动调整硬件和软件的连接关系。

第三个原因：AI让汽车真的可以学习，学习的结果需要固化下来。

当汽车开始学习用户的驾驶习惯、使用偏好，这些学习的结果放在哪里？传统架构是把学习结果放在算法模型里，但如果这些习惯影响到了各个部件的协同方式呢？比如，用户经常在某个路段用某种方式加速，动力系统和底盘系统的协同就需要调整。

这种调整就是”肌肉记忆”——骨架本身记住了常用的姿势，下次再遇到类似情况，反应更快更自然。这种肌肉记忆不可能都由厂家预先做好，必须在使用过程中自主形成。

所以，我们需要一种全新的骨架——它不再是出厂就固定不变的，而是能够被软件不断重新定义，能够被AI不断塑形，能够在使用过程中形成自己的肌肉记忆。

这就是”软件定义肌肉记忆的AI赋形”。

二、什么是AI赋形的骨架？四个核心特征

理解了为什么需要骨架进化，我们接下来要问：AI赋形的骨架，到底是什么样的？它有哪些核心特征？

通过对国内外领先车企和芯片厂商架构设计的观察，我总结出AI赋形骨架的四个核心特征：

硬件池化、接口柔性、动态重连、记忆固化。我们一个个来看。

2.1 硬件池化：从”静态分区”到”资源池”

第一个也是最根本的改变，就是从”静态分区”走向硬件池化。

什么意思？传统域架构是”一个萝卜一个坑”——座舱域就是这个坑，放的就是座舱的萝卜；智驾域就是那个坑，放的就是智驾的萝卜。每个萝卜都有自己固定的位置，不能乱挪。

硬件池化就是把所有的计算资源、存储资源、I/O资源都放在一个大池子里，不预先分给某个具体的域。需要用的时候，动态分配；用完了，再收回去。

听起来很简单，但真正做起来非常难。难在哪里？

第一，延迟问题。智驾对延迟要求非常高，如果你动态分配算力，会不会因为调度带来额外延迟？这对调度算法和硬件互连都提出了很高要求。

第二，安全隔离问题。功能安全要求不同安全等级的功能必须隔离，不能互相影响。如果你把所有资源都池化了，怎么保证安全隔离？一个应用崩溃了，会不会影响整个系统？

第三，软件生态问题。现在的汽车软件都是按照域划分开发的，每个域有自己的操作系统和 middleware。如果变成资源池，整个软件开发方式都要变，生态迁移成本很高。

但是，难归难，方向是对的。我们已经看到一些厂商开始在这个方向探索。比如，英伟达的Thor芯片，就是把整个SoC做成一个大一统的计算资源池，支持硬件虚拟化，可以动态分配给不同功能。高通最新的FlexGen架构，也是朝着这个方向走。

国内的一些新势力车企，也在探索中央计算机+区域控制器的架构，本质上就是在向硬件池化方向演进。中央计算机掌握大部分算力资源，动态分配给不同任务。

未来，随着3nm、2nm工艺进步，芯片整合度越来越高，把多个域的计算核心放在同一个die上，会越来越经济。到那个时候，硬件池化就水到渠成了。

2.2 接口柔性：从”硬编码”到”语义化”

第二个核心特征是接口柔性。

传统的硬件接口都是”硬编码”的——这个地址对应哪个寄存器，这个ID对应哪个功能，都写死在代码里。要改接口，就得重新编译代码，OTA整个软件包。

柔性接口是什么样的？接口不再是硬编码的物理地址，而是语义化的服务描述。我需要一个”输出10kW动力”的服务，不管这个服务到底是哪个硬件提供的，只要能满足我的语义要求就行。

举个例子：你要调节空调温度，传统接口是”发送ID为0x123的CAN信号，数值代表温度”。柔性接口是”我要把座舱温度降到24度”，至于这个请求具体发给哪个控制器，走什么通信路径，由框架自动路由，不需要上层应用关心。

这样做的好处是什么？松耦合。硬件可以换，只要语义接口不变，上层软件不用改。比如，你换了一个空调控制器，只要它还提供”调节温度”的语义接口，上层的空调APP完全不用动。

更重要的是，AI可以理解语义，自动匹配接口。当一个新的AI应用需要某个硬件功能，它不需要知道具体的接口定义，只要用自然语言描述清楚它需要什么，框架就可以自动找到对应的服务，完成连接。这对于AI原生应用来说太重要了。

现在，SOA（面向服务的架构）思想在汽车EEA中已经普及了，但大部分厂商做的SOA还只是”静态SOA”——服务接口还是在设计阶段就定义好了，出厂之后不怎么变。真正的柔性接口需要的是**”动态SOA”**——服务可以在运行时注册、发现、注销，接口可以动态协商。

这才是真正的柔性。接口不再是骨架上固定的挂钩，而是可以根据需要自动长出新的挂钩。

2.3 动态重连：从”固定拓扑”到”按需重组”

第三个核心特征是动态重连。

传统架构的连接拓扑——也就是哪个部件和哪个部件连接，谁给谁发数据——基本是固定的。设计的时候画好拓扑图，生产出来就按照这个连。

动态重连意味着拓扑可以在运行时重新组合。根据当前任务的需要，自动建立最合适的连接；任务完成了，就可以断开连接，释放资源。

比如，现在你要用到自动驾驶的自动泊车功能。自动泊车需要环视摄像头的数据，需要雷达数据，需要计算路径，需要控制方向盘和刹车。在动态重连架构下，系统会自动把这些相关的硬件和软件模块连接起来，形成一条专门针对自动泊车的数据流路径。任务完成了，这些连接就可以解除，资源释放给其他任务。

听起来是不是有点像云计算里的”容器编排”和”服务网格”？没错，思路是一样的。云计算早就走过了从物理机到虚拟机到容器到Serverless的路，就是从静态分配走向动态调度。智能汽车的骨架进化，走的是同一条路。

动态重连带来最大的好处就是资源利用率提升。需要的时候组合，不用的时候解散，资源始终用在刀刃上。特别是对于AI这种算力需求波动很大的场景，收益特别明显。

但是，动态重连也带来新的挑战。最大的挑战就是一致性和可靠性。每次连接重组，会不会出现延迟抖动？会不会出现数据不一致？功能安全怎么保证？这些都是需要解决的问题。

目前来看，软件定义网络（SDN）的思想可以借鉴过来。用一个中央控制器来管理整个拓扑，全局决策，局部执行。既有全局的灵活性，又有局部的稳定性。

2.4 记忆固化：从”出厂定型”到”肌肉记忆自主形成”

第四个，也是最有AI特色的特征，就是记忆固化。

什么意思？就是常用的连接模式和资源分配方案，会被系统记住，固化下来，变成骨架的一部分。下次遇到同样的场景，直接用，不需要重新计算和调度。这就是”肌肉记忆”。

我们人类的肌肉记忆就是这样——刚开始学骑自行车，每个动作都需要大脑刻意控制，很慢很僵硬。练得多了，肌肉就记住了姿势，变成了条件反射，不用想就能做，又快又自然。

智能汽车的肌肉记忆也是这个道理。比如，你每天上班走同一条路线，走走停停，你的驾驶风格比较猛，经常急加速急刹车。系统会观察到这个模式，逐渐把动力系统、底盘控制系统、能量管理系统的协同参数调整到最适合你这个风格的状态，并且固化下来。下次你一开上这条路，系统自动切到这个模式，车辆的响应就是你习惯的样子。

再比如，你经常用语音助手控制空调和导航，系统会观察到这个习惯，把语音模块和空调控制、导航模块的连接优先级调高，响应延迟就会降低，用起来更流畅。

这就是AI赋形的精髓——骨架不是厂家给的，是用户用出来的。汽车用得越久，对用户越了解，骨架就越贴合用户的使用习惯，用起来就越顺手。

这个过程是持续终生的。只要汽车还在使用，骨架就在不断调整，不断形成新的肌肉记忆。汽车真的变成了一个会”学习”的生命体，而不是一台出厂就定型的机器。

三、AI如何”记住”肌肉记忆？底层机制解析

说了这么多概念，我们来看点更实在的：AI到底是怎么让骨架形成肌肉记忆的？这个过程在技术上是怎么实现的？底层机制是什么？

我把这个过程分解为四个步骤：

观察学习→模式提炼→试错优化→固化沉淀。我们一步步解析。

3.1 第一步：观察学习——收集骨架使用数据

肌肉记忆形成的第一步，是观察。系统要持续收集各个部件的使用数据，看看骨架到底是怎么被使用的。

需要收集哪些数据？

• 时间维度：什么时候，哪个接口被调用了，频率是多少？
• 空间维度：哪些模块经常一起被调用，它们之间的连接流量有多大？
• 性能维度：当前的连接方案带来了多少延迟，有没有瓶颈？
• 用户维度：用户在什么场景下使用这些功能，用户的操作习惯是什么？

这些数据就是AI学习的原材料。没有这些数据，AI就不知道骨架哪里需要调整。

这里有一个很重要的设计原则：观察不能干扰正常运行。不能因为收集数据，就给系统带来额外的延迟和开销。所以，观察一般都是”带外”进行的，轻量级采样，不会影响正常业务。

现在很多新势力车企都在做用户数据收集，但大部分收集的是用户行为数据，用来改进产品设计。很少有车企收集骨架层面的使用数据，用来动态调整骨架本身。这就是差距所在。

3.2 第二步：模式提炼——发现频繁使用的”姿势”

有了数据之后，AI就要开始提炼模式——看看哪些连接模式是频繁出现的，哪些资源分配方案是常用的。

这个过程有点像采矿——从一大堆杂乱无章的数据里，挖出有规律的模式。

常用的方法有几种：

频繁项集挖掘：找出哪些模块经常一起被调用。比如，发现语音模块+空调模块+导航模块经常一起被调用，这就是一个频繁模式，说明用户经常一边导航一边调空调。那系统就可以考虑把这三个模块的连接优先级提高，预分配一些资源。

聚类分析：把相似的使用场景聚在一起。比如，发现用户工作日早高峰走高架的场景，有相似的动力需求和驾驶风格，那就可以聚成一类，形成一个专门的配置。

强化学习状态建模：把不同的使用场景看作不同的状态，学习每个状态下最优的骨架配置。比如，高速巡航状态下，智驾需要的算力多，座舱需要的算力少，那就把更多算力分配给智驾；停车充电状态下，座舱需要的算力多，智驾基本不用，那就把算力都分给座舱。

这个阶段的关键是不要过度拟合。不能把每个偶然的使用模式都记住，那样骨架会变得很碎，效率反而低。要抓住真正频繁、真正稳定的模式，只记住这些。

3.3 第三步：试错优化——找到最优配置

找到模式之后，就要开始试错优化——针对这个模式，尝试不同的骨架配置，看看哪个效果最好。

这个过程很像生物进化——变异出不同的配置，然后环境选择出好的变异，保留下来。

怎么试错？不能让用户感觉到试错，不能影响用户体验。所以，试错一般都是影子模式运行——新配置和旧配置同时跑，比较它们的性能，但只把结果给用户，不用新配置真正接管。只有当新配置确实比旧配置好，才会切换过去。

评价一个配置好坏的标准有哪些？

• 延迟更低：同样的功能，响应更快。
• 算力利用率更高：没有浪费的算力，也不够。
• 能耗更低：同样的性能，消耗的电量更少。
• 用户满意度更高：如果能从用户交互中得到反馈，那就更好了。

比如，针对用户上班路线这个模式，试一下不同的算力分配方案：分给动力系统多一点，会不会响应更快？分给智驾多一点，会不会能耗更低？试几次，找到一个平衡点，用户体验最好，那就用这个配置。

试错优化是一个持续的过程，不是一次就完了。用户习惯会变，路况会变，所以优化也要持续进行。

3.4 第四步：固化沉淀——变成骨架的一部分

试错找到最优配置之后，就要把它固化沉淀下来，变成骨架的一部分，这就是肌肉记忆形成了。

固化在哪里？一般分两层：

第一层：软件配置层。把最优的连接拓扑、资源分配方案、接口优先级这些，保存成配置文件，下次遇到同样场景，直接加载这个配置。这一层比较轻量，修改也比较容易。

第二层：硬件加速层。如果这个模式真的非常稳定，用户每次用都用到，那就可以考虑把它固化到硬件加速单元里，比如FPGA的逻辑里，或者AI加速器的固定流水线里。这样延迟更低，性能更好。当然，这一层改动成本比较高，只有非常稳定的模式才值得这么做。

固化之后，下次遇到同样场景，不需要再重新计算调度，直接用已经优化好的配置，速度快很多。这就是肌肉记忆的优势——形成之后，反应又快又准。

而且，肌肉记忆是可以遗忘的。如果一个模式很久不用了，系统会自动把它从固化中移除，释放空间给新的模式。这就像我们人类，很久不做的动作，肌肉记忆也会慢慢淡化。很符合生命体的特征。

四、AI赋形带来了什么？五大价值重构

讲清楚了机制，我们来看一个最实际的问题：AI赋形的骨架，到底能给智能汽车带来什么好处？为什么我们需要这个进化？

我总结了五大价值，这些价值重构了用户体验、研发效率和产品生命周期。

4.1 用户体验：越来越顺手的”个性化骨架”

第一个，也是用户最能直接感知到的价值，就是用户体验越来越好。

传统汽车买回去是什么样，就一直是什么样，最多就是OTA更新几个功能，底层骨架不会变。所以，用久了也不会更顺手，顶多就是你习惯了它。

AI赋形的骨架不一样，它会跟着你变。你用得越久，它越了解你的驾驶习惯、使用偏好，骨架就越贴合你，用起来就越顺手。

举几个具体的例子：

• 动力响应：如果你喜欢激进驾驶，它会把动力系统的响应调得更灵敏，扭矩给得更快；如果你喜欢舒适驾驶，它会把响应调得更平缓，油耗更低。而且这个调整不是你手动去设的，它自己观察，自己调整，自己记住。

• 交互流畅度：如果你经常用语音控制，它会把语音模块的优先级提高，预加载模型，响应速度会越来越快；如果你几乎不用语音，它会把资源让给其他模块，不浪费。

• 能耗优化：它会记住你常走路线的红绿灯位置、坡度变化，提前调整能量管理策略，该滑行的时候滑行，该充电的时候充电，不知不觉就能帮你省下不少电。

这种个性化不是厂家给你几个选项让你选，而是汽车自己学出来的，比你自己选的更懂你。

想象一下，你开着这样一辆车，就像穿一双已经被你的脚撑得 perfectly fit 的鞋子，那种舒服是标准码鞋子永远给不了的。这就是AI赋形带来的用户体验质变。

4.2 资源效率：算力利用率提升30%+

第二个价值，是硬件资源利用率大幅提升。

传统静态分区架构，最大的问题就是资源浪费。高峰的时候不够用，低谷的时候闲着。特别是AI大模型上车之后，算力成本这么高，浪费不起。

AI赋形加动态重连，能把闲置的资源充分利用起来。根据国内一家头部芯片厂商的内部测试，动态调度相比静态分区，整体算力利用率能提升30%以上。这个提升幅度非常可观。

什么概念？原来需要100TOPS的芯片才能满足需求，现在只要70TOPS就够了，成本直接降下来。或者说，同样100TOPS，能支持更多AI功能，用户体验更好。

除了算力，存储、带宽也都能提升利用率。比如，存储资源，常用的模型参数放在高速缓存里，不常用的放在低速存储里，自动冷热交换，既保证性能又节省成本。

资源利用率提升，最终转化就是成本下降或者体验提升，这对车企和用户都是双赢。

4.3 研发效率：接口进化不用停

第三个价值，是整车研发效率提升。

传统汽车研发，骨架在设计阶段就要定下来，接口都要定义好，后面改起来非常麻烦，牵一发动全身。如果某个接口要改，所有用到这个接口的模块都要改，测试工作量巨大。

AI赋形的柔性接口架构，接口是语义化的，动态发现的。新增一个服务，只要注册一下，上层应用自动就能发现，不用改上层代码。删除一个服务，也不会影响其他服务，只要把它注销就行了。

这对于快速迭代开发太友好了。现在智能汽车软件迭代这么快，每个月都更一次，如果每次更新都要改骨架，工程师累死了。柔性接口让骨架进化不用停，新增功能不会牵动全身，研发效率自然就上去了。

还有一个好处，就是第三方应用开发更容易。第三方开发者不需要知道底层硬件的具体接口，只要按照语义调用服务就行了，开发门槛降低，更容易形成生态。

4.4 生命周期：从”出厂即定型”到”终生进化”

第四个价值，是产品生命周期大大延长。

传统汽车，技术更新太快，三五年之后，硬件就不够用了，软件也更不了新，用户就想换车。为什么？因为骨架定死了，新功能需要新的骨架支持，旧骨架撑不住。

AI赋形的骨架不一样，它本身就是软件定义的，能够不断重新塑形。新功能来了，只要重新分配资源，重新组合连接就行了，不需要换硬件。只要核心算力够，骨架就能一直进化下去。

这样一来，汽车的使用寿命就能大大延长。原来可能五六年就要换车，现在可能七八年甚至十年，车还是能跟着时代进化，用户就不用急着换车。

这对于环保也有好处，减少了电子垃圾，符合可持续发展的方向。当然，对于车企来说，这可能意味着新车销量会受影响，但用户价值提升了，整个行业会向服务转型，靠软件服务赚钱，不一定靠卖新车赚钱。

4.5 安全可靠：动态调度反而更安全

讲到这里，可能有人会问：骨架天天变，动态重连，会不会变得不安全？功能安全怎么保证？

其实恰恰相反，AI赋形的骨架，反而能更安全更可靠。为什么？

第一，动态冗余。如果某个硬件出问题了，系统可以自动把它的任务重新分配给其他空闲硬件，只要重新建立连接就行了，不会因为一个硬件故障导致整个系统瘫掉。传统静态架构，一个硬件坏了，对应的功能就没了，很难动态替换。

第二，负载均衡。AI持续监控各个部件的负载，如果某个部件负载太高，温度过高，可以自动把一部分任务分到其他负载低的部件，避免过热过载，延长硬件寿命。

第三，异常检测。AI在观察使用数据的同时，也能检测异常。如果某个接口的行为突然变了，可能就是硬件要出问题了，系统可以提前预警，甚至提前隔离，避免故障扩大。

当然，这不是说动态架构没有安全挑战。恰恰相反，安全设计难度更大，因为状态变多了。但是，只要设计得当，动态架构能做到比静态架构更高的安全性。

五、当前产业实践：哪些玩家在走这条路？

讲了这么多原理和价值，我们来看一看，现在产业界进展如何？哪些玩家已经在往这个方向走了？

5.1 芯片厂商：从”固定分区”到”大一统算力池”

最积极推动这件事的，其实是芯片厂商。因为芯片厂商要卖更高性能的芯片，大一统架构更容易做大芯片，卖更高价格。

我们看几个典型：

英伟达Thor：我之前提到过，Thor就是一个典型的大一统SoC，754TOPS AI算力，整个算力做成一个资源池，可以动态分配给座舱、智驾、ADAS各个功能，支持硬件虚拟化隔离。这就是硬件池化的典型实践。

高通FlexGen：高通最新推出的中央计算架构FlexGen，核心思路就是把多个计算单元整合在一起，通过高通的NXP总线互联，实现动态算力分配。高通自己的宣传就是”软件定义的汽车”，支持动态负载管理。

地平线Journey 6：地平线最新的Journey 6，虽然还是主打智驾，但也开始支持多任务动态调度，可以把多余的算力分配给座舱或者其他AI任务，也是朝着池化方向走。

华为昇腾+麒麟：华为在智能汽车上的思路，也是中央计算+分布式执行，昇腾负责AI计算，麒麟负责CPU计算，通过高速总线连接，软件调度资源。本质上也是池化思路。

芯片厂商走得快，因为它们是架构革命的源头，硬件要先准备好，软件才能跟上。

5.2 新势力车企：探索中央计算+动态调度

接下来是新势力车企，它们没有传统架构的包袱，更愿意尝试新架构。

特斯拉HW 4.0：特斯拉是最早走中央计算路线的。HW 4.0的FSD芯片，就是一个大一统的计算核心，所有AI任务都在上面跑，软件调度。虽然特斯拉没有公开说”肌肉记忆”，但特斯拉确实在持续学习用户驾驶行为，优化控制策略，这其实就是一种肌肉记忆。

小鹏XNGP+中央计算平台：小鹏最新的XNGP架构，背后是小鹏自己研发的中央计算平台，把智驾和座舱的算力整合在一起，支持动态调度。小鹏也在做用户驾驶行为学习，个性化推荐，其实已经开始用到AI来优化骨架配置了。

蔚来NIO Adam：蔚来的Adam超算平台，用了四颗英伟达Orin芯片，总算力1016TOPS，软件层面动态分配给不同的智驾功能，也是池化思路。

理想AD Max：理想最新的AD Max架构，也是采用双Orin+orin，中央计算，动态调度。理想在交互个性化方面做得很多，其实就是在积累数据，为后续更深度的AI赋形做准备。

国内新势力在架构上都比较激进，中央计算是共识，剩下的就是怎么一步步把动态调度和AI赋形做出来。

5.3 传统车企：稳步跟进，试点先行

传统车企因为有庞大的存量开发体系，所以步子会慢一些，但也都看到了这个方向，在稳步跟进。

大众汽车的”软件定义汽车”战略，核心就是把EEA从分布式整合到域集中，再到中央计算，目标就是实现软件定义所有功能。大众投入了几百亿欧元研发软件，就是在为这个转型做准备。

丰田的”Arene”软件平台，也是朝着模块化、动态化方向走，支持OTA更新整个系统，包括底层架构。

宝马的”新世代”架构，从2025年开始，全面采用中央计算架构，软件定义所有功能，这也是在往这个方向走。

传统车企转型慢，但是它们资源多，经验丰富，一旦方向确定，推进起来也很快。

5.4 创业公司：聚焦关键技术，单点突破

还有一些创业公司，聚焦在AI赋形骨架的某个关键技术点上，单点突破。

比如，有些创业公司做汽车领域的服务网格，专门解决动态服务发现和流量调度问题，这就是动态重连的关键技术。

有些创业公司做AI驱动的资源调度，专门优化车载算力的利用率，这就是核心算法。

还有些创业公司做柔性语义接口框架，帮车企更快开发SOA服务，这就是接口柔性的基础设施。

整个生态正在慢慢形成，每个环节都有玩家在做。

六、挑战在哪里？五大障碍需要突破

前景很美好，但我们也要清醒地看到，这条路并不平坦，还有很多挑战需要突破。我总结了五大主要障碍：

6.1 功能安全标准跟不上技术发展

第一个挑战，就是功能安全标准跟不上。

现在汽车功能安全标准ISO 26262，主要是针对静态架构设计的。它要求你在设计阶段就要分析所有可能的故障场景，给出安全机制。但是动态架构，状态空间太大了，不可能在设计阶段把所有可能的动态组合都分析一遍。

这就带来一个问题：技术已经出来了，但安全认证过不了，没法上车。

怎么解决这个问题？需要标准组织更新标准，适应动态架构。同时，业界也在探索新的安全认证方法，比如AI辅助的形式化验证，运行时安全监控，这些新方法可能更适合动态架构。

这个过程需要时间，可能需要三到五年，标准才能跟上。

6.2 软件开发栈需要重构，迁移成本高

第二个挑战，就是整个软件开发栈都要重构，迁移成本很高。

现在汽车软件开发都是基于域架构的，每个域有自己的RTOS，自己的middleware，自己的开发流程。要改成池化架构，动态调度，整个开发栈都要换，从芯片驱动到操作系统到middleware到应用层，都要改。

这对于车企来说，迁移成本非常高，不是说换就能换的。所以，这个转型肯定是渐进式的，先从中央控制域开始，慢慢扩展到其他域，不可能一蹴而就。

6.3 实时性保障难度大

第三个挑战，就是实时性保障难度大。

动态调度肯定会带来一些额外的开销和延迟。对于智驾、动力控制这些对实时性要求非常高的功能，哪怕多几毫秒延迟，都可能出问题。

怎么解决？需要硬件和软件协同优化。硬件层面，更高带宽的互连，更低延迟的内存；软件层面，更聪明的调度算法，预测性调度——提前预测到接下来需要什么资源，提前分配好，这样就能把延迟降下来。

现在看，这个问题是工程问题，不是理论问题，慢慢优化总能解决。

6.4 碎片化的硬件生态

第四个挑战，就是硬件生态碎片化。

现在汽车上的硬件来自不同厂商，接口各不相同，要把它们都池化起来，统一调度，难度很大。每个硬件都要做适配，工作量很大。

这个问题需要时间解决，随着中央计算架构普及，越来越多硬件会开始支持标准化的池化接口，碎片化会慢慢改善。

6.5 用户信任问题：我的车一直在自己改，会不会改坏了？

第五个挑战，就是用户信任问题。

用户会问：我的车骨架一直在自己变，天天自己调整，会不会哪天调整错了，出问题？我怎么信任它？

这个问题需要透明化设计。系统要告诉用户，它调整了什么，为什么调整，用户可以看，可以改，可以回滚到原来的配置。用户有控制权，就会慢慢建立信任。

而且，AI赋形都是渐进式调整，每次只调一点点，试错没问题才固化，不会一下子大变样，风险是可控的。

七、未来展望：十年后的骨架是什么样？

展望一下十年后，AI赋形的骨架会发展到什么样子？我个人有几个判断：

7.1 整车级硬件池化成为标配

十年后，整车级的硬件池化肯定会成为标配。所有计算资源、存储资源都会放在一个大池子里，软件按需分配。所谓的域，更多是逻辑上的划分，不是物理上的分区。

芯片工艺进步，整合度越来越高，把更多计算核心放在同一个die上，成本越来越低，这为整车级池化提供了硬件基础。

7.2 AI会持续塑形，终生进化

汽车真的会变成活的数字生命体。骨架从出厂开始，就在持续不断地被AI塑形，持续形成新的肌肉记忆，持续进化，一直到汽车报废。

用户买的不再是一台固定的机器，而是一个持续成长的生命体。用得越久，它越懂你，越贴合你，价值越来越高，而不是越来越低。

7.3 出现”骨架即服务”商业模式

会出现新的商业模式——“骨架即服务”。车企不再只是卖车，还可以卖持续的架构优化服务，按月付费，持续给用户提供更好的骨架塑形，更好的肌肉记忆。

用户也愿意付钱，因为车确实越用越好开，体验一直在提升。

7.4 个性化程度远超今天想象

未来的个性化，远不止今天换个主题皮肤这么简单。你的车的骨架，就是为你一个人生长出来的，每个接口，每个连接，每个资源分配方案，都带着你的使用痕迹，都是你的肌肉记忆。

世界上没有两片完全相同的树叶，未来也不会有两辆完全相同骨架的智能汽车。每辆车都是独一无二的，因为每个用户的使用习惯都是独一无二的。

7.5 骨架进化会催生全新的设计方法

骨架进化也会催生全新的设计方法。原来的设计方法是”自上而下”——设计师在工厂里设计好一切，用户只用。未来会变成”自下而上”——设计师设计好规则和基础骨架，AI和用户一起完成最终的设计。

设计师从”造物者”变成”园丁”——种下种子，提供土壤，然后看着它生长，修剪它，而不是从头到脚控制每一个细节。这是设计哲学的根本转变。

八、结语：骨架进化是AI赋活汽车的必然一步

我们今天从一个很容易被忽略的维度——骨架——来看智能汽车的进化。大家都在关注AI算法、芯片性能、传感器这些看得见的东西，但是，支撑这一切的骨架，其实也在经历一场深刻的革命。

这场革命的脉络其实很清晰：

• 机械时代：钢铁浇筑的静态骨架，出厂即定型 →
• EEA转型：数字韧带连接的分区骨架，支持一定程度软件定义 →
• AI时代：AI持续赋形的动态骨架，自主形成肌肉记忆，终生进化 →

这是一个必然的进化方向。当AI开始进入汽车的核心，当汽车真的要变成会学习的数字生命体，骨架就不可能再是固定不变的。AI塑造了大脑和神经，自然也要塑造支撑这一切的骨架。肌肉记忆不是什么玄学，就是骨架在使用过程中不断优化、不断固化的结果。

对于用户来说，这场进化带来最直接的好处就是：你的汽车会越来越顺手，越来越懂你。它不仅仅是一台代步工具，真的会变成一个”活”的伙伴，陪着你一起成长。

对于产业来说，这场进化会带来整个价值链的重构。从芯片设计到整车研发，从销售模式到售后服务，都会跟着变。原来卖一次车赚一次钱，未来可以持续提供服务持续赚钱。原来车越用越贬值，未来车越用越贴合用户，反而可能更有价值。

当然，这条路还很长，还有很多技术挑战需要克服，标准需要更新，生态需要重构。但是，方向已经清晰了，走过去只是时间问题。

最后，我想用一个比喻来结束这篇文章：

一百多年前，卡尔·本茨造出了第一辆汽车，给了汽车第一个机械骨架。

今天，我们正在给智能汽车换上一副AI赋形的数字骨架。这副骨架会自己生长，自己学习，自己形成肌肉记忆。

当骨架活起来的时候，汽车才真正变成了有生命的数字生命体。

这就是骨架进化的终极意义——从机械到生命，这是智能汽车的必然归宿。