安德斯·贝尔指着自己的白发笑道："三年前，它还是金色卷发。"这位沃尔沃首席工程与技术官的自嘲之语，远不止是一句玩笑。它真实折射出沃尔沃这五年的历程：作为一家传统汽车制造商，在没有任何蓝图、没有任何供应商可以依赖的情况下，从零开始打造一款软件定义汽车（SDV）。

EX60是一款中型纯电SUV，于2026年1月在斯德哥尔摩正式发布，搭载沃尔沃全新电动车架构SPA3。今年4月，首辆量产客户车型在哥德堡托斯兰达工厂正式下线。这也是第一辆完全基于沃尔沃自研计算平台HuginCore打造的车型。

标普全球出行将沃尔沃评为软件定义汽车能力的最高等级——Level 5，使其成为全球唯一达到这一级别的汽车制造商。贝尔用一个生动的比喻来描述这段历程："把一块木炭放在高压下反复锤炼，直到它变成钻石。现在，我们正在打磨这颗钻石。"

HuginCore的核心是一套统一的软件主干：单一代码库，按车型配置，在平台上所有车型之间共享。开发者在修改某项门锁功能时，代码并不直接提交给EX60，而是提交到主干库，再从主干库配置到每一辆车上。

EX60是在该主干上运行的第三款沃尔沃车型，此前已有EX90和ES90。每一款车型的投入使用都进一步强化了代码库。贝尔说："这正是苹果的做法，也是微软的做法。如果你想在软件领域做到卓越，就只能有一套代码。"

从真实用户体验中汲取的深刻教训

平台上的首款车型EX90在上市初期经历了一段艰难时期。自动化测试未能发现的问题在实际使用中暴露出来，直接影响到了用户体验。"这是一段艰难而痛苦的历程，"贝尔坦言，"公司内部的磨砺我不在乎，但一旦波及到用户，就令人遗憾了。"

自研计算平台也深刻改变了沃尔沃与供应商的合作模式。传统的一级供应商通常交付完整的电子控制单元（ECU），硬件与软件打包提供。而在HuginCore体系下，沃尔沃自主研发区域控制器，并自行集成供应商软件。

"我们不是直接从博世拿来一个现成的ECU，"贝尔说，"我们必须与他们深度协作，把他们的软件集成到我们的区域控制器上，确保整个系统在车辆中协调运行。"

"我绝不会在220万辆车上直接按下按钮就一键推送。一次可以重试的失败更新没什么大不了；但一次导致车辆无法启动的更新，就是灾难。"——安德斯·贝尔，沃尔沃

这种转变赋予了沃尔沃对集成层的掌控权，而这种掌控所带来的影响，远比架构图上呈现的更为深远。

贝尔以一个具体案例加以说明。在极寒环境下（约零下25℃），电池需要防冻保护。传统方案是安装一个独立的电加热器，成本约150欧元。沃尔沃则提出了一个不同的问题：能否让电机在极寒条件下以略低的效率运行，从而主动产生热量？

答案是肯定的。独立加热器因此被取消。"我们测算，在电机上增加约8欧元的零件，就能省去其他地方150欧元的部件，"贝尔说。

这类跨系统优化，只有当不同工程领域的人坐在同一张桌子旁，将整辆车视为一个集成系统而非独立模块的组合时，才有可能实现。贝尔表示，在旧有的组织架构下，这样的对话根本不会发生。

产品发布必须达到令人惊艳的水准

单一软件主干在部署层面的实际意义十分清晰。沃尔沃目前正在向220万辆最早可追溯至2020年的车型推送一次统一的人机交互界面更新，为这些早在大语言模型诞生之前就已出厂的车辆带来标准化界面与谷歌Gemini对话式AI。

"2020年造那些车的时候，我们完全没想到，到了2026年，会在同一辆车、同一套硬件上推出对话式AI，"贝尔说，"2020年我们甚至不知道大语言模型是什么。"

软件定义的产品永远没有"完成"的那一天，总有更多功能等待集成与添加。但总会有一个时刻，你决定它已经足够好，可以发布了。贝尔的判断标准很务实："发布的时候，它必须足够出色。"而在那个时刻，它确实做到了。

但开发不会就此停止，今天令人眼前一亮的功能，五年后可能已显陈旧。贝尔认为，这不是问题，而恰恰是这件事的意义所在。目标不仅仅是在购车那一刻满足用户，而是在此后持续带给他们惊喜。如今推送至2020年出厂车辆的对话式AI，正是这一理念的体现。

这些部署背后的工程逻辑同样值得关注。沃尔沃每天构建20个完整的软件版本，每四小时筛选出最优候选版本，在测试台架上进行全天候自动化整车测试。用户每季度收到一次实质性更新。

针对220万辆车辆的更新成功率要求达到99.9%或以上。贝尔对这个数字有着清醒的认知：220万辆车中0.1%的失败，仍意味着超过两千辆车出现问题。

"我绝不会在220万辆车上直接按下按钮就一键推送，"他说。贝尔关注的不是那99.9%，而是那0.1%。即便在这一小部分中，也有严格的区分。"一次可以重试的失败更新没什么大不了；但一次导致车辆无法启动的更新，就是灾难。"

