大家好！今天让小编来大家介绍下关于儿童类语音产品设计方案_儿童类语音产品设计方案怎么写的问题，以下是小编对此问题的归纳整理，来看看吧。

文章目录列表:

• 如何设计幼儿园语言领域活动方案
• 电话手表十大排名
• 一段声音的旅程（八）语音的唤醒与识别
• （转）设计一个语音交互界面(Voice User Interface)

如何设计幼儿园语言领域活动方案

一、 活动名称： 写清楚语言教育活动的具体类型，适合于何种年龄阶段，具体内容是什么。如：大班诗歌：摇篮
二、设计思路：简略概括本班幼儿语言发展水平、教材特点、活动中准备运用的方法和手段以及期望达到的教学效果。【也叫设计意图，可写可不写】
三、 活动目标： 写清楚通过本次活动应达到的具体目标要求。【很重要！！关于目标应该怎么写，请参阅文后“制订教育活动目标的原则”】
四、 活动准备： 写清楚本次活动需要为幼儿做好的准备，包括幼儿知识经验准备和物质准备、环境创设等。
五、 活动过程： 一个经过精心策划的完整的活动过程在书写形式上应表明活动的起点和终点；清晰的活动过程步骤以及与这些步骤相关的内容和组织形式；需要重点提出问题。
六、 活动延伸： 设计出本次活动在集中教学之外扩展和延伸的具体方式和要求，如其他领域中的渗透、活动区活动、户外游戏活动、家园配合等。
七、 活动评价： 设计好评价的标准和范围，增加语言教育的科学性和有效性，以便具体的教育活动结束后及时进行评价。
教育是可以预见其结果的一种实践活动，但也是一种具有随机创造性的实践活动，语言教育活动方案设计千万不能成为具体实践的桎梏，而应成为教师产生再创造的温床和土壤，那种将教师如何提问，幼儿如何回答的详细内容全都设计出来的做法是不可取的。
∏制订教育活动目标的原则
1.目标应着眼于学前儿童的发展。包含着两层意思：一是目标的制订应适应学前儿童已有的发展水平，符合学前儿童语言发展的规律；二是目标的制订应将促进学前儿童的语言发展作为落脚点，落实到学前儿童对语言内容、语言形式和语言技能的掌握上。应该基于幼儿的年龄特点和已有的生活经验，并能促进幼儿在原有水平上的提高。
2.活动目标的内容和要求，在方向上应与总目标、年龄阶段目标相一致。活动目标要为阶段目标和终期目标服务，总目标和年龄阶段目标要通过一个个具体的活动目标落实在每个学前儿童身上。要根据学前儿童的年龄特征和发展水平，由浅到深、循序渐进地提出目标，使学前儿童从具体到抽象，从直接到间接地获得语言经验。应参照活动所属类别的总目标。比如，小班故事活动的目标表述就应参照小班文学活动的总目标。特别注意：指南目标是年龄段末期的典型表现。
3.目标的内容应包含认知、情感态度和能力三个方面。第一，应涉及到知识概念的学习，包括所获得知识的数量和种类，以及操作这些知识的技能和能力；第二；情感态度的培养，包括兴趣、态度和价值观等方面的变化。第三，能力的训练，包括组词成句的能力和在具体语境中运用语言的能力。
4.语言教育活动目标的表述应该采用特定的术语。教育活动目标通常可以用儿童学习行为变化进行表述。一个恰当的目标应能成功地向别人表达教师的教育意图，应便于观察者在活动后通过学前儿童的行为变化加以评价。站在幼儿的角度而不是教师的角度来表述目标。如“能”而不是“引导，帮助,培养,鼓励”。
5.目标应该是活动中确实想要达到即可行性的要求，而不是大而空的套话。

电话手表十大排名

电话手表十大排名：

1、华为／HUAWEI

华为／HUAWEI成立于1987年中国，隶属于华为技术有限公司，位居全球第三，华为手环除了含有通话功能以及平常基本功能之外，还可以提供个性化的运动，睡眠方案。

2、小天才

