有两个卖水果的公司，分别是 A 和 B。
他们分别给用户做了一个线上下单的系统，方便大家买水果。
随着时间的流逝，A 公司决定改造他们的下单系统，以便和 B 公司进行竞争，于是把页面改成了这个样子。
系统会根据用户历史购买的水果，来智能分析他喜欢吃什么，然后智能下单购买新的水果。但目前逻辑还很简单，单纯通过数量来决定，比如某用户购买苹果的数量要多于橘子，系统就认为用户更喜欢吃苹果，于是便会智能为其下单购买苹果。大部分用户都几乎是严重偏好一种水果的，所以 A 公司的系统很方便地帮助了他们省去了下单时填写的麻烦。A 公司的用户量增长了很多，抢占了 B 公司的市场。但是，随着时间的流逝，水果越来越多，不只有苹果和橘子，还多了香蕉。买水果的人也越来越多，很多人有了不同的诉求，比如有的人就是想吃一些曾经较少吃的水果，来平衡自己的饮食。所以，智能下单这个功能，变得越来越不智能了，好多人开始倾向于去简单明了的 B 公司买水果。A 公司看情况不对，赶紧商量对策，于是增加了一些新功能。用户可以给之前买过的水果打标签，比如给苹果点击一个【喜欢】按钮，给香蕉点击一个【不喜欢】按钮。那么之后智能购买，就会优先选择用户标记为喜欢的水果。如果用户没有标记，则选择用户曾经购买数量最多的水果。不过如果这个最多的水果恰好是用户标记了不喜欢的水果，那就找倒数第二多的进行购买。慢慢地，A 公司的系统又变得智能了起来，换来了用户的增长。可好景又不长，有的用户发现，自己给苹果标记了喜欢，但下单后发现得到的却是香蕉。这个 bug 反馈给 A 公司排查后发现，原来该用户不仅给苹果标记了喜欢，还给香蕉标记了喜欢，而香蕉的购买数量又大于苹果，所以系统判断用户更喜欢香蕉。但该用户实际上是忘记了自己曾经标记过香蕉，所以标记苹果后，得到了不符合预期的情况。A 公司迅速做出调整，修改了原有的打标签逻辑，当用户给一个新的水果点击喜欢时，自动取消原来水果的喜欢标签。但这样做似乎又不太好，所以再次优化了一下，就是当用户给一个新的水果点击喜欢时，把原来有喜欢标签的水果，改为【上一个喜欢的水果】标签。然后如果用户取消了新水果的喜欢标签时，上一个喜欢的水果，将会再次更改为喜欢。但又有好多用户反馈，我就是喜欢两种水果，我希望每次购买的时候多种我喜欢的水果都能自动购买，而不是只取一个。A 公司没办法，但为了兼容原来的逻辑，只能给用户增加了一个配置项，让用户决定当给一个新水果打喜欢标签时，原水果的喜欢标签是去掉、还是保留、还是变成上一个喜欢的标签。
一鼓作气，A 公司又增加了一系列用户可以配置的选项，包括，让用户决定首选策略，次选策略，兜底策略等。比如，首选打了喜欢标签的水果，如果没有，再次选数量相对多的水果，如果也没有，那就在剩下的水果里随机选一个。A 公司很满意自己的方案，觉得自己为用户已经无微不至、方方面面都照顾到了，还有兜底方案。但又有用户对随机选一个产生了质疑，他们觉得，随机选一个，还不如给我提示一个错误，让我手动选，不希望将决策权完全交给一个未知的系统。但还有一部分用户说，随机选一个方案挺好的，省去了很多麻烦，还能增加一些趣味性，不好么？为了照顾不同的用户，A 公司再次增加了一个个性化配置，就是让用户决定，当所有条件都不满足，需要随机选择一个水果时，是完全随机选一个，还是轮询选择，还是报出错误将决策权留给用户。就这样，A 公司的系统做得越来越复杂，越来越智能，而且还在不断优化、迭代。但是，新用户看到 A 公司的系统后，要配置好多信息，每次买水果时还要想着是否打标签，而且也不知道系统的选择策略是什么，学习成本很高。作为 A 公司系统的开发人员，也越来越难以排查问题，也不知道当一个用户选择智能购买时，到底会为其推荐哪款水果，因为逻辑已经太过复杂了。
虽然它需要手动输入水果的名称，但有 A 公司买水果经验的用户表示，这都不是事儿。A 公司始终想不明白，为什么他们投入了那么多人力优化系统，而且几乎照顾到了各种用户的各种刁钻的需求，可最后还是败给了什么都没做的 B 公司。
- EOF -
伯乐在线
分享IT互联网职场和精选干货文章（原域名已不再维护）。组织维护10万+star的开源技术资源库，包括：Python, Java, C/C++, Go, JS, CSS, Node.js, PHP, .NET 等。
回复 资源 获取10万+star开源资源