企业官网建设流程全解析

目录

一、问题的本质：定制化商品不是“更多SKU”，而是“可组合交易”

（一）从消费体验反推商品模型

1、线下的自由组合与线上的固定规格存在天然张力

2、判断一个字段应不应该进入SKU，要看它是否具有独立经营语义

（二）把“商品”和“成交结果”分开，是模型稳定性的起点

二、为什么“把配料做成销售属性”会必然失控

（一）组合爆炸不是实现细节，而是模型选错后的数学结果

1、传统SKU模型的增长方式是乘法

1.1 组合数量增长快于业务人员的理解能力

1.2 组合模型无法自然表达“默认值”和“份数”

2、动态上下文会让静态SKU穷举进一步失效

（二）SKU的库存语义被稀释，会反过来伤害供应链和数据体系

1、SKU本来应该代表可独立识别的库存或经营单元

2、原材料库存和成品SKU库存应当分层处理

（三）当模型语义错误时，系统会出现一连串“补丁式复杂度”

三、建模转向：用“SKU + 客制化属性”构造最终交易单元

（一）职责分离比新增一个字段更重要

1、SKU继续负责稳定的商品身份

2、客制化属性负责成交时的可选内容

3、客制化规则负责“在什么条件下可以怎么选”

（二）一个可落地的核心对象集合

1、目录层对象

1.1 Product：聚合展示和经营信息

1.2 SKU：可售变体和基础价格

2、配置层对象

2.1 CustomizationGroup：客制化组

2.2 CustomizationOption：具体选项

2.3 CustomizationRule：上下文规则

3、交易层对象

3.1 Selection：用户本次选择

3.2 PriceSnapshot：价格快照

3.3 OrderItemSnapshot：订单商品快照

四、规则模型：从“字段开关”升级为可解释的约束系统

（一）规则的本质是把配置空间裁剪到业务允许的范围

1、先定义可选空间，再定义条件变化

2、规则需要明确优先级，否则“覆盖”会变成不可预测

2.1 默认规则

2.2 SKU覆盖规则

2.3 门店/渠道规则

2.4 交易上下文规则

（二）规则不是越通用越好，而要围绕高频业务模式收敛

1、优先使用结构化规则表达80%的需求

2、复杂表达式只能作为受控扩展

五、价格模型：从“SKU有一个价格”升级为“交易价格可分解、可复现”

（一）实时计价必须先确定价格责任边界

1、基础价属于SKU，增量价属于客制化项

2、默认份数与“已包含份数”必须区分

（二）复杂价格需要从“固定加价”逐步演进，而不是一次做成万能引擎

1、固定单价与阶梯价

2、SKU相关价格

3、组合价格与套餐价格

（三）购物车、下单、退款必须共享同一套计价口径

六、库存与履约：弱库存场景不等于可以忽略资源约束

（一）成品SKU库存、门店产能和原材料库存是三类不同约束

1、成品SKU库存

2、原材料库存

3、产能与设备约束

（二）“客制化属性不进入SKU”并不意味着它脱离供给体系

七、前台交互：一个好模型应该直接生成正确的选择体验

（一）商品模型不只是后台数据结构，它应该驱动前台状态

1、前端不应硬编码某个品牌或品类的选择规则

2、禁用比报错更好的前提，是规则能够提前计算

3、默认选择要可解释，不能偷偷改变成交价

（二）前台选择状态应被视为一个受约束状态机

八、接口与数据结构：让配置、选择和快照在协议层有清晰边界

（一）商品详情接口应返回“可配置视图”，而不是数据库表的直出

1、一个建议的读取模型

2、写入接口只提交“事实”，不要提交客户端计算结果

（二）规则版本是分布式一致性的关键抓手

1、为什么需要configVersion

2、版本不要只靠updatedAt

九、性能与缓存：实时计算不意味着每次都去拼接几十张表

（一）运行时应该消费“编译后的商品配置”，而不是原始运营数据

1、配置态与运行态分离

2、缓存键必须包含影响结果的上下文