中国知名早教品牌，隶属广东小天才科技有限公司，专注儿童市场广东会产品研发与销售，致力于提供引领儿童时尚潮流的智能产品，陪伴孩子快乐成长，成为儿童向往的领导品牌。

3、小米

小米成立于2010年中国，旗下产品涉及手机、家电、智能终端等。“让每个人都能享受科技的乐趣”是小米公司的愿景。小米公司应用了互联网开发模式开发产品的模式，用极客精神做产品，用互联网模式干掉中间环节，致力于让全球每个人，都能享用来自中国的优质科技产品。

4、糖猫

糖猫始于2014年3月，是搜狗公司孵化的广东会业务，也是搜狗面向未来，在“智慧战略”的前提下，围绕大数据和“互联网＋智能硬件”所进行的重要布局。

5、咪咪兔

MIMITOOU成立于2012年。专注于儿童手表的设计，其品牌以款式新颖，设计大方，颜色搭配出色而受到了许多人的喜爱。

6、阿巴町／ABARDEEN

中国儿童智能穿戴行业优秀品牌，隶属深圳五洲无线技术有限公司，2016年上市，专注于儿童穿戴、娱乐、幼教、健康中高端智能产品。

7、读书郎／READBOY

中山市读书郎电子有限公司，学习机知名品牌，点读机知名品牌，广东省高新技术企业，广东省著名商标，广东省优秀民营科技企业，广东省自主广东会优势企业，国内最具实力和品牌影响力的教育电子产品制造企业之一。

8、ticwatch

Ticwatch成立于2014年，全球知名智能手表品牌，由顶尖设计公司frog挑梁设计，2015年首次推出智能手表则大受欢迎，目前每款手表都具有优雅圆润的特点，并且搭载了中文手表操作系统Ticwea r，具备人工智能语音交互。是谷歌投资的人工广东会公司，搭载Ticwear人性化操作系统，为用户带来真正快捷、优质、人性化的AI交互体验。

9、kido

Kido专注于儿童穿戴领域，是全球首款4G儿童手表研发者，领先行业1年，国内首家获得4G儿童手表入网许可证的品牌。专门为儿童开发出一套适合孩子操作的系统。有问必答的Al机器人，陪伴孩子健康成长。

10、天摩／TOMO

TOMO，源自纳维亚的时光传奇，天摩实业（中国）有限公司旗下的时尚腕表品牌，现拥有TOMO classics与TOMOSports两大系列，其代表着香港钟表老厂60年精艺的匠心传承。2014年初，正式推出全新子品牌——TOMOspor ts，形成TOMOclassics经典腕表与TOMOsports运动腕表两大产品线。

一段声音的旅程（八）语音的唤醒与识别

童鞋们好，我们花了六篇篇幅聊的信号处理终于告一段落啦~今儿我们要翻篇，讲一讲语音的唤醒与识别。

前几篇讲的信号处理环节，主要是硬件、空间、腔体等的信号落地工作，我们称之为“硬落地”。特点就是，在适配过后的信号处理五大因素中有任何一个发生不可忽略的变化，都建议再适配一遍，我们称这个适配调优的工作为“tuning”。一般来说，tuning过的硬件，直到硬件生命终结，都不需要再做第二次（当然，如果第一次tuning没做得足够好就量产出去了，那纯属自己作，要返工也是很有可能的，未来讲“迭代”的时候再细说这个点。 个人观点：特别不建议在tuning没有做好的情况下就发布产品 ）。这之后的ASR、NLP、TTS、DM的落地工作，都属于“软落地”。

这样分类有什么实质性意义吗？自然是有的。硬落地主要针对不同的硬件不同的使用场景，而软落地主要针对不同的人不同的功能需求。两个方向所需要的人才是不一样的，投入产出也是不一样的。这里主要分为三种情况：

如果一个team定位自己只针对一款硬件做语音产品，比如一款品牌音箱，那他们只需要把这款音箱tuning好。除非后面要改ID设计，否则负责硬落地的同学后期基本就没啥事儿可干了。但是音箱从被卖出到它报废之间的整个生命周期，产品都要不断迭代，功能也要不断丰富，运营、商业、服务等等都要接踵而来。所以相比起来负责软落地的同学，可能就要忙到飞起来。

