自从计算机发明后，它所能接受的输入本质上就没发生任何变化，始终都是类似加减乘除移位这样的指令。我们经常说的纸带其实并不是交互方式本身，而只是一种载体，纸带上面就是具体需要计算机执行的指令。在那个时代，人是要完全适应机器的，所以必须学会机器的语言，程序员则相当于掌握了机器语言的翻译。

同样道理键盘也不是一种交互方式，而是一种输入设备，真正的交互方式其实是命令，常见的比如mkdir这类命令其实可以看成是更多指令的集合，但抽象的级别更高了，可以完成建立目录这类功能。这个时候，其实也还是人在适应机器，但开始去除人机交互过程中一些繁琐重复的事情，让人机交互变得更为便利。

此后的图形用户界面是一个关键转折，图形用户界面让人机交互彻底地向人类一方迁移，屏蔽掉了几乎所有和机器相关的细节。在Windows下唯一还保留了些机器特征的东西，只是开机、关机、拷贝、粘贴、查找、最大化、最小化、关闭等少数几个命令，其它部分则和我们操作物理世界的东西很像，比如我们需要选择一样东西的时候，我们通常会把他们排成一排，而不管开始菜单还是任务栏都是这样做的。同样是图形用户界面，从使用鼠标到触屏内部还是有进展，导入触屏之后机器的细节被进一步抛弃，最大化、最小化这些事进一步消失，而只剩下App的排列以及选择，我们最常用的操作只是点击和滑动。所以我们可以说从鼠标到手指其实是进一步向人这端迁移。

随着人工智能的发展，机器人控制APP是智能机器人中的配置之一。我们将在APP的从0-1产品搭建、机器人产品运营上，遇到了诸多坑，也走了不少弯路。

1、现实中的技术制约

无论是行业内的技术还是自己公司的技术，本来就有一个瓶颈限制；这个限制一方面是由于整体技术有待进一步发展，另一方面是本家研发团队力量有限所致，这在互联网产品中可能具体表现为视频加载慢、播放卡顿，高并发时无法及时响应用户等等；但是无论如何软件类技术一定会有破解之道，bug或问题可以通过更新、上线、迭代的方法一个版本一个版本的修正。

但是机器人产品因为是一个硬件本体，如果问题或隐患是存在于硬件中，则很难通过远程的方式升级和改进问题，严重的话则需要召回产品或派驻工程师驻场维修；但碍于成本问题，无论是召回还是派驻都是解决方案的下下策。

这时，需要产品经理在PRD中，根据自己对目前研发团队所能实现的程度调整功能定义；比如，研发团队目前只能让机器人在室内地面自如移动，那么产品的PRD中就不得不对使用场景做限制；同时在产品使用说明书中也要添加场景使用的约束条件，必要时还需要在机器人的外壳上、屏幕APP上、机器人语言表达上都需要做使用条件的提醒。

例如，我们可以在使用说明上添加一句话“本产品仅在室内平整地面使用”——在外壳的某些部位丝印类似的语句表达出场地要求，当机器人正在走出室内房间时，让机器人自己主动报警异常位置并做语音提示，方便用户知晓。

这些工作都是互联网产品经理不常接触的，有益之处在于：可以规范和教育用户的使用规范，延长产品寿命，降低产品后期故障率。

诸如此类的添加条件限制的声明，按照国家法规规定，这也属于企业产品免责手段，在日后如果造成产品伤害消费者的情况，也可以在法律层面维护企业和产品利益。

在机器人等硬件产品中，产品更偏向保守而不是激进。能用成熟的可靠的技术，则不会使用实验室最新技术；通过产品经理设计的一句话、一个提示符号，就可以让成熟技术优先使用，那是产品最好的研发路线。

2、现实中技术实现的效能

假定我们的研发团队现在拥有了一套可靠的技术方案，接下来是否可以由产品经理基于它设计产品功能了吗？还是要等等，我们要看看这套技术方案所能实现的效果如何，使用范围如何。

例如，我们的移动技术方案在周围人多的时候就会大打折扣，而且短时间内技术有很难捅破天花板。

