产品规格变更检查清单：9 个总是改不干净的地方

产品规格变更检查清单不是行政流程，而是一次 20 mm 改动和一整柜索赔之间的距离。改掉一个尺寸，你改动的是一个早就在至少九个地方对外公布过的数字。多数供应商只更新两处：一处是自己还记得的那个商品页字段，另一处不存在。

其余每一处都还在向外播报旧数字。购物 feed、产品图、销售上周发出去的 PDF、外箱唛头、封在箱子里的说明书。它们都不会主动告诉你自己是错的。会告诉你的是买家，而且通常是在柜子已经开船之后。

同一个尺寸会同时存在的 9 个地方

产品规格变更检查清单，就是把尺寸、重量、材质这些数字对外公布过的每一个位置固定成一张表，让一次改动在下游有人发现不一致之前先走完所有位置。下面这张表按"多快会痛"排序。

#	数字所在的位置	字段或载体	谁在看	没更新会出什么事	现实中的修复周期
1	平台商品属性	详情页上展示的商品／产品尺寸	买家，在按下购买之前	尺寸不符退货、"与描述不符"索赔	几分钟
2	平台包装属性	包装尺寸或运输尺寸	承运商和运费计算引擎	运费报价出错、费用对账对不上	几分钟
3	购物 feed	`product_length` / `product_width` / `product_height` / `product_weight`	Google Shopping、比价引擎、AI 导购	商品从按尺寸筛选的结果里掉出去；feed 报警告	下一次 feed 抓取
4	自己网站上的结构化数据	schema.org 的 `width` / `height` / `depth`	搜索引擎和答案引擎	自家官网和自家商品页互相打脸	下一次上线
5	产品图或规格示意图	像素——数字是烧进图里的	每一个买家，而且早于任何文字	页面上最大声的那个错误数字	几天，如果还要设计介入
6	A+ 内容和对比图表	模块文案与模块配图	翻过主图区继续往下看的买家	同一个商品页内部的无声矛盾	几天，往往还要重新审核
7	产品目录、Line Sheet、报价单	团队直接粘进邮件的那份 PDF	B2B 买家、采购代理、经销商	你用白纸黑字报了一个已作废的数字	等谁想起来
8	运输单证和外箱唛头	外箱尺寸、净重与毛重	海关、货代、收货方	装柜方案算错，货被扣或被拒	每一票货
9	说明书、安装图、包装印刷稿	已经印出来、还躺在库里	终端用户，收到货之后	售后工单与一星评价	下一次开印

九个位置，五种不同的责任人，修复周期从几分钟到一整批印刷。产品数据变更管理的全部难点就在这个不对称：几秒钟就能改完的字段，恰恰是你记得住的；要花好几天的，恰恰是买家最先看到的。一份不给每一行写上责任人的产品规格变更检查清单，只是一份愿望清单。

过期的尺寸不会停在数据问题这一层。它会变成一笔退货，而退货的单件成本，多数卖家其实从来没有真的算过——退货成本计算器能把退货率换算成财务部门看得懂、也会有反应的那个数字。

为什么同一件产品会有不止一个正确数字

在盘点这九个位置之前，先接受一个不太舒服的事实：其中两个位置的数字可以互相不一致，而且两个都是对的。管着共享产品数据的 GS1 规则强制规定了取整方式，而且只往一个方向取。

依据 GS1 GDSN 包装测量规则标准（Release 2.5，2016 年 9 月批准）：

毫米一律向上取整到整毫米。99.3 mm 记作 100 mm。
英寸一律向上取整到最接近的 0.05 英寸。2.942 英寸记作 2.95 英寸。
跨制式换算时，先换算再取整，按 1 英寸 = 25.4 mm。
三个线性尺寸必须使用同一套度量制式和同一个单位。
一律量最大距离——凸起、瓶盖、上盖、随包装附带的赠品都算进去，不能略过。

把这几条并着读，结论很清楚。一个 99.3 mm 的零件，在走 GDSN 的系统里公布成 100 mm，在英制市场公布成 3.95 英寸，而你的图纸上写的还是 99.3。三个数字，一个零件，一个错都没有。