如果一个team定位自己是做硬件语音方案的，需要给那些做品牌音箱的提供整体解决方案，那么他们需要根据每一款客户的ID设计和使用场景去做tuning。这种情况下负责硬落地的同学，嘿嘿，你们的好日子就到头了，准备和老婆孩子热炕头say good bye几个月吧。同时因为team是提供解决方案，软产品的设计和定制往往是客户自己独立完成独立开发的，所以负责软落地的同学此时就可以放飞自我哪儿凉快哪儿玩儿去了。

当然，还有两者皆投入的team，也就是当前比较热门的 toBtoC（2B2C）模式。toB做项目落地，toC做用户体验。语音公司大部分都是2B2C的商业模式；

所以， 企业如果需要做语音产品，自身定位很重要，因为这涉及到整个 team 的人员结构和人才需求。不要盲目去抄袭语音公司的人员结构和人才定位，根据企业自己的定位和规划，按需要求人才，按规模定人数，做好人效供求的管理 ，不然到最后，有些人就会是这样的——

而有的人，又会是这样的——

显然，如果出现上述情况，很容易导致团队里负能量爆棚，事儿也就基本不可能做好。

语音识别是近几年非常火热的词，应该也是大家最熟悉的部分了，语音识别的核心任务，是音频转写成文字，看似简单无奇的这么一个环节，真的要用好是非常不容易的，我们先聊聊这个大环节里的细节吧。

假设一个场景：

哼哼：“唉半仙，几点啦？”，（我听到哼哼在后面喊我，我回过头看着她说）

秋半仙：“咋啦？”，

哼哼：“死鬼，问你现在几点了，我没带手机。”（我看一下手表，告诉她结果）

秋半仙：“哦，下午五点了。”

对话结束。

生活中，如果你要找一个人说事情，一般走过去第一句话应该是先“打招呼”，对方有所回应之后，才开始真正的对话。

这个场景中，在哼哼还没有喊我之前，我在“等待有人唤醒我”，我们称这个状态为“监听”状态。可以形象的理解为，此时，我在监听身边所有的声音，等待有广东会我“打招呼”。当哼哼说出“唉半仙”时，我意识到有人在找我，相当于此时我被激活了。我们把这个行为称为“唤醒”，把“唉秋半仙”称为“唤醒词”。唤醒之后，哼哼说出了自己的诉求，这里开始就是正常的“识别”了。

唤醒与识别

“唤醒”和“识别”是有很大的不同的。”监听“状态时，我们是不知道用户会从哪个地方来”唤醒“语音产品的。而一旦唤醒之后，我们是可以通过很多技术手段，比如前序文章中提到的”定向抑制“，排除掉其他区域的干扰，从而提升用户的语音体验。我们举个车内主副驾的例子，因为使用语音的既可能是主驾，也可能是副驾，所以，“监听”时两边都要监听着。如果副驾的同学此时正在打电话，你在主驾位置上唤起语音，那么副驾同学打电话的声音是会严重干扰你使用语音的。此时，可以抑制副驾声源，从而保障主驾的产品体验。

——“半仙，既然语音设备可以定向抑制，那也一定可以定向拾音吖，为什么不能主副驾都识别，根据具体的意思来决定用哪一个呢？”

——“哎，各位童鞋看看哈，这位童鞋能提出这种问题，说明他已经可以开始能跳出框框来思考产品了。这种思考方式应该保持，其他童鞋也要多向他学习哈~”

上面的这个问题的主因是系统的资源消耗。同时处理多路还要保证语音的实时性体验，对系统带来的消耗太大。另一方面，就是“根据意思来决定”这点很难具体定义“什么意思该使用哪个”，到最后可能会以“唤醒者”的内容优先考虑做为仲裁的核心依据，那牺牲大量的硬件资源的意义就大大减弱了。从产品落地和投入产出比的角度去考量，会退而求其次，这也是为什么今天很多概念demo和落地产品之间会有差异）。

“唤醒”是激活语音的其中一种方式，从产品设计来看，激活语音有七种方式：