产品经理就需要在PRD中增加对这种情况的功能定义；比如，我们可以让机器人在遇到人多无法正常通行的时候说一句求饶的话，“我最近又变胖了，求求你给我让让路”；我们姑且把它成为求饶功能，这个功能可以在80%的场景中解决移动的问题，设计这个功能的效能比就很划算。

再如，我们的电池电量正常可以使用8小时，但是温度如果低于-30度时，电池就只能工作2个小时。

那产品经理有什么好方法吗？不知道你现在是不是能想到什么好方法？第一个方法，如果我的用户中只有2%是这种情况，那么我就不管他们了，为了2%的用户做大量研发工作不划算。

OK这样也合理，可是还有更好的方法吗？我可以在软件上设计任务拆解功能，把原先的长任务分解成多个2小时以内的任务，再接上天气预报的数据，让机器人在气温低于-30度时，会自动拆解任务，并且还会自动继续之前的任务往下做；这样带给用户的体验是不是就会改善很多，这样的机器人功能设计是不是更合理。

3、现实中技术实现的范围

在互联网和移动端产品中，研发出的成果需要做测试，才能最后发布、上架和上线；在机器人领域中，这一过程需要做些调整。

产品经理需要在测试工程师和质量工程师的配合下，对功能指标做集中调研和摸底；调研的目的是了解和掌握国家或行业是否对此已经有具体的标准和规范，可以让产品经理设计和定义出更符合时代和现状的产品；摸底的目的是了解和掌握现阶段可用的技术能在各种条件、因素下，所带来的使用效果的最大性能区间。

例如，经过严格测试，我们掌握了机器人摄像头能够采集识别的最远人员特征是5米；如果产品经理认为这个距离不符合产品要求，可以对研发人员提改进要求，研发人员对应改进和提高性能。

这部分工作为什么要在之前做？还是因为硬件条件限制，影响性能的未必只是软件、算法，也有可能包含硬件的更换和优化；如果都放在产品研发的最后阶段再测试，一旦发现问题届时再想修改调整，就工程量巨大，难上加难了；那时候产品硬件接近定型，模具也可能已经做好，产品回头代价太大；同样，国标行规的使用范围约束也是此类原因，早掌握、早定义，保证后期少走弯路。

4、现实中生产工艺的条件限制

互联网和移动端产品研发完成后，经过测试就可以上线发布使用了。

对于机器人产品而言，还有一个重要的一步——生产，生产中的风险有供应商、OEM厂家、装配工艺、物料检验等等；作为产品经理，其实并不需要你知道、掌握和擅长生产中的每个环节，这部分由具体的项目经理来负责，但是还是建议你参与生产部门的例会，哪怕只是看看会议纪要。

你需要了解生产中关于供应商和装配之类的问题，这样可以提前了解未来产品上市后的潜在故障和隐患，这为你下一步的产品版本优化提前规划好方向；同时，跟供应链的同事经常沟通，也可以让你更加清楚目前产品的成本、性能、使用上潜在的不足和隐患、生产周期、供应商物料的短板等情况。

对自己产品了解的程度越深入，越完整，越有利于竞品调研中更准确的对比分析行业同类产品，找到己方产品的优势和不足，同时也方便在后期运营阶段提前编制好运营手册。

5、交互方式背后隐含的颠覆性

交互方式的改进如果只是带来纯粹便利性那就只是一个更好的功能，但如果这种交互方式影响了信息的整合与输出方式，那就会对行业产生颠覆性影响。典型的就是触屏对搜索的影响，在鼠标的模式下，搜索是互联网的中心，但因为触摸不能精确定位，进一步催生了App，这直接导致了搜索的中心地位被削弱。

那显然地注入了智能属性的语音交互一定会导致信息整合和输出方式的再次更迭，那这会对眼下已经日趋稳定的互联网生态带来什么影响？

从现象上看，第一个最直接的影响是App又会消失了，信息的整合与输出看起来似乎会经历一个分久必合，合久必分的过程。图形用户界面的鼠标时代，信息的整合与输出其实是大一统的，基本上就是浏览器与搜索引擎，然后大的客户端程序维持一定自己的空间（比如QQ）。图形用户界面的触摸屏时代，信息的整合与输出其实是分散化的，人们得记住自己要什么然后装特定的App。语音交互则是更加大一统的，没有App，同时也不会再有和浏览器相并列的大客户端，有的只是输入的一句句话。

