本文詳解了電商系統(tǒng)訂單模塊中的各項流程，包括了訂單的概念、構(gòu)成、狀態(tài)、流程、逆向訂單、訂單拆單等內(nèi)容。

一、訂單概述

電商所有模塊中，訂單模塊是核心中的核心，電商所有模塊都是直接或者間接為訂單模塊服務(wù)的。

訂單模塊看似簡單，很多新人產(chǎn)品經(jīng)理包括我自己，都覺得訂單模塊不就是瀏覽商品、加購、支付、訂單列表不就完了嗎？

后來隨著接觸的增多，發(fā)現(xiàn)訂單模塊并不是想象中的簡單，覺得簡單的只是看到了冰山的海面部分，其龐雜的體系都隱匿在海面一下。今天根據(jù)我的經(jīng)驗，來和大家訂單做詳細的說明。

電商系統(tǒng)涉及到3流，分別時信息流，資金流，物流，而訂單系統(tǒng)作為中樞將三者有機的集合起來，訂單系統(tǒng)就從這三流開始吧。

訂單模塊是電商系統(tǒng)的樞紐，在訂單這個環(huán)節(jié)上需求獲取多個模塊的數(shù)據(jù)和信息，同時對這些信息進行加工處理后流向下個環(huán)節(jié)，這一系列就構(gòu)成了訂單的信息流通。我們從以下幾個環(huán)節(jié)對訂單信息流動進行詳細的說明

1. 訂單場景

訂單場景的說明不言而喻，不同場景下訂單表現(xiàn)形式和數(shù)據(jù)傳遞方式也不相同，目前主流的訂單場景包括線上電商訂單、O2O電商訂單。

（1）線上電商訂單

這種電商就像淘寶、京東等，通過線上下單、支付后由自建物流或者第三方物流進行配送。這種電商系統(tǒng)通過，展示電商系統(tǒng)的商品模塊引導(dǎo)用戶對商品進行訂單模塊的處理，訂單模塊處理完成后將信息傳遞給WMS系統(tǒng)進行處理，當用戶收到貨品后在訂單系統(tǒng)進行確認。通過以上系統(tǒng)的協(xié)同處理來完成整個訂單信息的處理。如果是虛擬物品的話需要調(diào)用其他系統(tǒng)進行對接，通過接口返回參數(shù)方式完成信息的處理，比如充話費、買點卡等。

（2）O2O電商訂單

這種電商包括兩種外賣訂單和團購訂單。

外賣訂單和線上電商訂單有些類似，線上訂單處理完成后只是沒有經(jīng)過倉庫環(huán)節(jié)進行處理，而是需要生產(chǎn)環(huán)節(jié)對數(shù)據(jù)進行處理，生產(chǎn)完成后將信息傳遞給物流環(huán)節(jié)，用戶確認收貨后再對訂單信息進行處理。

而團購訂單則是線上獲取商品信息后，通過訂單系統(tǒng)處理完成，將信息傳遞給wms系統(tǒng)進行庫存處理，只是對庫存進行信息處理而沒有物流配送環(huán)節(jié)，用戶線下到店后對訂單系統(tǒng)進行核銷處理，從而完成整個訂單信息的閉環(huán)。

二、訂單構(gòu)成

我們先從訂單整個架構(gòu)進行了解，以下是整個訂單系統(tǒng)的構(gòu)成：

1. 用戶信息

用戶信息包括用戶賬號、用戶等級、用戶的收貨地址、收貨人、收貨人電話等組成，用戶賬戶需要綁定手機號碼，但是用戶綁定的手機號碼不一定是收貨信息上的電話。用戶可以添加多個收貨信息，用戶等級信息可以用來和促銷系統(tǒng)進行匹配，獲取商品折扣，同時用戶等級還可以獲取積分的獎勵等。

2. 訂單基礎(chǔ)信息

訂單基礎(chǔ)信息是訂單流轉(zhuǎn)的核心，其包括訂單類型、父/子訂單、訂單編號、訂單狀態(tài)、訂單流轉(zhuǎn)的時間等。

（1）訂單類型包括實體商品訂單和虛擬訂單商品等，這個根據(jù)商城商品和服務(wù)類型進行區(qū)分。