这套标准还公布了公差。像箱规单元这种非消费单元的贸易项目，GS1 的标准公差是深、宽、高各 4.0%，下限 0.25 英寸（7 mm），毛重公差 4.0%，下限 0.2 lb（0.1 kg）。小于这个幅度的改动，可能根本不必动箱规数据。大于这个幅度，就意味着所有还存着旧数字的系统不只是"没更新"，而是"超差"。

还有一个合理分歧的来源：轴向命名。GS1 是从产品的默认正面——也就是品牌方拿来推广这件产品的那一面——来判定高、宽、深的。你工厂的图纸几乎可以肯定是从另一个基准去标长、宽、高。哪个轴是哪个、买家为什么会读错顺序，本身就是个坑；在你默认买家会照你写的顺序读那三个数字之前，先看长宽高顺序。

产品尺寸和运输尺寸不是同一个字段

这是整份清单里最常见的失误，因为两个字段都收数字，而且都不会抗议。

Google Merchant Center 把两者完全分开，两组字段连有效取值范围都不一样：

	产品测量属性	运输尺寸属性
属性	`product_length`、`product_width`、`product_height`、`product_weight`	`shipping_length`、`shipping_width`、`shipping_height`
描述什么	产品本身	产品出货时装的那个包裹
可接受单位	cm、in（重量：lb、oz、g、kg）	cm、in
取值范围	cm 与 in 均为 1–3000	1–400 cm、1–150 in
用在哪里	商品曝光与结果准确性	承运商实时计算的运费
硬性规则	三个值要用同一个单位，否则信息不会展示	只要填了任何一个尺寸属性，就必须把其余的都填上

关键线索就在取值范围的差别。一个上限只有 400 cm 的字段，本来就不是拿来放产品尺寸的；一个能接受 3000 cm 的字段，本来也不是拿来算纸箱运费的。如果你团队里有人一直把同一组数字粘进两边，那么此刻其中一组一定是错的。

结构化数据又带进第三套词汇。schema.org 的 Product 有 width、height 和 depth——没有 length 这个属性——每一个都用带 unitCode 的 QuantitativeValue 表达。一次改动、三套命名习惯、三个系统、三个永远看不到彼此屏幕的人。如果这些在你自己网站上还是空的，产品尺寸结构化数据是九个位置里最便宜的一处。

平台还要再加一层麻烦：Amazon 通过 Product Type Definitions API 把每个商品类型的属性以 JSON schema 公布，所以某个商品类型有的尺寸字段，另一个商品类型不一定有。"多平台同步更新产品规格"不是一个动作，是每个 schema 一个动作。

永远轮不到更新的那一处，是图片

回头看那张表。第 1 到第 4 行是文本字段，运营一个上午就能改完。第 7 到第 9 行是文件，而所有人都接受文件本来就要改版。

第 5 行才是那个能错好几年的位置，因为数字活在像素里。要改它，得找到源文件、找到当初做图的人、把要改什么讲清楚、等、确认、再重新上传到每一个渠道。所以大多数公司里诚实的答案是：下次重拍的时候一起改。而下次永远不来。

这很贵，因为图片是买家最先读到、也是最后才有人去核对的东西。规格表会被随手扫过，印在照片上的尺寸会被当真。

务实的做法，是别再把规格示意图当美工件，而当成你数据的一个视图：对着产品真实的边缘量一次，把标注层留成可编辑的活图层、而不是压平进 JPEG，数字一变就按各渠道的图片规格重新导出。这样一来，第 5 行就从一件设计活儿缩成两分钟的编辑——这也是它唯一真的会被做掉的理由。

工具选型决定这件事现不现实。会量的软件——把尺寸线吸附到物体真实的边，并让数字绑在那段几何上——在你改输入时会跟着改对。而只会生成一张看着煞有介事的带标注照片的产生器，什么都没量；它编出一个读起来合理、却无从核对的数字。做营销背景图，这笔交易划算；做一个买家日后会拿来跟你索赔的数字，就不划算。附在报价单后面的规格表也是同一个道理：它的价值不在于看着有设计感，而在于上面每一个数字都能追回到一次实测。

产品规格变更检查清单

