国内语音交互人工智能创业公司里走从硬到软赛道的公司还比较稀少，最典型的应该是声智科技（这公司是我Portfolio公司，所以比较了解），声智科技是从最底层的声学阵列开始，先做噪声抑制、混响消除、回声抵消等，反过来再考虑上面的ASR等，与云知声等的道路正相反。

　　这种模式的好处是可以站到产业链的最前端，容易落地，是数据的必经之路。而数据本身是未来ASR甚至NLU的核心驱动力，所以后劲比较足。

　　坏处是短期需要用硬件获取客户，并且需要组织硬件的生产，需要较多的启动资金。

　　可以讲产品系创业公司的成功事实上有两个外部要求：一是趋势要来，其次是产品要经得起市场检验。从硬到软的公司也有两个外部要求，一是趋势要来，二是要技术过硬，有价格优势。2B的公司所面临的客户通常非常理性，很多花哨额营销反倒是作用不大。

　　从软到硬

　　语音交互上从软到硬比较典型的创业企业则是云知声，这种模式选择和公司定位甚至从名字上就可以看得出来。

　　从软到硬的好处是更容易覆盖已有的成熟计算平台，比如所有的App都需要一个自己的Siri，直播，那云知声这样的企业只要做好技术壁垒，等着携程、今日头条上门就行了。这个方向上主要的挑战在于要和大公司（比如百度和讯飞）直接竞争。我们这篇文章主要关注的是新硬件产品上落地，所以这点不再展开。

　　坏处则是在新硬件产品（Echo、汽车、机器人、AR等）上很难落地，因为为了在新硬件产品上落地，中间必须加入阵列那一层，否则效果会很差。而一旦无法落地，其技术优势就很容易被突破。语音识别的精度骨子里是数据驱动的，但显然不做阵列等硬件，你没法落地，没法落地就没有数据，也就很难获得数据、技术、精度、场景上的正反馈，也就不容易解决真实环境的语音识别精度问题。云知声等显然认识到了这一点，所以也在积极往这一方向扩展。这时候通常会碰到软件企业跨界做硬件的一般性问题，比如供应链侃价搞不定会导致同样的产品成本会高个百分之几十等。

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

　　上面拿语音语义的企业做了个例子，但事实上在计算机视觉上同样成立，只不过细节会有差异，比如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做出来的。