（2）同時訂單都需要做父子訂單處理，之前在初創(chuàng)公司一直只有一個訂單，沒有做父子訂單處理后期需要進行拆單的時候就比較麻煩，尤其是多商戶商場，和不同倉庫商品的時候，父子訂單就是為后期做拆單準備的。

（3）訂單編號不多說了，需要強調(diào)的一點是父子訂單都需要有訂單編號，需要完善的時候可以對訂單編號的每個字段進行統(tǒng)一定義和詮釋。

（4）訂單狀態(tài)記錄訂單每次流轉(zhuǎn)過程，后面會對訂單狀態(tài)進行單獨的說明。

（5）訂單流轉(zhuǎn)時間需要記錄下單時間，支付時間，發(fā)貨時間，結(jié)束時間/關(guān)閉時間等等。

3. 商品信息

商品信息從商品庫中獲取商品的SKU信息、圖片、名稱、屬性規(guī)格、商品單價、商戶信息等，從用戶下單行為記錄的用戶下單數(shù)量，商品合計價格等。

4. 優(yōu)惠信息

優(yōu)惠信息記錄用戶參與的優(yōu)惠活動，包括優(yōu)惠促銷活動，比如滿減、滿贈、秒殺等，用戶使用的優(yōu)惠券信息，優(yōu)惠券滿足條件的優(yōu)惠券需要默認展示出來，具體方式已在之前的優(yōu)惠券篇章做過詳細介紹，另外還虛擬幣抵扣信息等進行記錄。

為什么把優(yōu)惠信息單獨拿出來而不放在支付信息里面呢？

因為優(yōu)惠信息只是記錄用戶使用的條目，而支付信息需要加入數(shù)據(jù)進行計算，所以做為區(qū)分。

5. 支付信息

（1）支付流水單號，這個流水單號是在喚起網(wǎng)關(guān)支付后支付通道返回給電商業(yè)務(wù)平臺的支付流水號，財務(wù)通過訂單號和流水單號與支付通道進行對賬使用。

（2）支付方式用戶使用的支付方式，比如微信支付、支付寶支付、錢包支付、快捷支付等。支付方式有時候可能有兩個——余額支付+第三方支付。

（3）商品總金額，每個商品加總后的金額；運費，物流產(chǎn)生的費用；優(yōu)惠總金額，包括促銷活動的優(yōu)惠金額，優(yōu)惠券優(yōu)惠金額，虛擬積分或者虛擬幣抵扣的金額，會員折扣的金額等之和；實付金額，用戶實際需要付款的金額。

6. 物流信息

物流信息包括配送方式，物流公司，物流單號，物流狀態(tài)，物流狀態(tài)可以通過第三方接口來獲取和向用戶展示物流每個狀態(tài)節(jié)點。

三、訂單狀態(tài)

1. 待付款

用戶提交訂單后，訂單進行預(yù)下單，目前主流電商網(wǎng)站都會喚起支付，便于用戶快速完成支付，需要注意的是待付款狀態(tài)下可以對庫存進行鎖定，鎖定庫存需要配置支付超時時間，超時后將自動取消訂單，訂單變更關(guān)閉狀態(tài)。

2. 已付款/待發(fā)貨

用戶完成訂單支付，訂單系統(tǒng)需要記錄支付時間，支付流水單號便于對賬，訂單下放到WMS系統(tǒng)，倉庫進行調(diào)撥，配貨，分揀，出庫等操作。

3. 待收貨/已發(fā)貨

倉儲將商品出庫后，訂單進入物流環(huán)節(jié)，訂單系統(tǒng)需要同步物流信息，便于用戶實時知悉物品物流狀態(tài)

4. 已完成

用戶確認收貨后，訂單交易完成。后續(xù)支付側(cè)進行結(jié)算，如果訂單存在問題進入售后狀態(tài)

5. 已取消

付款之前取消訂單。包括超時未付款或用戶商戶取消訂單都會產(chǎn)生這種訂單狀態(tài)。

6. 售后中

用戶在付款后申請退款，或商家發(fā)貨后用戶申請退換貨。

