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