什么样技术趋势就会导致什么样的格局。形象讲我们可以认为搜索、电商、IM的格局是先天内置在行业里面的，然后才是谁是搜索的王者，谁是电商的王者。

在PC时代浏览器和搜索处于核心地位，所以就会有Google这样的巨头，其它人都要活在它的阴影下面。而一旦信息的整合与输出再一次大一统化，那就一定会催生新的大号统治者，而这种大号统治者的出现，实质上意味着现有的巨头或者小巨头会被削弱。如果没有了App，对于O2O、甚至出行等谁掌握了上层的控制权，谁就掌握了他们的命脉。

终局看来就会是这样，但这个过程现在来看会非常漫长。

6、未来三年的交互方式发展

交互方式的发展一定依赖于具体产品的销售状态，而终端产品的销售起量则有两种模式：一种是智能手机式的，一种则是MP3式的。

智能手机的启动进程显然和苹果有巨大的关系，苹果先推出一款标杆产品，然后迅速出现大量的模仿者，最终市场大幅启动。在手机上整个过程历时4~5年。MP3则与此不同，先是出现各种形状的MP3，没有领头羊，市场也启动了，然后苹果出了一款体验远超其它人的产品。

对语音交互的发展而言，我们同样面临两种可能性：一种是有人做出了一款足够爆款的产品，让语音交互的落地有一个符号性的标志，然后类似产品持续跟进，产品品类持续拓宽；一种是没什么标志性的产品，但交互方式极为宽泛地不停地在各个行业进行渗透，累积到一定程度再出各种标志性产品。在国外显然走的是第一条路线，其中Amazon Echo扮演了领头羊角色。在国内则暂时还看不到这样一个角色，越来越往MP3的走势偏移。

具体来讲，如果是有人扮演领头羊的角色，那市场会在领头羊之后高速推开，因为交互方式的一切细节都会在领头羊身上得到验证，各个公司不会有任何疑虑，但如果是没有领头羊的模式，那整个进程就会拖的比较漫长。

也就是说，未来三年交互方式的发展，最终会依赖于我们实质上会走到那条道路上来，眼下来看后者的可能性在升高，因为领头羊这种事，事实上是具有极大偶然性的，乔布斯这种人是非常难以复制的，其信徒们似乎都走上了邯郸学步的套路。

对话设计的重要性

1. 对话设计是什么？

对话机器人，主要由几个部分组成：语义识别、信息采集/使用、对话设计、知识库。

语义识别：

通常由AI算法模型进行（NLU，自然语言理解），这也是对话机器人中，AI技术应用最多的部分。当然，算法也有识别不到位的情况，通常会使用规则做矫正/补充。

信息采集/使用：

即对语义识别的结果做收集、更新、使用。对话的本质是信息的交换，对于机器人来说，获取访客的需求信息至关重要。信息决定了后续机器人采取的策略与动作。

知识库：

知识库是应用于单轮对话的机器人知识储备库，可以为访客提供答疑服务。由于知识库的FAQ特性使然，知识库侧重于一问一答的“知识解答”。

对话设计：

对话设计是对话机器人的核心部分，相当于机器人的“大脑”。即：面对什么样的信息，需要做什么样的动作，从而让对话可以顺利地进行，并满足访客的需求与机器人本身所需达到的目的。对话设计就是机器人对话逻辑处理的设计。

2. 对话设计为什么重要？

可想而知，如果对话机器人没有了对话设计，那么机器人基本失去了多轮问答的能力。相当于访客问一个问题，机器人回答一个问题。这在较为简易的机器人中应用较为常见，但是一旦业务变得复杂一些，机器人就很难处理，应付不来。在人看来，就像“智障”一样。

那为什么不使用AI算法来解决对话逻辑的问题呢？

因为AI技术发展到现在，还无法做到通过会话级的学习，达到应答自如的对话效果。这就需要AI PM与AI训练师，通过对话逻辑的设计，让机器人变得智能，处理业务问题，从而实现预定目标。

二、对话设计关键8个要点

对话设计在功能形式上，表现为对话流程。通常流程与对话场景相对应，即一个流程处理一个对话场景。当然如果场景较大，可能一个场景需多个流程处理，流程间会协作配合，分别处理不同的任务。