售后也同樣存在各種狀態(tài)，當發(fā)起售后申請后生成售后訂單，售后訂單狀態(tài)為待審核，等待商家審核，商家審核通過后訂單狀態(tài)變更為待退貨，等待用戶將商品寄回，商家收貨后訂單狀態(tài)更新為待退款狀態(tài)，退款到用戶原賬戶后訂單狀態(tài)更新為售后成功。

四、訂單流程

訂單流程是指從訂單產(chǎn)生到完成整個流轉(zhuǎn)的過程，從而行程了一套標準流程規(guī)則。而不同的產(chǎn)品類型或業(yè)務(wù)類型在系統(tǒng)中的流程會千差萬別，比如上面提到的線上實物訂單和虛擬訂單的流程，線上實物訂單與O2O訂單等，所以需要根據(jù)不同的類型進行構(gòu)建訂單流程。

不管類型如何訂單都包括正向流程和逆向流程，對應(yīng)的場景就是購買商品和退換貨流程，正向流程就是一個正常的網(wǎng)購步驟：訂單生成–>支付訂單–>賣家發(fā)貨–>確認收貨–>交易成功。而每個步驟的背后，訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的，可概括如下圖：

1. 訂單創(chuàng)建

訂單創(chuàng)建是從用戶下單開始的，當用戶對商品進行下單后，系統(tǒng)會引導(dǎo)用戶來到確認訂單頁面，此時系統(tǒng)會獲取用戶預(yù)下單的商品信息，同時判斷商品是否涉及到優(yōu)惠促銷的信息，這些優(yōu)惠券包括促銷活動，優(yōu)惠券，積分抵扣等。

除了獲取優(yōu)惠信息外，還需要判斷用戶等級權(quán)益，比如VIP用戶8折優(yōu)惠，新用戶立減優(yōu)惠等，其中的券別在于一個是針對商品，一個針對的用戶等級權(quán)益，電商系統(tǒng)在開發(fā)初期如果不涉及用戶等級折扣而又有新用戶促活優(yōu)惠的話，建議使用優(yōu)惠券來做。而在優(yōu)惠活動需要遵循配置的疊加規(guī)則和優(yōu)先級規(guī)則，在預(yù)下單操作是需要做判斷。

在預(yù)下單操作時，需要對庫存進行查詢，而庫存從什么時候進行增減，目前主流有兩種方式：

1. 下單減庫存，用戶預(yù)下單成功時減少庫存數(shù)量，優(yōu)點是系統(tǒng)邏輯比較簡單，庫存實時展示用戶體驗好，同時也帶來了惡意下單的風(fēng)險。
2. 付款減庫存，用戶支付完成后再減少庫存，優(yōu)點減少惡意下單的風(fēng)險，缺點是第三方支付回調(diào)采取的是異步回調(diào)方式，回調(diào)結(jié)果返回系統(tǒng)需要時間，并發(fā)下單情況下可能導(dǎo)致庫存不足引發(fā)退款和投訴。

個人比較傾向于下單減庫存的方式，在電商這個競爭激烈的環(huán)境下，保障用戶體驗才是第一位的，同時需要做好相對的措施，預(yù)下單后馬上對庫存進行鎖定，鎖定時間同步訂單支付的限定時間。

比如淘寶的15分鐘，限定時間內(nèi)沒有付款，將鎖定庫存進行回滾釋放。這種下單減庫存的方式，可以減少用戶因為下單后倉庫沒有貨的情況，減少用戶的挫敗感。

2. 訂單支付

訂單支付在支付層面涉及的方面比較多，比如默認支付渠道，支付渠道的路由，組合支付等，在這里就不多加敘述，訂單支付過程做需要選擇支付方式，支付完成后通過支付渠道會返回支付流水號，支付完成時間。系統(tǒng)需要記錄訂單同時生成支付流水，方便與支付渠道進行對賬。

支付完成后下一步是等待賣家發(fā)貨或者是訂單下放到倉庫，在此過程中，會涉及到拆單過程，一般拆單分為兩次拆單：

• 一次拆單：訂單層面的拆單，這個拆單主要是因為組合商品時，各個商品屬于不同商家，此時訂單需要使用父子訂單進行區(qū)分
• 二次拆單：商品層面的拆單，這個拆單由于商品分屬不同的倉庫，重量/體積限制，商品品類要求比如易燃或者貴重物品需要單獨打包，商品庫存原因，比如需要有些商品當天發(fā)生，有些商品48小時后發(fā)送，另外對于海淘來說還存在關(guān)稅問題需要拆單的。

