路线差异起源于对计算架构的认知

上面拿语音语义的企业做了个例子，但事实上在计算机视觉上同样成立，只不过细节会有差异，比如Movidus的芯片可能在端上就把图像识别处理完了，而不需要像麦克风阵列那样自己处理后再把结果传到云端。这种模式选择背后隐含的共通的东西是对计算架构认知和假设。

到现在为止这种假设和认知一共有三种：

一种是为保证体验（速度等）端始终要扮演重要的角色，云用来辅助端完成计算。所有我们用的硬件产品：手机、Pad等基本都是这种模式。

一种是计算应该大部分发生在云上。Google主推的ChromeBook是这种模式，以前银行里的终端也是这种模式。

一种是正在兴起的传感器+Fog computing+云架构。这种可以看成是第一种架构的扩展，比如智能家居里所有的设备都直接连云上计算成本太高，那就不如家里有一个中枢先把能处理的处理了（比如天冷开空调，下雨关窗户就不传到云端了），实在不行的再连云。

前两种架构在现实里经常会发生PK，并且导致很严重的后果，下面说两个例子：

一次PK发生在PC上，那时候Oracle等尝试做的Network Computer骨子里的含义就是把各种计算转移到后端，让前端就变成输入输出设备。这种尝试显然失败的惨不忍睹，但有意思的是20几年后当PC这个品类足够成熟后仍然走这条路线的Chromebook却看到了些成功的曙光。

一次发生在Native APP和HTML5上，当时Facebook是很希望主推HTML5，那时候扎克伯格想用Web App来打破iOS和Anroid的垄断，但实际上Facebook差点死在在这个选择上，因为这选择几乎让它错过移动互联网，后续的Instagram与WhatsApp大额收购很可能与这种错误路线的选择有关。

我个人对此的基本认知是：对于新品类硬件产品刚出现的时候，首先是端要足够强大，把体验做到极致，随着应用、带宽等的逐步发展，那端上的计算量可能会转移到云上，因为那会有成本优势，但这需要一个漫长的过程，PC走了20几年刚看到这可能性。

如果这是对的，那意味着在新硬件产品上，首先成立的会是从硬到软的模式，而不是从软到硬。AR、自动驾驶等都和前面说的语音交互一样要先解决终端上的问题，让产品能够快速准确的进行实时响应，确保用户体验，之后再谈其它。也可以换个角度来考虑这问题，在新产品上更可能是先有iPhone才有Android手机，而不是掉过来，因为iPhone给用户的冲击更强，更容易树立起一个新的品类，但iPhone不可能用HTML做出来的。

但确实从硬到软的模式对创始人提出更复杂的要求，比如声智科技的陈孝良首先是声学专家，同时也是语音识别专家所以才会选择这种从前端开始，结合后端的路线。而云知声的CTO是计算机科学家，更擅长的是算法，深度学习，所以先天上就会倾向于用数据、神经网络算法和大幅增长的计算能力（从云计算到HPC）来解决问题。转到重视端的这条路上来同时需要跨越思维和技术壁垒，也许不太容易。