流程的设计，即机器人“大脑”的设计。一般通过设定流程逻辑规则，让机器人具有处理不同问题的能力。以下为流程设计的关键点，提炼为8个。

1. 流程间执行优先级

一个机器人中，有多个流程，数量可达几十个。比较通常的情况是在30-40个左右。当然，流程的多少，跟场景划分颗粒度粗细有关。一般而言，一个流程会对应一个意图。意图即为流程的准入条件。

流程间是需要设定执行的优先级顺序的。为什么？

因为访客的同一句表述，可能会同时满足多个流程进入的条件。此时应该进入哪个流程，就需要人为地划分优先级。

你可能会说，这样划分科学吗？有效吗？是的，这样并不能保证是最客观最科学的，但是只能在可能的情况下，尽可能考虑访客的各种情况下做出最优解。

在所有的流程中，我们一般做的设计就是，将所有的流程排优先级。从第一个流程开始匹配，命中则进入流程；未命中则执行下一个流程，直至命中流程为止。若未有流程命中，则不进入流程。

所以，在做对话设计时，做好流程间的执行优先级，就可让机器人在面对访客表述识别模棱两可时，做出优先级选择，从而进入欲进入的流程。当然，也会出现未考虑到的情况，毕竟语言表达在不同的访客、不同的场景中，可能千变万化。故只能说，在已有条件下找到最优解。

2. 流程内执行、流程间跳转优先级

当进入流程后，机器人可能会面临，在同一句访客表述前，是应该在该流程继续执行，还是应该跳转到另外一个流程。

这个时候你可能会说，如果访客说到另一个场景/话题，就跳到那个流程；如果是继续当前的话题，那就应该继续原有的流程。思路是这样的没错，但是实际情况往往会比我们预想的复杂。对于场景清晰界限明确的流程间，比如“播放音乐”和“订火车票”这两种泾渭分明的场景，就很容易处理。但是当出现场景间的界限较为模糊的情况，就较难通过简单的准则区分。比如在医疗领域“咨询牙齿种植”和“咨询补牙”，由于场景相近，访客描述的内容可能很相近，机器人做意图识别时，在一些表述上很难做到区分。

所以，我们一般会制定一套跳转规则。比如，当流程间界限分明/机器人应答策略更希望流程尽量不做跳转时，设置当前流程执行有限；当流程间界限不太分明/机器人应答策略更希望在不同流程间跳转时，设置流程跳转优先。

再次地，这样的设置是通过人为地制定一套规则，让机器人可处理不同的业务问题，从而让机器人对话“智能”。

3. 流程间跳转限制

多个流程间，有诸多的流程是并列的关系。但是 也有流程间是“父子”关系、“只进不出”关系。

举个例子，比如流程A和流程B：

• 在某些情况下，流程B的准入条件，必须是进入了流程A后，满足一定条件，如访客说了某个关键字，才可进入流程B。这种关系即“父子”关系，A流程是父流程；B流程是子流程。不进入A流程，就不能进入B流程。
• 在某些情况下，流程A可跳转到流程B，但是流程B不可跳转到流程A。常见的情形是，流程A是“无意图”流程，流程B是有意图的流程。一般而言，在识别了访客意图后，当访客当前轮次的表述是无意图，也不会跳转回“无意图”流程。

通常，我们会通过流程关系的设置，来确定流程间的跳转关系和限制。在Google Dialogflow中，Context的概念，就是为了设置流程间的“父子关系”。不仅是流程间的跳转关系，流程中传递的信息（词槽信息）也会被传递/继承。故称之为Context语境。

4. 流程问句重复/不重复发送

行业中有一部分场景，是需要把机器人做成“仿真”的。即：让访客无感知/较弱感知到与自己对话的是一个机器人。这些情况下，就需要将机器人做拟人化设计。

流程问句的重复/不重复发送设计，是其中很重要的一步。试想，如果在一个对话中（特别是客服等提供业务服务的对话），对方反复发送同一句话，你会不会很容易质疑对方就是一个机器人，很生气地结束对话，或者要求转人工？

那么，如何让机器人避免流程话术重复发送呢？