對于拆單后面還會繼續(xù)進行說明。

3. 賣家發(fā)貨/倉儲處理

這個過程從線下走向線下，商家發(fā)貨過程已經(jīng)形成一個標準化的流程，訂單內(nèi)容會下放到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送。

目前很多WMS系統(tǒng)都與主流電商系統(tǒng)進行了對接，訂單下單成功后直接進入到WMS系統(tǒng)，在此過程中會涉及到合并訂單，比如同一買家同一收貨信息分多筆下單的訂單，訂單審核，訂單重新分倉，下放庫房，生成批檢單，訂單打印等等。關(guān)于物流倉儲方面后面物流篇講進行詳述。

4. 確認收貨

訂單通過倉儲環(huán)節(jié)，已經(jīng)發(fā)貨了，在訂單系統(tǒng)中會涉及到對物流信息的獲取，包括配送方式/物流公司/物流單號/物流狀態(tài)的實時顯示。

記得淘寶沒有打通物流查詢環(huán)節(jié)時，那時候想知道包裹到哪里，需要根據(jù)商家提供的物流公司和物流單號，在物流公司官網(wǎng)進行查詢，而現(xiàn)在很多物流公司開放了物流接口，可以根據(jù)物流接口獲取物流狀態(tài)信息。當用戶收到貨后，可以根據(jù)物流公司反饋的簽收結(jié)果，設(shè)置提醒用戶確認收貨。

5. 訂單完成

用戶確認收貨后，這個訂單總算完了，NO,NO,NO，演出才剛剛開始。

訂單完成后會涉及到需要提醒用戶進行訂單的點評，同時可能會涉及到訂單的售后問題。

交易成功是指在收貨后N天后，此時除去售后問題外，渠道側(cè)會涉及到平臺和支付渠道結(jié)算的問題，貨款需要從支付渠道流入平臺賬戶；商戶側(cè)會涉及到平臺需要生成待結(jié)算清單問題，明細該筆訂單商戶結(jié)算款是多少。如果涉及到三級分銷的話，還需要考慮到各級代理分潤問題。

五、逆向訂單

訂單逆向過程是個非常頭痛的問題，每次涉及訂單的時候，每次都傻傻地問boss可以不做退款退貨流程嗎？

老板很鄙夷地回答：沒有買賣就沒有傷害。有人的地方就有江湖，有訂單的地方就有退款退貨一個道理，所以安心設(shè)計好逆向流程才是王道。

關(guān)于訂單逆向流程，想想線下一些購買場景理解起來就方便很多了，接下來就舉例說明逆向訂單：

大傻去電腦城去買個筆記本電腦，在千挑萬選后終于在奸商小K的說服下，準備下單購買一臺聯(lián)想小新air，故事就這么發(fā)生了……

CASE1 修改訂單

這個時候在小K的說服下大傻選購小新air，突然大傻對小新air配置還有一些優(yōu)惠提出了新的疑問，好吧……正準備開單的小K為了促成這個交易在單子上面給大傻填寫贈送鼠標，背包…

修改訂單發(fā)生在預(yù)下單過程中，用戶沒有提交訂單，可以對訂單一些信息進行修改，比如配送信息，優(yōu)惠信息，及其他一些訂單可修改范圍的內(nèi)容，此時只需對數(shù)據(jù)進行變更即可。

CASE2 訂單取消

待支付情況下，各種單據(jù)都填好了，小K說：哥，你該付款了。大傻一摸口袋，錢包不見了。小K心里想，哥，你逗我玩呢？

這個時候有3種情況：

第一，大傻回去拿錢后給了小K錢。

第二，大傻說這個電腦不要了，單據(jù)作廢吧。

第三，大傻說我回去拿錢，返回后結(jié)果門店下班了，單據(jù)也作廢了。

這個狀態(tài)下對應(yīng)電商場景下的 用戶主動取消訂單和用戶超時未支付，兩種情況下訂單都會取消訂單，而超時情況是系統(tǒng)自動關(guān)閉訂單，所以在訂單支付的響應(yīng)機制上面要做支付的限時處理，尤其是在前面說的下單減庫存的情形下面，可以保證快速的釋放庫存。