把这份产品规格变更检查清单直接贴进你的变更单。一轮走完、四组、谁负责哪一块不用猜。

唯一数据源

改后的数字只记录一次，带版本号和日期，放在其他所有地方都从它复制的那份文件里
单位和度量制式明确写出来（毫米还是英寸——不是只写"1180"）
测量已包含凸起、把手、瓶盖和上盖，符合 GS1 的最大距离规则
已确认这次改动有没有超过 4% / 7 mm 的箱规公差，这决定它必须往下游传多远

买家看得到的字段

每一个平台的商品／产品尺寸都更新了，不是只更新最大的那一个
包装尺寸或运输尺寸单独更新，并确认填的确实是包装的数字
购物 feed 的产品属性已更新；feed 重新抓取，警告逐条看过
自己产品页上的结构化数据已更新

图档与文件

规格示意图或带标注的产品图已重新导出，并重新上传到每一个挂着它的渠道
A+ 内容、对比图表，以及任何含旧数字的图片都已换掉
产品目录、Line Sheet 与报价单模板已重新生成；旧 PDF 从共享盘与邮件模板里删掉

纸质与印刷

装箱单、商业发票与外箱唛头模板已为下一票货更新
说明书、安装图与包装印刷稿已标记到下一次开印，现有库存已盘点
已经发出去、带着作废数字的报价单被逐一找出来，并赶在买家自己发现之前先告知

执行顺序

顺序比速度更重要，因为这些步骤有些会被缓存，有些是给机器读的。

先冻结唯一数据源。 如果还有两个人在改这个数字，下面每一步都会继承这份分歧。
先更新买家看得到的平台字段。 改起来最快，出事也最快。
动 feed 之前先把图重新导出。 feed 和缓存会在同一个周期里一起取到新的图片 URL 和新的数字，中间就不会出现一段不一致的空窗。
推送 feed 并重新抓取。 确认商品没有卡在警告里；被拒绝比数据过期更糟。
重新生成文件。 产品目录、Line Sheet、报价单模板——而且是删掉旧文件，不是改个文件名。
印刷放最后。 整份清单里，只有印刷是不可逆的。

然后做一件几乎没人做的事：搜自己的产品名，用手机、不登录，以买家的身份把自己的商品页读一遍。你漏掉的那处矛盾，大概八秒钟就会自己跳出来。

常见问题

怎么更新商品页面的产品尺寸又不掉排名？

就地改属性。改一个数据字段不等于重新上架，商品页的历史数据会保留。真正伤排名的，是把商品删掉重建、想"从头来过"——那会丢掉评价、销售记录，以及买家已经收藏的那个标识。

商品尺寸和包装尺寸有什么区别？

商品尺寸（产品尺寸）描述产品本身，买家用它判断放不放得下。包装尺寸（运输尺寸）描述它装在什么箱子里走，承运商用它算运费。Google Merchant Center 在 schema 层就把两者切开：product_length 及同组字段最多接受 3000 cm 或英寸，而 shipping_length 及同组字段上限是 400 cm 或 150 英寸。

尺寸变了，产品图一定要改吗？

要，而且它是这份清单里优先级最高的一项，不是最低。印在图上的数字比规格表更早被读到，在纠纷里分量也更重，因为买家可以直接指着它说话。如果你的标注已经压平进 JPEG、没有可编辑的源文件，现在就是把它重建成照片上一层活标注的时候，这样下一次改动只要几分钟。

尺寸要变动到多大，才必须通知买家？

从商务角度看，只要影响装配、间隙或堆叠，就该通知——这是判断，不是阈值。但共享产品数据里有一个公开的参照点：GS1 对箱规单元的标准公差是每个尺寸 4.0%，下限 7 mm。落在这个带宽以内的变动属于数据噪声；超出这个带宽，就意味着所有还存着旧数字的系统全部超差。

该公布毫米还是英寸？

按目标市场要求的制式公布，而且三个轴要用同一个单位——GS1 要求三个线性尺寸共用一套度量制式和一个单位。换算时先换算再取整，按 1 英寸 = 25.4 mm，然后再对该单位套用向上取整的规则。拿一个已经取过整的数字去换算，就是 3 mm 误差变成 6 mm 误差的过程。