当监控数据显示某一特定市场或车型变体出现故障集中现象时，该群体的推送会立即暂停，其余车辆继续更新。问题修复后，该群体才会收到更新。贝尔说，每一次部署都是一次精密行动。而在这种规模下的精密，需要真正理解自己在构建什么的人才来支撑。

汽车软件开发人才极为稀缺

人才问题是结构性的，贝尔对此并不回避。"我们现在所做的汽车软件工程，从规模化角度来看，基本上是一个只有五年历史的新兴学科。所有人都在争夺软件定义汽车领域的领军人才，但这样的人才根本不存在。"

这不是在抱怨劳动力市场，而是在描述一个几乎尚未成型的学科现实。为一辆两吨半重的车辆编写符合ISO 26262功能安全标准的安全关键代码，与开发消费类应用程序截然不同。

背景不同，约束不同，出错的后果也不同。"这不仅仅是把软件工程师招进汽车公司那么简单，不只是会写代码就够了，关键是要在汽车的背景下写代码。"

沃尔沃自己构建了这套环境。工具链、测试基础设施、代码库结构、跨八代芯片和四座工厂配置单一代码库的流程——这一切都没有现成的解决方案可用。"我们起步时什么都没有，"贝尔说，"没有任何一级供应商可以打电话购买现成方案，所有东西都必须自己创造。"

这也解释了为何公司需要投入大多数组织难以接受的资源。沃尔沃在哥德堡的软件测试中心占地2.5万平方米，耗资约2600万欧元。即便如此，贝尔从过去五年中总结出的最重要的一课仍然是："早点开始。不要低估这项工作的体量。"

HuginCore是这一投入的核心，但它并不意味着沃尔沃可以完全独立。该平台运行于英伟达的Drive AGX Orin系统级芯片和高通的骁龙座舱平台之上，并集成了谷歌的AI能力。

贝尔坦然承认这种依赖关系的张力，并没有试图回避。"依赖别人，从来都不是件舒服的事。"他认为，长期协议和应急规划才是答案，而非一路向下追求垂直整合。"技术在演进，我们也会随之演进。"

更深层的问题在于：自研与共享之间的边界该如何划定。贝尔认为，软件栈的底层——网络安全、更新管理和基础设施——最终将走向商品化。

"你是否需要事事亲力亲为，还是可以采购更大模块，与其他车企共担这笔投入？我认为这是有意义的，"他说。这个问题在汽车行业尚未有定论，在企业IT领域同样如此。

聚焦项目节奏与充分准备

对于汽车行业以外的技术领导者而言，贝尔的核心经验并不在于技术本身，而在于节奏与准备。"进场前先深呼吸。不要企图一口气做太多。不要在第一个版本上设置过于激进的时间表。在确定产品规划之前，先做好基础的概念验证。"

他还特别提到了组织规模这一鲜少被坦诚讨论的因素。在贝尔看来，沃尔沃大概是西方世界规模最小的独立汽车开发机构。"我们足够大，能够理解所需的规模化程度；但我们又足够小，不会陷入体制僵化，不会被委员会议拖住脚步。"

这种平衡难以复制，但其背后的原则适用于任何一个组织——只要软件转型必须在硬约束下快速推进，且其后果远不止于屏幕之内。

在金融服务、医疗健康和关键基础设施领域，这套方法论同样适用。"我们无法指着任何人说，'嘿，我们应该学他们，'"贝尔说，"我们必须走自己的路，走一条没有人走过的路。"

这颗钻石尚未打磨完成，但打磨正在继续。

Q&A

Q1：沃尔沃的HuginCore平台是什么？它有什么特别之处？

A：HuginCore是沃尔沃自主研发的车载计算平台，其核心是一套统一的软件主干——单一代码库，按车型配置，跨平台所有车型共享。开发者提交代码至主干库，再由主干库配置到每辆车，这与苹果、微软的软件管理思路一致。沃尔沃因此成为全球唯一获得S&P Global软件定义汽车最高评级Level 5的汽车制造商。

Q2：沃尔沃是怎么向220万辆老车推送AI功能的？

A：沃尔沃通过HuginCore统一软件主干，向最早可追溯至2020年出厂的220万辆车辆推送人机交互界面更新，带来标准化界面与谷歌Gemini对话式AI。每天构建20个软件版本，每四小时自动化测试一次，用户每季度收到一次实质性更新，成功率要求达到99.9%以上，并对异常市场或车型实施分组暂停机制，确保部署精准可控。

Q3：汽车软件工程师为什么这么难招？

A：汽车软件工程是一个从规模化角度看只有约五年历史的新兴学科，行业内真正具备经验的领军人才极为稀缺。为重达两吨半的车辆编写符合ISO 26262功能安全标准的安全关键代码，与开发普通消费类应用截然不同，需要在特定的汽车工程背景下理解约束条件与后果。沃尔沃的解决方案是从零开始自建工具链、测试体系和工程流程。