1. 车载语音助理的产品分工
1）声学交互PM
通过制订应用语音识别技术时的一些策略，来实现端上的一些产品特性。声学交互PM有点类似传统互联网的策略PM，但需要PM对语音识别的各项技术及其应用的场景较为了解。
2）客户端PM
主要对语音助理框架性的交互（GUI及CUI）体验负责，过程中，往往需要形成一套交互规范供技能PM参考，保证端体验的一致性。语音客户端PM相比于传统互联网的客户端PM，除了要对GUI交互熟悉之外，更需要对CUI交互有独到的理解。
3）技能PM
基于Bot Framwork，设计各个技能的意图、会话及服务，来实现端上的一些产品特性。技能PM需要对语义技术、语义设计有自己的理解，同时在服务设计上需要对CUI交互有自己的理解。
如果将语音助理比作一座大厦，那声学交互PM就像是负责打地基的，提供了最基础的语音交互能力；而客户端PM，则像是用钢筋搭起了整个建筑的框架；而技能PM，则是用混凝土们将整个建筑填充的更加丰满。
2. 车载语音助理的产品需求
由于声学交互PM、客户端PM和技能PM的分工不同，他们的需求文档在需求内容方面的侧重就有所不同。
1）声学交互类需求
这类需求，首先对技术提出了能力方面的要求，其次选取合适的场景将能力落地，形成一定的语音交互上的产品特性。
一方面，产品需要在需求文档中说明“要运用的技术需要达到的能力”，并将这个能力包装为接口，指定相应的输入和输出，同时规定一些性能指标。另一方面，产品也会结合一些场景，制订一些策略，从而产出一些新的交互特性。这些特性，往往可能不是由一个单一的技术来实现的，可能需要将多种技术综合应用。
例如，语音助理的多音区，其实包含了两种技术能力。首先是声源定位，即分辨车内发音人的来源是在主驾、副驾还是后排，其次是波束成形，即可以只对唤醒人所在方向进行收音，对过程中非唤醒人的声音信号进行抑制。在这个能力上，产品可以指定将多音区的声源定位能力加入车控指令，从而实现副驾说打开车窗，仅开启副驾侧车窗的特性；也可以指定将多音区的波束成形能力接入语音交互的流程，使得主驾唤醒之后只接收主驾的指令。
2）客户端类需求
一般来说，语音助理是围绕一个bot来运作的，这个bot接收文字输入，输出语义或服务结果，过程中可能会涉及到多轮和应答。
而客户端类需求，就是针对bot从输入到输出的整个过程去定义框架性的交互体验，同时，还会涉及到一些端上常规模块的功能设计。
首先，需要定义bot接收文字输入前所有流程的设计，主要是唤醒和识别流程中的GUI和CUI设计，以及过程中的异常流程处理，例如用户不说话时如何处理、超时时如何处理、网络异常时如何处理等。
其次，需要定义在bot运行过程中，包括语义解析、多轮会话及相应多轮应答以及最终输出语义及服务结果时所需的框架性GUI设计，如显示区域定义、显示模板定义、GUI交互定义等。
值得指出的是，这两部分需求的提出，往往伴随着设计规范一起产出。对于GUI而言，类似于传统互联网的客户端PM，需要给出整个界面的原型设计，不同的是，这里往往需要给出模板化的设计，来尽可能的满足各类场景下GUI展示的需要。CUI方面，会给出回复语设计应该遵循的一些原则，例如合作原则、礼貌原则等，同时，也会根据语音助理的设定提一些语气方面的要求。
最后，是语音助理客户端上一些常规模块设计。例如用户登录、设置、帮助等，而后者和传统互联网产品基本上是一致的。
3）技能类需求
这类需求侧重于技能相关的语义 、会话及服务设计。
语义设计，分为语义表示定义、模板定义和语料定义三个部分。
语义表示定义，即定义技能所属领域Domain、领域下的意图Intent、意图内的参数Slot以及参数对应的实体。
例如，为了让语音助理听懂并回答“今天天气怎么样？”这一问题，技能PM需要设计一个天气查询的技能，定义它属于语义所属的领域 - 天气、意图 - 查询天气，定义用户query中可能会出现的参数 - 地点、时间等，同时还要定义参数对应的实体库。
