做了这么多年软件，一直有这样的体会，想实现的东西一句话说得完，但用软件实现却是像搭建一座大厦，不得不惊叹人的高级之处，人类统治地球是有道理的，共党统治中国同样也有深奥的学问，万事皆相通。
自然逻辑的抽象与实现
这里的自然逻辑不是指大自然的逻辑，而是人类自然而然的要求，显然，符合常规思维习惯，也符合常规逻辑推理。如果想在智能产品上实现这些东西，显然需要考虑到硬件的工作环境，硬件响应的及时性和准确性，软件层面的缜密和时效性。
比如，要实现一款定位鞋，需要硬件端感知触摸、按压以及运动，然后将这些数据反映到软件端，再由软件来实现自然逻辑。鞋子有哪些自然逻辑？很简单的就有，孩子穿脱鞋时给家长提醒。这是多么简单的一个诉求啊！简单的话再加一个吧，同时还要知道穿脱时的地理位置。
要实现这个诉求，是一个完整的闭环功能：鞋子需要有定位模块，定位模块的作用是采集数据交给服务端分析获得坐标点。鞋子要有能感应到穿脱的模块，暂且叫cap sensor。这个模块要解决很多问题：模块受潮了怎么办？孩子坐着模块感觉不到了压力怎么办？孩子跳动怎么办？等等。如果实际场景下，现硬件技术无法克服所有的这些问题怎么办？
再引入一个硬件：G-sensor，用于感应硬件的运动，脱鞋后鞋子必然是静止的了，那这是不是双保险了？但是如果穿着鞋子静止不动呢？
所有的这些事通过软件来解决吧，也就是软硬的互补，因为硬件稳定可靠性，特别是真实场景与硬件工作原理冲突的问题，这时需要软件介入，规避类似问题，但不能完全规避。
一个流程图看到的处理逻辑
为了解决上段提到的硬件和场景受限的问题，软件来辅助，以下是穿脱鞋子提醒的完整逻辑图：
这张图看出，正因为源头数据的不完全可靠，最后不得不分析多项条件，只要条件适合便做出相应的判定。要发送穿鞋通知，只要满足两套组合条件中的一套：
（1）最好的情况：收到G-sensor运动提示，且收到穿鞋数据；组合条件之二：之前发出的是脱鞋通知
（2）不良现象：G-sensor或不稳定，这时连续收到两次穿鞋数据即认为真实状态为穿鞋；组合条件之二：之前发出的是脱鞋通知
要发送脱鞋通知，只要满足三套组合条件中的一套：
（1）最好的情况：收到G-sensor静止的提示，且一直收到的脱鞋数据；组合条件之二：之前发出的是穿鞋通知
（2）不良场景：G-sensor一直感知运动，这样硬件一直在线，但cap sensor感应到脱鞋，设定连续10分钟为脱鞋即视为真实的状态为脱鞋；组合条件之二：之前发出的是穿鞋通知
（3）不良现象：cap sensor不良，最后一段时间一直感应到是穿鞋，或偶有穿鞋，其实已经脱鞋。解决办法是：只要G-sensor下线后，连续10分钟未上线见认为脱鞋；组合条件之二：之前发出的是穿鞋通知
别认为以上仅保存数据、比较数据、查历史状态就可以了，特别是发送脱鞋通知时的第三套组合条件，有以下几个场景：
（1）cap sensor不良才处理，不良的判定
（2）G-sensor正常，说明已经离线，即与服务端的会话已经终结，但需要一个作业，在10分钟后来干活，肯定不能由会话内部来管理这个作业，因为会话已经没有了。另外，会话的数据也将消失，要保存在一个地方被作业获得
（3）假如之后的10分钟内，又上线了，需要取消作业
（4）10分钟之后作业触发，发送脱鞋通知
以上穿脱N套逻辑在一段代码里如何实现？这真是软开的家常便饭了。自然逻辑里的一个简单诉求，在软开里几乎是虐人，不单这样，对测试部门也是一个压力。
引申——人工智能
大脑是一个复杂的物体，近期很火的自动驾驶，是一个非常复杂的命题，大脑轻易完成的事，用软件来实现将变得非常复杂和困难，大脑的认知和分析是无可比拟的。假如，车前方横出来的一个行人，面对他的走向、速度，司机的反应时间点以及实行正确的处理方式，用软件去完成你说难不难？