目錄一、問題的本質(zhì)：定制化商品不是“更多SKU”，而是“可組合交易”（一）從消費(fèi)體驗(yàn)反推商品模型1、線下的自由組合與線上的固定規(guī)格存在天然張力2、判斷一個(gè)字段應(yīng)不應(yīng)該進(jìn)入SKU，要看它是否具有獨(dú)立經(jīng)營語義（二）把“商品”和“成交結(jié)果”分開，是模型穩(wěn)定性的起點(diǎn)二、為什么“把配料做成銷售屬性”會必然失控（一）組合爆炸不是實(shí)現(xiàn)細(xì)節(jié)，而是模型選錯(cuò)后的數(shù)學(xué)結(jié)果1、傳統(tǒng)SKU模型的增長方式是乘法1.1 組合數(shù)量增長快于業(yè)務(wù)人員的理解能力1.2 組合模型無法自然表達(dá)“默認(rèn)值”和“份數(shù)”2、動態(tài)上下文會讓靜態(tài)SKU窮舉進(jìn)一步失效（二）SKU的庫存語義被稀釋，會反過來傷害供應(yīng)鏈和數(shù)據(jù)體系1、SKU本來應(yīng)該代表可獨(dú)立識別的庫存或經(jīng)營單元2、原材料庫存和成品SKU庫存應(yīng)當(dāng)分層處理（三）當(dāng)模型語義錯(cuò)誤時(shí)，系統(tǒng)會出現(xiàn)一連串“補(bǔ)丁式復(fù)雜度”三、建模轉(zhuǎn)向：用“SKU + 客制化屬性”構(gòu)造最終交易單元（一）職責(zé)分離比新增一個(gè)字段更重要1、SKU繼續(xù)負(fù)責(zé)穩(wěn)定的商品身份2、客制化屬性負(fù)責(zé)成交時(shí)的可選內(nèi)容3、客制化規(guī)則負(fù)責(zé)“在什么條件下可以怎么選”（二）一個(gè)可落地的核心對象集合1、目錄層對象1.1 Product：聚合展示和經(jīng)營信息1.2 SKU：可售變體和基礎(chǔ)價(jià)格2、配置層對象2.1 CustomizationGroup：客制化組2.2 CustomizationOption：具體選項(xiàng)2.3 CustomizationRule：上下文規(guī)則3、交易層對象3.1 Selection：用戶本次選擇3.2 PriceSnapshot：價(jià)格快照3.3 OrderItemSnapshot：訂單商品快照四、規(guī)則模型：從“字段開關(guān)”升級為可解釋的約束系統(tǒng)（一）規(guī)則的本質(zhì)是把配置空間裁剪到業(yè)務(wù)允許的范圍1、先定義可選空間，再定義條件變化2、規(guī)則需要明確優(yōu)先級，否則“覆蓋”會變成不可預(yù)測2.1 默認(rèn)規(guī)則2.2 SKU覆蓋規(guī)則2.3 門店/渠道規(guī)則2.4 交易上下文規(guī)則（二）規(guī)則不是越通用越好，而要圍繞高頻業(yè)務(wù)模式收斂1、優(yōu)先使用結(jié)構(gòu)化規(guī)則表達(dá)80%的需求2、復(fù)雜表達(dá)式只能作為受控?cái)U(kuò)展五、價(jià)格模型：從“SKU有一個(gè)價(jià)格”升級為“交易價(jià)格可分解、可復(fù)現(xiàn)”（一）實(shí)時(shí)計(jì)價(jià)必須先確定價(jià)格責(zé)任邊界1、基礎(chǔ)價(jià)屬于SKU，增量價(jià)屬于客制化項(xiàng)2、默認(rèn)份數(shù)與“已包含份數(shù)”必須區(qū)分（二）復(fù)雜價(jià)格需要從“固定加價(jià)”逐步演進(jìn)，而不是一次做成萬能引擎1、固定單價(jià)與階梯價(jià)2、SKU相關(guān)價(jià)格3、組合價(jià)格與套餐價(jià)格（三）購物車、下單、退款必須共享同一套計(jì)價(jià)口徑六、庫存與履約：弱庫存場景不等于可以忽略資源約束（一）成品SKU庫存、門店產(chǎn)能和原材料庫存是三類不同約束1、成品SKU庫存2、原材料庫存3、產(chǎn)能與設(shè)備約束（二）“客制化屬性不進(jìn)入SKU”并不意味著它脫離供給體系七、前臺交互：一個(gè)好模型應(yīng)該直接生成正確的選擇體驗(yàn)（一）商品模型不只是后臺數(shù)據(jù)結(jié)構(gòu)，它應(yīng)該驅(qū)動前臺狀態(tài)1、前端不應(yīng)硬編碼某個(gè)品牌或品類的選擇規(guī)則2、禁用比報(bào)錯(cuò)更好的前提，是規(guī)則能夠提前計(jì)算3、默認(rèn)選擇要可解釋，不能偷偷改變成交價(jià)（二）前臺選擇狀態(tài)應(yīng)被視為一個(gè)受約束狀態(tài)機(jī)八、接口與數(shù)據(jù)結(jié)構(gòu)：讓配置、選擇和快照在協(xié)議層有清晰邊界（一）商品詳情接口應(yīng)返回“可配置視圖”，而不是數(shù)據(jù)庫表的直出1、一個(gè)建議的讀取模型2、寫入接口只提交“事實(shí)”，不要提交客戶端計(jì)算結(jié)果（二）規(guī)則版本是分布式一致性的關(guān)鍵抓手1、為什么需要configVersion2、版本不要只靠updatedAt九、性能與緩存：實(shí)時(shí)計(jì)算不意味著每次都去拼接幾十張表（一）運(yùn)行時(shí)應(yīng)該消費(fèi)“編譯后的商品配置”，而不是原始運(yùn)營數(shù)據(jù)1、配置態(tài)與運(yùn)行態(tài)分離2、緩存鍵必須包含影響結(jié)果的上下文（二）規(guī)則引擎的性能優(yōu)化重點(diǎn)不是“算得快”，而是“少算和可預(yù)測”1、建立依賴索引2、將靜態(tài)規(guī)則提前折疊3、報(bào)價(jià)接口要冪等十、訂單快照與可審計(jì)性：今天賣出的商品，半年后仍要解釋得清（一）訂單不能只保存ID引用1、商品名稱和選項(xiàng)名稱都需要快照2、價(jià)格必須保存逐項(xiàng)明細(xì)3、關(guān)鍵規(guī)則結(jié)果也應(yīng)快照（二）修改商品配置時(shí)，要明確“新單”和“歷史單”的邊界十一、遷移路線：從“配料SKU”平滑切換到客制化屬性（一）第一步不是刪SKU，而是識別哪些維度被誤建模1、按業(yè)務(wù)語義給現(xiàn)有屬性分類2、優(yōu)先遷移組合爆炸最嚴(yán)重的維度（二）雙軌期要保證老鏈路可回退1、建立舊SKU到“基礎(chǔ)SKU + Selection”的映射2、灰度發(fā)布時(shí)同時(shí)比對價(jià)格3、等訂單、庫存、履約、報(bào)表都完成適配后再下線舊SKU十二、測試體系：定制化模型最需要驗(yàn)證“組合邊界”，而不是只測幾個(gè)樣例（一）規(guī)則測試要覆蓋邊界值和組合關(guān)系1、數(shù)量邊界2、聯(lián)動邊界3、互斥與依賴（二）價(jià)格測試應(yīng)采用“金絲雀案例 + 屬性測試”結(jié)合1、金絲雀案例2、屬性測試（三）性能測試要貼近用戶連續(xù)點(diǎn)擊的真實(shí)節(jié)奏十三、治理與擴(kuò)展：把“客制化屬性”做成能力，而不是新的萬能垃圾桶（一）何時(shí)適合使用客制化屬性1、餐飲和現(xiàn)制商品2、輕定制零售3、服務(wù)型商品（二）哪些內(nèi)容仍然應(yīng)該堅(jiān)持使用SKU1、需要獨(dú)立庫存的變體2、具有長期編碼和財(cái)務(wù)身份的變體（三）客制化屬性必須設(shè)置能力邊界1、不要把搜索篩選屬性混入客制化2、不要把營銷規(guī)則全部塞進(jìn)客制化規(guī)則3、不要把后廚工藝全文當(dāng)作前臺選項(xiàng)十四、常見誤區(qū)：模型重構(gòu)最容易在這些地方再次走回老路（一）誤區(qū)一：只是把“銷售屬性”改名成“客制化屬性”（二）誤區(qū)二：客制化屬性可以無限嵌套、無限聯(lián)動（三）誤區(qū)三：既然實(shí)時(shí)計(jì)價(jià)，就不需要價(jià)格版本（四）誤區(qū)四：只改商品中心，不改訂單和履約（五）誤區(qū)五：為了減少SKU，反而把真正的庫存變體也客制化十五、落地方法論：用六個(gè)問題判斷模型是否健康（一）面向架構(gòu)評審的檢查框架1、這個(gè)選擇是否需要形成長期獨(dú)立經(jīng)營單元2、這個(gè)選擇是否允許多選、重復(fù)或數(shù)量變化3、這個(gè)選擇是否會被SKU、門店、渠道或時(shí)間改變約束4、價(jià)格是否能夠逐項(xiàng)解釋并在歷史訂單中復(fù)現(xiàn)5、供給約束究竟屬于成品庫存、材料庫存還是產(chǎn)能6、前端能否僅依靠服務(wù)端元數(shù)據(jù)完成正確交互十六、結(jié)語：把SKU從“所有選擇的容器”還原為穩(wěn)定的商業(yè)身份可參考文章與文檔干貨分享，感謝您的閱讀！在茶飲、咖啡、餐食、烘焙、禮贈等行業(yè)里，“商品”正在從一個(gè)固定成品，演化為一個(gè)可以在交易時(shí)被用戶重新配置的組合體。杯型、溫度、糖度、加料、份數(shù)、醬料、制作方式等信息，表面上都像商品屬性，但它們的業(yè)務(wù)語義并不相同：有些決定可獨(dú)立管理的庫存單元，有些只是成交時(shí)的個(gè)性化選擇；有些改變基礎(chǔ)價(jià)格，有些只產(chǎn)生加價(jià)；有些需要控制必選、默認(rèn)、最大份數(shù)，有些還會隨著SKU、門店、渠道和時(shí)間發(fā)生聯(lián)動。如果把這些差異全部壓進(jìn)傳統(tǒng)“銷售屬性 → SKU”的組合模型，就會快速遭遇SKU數(shù)量爆炸、庫存語義錯(cuò)位、運(yùn)營配置困難、價(jià)格難以解釋、訂單歷史不可復(fù)現(xiàn)等問題。本文以“客制化屬性”這一思路為起點(diǎn)，對原方案進(jìn)行重新抽象與工程化擴(kuò)展：保留SKU作為真正可銷售、可庫存、可履約的核心單元，把加料、做法等交易時(shí)選擇拆分為獨(dú)立的客制化屬性；再通過規(guī)則層、定價(jià)層、庫存/履約層和交易快照層建立穩(wěn)定邊界。文章進(jìn)一步給出領(lǐng)域模型、規(guī)則建模、實(shí)時(shí)計(jì)價(jià)、接口結(jié)構(gòu)、緩存與性能、訂單審計(jì)、遷移方案和測試體系，目標(biāo)不是為茶飲單一場景“打補(bǔ)丁”，而是構(gòu)建一套能夠延伸到餐飲、