关于场景库&服务库的新灵感-CSDN博客

本文链接：https://blog.csdn.net/whyskysun/article/details/137962003

在SOA的话题中，提到过场景库与服务库的事儿。场景是积累出来的，而服务是迭代出来的，但仅以车厂或供应商的产品经理团队去推动这个事儿，在想象力以及更新速度上都受到“小群体”认识的限制，如何突破这个限制就是今天要聊的话题。

在有SDV（软件定义汽车）这个概念之初，就有大佬提出：“生态赋能”“共创应用”之类的概念，期望有更多的第三方开发者能够参与场景的设计，从而加快服务迭代速度，形成标准化的服务。

这个想法本身没有任何问题，只是忽略了第三方开发者参与的落地路径：

首先，第三方开发者参与汽车场景应用的开发是为了赚钱，但在标准服务形成之前，每一个场景创意的实现仅能为单个车型或单个平台车型使用，不同的服务抽象设计导致应用实现的碎片化，就像安卓应用为满足不同分辨率需要去适配多种版本一样，而车型的差异远比安卓手机的碎片化要严重得多，汽车数量也远远小于手机，这就使第三方开发者很难投入到这项工作中；

其次，验证过程的复杂性。就算是以“组合服务”的方式来实现的场景，也需要相对完整的实车验证过程，且用户实际使用体验的反馈也需要漫长的周期，从而使得场景创意设计的价值验证速度很慢，无法在短时间内形成大量的价值场景，更无法形成快速的服务设计迭代，进而影响了标准化服务的成型时间。换个简单说法就是：低效率的验证方式导致了服务标准化的无限延期；

最后是用户作为试错群体的容忍度。这种“共创应用”是否上车的判断权力最终还是属于车厂，由于受到车厂产品经理的认知限制，导致大量的体验和价值验证被传导至用户，从而让用户变成了测试人员。而汽车的使用与手机的使用有着巨大的场景差异，用户试错的容忍度也不可能像手机应用一样。一旦被用户厌恶，就会对整个场景化应用产生反感，导致长期的不信任（可以参考最初形态的语音输入导航目的地）。

以上问题仿佛让这个共创生态走进了一个死循环，直到上个月有朋友找我参与一个内部测试，突然让我产生了新的灵感。

某大学汽车专业发起了一个“汽车场景创意大赛”，要求参赛者讲明白在什么场景下，调用车上的什么功能，实现什么样的价值，并通过类似“场景编辑器”的工具将这个创意以“拖拉拽”的方式搭建出来用以展示……比赛的目的就是让学生在发挥想象力的基础上，了解车内功能，并通过搭建过程思考不同条件下的各种安全约束与功能约束，从而提前熟悉车厂的开发思维。

我参与测试的就是这个“工具”，工具本身与现在一些软件供应商提供的“低代码”场景设计工具类似，与其说更简单，不如说是更“简陋”，不过恰好满足学生群体的使用需要，毕竟所谓的专业工具在车厂的实际使用过程中，连专业的产品经理使用起来都有困难，而这种“简陋”反而达到了“上手即会”的效果。