目录
一、先重述问题：多品类系统真正的瓶颈不是字段不足，而是语义失控
（一）从“增加字段”开始的系统，往往会在品类扩张时失速
（二）模型升级的目标，不是“无限灵活”，而是建立受治理的可变性
二、先拆清语义：商品不是一张表，而是一组职责不同的实体
（一）属性分类的价值，在于明确“谁负责、何时变、被谁消费”
（二）产品、规格、报价、库存四层分离，是多渠道零售的基本盘
1、Product：描述“它是什么”
2、SKU：描述“具体卖的是哪个变体”
3、Offer：描述“谁以什么条件卖它”
4、Inventory：描述“在某个履约节点还能卖多少”
三、通用类目属性模型：Category、Property、Value、Template 四个核心对象
（一）后台类目不是导航菜单，而是平台内部的稳定语义坐标
（二）Property 与 Property Value：属性本身必须拥有数据类型和业务语义
1、Property：不是一个字段名，而是一份可执行的元数据定义
1.1 基础定义
1.2 值域与输入约束
1.3 使用角色
2、Property Value：离散值要被治理，而不是随意写字符串
（三）Template：模板的本质是“类目语义合同”，而不是字段集合
四、为什么不能只选 CPV 或 EAV：工程上需要“核心强模型 + 受约束扩展模型”
（一）三种常见方案的优缺点
（二）推荐混合架构：不要让灵活性污染所有查询
五、模板不应只是“属性清单”：约束系统决定商品模型能否真正配置化
（一）从 required/optional 升级到条件约束
（二）模板的六类配置能力
1、数据约束
2、表单行为
3、业务角色
4、数据来源
5、权限与审核
6、输出映射
六、规格轴是最容易被低估的部分：SKU 变体必须被当作组合约束处理
（一）“颜色、尺码”不是普通属性，它们会改变可售实体数量
（二）规格建模至少要满足四条不变量
七、从配置到业务：元数据驱动必须贯穿运营端、商家端和用户端
（一）运营端：把行业知识从需求文档变成可发布的元数据
（二）商家端：动态表单只是表象，实时校验才是核心
（三）用户端：不要直接“渲染数据库字段”，而是消费语义化读模型
八、存储设计：把“原始值、标准值、展示值”分开，避免后期数据清洗地狱
（一）属性值至少要保存三种语义
（二）属性值表不要只设计成 varchar
1、按类型拆列或拆表
2、多值属性使用关联记录，不要拼接字符串
3、单位必须标准化
九、索引与搜索：属性体系的商业价值，最终体现在可发现性上
（一）不是所有属性都应该进搜索索引
（二）属性标准化直接决定搜索质量
十、数据治理：真正难的不是建模，而是让模型三年后仍然可用
（一）类目和属性必须有版本，而不是直接原地修改
（二）属性删除应采用“弃用”而不是物理删除
（三）建立可度量的数据质量体系
十一、多业务线复用：模板需要“继承 + 覆盖”，但必须限制自由度
（一）为什么需要继承
（二）继承的风险：配置系统也会出现“面向对象地狱”
十二、跨渠道商品分发：内部模型要稳定，对外模型要可映射
（一）不要直接把内部属性编码暴露给外部渠道
（二）标准标识符是跨系统连接的关键
十三、面向AI时代的扩展：类目属性体系将从“表单元数据”升级为“商品知识底座”
（一）LLM 可以提高属性生产效率，但不能绕开标准化
（二）属性语义需要机器可理解的描述
十四、迁移策略：不要试图一次性重构全量商品系统
（一）第一阶段：先建立元数据旁路，不改交易主链路
（二）第二阶段：建设统一读模型和搜索索引
（三）第三阶段：拆分交易、库存、履约职责
（四）第四阶段：建立跨渠道与AI能力
十五、落地时最值得警惕的十个反模式
（一）反模式清单
十六、结论：好的商品模型，不是“最通用”，而是让变化有边界、让语义可复用
可参考文章与标准
干货分享，感谢您的阅读！
多业态零售平台的商品系统，最难的并不是“再加几个字段”，而是如何在餐饮、商超、生鲜、医药、服饰、3C、图书等差异巨大的行业之间建立一套稳定、可演进、可治理的商品语义底座。
本文以“类目—属性—属性值—模板”这一通用抽象为起点，进一步讨论商品、规格、报价、库存、履约、内容与搜索之间的实体边界，给出元数据驱动的模型设计、约束表达、存储索引、版本治理、迁移策略以及面向搜索和生成式AI的扩展方法。
我们不追求复刻某一平台的历史实现，而是试图回答一个更普遍的问题：当业务从单一品类走向多品类、多业态、多渠道时，商品模型应如何从“业务表结构”升级为“企业级商品知识底座”。