（二）规则引擎的性能优化重点不是“算得快”，而是“少算和可预测”

1、建立依赖索引

2、将静态规则提前折叠

3、报价接口要幂等

十、订单快照与可审计性：今天卖出的商品，半年后仍要解释得清

（一）订单不能只保存ID引用

1、商品名称和选项名称都需要快照

2、价格必须保存逐项明细

3、关键规则结果也应快照

（二）修改商品配置时，要明确“新单”和“历史单”的边界

十一、迁移路线：从“配料SKU”平滑切换到客制化属性

（一）第一步不是删SKU，而是识别哪些维度被误建模

1、按业务语义给现有属性分类

2、优先迁移组合爆炸最严重的维度

（二）双轨期要保证老链路可回退

1、建立旧SKU到“基础SKU + Selection”的映射

2、灰度发布时同时比对价格

3、等订单、库存、履约、报表都完成适配后再下线旧SKU

十二、测试体系：定制化模型最需要验证“组合边界”，而不是只测几个样例

（一）规则测试要覆盖边界值和组合关系

1、数量边界

2、联动边界

3、互斥与依赖

（二）价格测试应采用“金丝雀案例 + 属性测试”结合

1、金丝雀案例

2、属性测试

（三）性能测试要贴近用户连续点击的真实节奏

十三、治理与扩展：把“客制化属性”做成能力，而不是新的万能垃圾桶

（一）何时适合使用客制化属性

1、餐饮和现制商品

2、轻定制零售

3、服务型商品

（二）哪些内容仍然应该坚持使用SKU

1、需要独立库存的变体

2、具有长期编码和财务身份的变体

（三）客制化属性必须设置能力边界

1、不要把搜索筛选属性混入客制化

2、不要把营销规则全部塞进客制化规则

3、不要把后厨工艺全文当作前台选项

十四、常见误区：模型重构最容易在这些地方再次走回老路

（一）误区一：只是把“销售属性”改名成“客制化属性”

（二）误区二：客制化属性可以无限嵌套、无限联动

（三）误区三：既然实时计价，就不需要价格版本

（四）误区四：只改商品中心，不改订单和履约

（五）误区五：为了减少SKU，反而把真正的库存变体也客制化

十五、落地方法论：用六个问题判断模型是否健康

（一）面向架构评审的检查框架

1、这个选择是否需要形成长期独立经营单元

2、这个选择是否允许多选、重复或数量变化

3、这个选择是否会被SKU、门店、渠道或时间改变约束

4、价格是否能够逐项解释并在历史订单中复现

5、供给约束究竟属于成品库存、材料库存还是产能

6、前端能否仅依靠服务端元数据完成正确交互

十六、结语：把SKU从“所有选择的容器”还原为稳定的商业身份

可参考文章与文档

干货分享，感谢您的阅读！

在茶饮、咖啡、餐食、烘焙、礼赠等行业里，“商品”正在从一个固定成品，演化为一个可以在交易时被用户重新配置的组合体。杯型、温度、糖度、加料、份数、酱料、制作方式等信息，表面上都像商品属性，但它们的业务语义并不相同：有些决定可独立管理的库存单元，有些只是成交时的个性化选择；有些改变基础价格，有些只产生加价；有些需要控制必选、默认、最大份数，有些还会随着SKU、门店、渠道和时间发生联动。如果把这些差异全部压进传统“销售属性 → SKU”的组合模型，就会快速遭遇SKU数量爆炸、库存语义错位、运营配置困难、价格难以解释、订单历史不可复现等问题。

本文以“客制化属性”这一思路为起点，对原方案进行重新抽象与工程化扩展：保留SKU作为真正可销售、可库存、可履约的核心单元，把加料、做法等交易时选择拆分为独立的客制化属性；再通过规则层、定价层、库存/履约层和交易快照层建立稳定边界。文章进一步给出领域模型、规则建模、实时计价、接口结构、缓存与性能、订单审计、迁移方案和测试体系，目标不是为茶饮单一场景“打补丁”，而是构建一套能够延伸到餐饮、