蔚来面对软件定义汽车：OTA带来新功能，也把质量考验推到了交付之后

以前汽车的交付就是指一套比较固定的车子完成；目前，智能汽车交付之后仍然会不断进行更新。手机远程控制车辆、车机功能不断更新、辅助驾驶能力持续提升，这些变化使得汽车越来越像一台可以“成长”的机器，也使一个问题变得无法回避：用户买到了的是完成度更高的汽车还是没有完成的汽车？是代替汽车制造商来做一部分测试工作吗？

这并不是对智能化持否定态度，而是告诫汽车制造商，在软件更新方面可以一直进行下去，但是安全以及基本的质量却不能用“以后会改进”的理由来搪塞。

01. OTA解决了什么，也改变了什么

OTA的价值非常直观。以前发现车机逻辑、交互功能或者部分控制策略存在缺陷时，一般要回到店里进行处理；目前很多软件层面的修改都可以用远程更新的方式来做。对汽车企业而言，这样可以提高产品的更新换代的速度；对消费者而言，就是说车辆不会在交付当天就停止进化。

但是软件可以更新，并不意味着所有的故障都必须通过更新来解决。

车机界面不顺手、功能入口不合理，属于可以经过版本更新来逐渐改善的问题；对于影响行车安全、车辆控制、关键信息提示等问题，其性质完全不同。前者可以接受产品的不断打磨，后者则要在交付之前就建立起足够的验证标准。

汽车和手机不一样，在系统出现故障的时候，并不是只有几秒钟的卡顿，还会有真实的道路风险。**

 

这是“软件定义汽车”最容易被人误解的地方：软件使汽车具有了不断进化的功能，但是不能成为减少初始完成度的要求理由。

02. 用户可以接受更新，但不该被迫接受试错

消费者并不是不愿意进行升级。很多用户都愿意去体验新的功能，也会尝试更加好用的交互方式。最容易引起人们不满的是，在更新的内容与更新的风险之间没有被说明清楚。

一次OTA到底给用户带来了哪些变化呢？哪些属于功能增强，哪些属于逻辑变更？会不会影响到原来的操作习惯呢？当出现异常的时候，用户能不能够迅速地恢复过来？这些问题就决定了更新的服务还是负担。

尤其是随着汽车越来越依靠软件的时候，用户所要的是一个“新增功能”的清单，并不是清楚的变更边界。新的功能可以稍微推迟一下，但是和安全有关的功能必须要经过严格的测试之后才能使用；界面可以逐步进行优化，但是不能让使用者在更新之后再重新学习重要的操作。

 

用户愿意为持续升级买单，但是不愿意为不透明的试错买单。**

不能因此就说所有的智能汽车都有严重的质量问题，也不能因为车辆增加了很多电子功能，就直接得出结论，“小毛病一定更多”。更准确的说法是：系统的复杂程度越高，潜在问题的种类就越多，汽车制造商就应当把测试、回滚、提示和售后机制做得很完善。

03. 真正的竞争，不只是功能数量

智能汽车发布会通常会因为新的功能而受到关注：大屏幕、多样的语音交互、复杂的场景联动和不断增加的辅助驾驶能力。但是功能越多并不一定代表产品已经很成熟了，更新速度快也不一定就代表用户体验好了。

最后的一辆车要面对的就是高温、低温、雨雪、堵车、长距离行驶以及各种不同的驾驶方式。软件要能够在这样的环境里保持稳定，而硬件也必须能够承受长时间的使用。车辆内部的零部件、安全测试以及碰撞表现等，依然是汽车产品最基础的部分，并不能因为“智能化”这三个字而被掩盖过去。

 

从这个角度来讲，智能汽车的质量不应该仅仅依靠“能不能增加功能”来判断，还应该考虑“出了问题能否及时发现、准确说明、有效处理”。这就需要汽车企业建立起更加严格的企业内测，并且在产品发布的时候少一些功能炫技，多一些对于使用边界的规定。

如果一个功能需要通过大量的真实的用户的反馈来找出最基本的问题，那么这样的功能就不可能以成熟的商品的形式出现。用户可以参与到改进当中去，但是不能在不知情的情况下成为主要的测试环节。

04. 车企该把“持续进化”说清楚

软件定义汽车的未来不是不更新了，而是要使更新更加值得信赖。汽车制造商可以选择保持快速迭代的优势，也可以把不同的功能分出等级来：哪些是体验优化的内容，哪些涉及到对车辆进行控制，哪些又会影响到对安全状况的判断。距离安全底层功能越近的地方，就越不能用“以后再升级”来回答。

对于消费者而言，在选购智能汽车的时候，并不需要仅仅看功能的数量。更值得我们关注的是汽车厂商是否愿意公开更新的内容，有没有一个稳定的信息反馈渠道，在出现问题的时候能否给出明确的解决方案，并不是把所有的缺点都包装成“正在改进中”。

汽车也可以像软件一样不断进化，但是它不能像试用版那样把风险推给消费者自己来承担。**

蔚来和其他智能汽车品牌所要证明的并不是可以再增加哪些功能，而是在交付之后能不能保证这些功能仍然可控、可解释、可负责。

你会选择哪种情况：功能减少但是交付的时候更加完善，还是功能不断增加的同时也接受一定的后续优化？