從前，有兩個賣水果的公司……

有兩個賣水果的公司，分別是 A 和 B。

前期水果不多，只有蘋果和橘子。

他們分別給用户做了一個線上下單的系統，方便大家買水果。

隨着時間的流逝，A 公司決定改造他們的下單系統，以便和 B 公司進行競爭，於是把頁面改成了這個樣子。

系統會 根據用户歷史購買的水果 ，來智能分析他喜歡吃什麼，然後智能下單購買新的水果。

但目前邏輯還很簡單，單純通過 數量 來決定，比如某用户購買蘋果的數量要多於橘子，系統就認為用户更喜歡吃蘋果，於是便會智能為其下單購買蘋果。

大部分用户都幾乎是嚴重偏好一種水果的，所以 A 公司的系統很方便地幫助了他們省去了下單時填寫的麻煩。A 公司的用户量增長了很多，搶佔了 B 公司的市場。

------

但是，隨着時間的流逝，水果越來越多，不只有蘋果和橘子，還多了香蕉。

買水果的人也越來越多，很多人有了不同的訴求，比如有的人就是想吃一些曾經較少吃的水果，來平衡自己的飲食。

所以，智能下單這個功能，變得越來越不智能了，好多人開始傾向於去簡單明瞭的 B 公司買水果。

A 公司看情況不對，趕緊商量對策，於是增加了一些新功能。

用户可以給之前買過的水果 打標籤 ，比如給蘋果點擊一個 【喜歡】 按鈕，給香蕉點擊一個【 不喜歡】 按鈕。

那麼之後智能購買，就會優先選擇用户標記為喜歡的水果。如果用户沒有標記，則選擇用户曾經購買數量最多的水果。不過如果這個最多的水果恰好是用户標記了不喜歡的水果，那就找倒數第二多的進行購買。

慢慢地，A 公司的系統又變得智能了起來，換來了用户的增長。

------

可好景又不長，有的用户發現，自己給蘋果標記了喜歡，但下單後發現得到的卻是香蕉。

這個 bug 反饋給 A 公司排查後發現，原來該用户不僅給蘋果標記了喜歡，還給香蕉標記了喜歡，而香蕉的購買數量又大於蘋果，所以系統判斷用户更喜歡香蕉。

但該用户實際上是 忘記了自己曾經標記過香蕉 ，所以標記蘋果後，得到了不符合預期的情況。

A 公司迅速做出調整，修改了原有的打標籤邏輯，當用户給一個新的水果點擊喜歡時，自動取消原來水果的喜歡標籤。

但這樣做似乎又不太好，所以再次優化了一下，就是當用户給一個新的水果點擊喜歡時，把原來有喜歡標籤的水果，改為【 上一個喜歡的水果】 標籤。然後如果用户取消了新水果的喜歡標籤時，上一個喜歡的水果，將會再次更改為喜歡。

但又有好多用户反饋，我就是喜歡兩種水果，我希望每次購買的時候多種我喜歡的水果都能自動購買，而不是隻取一個。

A 公司沒辦法，但為了兼容原來的邏輯，只能給用户增加了一個 配置項 ，讓用户決定當給一個新水果打喜歡標籤時，原水果的喜歡標籤是去掉、還是保留、還是變成上一個喜歡的標籤。

一鼓作氣，A 公司又增加了一系列用户可以配置的選項，包括，讓用户決定首選策略，次選策略，兜底策略等。

比如，首選打了喜歡標籤的水果，如果沒有，再次選數量相對多的水果，如果也沒有，那就在剩下的水果裏隨機選一個。

------

A 公司很滿意自己的方案，覺得自己為用户已經無微不至、方方面面都照顧到了，還有兜底方案。

但又有用户對隨機選一個產生了質疑，他們覺得，隨機選一個，還不如給我提示一個錯誤，讓我手動選，不希望將決策權完全交給一個未知的系統。

但還有一部分用户説，隨機選一個方案挺好的，省去了很多麻煩，還能增加一些趣味性，不好麼？

為了照顧不同的用户，A 公司再次增加了一個個性化配置，就是讓用户決定，當所有條件都不滿足，需要隨機選擇一個水果時，是完全隨機選一個，還是輪詢選擇，還是報出錯誤將決策權留給用户。

------

就這樣，A 公司的系統做得越來越複雜，越來越智能，而且還在不斷優化、迭代。

但是，新用户看到 A 公司的系統後，要配置好多信息，每次買水果時還要想着是否打標籤，而且也不知道系統的選擇策略是什麼，學習成本很高。

作為 A 公司系統的開發人員，也越來越難以排查問題，也不知道當一個用户選擇智能購買時，到底會為其推薦哪款水果，因為邏輯已經太過複雜了。

最後，越來越多的人選擇 B 公司來購買水果。

雖然它需要手動輸入水果的名稱，但有 A 公司買水果經驗的用户表示，這都不是事兒。

A 公司始終想不明白，為什麼他們投入了那麼多人力優化系統，而且幾乎照顧到了各種用户的各種刁鑽的需求，可最後還是敗給了什麼都沒做的 B 公司。

- EOF -

伯樂在線

分享IT互聯網職場和精選乾貨文章（原域名已不再維護）。組織 維護10萬+star的開源技術資源庫，包括：Python, Java, C/C++, Go, JS, CSS, Node.js, PHP, .NET 等。

回覆  資源  獲取10萬+star開源資源