另外需要需要處理的是促銷優(yōu)惠中使用的優(yōu)惠券，權(quán)益等視平臺規(guī)則，進行相應(yīng)補回給用戶。

CASE3 退款

待發(fā)貨情況下，大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了，結(jié)果跑到倉庫拿貨，倉庫告訴小K沒有貨了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好回去告訴大傻，完了大傻對小K一頓咆哮，最終小K還是把錢退給了大傻。

故事還有另外一個版本：大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了。還沒有到倉庫，前臺小姐姐給他打電話，大傻說隔壁王阿姨的姑姑的表姐的女兒出了車禍要借錢，所以大傻不要筆記本了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好給大傻退款。

在待發(fā)貨訂單狀態(tài)下取消訂單時，分為商戶缺貨退款和用戶申請退款。

• 商戶缺貨退款由于訂單系統(tǒng)和WMS系統(tǒng)商品沒有進行及時同步導(dǎo)致，或者是倉管和客服分開產(chǎn)生的，這個情況下需要與用戶協(xié)商處理退款。
• 用戶申請退款，用戶下單后，商家還未發(fā)貨，系統(tǒng)應(yīng)該支持用戶申請退款，如果發(fā)貨單已經(jīng)下發(fā)到wms系統(tǒng)，但是尚未推送至倉庫，則應(yīng)該挺推送至倉庫，推送至倉庫則需要WMS中進行攔截，攔截成功則暫定出庫，同步訂單系統(tǒng) 同意取消訂單，同時進入退款流程。

如果是全部退款則訂單更新為關(guān)閉狀態(tài)，若只是做部分退款則訂單仍需進行進行，同時生成一條退款的售后訂單，走退款流程。退款金額需原路返回用戶的賬戶。

CASE4 發(fā)貨后的退款

我們繼續(xù)那個故事：當小K從倉庫將筆記本電腦領(lǐng)出來后，將電腦拿給大傻，大傻一看包裝破破爛爛的啥玩意啊，老子不要了，不管小K好說歹說，大傻堅決不要了，拗不過他，小K最終還是給大傻退了錢。

發(fā)貨后的退款，發(fā)生在倉儲已經(jīng)貨物的配送，在配送過程中商品遺失，用戶拒收，用戶收貨后對商品不滿意，這樣情況下用戶發(fā)起退款的售后訴求后，需要商戶進行退款的審核，雙方達成一致后，系統(tǒng)更新退款狀態(tài)，對訂單進行退款操作，金額原路返回用戶的賬戶，同時關(guān)閉原訂單數(shù)據(jù)。

僅退款情況下暫不考慮倉庫系統(tǒng)變化。如果發(fā)生雙方協(xié)調(diào)不一致情況下，可以申請平臺客服介入。在退款訂單商戶不處理的情況下，系統(tǒng)需要做限期判斷，比如5天商戶不處理，退款單自動變更同意退款。

CASE5 退款退貨

故事還沒有完，大傻沒有在小K家買成筆記本，又去了阿貍家買成了筆記本電腦，誰知道阿貍家筆記本更黑，翻新機做新機賣給大傻，大傻回去后筆記本沒用到1晚上就直接掛了。

火大的大傻第二天就找到阿貍要退貨，阿貍各種忽悠還是沒有忽悠到大傻這顆要退款退貨執(zhí)著的心，萬般不情愿下阿貍終于將筆記本重新入庫后，給大傻退了錢。

用戶退款退貨的流程和用戶僅退款的流程差不多，需要與商戶進行協(xié)商，如果協(xié)商過程存在爭議平臺客服介入進行協(xié)調(diào)。如無爭議，商戶審核通過后告知用戶退貨流程及退回的收件信息，進入退貨流程后，商家收到用戶退貨商品后，庫存系統(tǒng)進行補回，退貨入庫，訂單系統(tǒng)確認后進行退款，同時關(guān)閉訂單。

