智能机器人控制APP的逻辑及开发架构

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

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

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

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

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

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

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

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

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

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

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

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