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

有兩個賣水果的公司，分別是 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開源資源