为所有空难的遇难者致哀。
3月10日，埃塞俄比亚航空一架737MAX8客机，在起飞阶段坠毁，机上157人全部遇难，有8位是我们的同胞。短短4个半月之前（去年10月29日），印尼狮航的同一机型在起飞阶段坠毁，机上189人遇难。
一般空难多发生在服役多年的老旧机型。737MAX8可是波音力推的新机型，两驾客机分别只有3个月和4个月的机龄。都是在起飞阶段，坠毁前都发生过多次剧烈升降，且机长都报告过操作困难。两起空难的诸多相似点，让大众对波音产生强烈的怀疑。
空难的事故原因认定，可能要花费好几年。但很多行业专家都提出了相对一致的猜测，且在第一次事故发生后就有人提出相同的分析：空难的根源可能是新机型上的（机动特性加强系统）。
（以下内容均为行业专家的推论，最终事故原因要等官方调查结论。）
737MAX8的最大卖点，是配备马力更大的LAEAP-18发动机，“更加节能、噪音更低”。但这款发动机可能会导致机翼产生更大的迎角而失速。为解决该问题，波音增加了MCAS系统。空难很有可能就是因为MCAS误判，不断自动压低机头导致坠毁。
为新型发动机改动机身设计，面临高额的设计、开发、审核、培训承办。选择在经典机型上安装新发动机是个不错的选择。但新型发动机更大，只能提高安装位置，可能会导致俯仰配平性能变化（飞机机翼迎角过高）。为了解决这个问题，波音选择增加MCAS系统。
增加新系统需要对客户进行培训，会增加不少成本，于是波音选择隐瞒（为告知客户，操作手册中也未提到）。这导致一般系统误判，飞行员连发生什么都不知道，更不要说处理问题。系统不但被隐藏，触发之后权限还高于人工操作，不断重复激活压低机头。
针对触发的条件，居然没有对两个传感器的数据进行校验，只要有一个传感器判断即可触发。为什么做出这么愚蠢的设计？还是为了隐藏MCAS，两个传感器数据不一致时，就需要触发人为判断，这不就没法隐藏了么……
我发现这种错误逻辑在很多产品（尤其是企业系统）中存在。尝试假设一个例子，讲述类似的错误。
A公司有一个龙头产品，服务某垂直行业的业务数据分析系统，为分析人员提供数据分析工具。这套系统多年来市场反响不错，但已经逐渐陈旧，随着人工智能技术的逐渐成熟，公司希望研发智能分析算法继续在该应用领域的辉煌成就。
经过技术攻关，公司研发出了想要的分析算法。但是要让算法在产品中体现，要么重构系统，但是周期长成本高。要么在原有系统内迭代，成本更低，周期也短。但是系统迭代时发现，新的算法与原系统部分数据计算有冲突，可能产生数据冗余。为了解决该问题，研发团队在系统中增加一个数据自动校验并删除冗余数据的功能。为了降低培训成本及降低客户对系统不稳定的疑虑，公司选择不对客户声明和培训这个辅助功能。
为了迅速推向市场，相关功能未进行深入的测试和试运行。且对辅助系统误差触发后，对数据可能误删的验证度估计不足。
推向市场之后，不久在一个小客户使用中，第一次出现问题，因为辅助功能判断失误，将客户重要业务分析数据清空。问题发生后A公司推卸责任，也未及时修正错误。
最终，在多个客户之后的使用中，造成了更大损失。
企业应用出现问题不像空难，造成直接的人身伤亡，不管对遇难者还是对家属都是巨大的悲痛和损失。企业应用直接和经济效益挂钩，造成的经济损失也会非常巨大。
例如：光大乌龙指事件。光大投资部的套利策略系统中订单生成功能存在缺陷，导致特定情况下生成预期外的订单。该系统完全独立于公司其他系统，甚至未置于公司风控系统监控下。2013年8月16日上午11时05分08秒之后的2秒内，瞬间重复生成26082笔预期外的委托订单，并被直接发送至交易所。前后共下单230亿，成交72亿，涉及150多只股票，当日盯市损失约为1.94亿元。
因此，设计企业应用系统，尤其是涉及核心业务数据、业务交易、业务保障等方面的系统要尤其谨慎。为节省成本，放弃重构，选择迭代无可厚非。对新功能做出理性判断，增加辅助功能，也是正常思路。但需要认真对待：
- 不隐瞒辅助功能
不光不要隐瞒，最好还要与客户的业务人员深入沟通。毕竟设计人员和实际业务之间有不少信息差。业务人员的反馈，可能会让你提高发现很多隐患。 - 谨慎设计辅助触发条件
辅助功能的触发条件，一定要考虑各种极限和边界情况。当多渠道数据不一致时，要触发人为判断。将核心的判断交给人，而不是机器。 - 控制人工和智能的边界
当前AI技术条件下，智能仍无法替代专业人员，特别是最核心的决策层面。合理限制智能的边界，让其成为辅助专业人员，提高决策效率和质量。
很多悲剧本可避免，利益和短视却带来空难。
愿空难不再有，愿人祸不再来。