1. 主动唤醒。就是前面说的，在”监听“状态，通过唤醒词“唉半仙”来唤醒，唤醒之后，语音会有所反馈，比如“你好吖”、“有什么可以帮你的”，引导用户进入“识别”状态。

2. OneShot。前面的主动唤醒，是在唤醒之后要等待反馈再说指令，oneshot则是将“唤醒”和“识别”组合在一句话里说，比如“秋半仙，现在几点了？”，一句话完成。

3. 快捷唤醒。这个和主动唤醒的逻辑基本是一样的，区别在于：主动唤醒是激活语音等待用户说指令，快捷唤醒是激活语音直接执行指令，唤醒词即指令。比如，在”监听“状态，直接说“下一首”来执行切歌流程，所以快捷唤醒其实是将“唤醒”和“识别”合并在一起了。因为“快捷唤醒”的引入，我们为了区分，会把“主动唤醒”的唤醒词，叫做“主唤醒词”。

4. 被动触发。当满足某些特定条件之后，语音交互会被触。这个从语音角度去说，叫“被动触发”，但从用户角度去说，就应该叫“主动语音”。此时用户没有激活语音，但语音因为某些特定的条件满足被激活，与用户进行语音交互；比如，“堵车”的条件满足时，主动激活语音，询问用户，“前面有点堵，帮您把空调切到内循环吧，确定还是取消？”

5. 流程触发。根据当前语音的交互流程设计，若需要用户继续下达指令，则可以自动激活语音开启新一轮交互，若流程结束，则可以结束语音交互，回到“监听”状态。

6. 混合操作。可以通过触屏、按键、手势、图像等等其他交互方式来激活语音。常见的是按键，比如app里的语音按键、车上方控的语音实体按键等等。（ 秋半仙 特别提醒： 现在很多语音产品，在交互上都是很纯粹的以语音为主，按键一般都是启动、关闭、选择等简单的逻辑。以现在的发展趋势，未来语音将会和更多操作方式进行混合，会有更多的广东会和机会。混合操作是一个大趋势，也会让语音交互越来越丰富，同样也会越来越复杂。）

7. 文字触发。文字触发的流程，是一种绕过“识别”直接进入“语义”环节的激活方式。

如果我们把语音交互中有用户感知的“语音录入”过程进行拆解，还可以区分出六个部分：

1. “初始化”。这里的“初始化”也可以叫“准备中”。此时语音在做初始的准备工作。在这个过程中，语音全系功能都还不可用，用户必须等待初始化成功完成，成功完成之后，再进入“监听”状态。

2. “唤醒”。用户通过“主唤醒词”进行唤醒激活。

3. “说话”。用户下达指令的过程。

4. “识别中”。语音识别的处理过程，此时一般是引导用户等待。

5. “识别结果”。识别处理完成，给予“文字”结果，此时根据交互设计决定是否展示结果给用户。

6. “流程处理”。之后就是交互的具体业务流程环节了。

我们将七种语音激活方式，和这六个过程进行结合，得出下面的示意图，便于理解和记忆。

“唤醒”和“识别”虽然都是基于“语音识别”来实现的，但是逻辑还是有很多区别的。

“唤醒”对实时性要求很高，追求“快”。如果主唤醒词话音刚落，立马就有了响应，你是不是觉得被伺候的特爽？这和生活中我们去找别人，希望别人快速响应是一样的心理过程。一般我们是仅在设备上做“唤醒”，不会放到云端处理。这里有几个原因：其一，实效性。由于对响应的实时性要求太高，放云端处理，一个网络延时就凉凉了；其二，安全性，也是隐私问题。你说家里有一个设备，在实时“监听”你家里的声音，并放到“云端”去处理，万一你想干点……（此处省略一万字）对吧，相信每个人都是会有些安全顾虑的。

“识别”则对准确性要求很高，所以会结合本地和云端一起来处理。因为这些产品诉求的种种不同，“唤醒”会更加倾向于“声音”的相似度，不用等文字结果，就能快速响应，所以现在很多语音公司在做“唤醒”和“识别”时，也是分在两个不同的模型和引擎里来实现的。

