（本文最初发表于Forbes.com）

车辆生命周期的每个阶段都运行着不同的软件。开发团队使用仿真平台；测试团队使用数据记录仪和验证套件；制造团队在各自的专用系统上进行生产线末端测试；售后服务团队则使用另一套诊断工具。每个团队都会根据自身特定领域的需求，选择合适的工具。

问题在于各个阶段之间以及跨阶段发生的情况，而不是阶段内部的情况。不妨将传统的车辆生命周期视为一场接力赛：开发阶段将工作交接给测试阶段，测试阶段交接给生产阶段，生产阶段再交接给服务阶段。在每次交接时，相关知识都必须重新整理或重建。往往情况比这更糟：各个阶段所使用的工具之间根本不会共享任何知识或经验。这会产生三项成本，且随着每次交接而不断加剧：

  1. 系统维护的开销会成倍增加，因为链条中每增加一个工具，就意味着需要额外为该系统办理许可、进行集成、打补丁并提供支持。
  2. 培训成本不断增加，因为新员工和跨职能团队在参与的每个阶段都必须学习不同的工具。
  3. 最重要的是，知识的连续性被打破了。工程师在开发某项功能时所处的背景，无法完整地传递给六个月后在实际环境中排查该问题的人员。

这一切都不是任何单个团队的失误。这是将设计、开发、测试、生产和支持视为五个独立的工作流程，而非一个连续过程所带来的结构性成本。对于原始设备制造商（OEM）而言，这种成本体现在每个阶段都增加了额外的时间：开发速度变慢、测试速度变慢、故障排查速度变慢——此外还有工作重复，以及机构知识在团队之间交接时流失。

此前是什么原因导致统一难以实现

在软件发展史的大部分时间里，将这些工具统一起来并不现实。软件都是针对特定目的而开发的。测试工具旨在验证系统在定义好的条件下是否按预期运行，而诊断工具则用于在出现故障时定位故障的根本原因。要让其中一种工具承担另一种工具的职责，就意味着需要重写大量代码。如果工程师想移动一个按钮或更改一个工作流，这就需要经历一个完整的开发周期。

AI 这一局面正开始发生改变，因为在这些阶段中，基于代理的AI 解决方案越来越共享同一基础。测试工具底层的大型语言模型（LLM），从根本上说，与现场诊断工具底层的模型并无二致。无论是发布前分析验证测试用例，还是售后排查客户问题，进行推理的AI 都是同一个。唯一变化的是周围的上下文。

与其为每个领域构建独立的系统，组织不妨将同一套基础智能扩展至开发、测试和服务环节，从而适应各团队的具体情况，而无需每次都从零开始。这就是Sonatus Fastlane™ Platform， 这一闭环AI 平台，能够将车辆数据和知识从生命周期的一个阶段传递到下一个阶段。这与行业以往的起点有着实质性的不同，尽管大多数组织目前仍处于付诸实践的初期阶段。

最难的工作在于组织方面

整个行业已显现出这一趋势的早期迹象，即使目前一些组织可能仅实施了其中一两项措施：​

  • 将现场故障更直接地纳入空中更新周期，利用车载AI 等技术，例如Sonatus Fastlane™ Edge ，有助于实现从问题发现到修复方案部署的闭环管理。
  • 将服务台的知识反馈到下一车型年的设计和测试标准中，而像 Fastlane™ Insight 此类工具便能将诊断结果转化为工程团队可付诸行动的洞察
  • 利用生产车间的异常数据，对不同供应商的零部件质量进行比较。
  • 探讨开发阶段的验证数据能否随车辆一同传输，以加快车辆投入运营首日的故障诊断速度，并借助AI 提供的车辆上下文信息支持，该信息来自Sonatus Fastlane™ Collector提供的xml-ph-0000@deepl.internal辅助车辆上下文信息。

目前这些问题在任何地方都尚未得到彻底解决，但这预示着，一旦工具不再在每次交接时重置，该行业将朝着哪个方向发展。​

这也不仅仅是更换软件的问题。在生命周期的各个阶段实现工具统一，通常意味着要将多年来独立运作的各个团队在所有权、预算和流程方面统一起来。这既是一个技术挑战，也是一个变更管理方面的挑战。那些将此单纯视为工具选择问题的组织，很可能会发现，真正困难的工作其实在于组织层面。

制定统一战略

根据我的经验，此类组织转型通常遵循以下几个核心原则：

  • 将统一作为全公司范围的战略。数据、知识以及AI 的统一必须是领导层下达的指令，而非由单个团队负责的项目。
  • 在流程的每个阶段指定推动者。该工作需要在开发、测试、制造和服务等各个环节都配备推动者。
  • 确定哪些内容应属于共享上下文。并非 所有数据、知识或成果都需要在各个阶段之间传递，但正确的信号必须传递。
  • 首先针对一两个用例实施AI 解决方案。这些用例 应特别利用整个生命周期中的双向知识流动，而不是一次性全面部署。
  • 将早期的实现视为起点。 从中吸取经验 ，不断迭代和扩展。

为什么此事刻不容缓

应对这些工具的压力与日俱增。随着车辆日益向软件定义化转型，迭代速度不断加快，孤岛式工具带来的成本也在不断攀升。每增加一个特定阶段的专用工具，就意味着机构知识被困在另一个环节，需要维护的集成点又增加一个，从发现问题到实施修复之间也会产生新的延迟。

要弥合这一差距，关键在于在每个阶段都使用相同的工具——或者至少是相同的底层智能。那些能够将设计、开发、测试、生产和支持视为一个连续的系统，而非五个独立职能的企业，将获得结构性的竞争优势：​

  • 由于前一阶段的洞察能更快地传递到下一阶段，因此能更早地发现问题。
  • 由于数据和上下文得以沿用，因此可以减少所需的实体测试车辆数量以及重复的验证工作。
  • 缩短现实世界信号与已实现解决方案之间的距离。