我们的处理是，在设计流程的问句时，再配置上该问句要收集的信息。通过对上文该信息的识别、获取、存储与判断，来避免下文重复发送相同/类似的问句。比如：

【流程A】机器人问：“您多大年纪呢？”，配置“年龄”的信息

【流程B】机器人问：“您今年几岁呢？”，配置“年龄”的信息

当上文执行了流程A的上述问题，并获取保存了访客的“年龄”信息，则在下文执行流程B时，再次询问“年龄”的问句将被跳过，不会再触发。从而实现避免重复发同类问句的目的。

当然，如果机器人是“非仿真”的机器人，则无需做这一种判断处理。因为用户对于对话的认知就是在跟机器人对话，无所谓是否重复话术。但是，AI不就是通过智能让生活更加便捷美好吗？仿真化对应的智能，势必会是以后的大趋势。

5. 流程重复/不重复执行

执行过的流程，当访客表述又再次满足其准入的条件时，流程还可以重复执行吗？

其实这一点和上面一点的思路有点类似。流程重复执行，意味着发过了的问句/话术再次发送一遍。对于“仿真”的机器人来说，一般是需要做避免重复执行的设计。

比如：

• 流程A中执行到第3轮话术，由于访客表述跳转到了流程B
• 当流程B执行后，又满足流程A的条件从而回到流程A
• 那么此时，应该
• 从流程A的第4轮继续执行（接着刚才执行到的第3轮）

同样的，如果是“非仿真”的机器人，可容忍流程重复执行，则无需做此设计。

6. 流程被打断后恢复/不恢复

当流程发生跳转的，一般会伴随流程的打断。可能的情形是，在原有流程中聊得挺好，访客突然说了个与该流程不相干的内容，或是另起一个话题，导致跳转到了另一个流程。

比如：

• 流程A中执行到第3轮话术，由于访客表述跳转到了流程B
• 当流程B执行完
• 此时，由于A流程是被打断的主要场景，访客更倾向于继续将A流程话题继续至结束。故需恢复至A流程并执行完

这种情况一般是在A流程是主要场景/流程的情况下，在A流程中做的设置。而对于那些较为次要的流程，则较无需做“打断后恢复”的设置。因为有可能其跳转的是主要的流程，便无需做恢复动作。

7. 信息采集与追问

对话的本质是对话双方信息的交流。在对话流程进行中，信息的采集尤为重要。信息不仅可作为机器人话术的组成部分、作为访客信息记录/传递，还可作为条件判断的来源、第三方接口的传递内容。所以信息采集对于对话流程来说很重要。

所以，一般我们在设计流程的问句时，会设置相应的信息采集内容。还是上面的例子：
机器人问：“您多大年纪呢？”，一般会设置“年龄”的信息采集。可通过算法的实体识别（NER）技术，获取访客表述的年龄信息。

当信息未获取时，也可通过“信息追问”的方式，追加询问，以获取欲获得的信息。

当然，信息追问也许根据具体场景来设计，设计过多也会让访客觉得反感。一般来说，信息追问的话术连续不应超过2次。

8. 流程与知识库的协作配合

以上说的都是流程内部的设计点。在流程之外，知识库是机器人另一重要组成部分。知识库主要进行单轮一问一答的知识答疑。那么流程和知识库如何协作配合，对于对话来说也是很重要的一环。

一般而言有以下4种策略：

• 策略1：针对访客的表述，先进行知识库答疑，后执行流程话术；
• 策略2：针对访客的表述，先进行流程内判断，若不满足流程执行的条件则进行知识库答疑；若满足流程执行条件则执行流程话术
• 策略3：只使用知识库答疑，不执行流程话术
• 策略4：只执行流程话术，不使用知识库答疑

四种策略，侧重点不同。

• 策略1，是种综合的方式，结合了知识库与流程话术的优点，在较大限度上限制二者的缺点；
• 策略2，是侧重流程话术的方式。知识库作为流程的补充使用；
• 策略3，一般适用于问答机器人，业务较为简单，无需较复杂的对话逻辑处理
• 策略4，一般适用于强引导型的机器人，可以基本不做访客的知识答疑

一般根据客户的实际场景，去设计不同的协作策略。一句话，可达到业务目标即可，没有优劣之分，只有侧重点之分。