既然是分成两个引擎来处理，那么两个引擎的调度就需要时间，这个时间会给产品带来什么风险呢？

我们拿“按下语音键后说话”举例。大家回忆一下，你们微信或钉钉发语音，是不是下意识地按下语音键立马就开始说话？然后你再听一听，你会发现，开头有一段声音没录进去。仔细看这些产品的体验，其实是有一些交互细节在引导你不要立马就说话的。这个现象在很多语音产品里都有，主要有两个原因：一个是硬件麦克风要开启，这里就有一个避不掉的系统层激活调度的时间；一个是相关引擎的初始化时间，这也是一个必然存在的时间。两个都是必然时间，那么这个体验是不是就没办法做了呢？当然是有办法的，产品同学需要注意， “ 用户的感知是产品整体对外的表现所产生的。也就是说，我们所谓的体验的极致，指的是用户 感知的极致，它并不等于每个点都必须完美无缺 ” 。

这个地方的解决办法有些偏技术，其实就是将录音抽象到一个独立的模块，且录音不停止。等用户一旦激活语音，录音模块还是将数据保留下来，同时去初始化引擎。等引擎初始化好，再将数据交给引擎处理。从用户表现层来看，就是按下语音键立马就能说话。这个方案貌似解决了问题，但是总不能应用一起来就把麦克风开开吧，这样太耗电了，产品也不太可能会这样定义。不过，有些语音产品是一旦启动就需要具备“语音唤醒”的能力，此时的语音产品就一直处于“监听”状态，麦克风就已经常开了，那么这个方案就适用了。其他情况，就得想其他办法了，但是思路是一样的，“ 要么解决每个关键点的耗时，要么就将他们藏起来让用户无感” 。

好了，今天分享会秋半仙有点儿啰嗦了，我们就讲到这，别忘了点赞打卡哦~

                                                          —THE END—

（转）设计一个语音交互界面(Voice User Interface)

此文为Medium上的一篇文章，搬运过来供自己和大家学习下。原文链接

//medium.com/@xuuuwj/%E8%AE%BE%E8%AE%A1%E4%B8%80%E4%B8%AA%E8%AF%AD%E9%9F%B3%E4%BA%A4%E4%BA%92%E7%95%8C%E9%9D%A2-voice-user-interface-1-6364d4529a28

去年11月第一次接触VUI Design以来，已有三个多月，期间凭着网上的资料(主要是google designguideline\dueros.com\设计师手记\论文)以及自己的UX知识，我尝试设计了三个项目： 一个买书的skill 、一款智能音箱语音交互游戏、 一个关于中国电信100M宽带业务的微信咨 询机器人 ，前两个项目做到原型为止，最后一个已经在微信公众号后台实现。但这三个项目的重点都被放在conversation design上，并不能算完整意义上的VUI。

本月刚刚读完  Cathy Pearl 的《语音用户界面设计》(《Designing Voice User Interface》) 和《Voice User Interface Design》(By Michael H. Cohen, James P. Giangola, Jennifer Balogh)，书中完整地讨论了VUI设计的基本原则、重要的技术模块以及用户测试等问题，帮助勾画出了一张比较完整的VUI Design全景图。

在接下来的文章中，我会尝试用一个happy path串连起由0到1设计一个语音交互界面的过程，希望能定义好每个小框架中的设计问题，然后把它们变作一种肌肉记忆。

By the way， 因为说话这件事情太本能了，所以我觉得设计VUI困难的一点在于怎样从用户思维中跳出来，让自己重新回到设计师的角色上：）

语音界面的优势主要体现在三个方面：一是速度，包括输入更方便、入口更浅、学习负担更小等；二是共时，比如允许多任务同时进行；三是探索性，更能激发用户的好奇心，提升用户体验。不过同时，也不要忘记语音交流是非常受场景、技术及用户习惯限制的一件事。

可以参考 Google-fit-quiz 里的问题，来验证VUI究竟是不是你的最佳选择。
在回答之前，我们需要先了解：1.用户进行语音交互的方式有哪些，2.VUI系统内部是如何运作的。

The Nielson Norman Group 将语音交互总结为以下屏幕优先、纯语音和语音优先三种模式：