當訂單中發(fā)生部分退貨時，原訂單的狀態(tài)不變，維持待收貨或交易成功狀態(tài)，同時退貨的部分生成交易售后訂單。剩余未退貨部分仍然允許申請售后。如果退貨商品在驗收環(huán)節(jié)存在用戶導(dǎo)致的問題，可以通過線下協(xié)商后，將商品重新發(fā)回給用戶，或者進行退部分款項。

之前在聊促銷活動時，說到過優(yōu)惠金額的處理方式，之前只是針對平臺類和單店鋪模式進行說明，本節(jié)對優(yōu)惠券和促銷進行訂單逆向的退款退貨進行說明，主要進行部分退款進行說明。

講解前先列公式，便于計算：

好了公式列完了開始講故事了：

618大促時夏天正好快到了，王小胖在某商城進行血拼，在618之前王小胖已經(jīng)領(lǐng)取幾張優(yōu)惠券分別時平臺服飾類優(yōu)惠券滿500減50，小貓門店滿800減200優(yōu)惠券，小花花門店滿400減100優(yōu)惠券。

以下就是羅列每件商品的優(yōu)惠券金額和實付金額：

如果王小胖對小貓門店休閑長褲不滿意，退款只需要退款149.31元即可。

到這里關(guān)于訂單正向和逆向流程已經(jīng)說明完畢，拋出一個問題，如果同一個SKU里面有多件商品，需要對某件商品進行退款怎么操作？

六、訂單拆單

為什么要拆單呢？

因為電商平臺存在購物車進行合并付款，如果不拆單會遇到無法跟蹤物流或者會存在多個物流，另外做結(jié)算時不方便進行核賬等，哪怕時同一家店鋪也會存在發(fā)貨時間、分不同物流發(fā)貨問。這個時候我們需要進行拆單。

從訂單表層面，我們需要將訂單建立父子訂單，加購后提交訂單時需要創(chuàng)建父子訂單和編號，這個從用戶體驗角度來說方便用戶進合并付款，減少用戶操作提高轉(zhuǎn)化率。

拆單的原因包括：

• 店鋪：在多商戶商場下，商品歸屬不同商戶，所以涉及到商戶后臺的財務(wù)結(jié)算和物流發(fā)貨問題。
• 倉庫：商品不在同一個倉庫時需要按照倉庫歸屬進行拆單
• 屬性：有些商品需要單獨運配送，購買沙發(fā)和衣柜都需要獨立包裝，商品不在一起需要進行拆單
• 價值：這個涉及跨進電商，政策對跨境電商有單次限額，超過金額翻，也需要對訂單進行拆單。

第一次拆單 訂單層面拆單

訂單層面拆單主要加購下單后存在上面說的對應(yīng)不同的商戶和不同倉庫，用戶完成支付后可以訂單中有多個不同的子訂單。

父訂單是記錄一次下單和合并支付的依據(jù)，同樣在促銷層面來說可以通過父訂單享受購物的優(yōu)惠，然后通過子訂單進行分攤，而子訂單是跟蹤物流，售后、結(jié)算的依據(jù)。所以在設(shè)計訂單設(shè)計需要所有訂單都設(shè)計父子訂單。

從物流層面來說訂單生成后，訂單會進行下放。對于平臺會將訂單推送到調(diào)度系統(tǒng)進行處理，多商戶商城可以將訂單導(dǎo)出安排發(fā)貨，在更新發(fā)貨信息；自接系統(tǒng)會將訂單同步WMS系統(tǒng)或者ERP里，安排發(fā)貨。

第二次拆單 物流層面拆單

訂單推送至調(diào)度層后，調(diào)度中心需要進行審核處理，審核通過后訂單開始進行調(diào)撥和配貨，這個時候需要倉儲需要根據(jù)發(fā)貨單進行拆單，這次拆單會包括商品屬性/價值/體積/重量/庫存進行拆單，子訂單包括多個包裝，也存在多個物流信息。

以上就是整個訂單信息流的說明，關(guān)于訂單還包括訂單結(jié)算，訂單支付等流程，這塊屬于支付和結(jié)算體系需要考慮的范疇，有機會再后面會進行支付和結(jié)算體系的說明。

作者：產(chǎn)品_空，微信號king_mario

本文由 @產(chǎn)品_空 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理 ，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 unsplash，基于 CC0 協(xié)議