设备外形参数被 AI 搜索答错三周之后：Product 的 height 与 weight 字段结构化对照

设备外形参数被 AI 搜索答错三周之后Product 的 height 与 weight 字段结构化对照适用读者非标设备与工业品厂商的官网维护者、B2B 站点前端与内容工程师以及负责让产品信息被 AI 搜索正确引用的技术负责人。TL;DR核心问题AI 搜索把产品页的 1200mm 长度当成了高度导致客户据此压价参数被答错整整三周。根因1200×800×1500mm这类排版文本对机器不可读AI 只能靠猜猜错率取决于模型运气。解决方案用 Schema.org Product 的 height/width/depth/weight 字段 QuantitativeValue unitCodeUN/CEFACT 三字母码把参数结构化。验证结果改造上线 30 天外形/重量回答正确率从 3/13 升到 11/13编造数值的轮次从 5 降到 0。行动建议现在就检查产品页 head 里有没有 JSON-LD——没有的话AI 大概率正在替你「即兴发挥」。一、问题是怎么被发现的华东一家做自动化装配线的非标设备厂商官网产品页写得很「传统」外形尺寸 1200×800×1500mm整机重量约 850kg再配三张渲染图。这种写法人看得懂销售发链接客户也看得懂多年没人觉得有问题。8 月 26 日销售老周在客户现场发现一件怪事客户拿着豆包的回答来压价说「你们这设备高才 1.2 米装不下我们的工件」。豆包把长度 1200mm 当成了高度客户据此推算内部空间结论完全跑偏。老周回来复盘才知道这不是一次偶然——第 2 周里又有一家客户在电话里问「你们设备是不是 450 公斤」450 这个数字官网从头到尾没出现过是某个 AI 搜索自己估的。也就是说从第一次被答错到团队真正确认中间隔了整整三周。我 9 月初进场排查时把主流几个入口都问了一遍问「GL-1500 锁附工作站的外形尺寸」DeepSeek 给出三个数字但没标哪是长哪是高Kimi 直接回答「页面未提供完整参数」另有一家引擎把 800 说成高度。三次提问三种错法。根因不在内容写得少而在这段文本对机器不可读。「1200×800×1500mm」是一个人读的排版串乘号×U00D7在分词阶段容易被切开或吞掉三个数字共享一个单位后缀单位归属全靠读者按「长宽高」的阅读习惯脑补页面 DOM 里这段字还嵌在表格单元格里上下文跟「净重」「毛重」混排。AI 管线从这种文本里抽取字段本质是在猜猜错率取决于模型的运气。这也是我们在做生成式引擎优化Generative Engine Optimization, GEO时反复强调的一点给 AI 的参数要像给下游系统传接口一样给结构。二、改造方案Schema.org Product 的尺寸与重量字段2.1 字段选型与单位码Schema.org 的 Product 类型自带四个几何与重量字段height、width、depth、weight全部要求用 QuantitativeValue 表达。QuantitativeValue 的两个关键子字段是 value数值和 unitCode单位代码unitCode 必须用 UN/CEFACT 规定的三字母码不是随手写 “mm”、“kg”。物理量unitCode含义常见错写长度/宽/高毫米MMTmillimetremm、MM、毫米长度厘米CMTcentimetrecm长度米MTRmetrem重量千克KGMkilogramkg、KG、公斤重量克GRMgramg为什么坚持用 UN/CEFACT 码因为它是国际物品编码体系里被 EDI、海关、电商主干网广泛复用的口径AI 引擎做单位归一化时优先对齐这套码表。写 “mm” 引擎多半也能猜对但猜对是恩赐对齐码表才是契约。2.2 完整可运行的 JSON-LD 片段下面是这家厂商产品页实际落地的 JSON-LD品牌名做了替换放进head即可被 AI 爬虫与搜索引擎直接解析{context:https://schema.org,type:Product,name:GL-1500 视觉定位锁附工作站,sku:GL-1500-STD,brand:{type:Brand,name:GleaLine},description:面向 3C 产线的双工位视觉定位锁附设备节拍 6 秒/件。,height:{type:QuantitativeValue,value:1500,unitCode:MMT},width:{type:QuantitativeValue,value:800,unitCode:MMT},depth:{type:QuantitativeValue,value:1200,unitCode:MMT},weight:{type:QuantitativeValue,value:850,unitCode:KGM},additionalProperty:[{type:PropertyValue,name:外形尺寸长×宽×高,value:1200×800×1500 mm}]}三个容易写错的点单独说。其一是 height/width/depth 的语义方向Schema.org 约定 height 对应垂直方向depth 对应纵深不要按中文「长宽高」的直觉把 1200 填进 height——这正是此前被 AI 答错的同款错误。其二是 value 建议写纯数字而不是 “1500 mm” 字符串单位已经由 unitCode 承载数值再粘单位会破坏类型一致性。其三是 weight 只有一个字段没有「净重/毛重」的区分如有必要用 additionalProperty 补充说明别在 weight 里塞两个值。2.3 从产品主数据生成 JSON-LD厂商的产品参数存在 Excel 和 PDM 里让运营手工维护 JSON 迟早出错。我们用一段 Python 脚本从 CMS 导出的字段直接生成并把校验做在发布前# -*- coding: utf-8 -*-# 依赖Python 3.10无第三方库仅标准库 json# 用途从 CMS 导出的产品字段生成 JSON-LD并在发布前做硬校验importjson# 单位白名单只允许 UN/CEFACT 三字母码杜绝 mm/kg 这类散写# 码表来源见文末 QuantitativeValue 链接单位归一化按这套口径对齐UNIT_WHITELIST{MMT,CMT,MTR,KGM,GRM}defbuild_qv(value,unit_code):# QuantitativeValue 构造器所有几何与重量字段统一从这里走# 数值必须可转 float防止 CMS 里混入 约850 这类脏数据# 这里故意不放 try/except让脏数据在发布环节直接炸出来numfloat(value)# 单位码统一大写后再比对白名单# 运营手改过 mmt引擎不报错但个别入口会忽略字段必须在源头卡死unitunit_code.strip().upper()ifunitnotinUNIT_WHITELIST:# 单位码不合法直接抛错宁可发版失败也不带病上线raiseValueError(f非法单位码:{unit_code})# type 必须写 QuantitativeValue漏写会让严格解析器丢弃整段return{type:QuantitativeValue,value:num,unitCode:unit}defbuild_product_jsonld(p):# p 是从 CMS 导出的产品字典字段名与后台录入项一一对应# 每个型号独立调用一次禁止多型号页面复用同一份片段return{# context 固定指向 schema.org写成 http 会有兼容性告警context:https://schema.org,# type 用 Product设备类可在 additionalProperty 补充行业参数type:Product,name:p[name],# sku 是 AI 实体对齐的重要锚点多型号站点尤其不能省sku:p[sku],brand:{type:Brand,name:p[brand]},# 注意方向语义depth纵深, width横向, height垂直方向# 不要按中文「长宽高」直觉把 1200 填进 height这正是之前被 AI 答错的同款错误# 三个方向都用 MMT 毫米与官网文本口径保持一致depth:build_qv(p[len_mm],MMT),width:build_qv(p[wid_mm],MMT),height:build_qv(p[hgt_mm],MMT),# 重量统一录千克unitCode 固定 KGM# weight 没有「净重/毛重」之分毛重请放 additionalProperty 里补充# 这里只录净重与官网文本「整机重量约 850kg」口径一致weight:build_qv(p[net_kg],KGM),}if__name____main__:# 演示数据与官网 GL-1500 页面参数保持一致demo{name:GL-1500 视觉定位锁附工作站,sku:GL-1500-STD,brand:GleaLine,len_mm:1200,wid_mm:800,hgt_mm:1500,net_kg:850}# 生成后打印接入 CI 时改为写入模板文件# 接入 CI 的判断标准脚本退出码非零则阻断发布# ensure_asciiFalse 保证中文名称不被转义成 \u 序列print(json.dumps(build_product_jsonld(demo),ensure_asciiFalse,indent2))上线后我们又加了一个探针脚本每天抓一次自己的产品页解析 JSON-LD 并与 PDM 主数据比对字段不一致就发企业微信告警。参数被答错的代价是三周而探针发现字段漂移只要一天。三、原理剖析AI 管线为什么只认数值加单位要看懂这场改造为什么有效得拆开 AI 引擎回答「设备外形」这类问题的完整链路。一次典型的回答要经过抓取、抽取、建实体、检索、生成五步结构化数据改变的是中间三步的行为。有没有AI 爬虫抓取产品页head 里有无 JSON-LD?解析 typeProduct取出 height/weight 的 value 与 unitCode写入商品实体库 与页面文本互相印证对正文做文本抽取模型猜测数值与单位的归属槽位歧义: 1200 是长还是高?生成时按概率填槽 答错或拒答生成回答时直接取字段 可溯源可引用没有 JSON-LD 时管线走的是 F 到 I 这条猜的路。文本「1200×800×1500mm」经过分词后乘号这种低频符号经常被过滤掉剩下的三个裸数字与一个拖尾单位之间没有确定的绑定关系「外形尺寸」这个词与「高度」这个词在 embedding 空间里确实相关但相关不等于对齐模型只能按训练语料里的统计惯性填槽——多数工业品描述里第一个数字是长度于是 1200 被填进「长」可一旦页面上有渲染图配文说「机身高达 1.5 米」槽位又会漂。AI 搜索的回答质量上限由抽取时的确定性决定而不是由生成模型多聪明决定。有 JSON-LD 时走的是上面那条短路径value 是明确的数字字面量unitCode 直接对到码表height/depth 的语义由 Schema.org 词表背书。生成阶段引擎可以精确引用「高 1500mm、整机 850kg」并附上来源链接这就是 AI 搜索引用条数的来源。我们同时把结构化数据的产出做成了管线避免「手写一段 JSON 就完事」的脆弱状态否是产品主数据 PDM/ExcelCMS 结构化字段录入校验规则: 数值必填 单位走码表模板引擎渲染 JSON-LD 注入 head发布前 Schema 校验脚本校验通过?发布 HTML每日探针复检 字段比对主数据AI 引擎抓取 进入实体库这条管线的价值在于把「对 AI 可读」从一次性动作变成持续状态。参数改版、站点重构、模板升级都可能把 JSON-LD 弄丢没有探针的话你往往要到客户来质问才发现——就像那三周一样。四、改造前后 30 天对照改造于 9 月 3 日上线。我们用固定的 13 个问法涉及外形尺寸、高度、占地面积、整机重量、与竞品对比 5 类问题在三个主流 AI 搜索入口每天各问一轮人工记录回答是否与官网一致。下表是按周汇总的结果。观测项上线前一周第 1 周第 2 周第 3 周第 4 周外形/重量回答正确率3/136/139/1311/1311/13AI 回答附引用链接条数周均0.31.72.63.13.4出现「编造数值」的轮次53100客户来电澄清尺寸/重量的次数43110两点说明这是单一站点的小样本观测问法集合固定、记录口径为主观判定「与官网一致」数字不构成普遍结论参考趋势即可正确率在第 2 周之后才明显抬升此前有同行说改完当天就见效我们的体感是实体库更新有滞后别急着下结论。另外一个副产品第 3 周起DeepSeek 在回答「双工位锁附设备推荐」时开始引用这个产品页把 850kg 的整机重量作为「结构刚性」的论据列出。参数答对之后产品才开始进入 AI 的推荐语境——这是当初没预料到的收益。这里把验证方法本身说透方便你复刻这套观测。问法集要覆盖「会踩雷」的提问角度我们固定了 13 个问法按 5 类问题分布外形尺寸类 4 个「GL-1500 的外形尺寸」「长宽高各是多少」「设备多高」「占地面积多大」、高度类 2 个「机身高度」「装得下 1.2 米高的工件吗」、整机重量类 3 个「整机多重」「重量多少」「850 公斤对吗」、与竞品对比类 2 个「和 XX 相比哪个更重」「谁的占地更小」、以及 2 个带诱导性的问法「这设备是不是只有 1.2 米高」「重量是不是 450 公斤」——后两类专门用来暴露「编造数值」和「方向错位」。判定「与官网一致」的操作细则以官网产品页的 JSON-LD 与正文参数为唯一基准回答里出现以下任一情况即判为不一致——数值与官网不符、单位换算错误如把 1500mm 说成 1.5 米之外的任何值、方向错位把长度当高度、以及回答里出现官网从未出现过的数字。回答里只要数值、单位、方向三者都对即使措辞不同也判为一致。避免主观偏差我们采用双人复核——每天由两名记录员独立打分不一致的轮次当天拉齐口径每周再抽 20% 的轮次由第三人盲审盲审通过率低于 95% 就回炉重定判定标准。另外把「编造数值」单独列成一个观测项因为它比「答错」更能反映结构化数据是否真正生效——答错可能是口径问题编造则是抽取链路彻底失守。五、踩过的坑与排查清单过程不全是顺利的这几个坑我们或深或浅都踩过unitCode 大小写与拼写。运营手工改过一版写成 “mmt”引擎没报错但个别入口忽略了该字段。单位码按码表大小写写全再交给脚本白名单卡住。weight 嵌套层级写错。有人把 weight 直接写成{weight: {value: 850, unitCode: KGM}}却漏了type: QuantitativeValue部分解析器宽容、部分严格别赌运气。多型号页面复用同一份 JSON-LD。厂商有 6 个型号早期图省事共用一个片段AI 抓到 B 型号页也能答出 A 型号的重量。每个 SKU 独立生成sku 字段别偷懒。页面文本与结构化数据打架。产品页宣传语写过「占地不足一平米」而 1.2×0.80.96 平米确实不足但有一个入口把「一平米」直接当成参数回答。口径要统一宣传归宣传、参数归参数。排查清单浓缩成一张表发布前逐项核对三层都过才算真稳检查项检查方法通过标准JSON-LD 解析是否通过用 Rich Results Test 验证解析结果无错误告警height/width/depth/weight 均被识别为 QuantitativeValueunitCode 是否全部为 UN/CEFACT 三字母码用脚本白名单校验如 2.3 节的 UNIT_WHITELIST所有单位码均为 MMT/CMT/MTR/KGM/GRM 等三字母码无 mm/kg 散写height/width/depth 方向是否与 Schema.org 语义一致人工复核height垂直方向、depth纵深、width横向与官网文本口径一致不按中文「长宽高」直觉填错方向多型号页面是否每个 SKU 独立生成检查每个型号页面的 sku 字段每个 SKU 有独立 JSON-LD 片段无多型号复用同一份页面文本与结构化数据是否口径一致对比宣传语与参数值宣传归宣传、参数归参数无「占地不足一平米」这类歧义表述六、误区澄清与收尾常见的误区是认为「上了 JSON-LD 就会被 AI 引用」。结构化数据的作用是消除歧义、提供可验证的取值来源它不承诺排名也不承诺引用量但如果连字段都不给AI 只能在文本里猜猜错的概率永远存在。另外这套工作与传统搜索引擎的站点优化并不冲突——同一份 JSON-LD 同时服务于 Google 的富结果与 AI 引擎的实体库属于一次投入两处受益后续再展开 SEO 侧的做法。回到那三周损失的不是流量是客户对专业度的印象。对设备厂商来说外形与重量是采购决策链上被问频率极高的一组参数把它们从「排版文本」升级为「机器可读字段」成本不过半天收益却直接体现在 AI 搜索的回答里。如果你也在维护工业品官网不妨今天就查一下自己产品页的源码看 head 里有没有那段 JSON-LD——没有的话AI 大概率正在替你「即兴发挥」。遇到多型号、多语言站点的结构化改造问题欢迎评论区交流。七、常见问题 FAQQ1JSON-LD 放在哪里放在产品页head里即可正文 2.2 节的片段就是直接放进head被 AI 爬虫解析的。也可以像 2.3 节那样由脚本在发布前注入模板但核心是保证每个型号页面 head 里都有自己那份独立片段。Q2unitCode 写错会怎样正文踩坑记录里运营把 “MMT” 手改成 “mmt”引擎没报错但个别入口直接忽略了该字段。所以单位码必须按 UN/CEFACT 码表大小写写全并交给脚本白名单卡住别赌引擎的宽容度。Q3多型号页面如何避免数据串扰每个 SKU 独立生成 JSON-LDsku字段别偷懒。正文里厂商早期 6 个型号共用一个片段结果 AI 抓到 B 型号页也能答出 A 型号的重量这就是串扰的典型代价。Q4没有 PDM 系统如何维护结构化数据正文 2.3 节的做法是让运营从 CMS 导出字段用一段纯标准库 Python 脚本直接生成 JSON-LD并把单位白名单校验做在发布前。没有 PDM 也能跑通关键是别让运营手工维护 JSON。Q5改造后多久能看到效果正文 30 天对照里正确率第 1 周才从 3/13 升到 6/13第 2 周后才明显抬升到 9/13。实体库更新有滞后别信「改完当天见效」的说法至少留出两周观察窗口。参考与延伸Schema.org Product 类型定义https://schema.org/ProductQuantitativeValue 类型定义含 unitCode 说明https://schema.org/QuantitativeValueGoogle 搜索中心 · 商品结构化数据文档https://developers.google.com/search/docs/appearance/structured-data/productGEO、AI 搜索引用、JSON-LD、Schema.org、QuantitativeValue、结构化数据、设备厂商 AI 获客ode 说明https://schema.org/QuantitativeValue3. Google 搜索中心 · 商品结构化数据文档https://developers.google.com/search/docs/appearance/structured-data/productGEO、AI 搜索引用、JSON-LD、Schema.org、QuantitativeValue、结构化数据、设备厂商 AI 获客