📱 Screen-first Interaction（屏幕优先）:  Here, we start with an application designed primarily for screen, and voice controls are added afterwards to enhance the experience.（设计一个以屏幕显示为主的App, 为了提升用户体验，会加一些语音元素）

🗣  Voice-only Interaction（只有语音交互）:  Here there is no screen at all, and input and output is based on sound, such as a smart speaker.（VUI设备没有屏幕，输入和输出都要声音，比如智能扬声器）

💬 Voice-first Interaction（语音优先）:  This is where an app designed primarily for voice is enhanced through the addition of a screen to output information.（以语音为主要交互方式的App，输出信息在屏幕上显示，通过这种方式提升App体验）

屏幕优先 的情况下，最典型的代表就是手机语音助手，用户不仅可以通过语音，还可以通过键入、手势来进行操作，系统回复的内容也包含了语音、文本、图片、列表、链接等等。
纯语音交互 的代表之一是智能音箱，用户通过“唤醒”词，比如“ Alexa”，来开启VUI交互；另一个代表是电话客服，也就是交互式语音应答(Interactive Voice Response, IVR)，它可以通过电话线路理解人们的请求并指引用户完成相应的任务，比如预定机票、查询话费等。
可以把对话系统看作人机翻译机，接收人类的自然语言并把它翻译成计算机能懂的结构化语言，以便进行信息匹配与加工，最终再以自然语言的形式反馈给说话者，完成一次“沟通”。“沟通”的本质是通过对最优解的一步步预测，以生成一个匹配概率尽可能高的反馈，需要计算能力、算法与数据的背后支持。

具体情况如下图所示：
当用户对系统讲话(utterance)，系统会首先通过 语音识别(ASR) ①接收并解析语音，识别器可以提供多个可能的结果，即N-best list，从中为接收到的语音匹配最相似的词串文本(recognition hypothesis)，然后反馈给下一个自然 语言理解(NLU) ②模块。

理解自然语言，即系统通过对词法、句法、语义的分析，识别(identify)用户的意图(intent)或者用户言语所涉及的领域(domain)、实体(entities)，生成一个结构化的 语义表示*， 包括语言类型(陈述需求，询问属性，否定，选择疑问，等等)和条件信息(有什么条件、值是多少)。比如，“帮我查深圳的天气”这句话对应的语义表示为“inform(occasion=天气，location=深圳)”，其中“inform”代表“陈述需求”，括号里面的内容我们称之为slot-value pair。关于计算机是如何理解自然语言的，可以点击 这里 详细了解。

语义表示生成之后被转交给 对话管理器(DM) ③，由对话管理器来决定答复给用户什么以及怎样答复。

对话管理器是对话系统中很关键的一个模块，连结着一个或多个 知识库(Knowledge Base, KB) ④。通常包括：a.对话状态跟踪(dialogue state tracking)，比如追踪执行用户意图所需的信息是否完整；b.对话策略(dialogue policy)，即根据当前的状态 决策 下一步应该采取的最优动作，比如，是直接调用知识库(knowledge base)内容提供结果、询问特定限制条件、澄清或确认需求、还是开启相关的某个软件呢。

不同的对话系统，goal-driven system(比如任务型、问答型)和open-domain system(比如闲聊型)，对话管理器的任务、知识库内容也不同。
任务型对话的场景相对复杂，通常会与用户进行多伦对话，需要参数化请求并通过slots filling的形式持续跟踪对话，直到识别出用户意图、特征词、slot-value pairs，即系系统要执行的动作的类型和操作参数。

问答型则不需要考虑复杂的对话逻辑，通常一轮对话就可以解决，重点在于语义解析与实体匹配。

闲聊型包括检索模式和生成模式，检索式是利用网络中已有的大量对话语料来构建索引，从索引中查找可能的候选回复，而生成式则直接从大量的人人的对话中学习对话模型，然后利用对话模型“创作”回复。

对话管理器会根据当前的对话状态生成一个预期回复(intended response)，然后进入 自然语言生成(NLG) ⑤- 文本转语音(TTS) ⑥环节，把结构化的预期回复改造成自然语言，最终呈现给用户。

常见的说法是“系统形象(system persona)”，相当于产品的前端，即系统通过的①语音特征，语气、语调、音色、节奏等。你可以选择使用合成(synthesized)声音，也可以选择录制的(recorded)声音；

②话术，编写问候语、特殊应答、提示语等时的用词、长短句这些，来展现与品牌相符的性格特质，比如亲切or正式，主动or顺从。

一个好的system persona能够很自然地成为你编写对话时的参考条件：“在这种情况下，这个persona会说什么或做什么？”

VUI的交互方式与对话内容很难彻底分开讨论，但做这种尝试，有助于跳出用户视角，走进“黑盒子”中。

我倾向于将“交互方式”看作《Voice User Interface Design》中所言的“High-level design”，而将“对话内容”看作“Detailed design”。

“High-level design”关心的是怎样推动对话流畅地进行，让用户知晓系统的状态、任务进度等以便操作，比如系统在聆听、在期待收到指令、已离线等，可以理解为GUI中的弹窗、动效、视觉反馈等。

同时也为系统设计更好的规则，以便它做出更好的决策，比如在什么情况下需要向用户确认请求，可以理解为GUI设计中看不见的菱形判断框。
这些问题主要涉及到以下：

①对话模式设计

A.命令-控制式(command and control)，即用户想要说话时必须先唤醒系统，方式可以是使用唤醒词、手势触摸或者按键。一轮对话完毕，用户须再次唤醒系统以开启下一轮对话。

B.对话式，即在一段封闭的对话期间，比如完成某项特定的任务时，用户不必每一回合都唤醒系统，而是自然地进行话轮转换，在轮到用户说话时系统自动开启麦克风。

C.混合式，即命控式与对话式的结合，系统向用户提供明显的状态切换标识，比如使用声音标志(earcon)以表示某个状态的开始与结束。

②对话策略(dialog strategy)设计

包括：

A.对话框架设计，即对话组织策略

《Designing Voice User Interface》一书把对话框架分为：a.定向对话(directed dialog)，即系统主导对话，向用户询问非常具体的问题，以期望获得同样具体的答案；b.菜单层级结构(menu hierarchy)，即系统向用户提供一系列选择，一旦用户完成了菜单a的选择，系统会继续提供菜单b，直到完成用户的请求；c.混合推动(mixed-initiative)，即定向对话与菜单层级相混合，系统询问用户问题，也允许用户通过提供额外的信息来引导对话。
B.对话修补策略

技术并不完美，识别器可能还没有准备好接受呼叫者的话语，或者没有接收到说话者的语音，也可能响应时间太长 。用户也常常会突然扭转话题，或者提供太多信息。因此在正向推动对话之外，系统也必须配备处理这些情况的策略，以减少前功尽弃的概率。

a.错误恢复

可能出现的错误有以下四种：

·未检测到语音

·检测到语音，但没有识别

·正确识别语音，但无法处理

·部分语音识别错误

·延迟

一般有两种方法来处理这些情况，明确地说出来，最好能增加更多的细节让用户明白现在的状况，比如“抱歉，我没听懂，请说出您所在的城市和区域名称”，或者什么也不做。如何选择要取决于VUI系统的交互模式与用户场景。

b.万能指令

比如“帮助”、“停止”、“请重复一遍”、“退出”等等。设计时不仅要考虑用户可能的需要，也要考虑用户会怎样表达这些需要。

③条件阈值(threshold)设计

每个应用程序都会定义系统能承受的最大错误，对话系统也不例外，尤其是上文对交互流程的描述也向我们清晰地展示了，从用户、到技术模块、再到数据资源，VUI的运行充满了不确定性。

《Designing Voice User Interface》 一书建议我们考虑设置三种阈值：单个对话状态中的最大连续错误数（特定于状态的错误计数），全局计算的最大错误数，以及最大错误确认数。

牢记这一点便很容易理解Detailed design需要做什么，即深入到单条对话中，详细设计对话流程、辅助提示、以及异常情况处理方案。包括：

①对话设计

设计对话流程很像写剧本，即什么样的角色在什么情况下应该说什么话，不同之处在于对话系统的情节和部分角色是写定的。
各大平台上，Google、Amazon、Microsoft，都有对话设计的相关指导，可以通过 这篇汇总文章 来进一步了解。

②提示列表(prompt lists)

回想一下，人与人之间的沟通也要建立在共同知识的基础上，与机器对话也是一样。让用户了解系统能做什么、不能做什么、怎么做是对的等等，才能够实现高效率的对话。

这一点可以通过设计提示列表(prompt lists)来辅助实现，提示类型包括：

A.初始提示，

B.错误提示,

C.帮助提示，

D.特殊应答等等

提示的形式有多种，语音、文本、图像，甚至声音，都可以。

比如图中Google assistant采用带有文字的按钮来告诉我它能识别屏幕上的内容，而我只需点击或者说出指令即可；右边的两张图里，Google通过[视觉元素变换+“进入对话”“离开对话”的文字提示+音效(earcon)]来隐喻游戏的开始与结束。

Google在designguideline for Google assistant里总结了 他们运用在提示语(prompt)中的不同元素(types of conversational components) ，是一份非常好的参考。

设计过程其实与一般产品并无大异，需要考虑：

1). 用户研究结果。 包括用例、使用场景 、用户语言模式与心理模式等。可以参考博主@Lu的设计手记 《语音理财案例分析》 。

2). 业务场景与目标。 主要是据此确定功能列表、功能优先级、交互方式等。推荐百度AI社区的 《酒店语音助手实例教程》 。

特殊的是，人工智能产品的形态多种多样，设计师必须对于产品所依附的硬件设备、产品背后的数据与技术支持有所了解，以确定产品边界、发现设计机会、持续优化用户体验。因此也需要考虑：

3). 技术与硬件基础。

比如设备联网程度，ASR引擎是否允许你设置N-best列表、自定义语音终止超时的时长，系统的负载量等。

4). 数据资源。

比如当前资源是否能满足该功能，哪些数据会影响系统响应时间等。
人们往往通过语音识别准确度来评估应用程序的运行效果，这也许是最糟糕的度量方式。一个应用程序能达到90%的识别准确度，同时自动实现85%的业务呼叫；另一个应用程序达到97%的识别准确度，且自动实现40%的业务呼叫，前者就一定比后者更差或更好吗？

——《如何构建语音识别应用》( Bruce Balentine, David Morgen)

评估涉及到三个问题：

1.如何定义成功

需要与开发人员、客户共同完成，以方便确定哪些状态是可以衡量的，哪些不可以。尽可能将成功状态具体化、数字化。

以下使一些成功标准的示例：

·60%想要预定酒店的用户最终完成了预定。

·85%的用户在1个月内至少完成了20天的每日健康记录。

·播放歌曲的错误率低于15%。

——《语音用户界面设计》Cathy Pearl

2.可以通过什么来衡量

A.任务完成率

B.用户(在何处)(因为什么)流失率

C.使用时长

D.语音打断情况

E.高频异常情况

……

*如果不思考原因，以上所有衡量结果都不可用

3.如何获得衡量数据

A.在早期建立记录日志

B.转录用户呼叫记录

……

参考资料：

《语音用户界面设计》Cathy Pearl

《Voice User Interface Design》Michael H. Cohen, James P. Giangola, Jennifer Balogh

百度AI社区

Google Design Guideline

Cortana Dev Center

Nielsen Norman Group

//voiceprinciples.com/

《周耀明：自然语言对话引擎》

机器之心

       以上就是小编对于儿童类语音产品设计方案_儿童类语音产品设计方案怎么写问题和相关问题的解答了，儿童类语音产品设计方案_儿童类语音产品设计方案怎么写的问题希望对你有用！

       免责声明： 1、文章部分文字与图片来源网络，如有问题请及时联系我们。 2、因编辑需要，文字和图片之间亦无必然联系，仅供参考。涉及转载的所有文章、图片、音频视频文件 等资料，版权归版权所有人所有。 3、本文章内容如无意中侵犯了媒体或个人的知识产权，请联系我们立即删除，联系方式：请邮件发送至 cnc1698@l63.com