周工在客户现场被问住过一次。对方举着手机念 AI 给的答复：「XS-260 的锁模力是 780mm」。780 是最大开模行程，锁模力是 2600kN。参数表就摆在官网上，一行不差，AI 抽错了列。

适用读者：制造业 B2B 官网和外贸独立站的维护者、负责产品结构化数据的前端与 SEO 工程师、想把设备参数喂进 AI 搜索的技术负责人。看得懂 JSON-LD（JavaScript Object Notation for Linked Data）的基本写法就够，不需要搜索引擎背景。

参数表摆得整齐，AI 只读到一半

华岑机械（化名）那台机的详情页有一张 34 行的参数表，分合模单元、注射单元、动力与能耗三组。改版第三周，外贸同事挑了 12 组客户常问的参数去问 AI，逐条对着官网核：34 个参数里答对 19 个，6 个串到了隔壁列，剩下 9 个答复写「官网未提供」。

事后复盘，问题不在模型，在表格这种形态本身。表格靠位置传递关系，人扫一眼就知道 780 属于「最大开模行程」那一列，机器不行。

我们把那张表拆开看，踩中的坑有四种：

一是合并表头。「合模单元」用了 rowspan 跨 12 行，页面渲染成文本之后，这个分组名只出现在第一行，后面 11 行全是裸数值。二是单位单独占一列，数值和单位中间隔着若干空格或制表符，文本切块时经常被切进两个块里，单位就丢了。三是「标配 / 选配」写在表格下方的脚注里，跟具体哪一行没有任何锚点关系。四是一个单元格塞三个值，比如「螺杆直径 65/70/75（后两项选配）」。

这四类问题的共同点是：信息都在页面上，关系只存在于视觉布局里。生成式引擎优化（Generative Engine Optimization, GEO）要做的事，就是把这部分关系显式写出来。

表格进到 AI 引擎里，机制上发生了什么

要理解为什么 JSON-LD 能救回来，得先看引擎那条链路怎么走。抓取拿到 HTML 之后，大致分四步：渲染、文档转文本、分块、槽位填充。

渲染这步各家做法不一样，有的跑一遍无头浏览器，有的只取静态 DOM。表格转文本是分水岭：主流转换器会把 <table> 摊平成 Markdown 表格或者「键: 值」的行，rowspan 与 colspan 在这一步基本被丢弃，跨行表头往往只在首行保留一次。

分块按 token 长度切，一张 34 行的表很容易被拦腰截断，被切走的那半段既没有分组名也没有表头。到了槽位填充阶段，模型拿到的文本里，数值和参数名可能已经不在同一块里，它只能靠邻近词的语义猜，猜错列是常态。

结构化数据走的是另一条路。页面里那段 application/ld+json 不参与正文分块，被单独解析成一张图：节点是实体，边是属性。属性名本身就是槽位名，unitText 和 value 挂在同一个节点下，天生绑定，不会被切块拆散。

flowchart LR
  A[设备详情页 HTML] --> B[正文参数表]
  A --> C[JSON-LD 脚本]
  B --> D[表格转文本 rowspan 摊平]
  D --> E[按 token 分块]
  E --> F[表头行与数值分离]
  F --> G[槽位填充 易串列 易丢单位]
  C --> H[结构化解析 不参与分块]
  H --> I[属性名即槽位名]
  I --> J[槽位填充 字段与单位绑定]

两条路最后都会走到槽位填充，但输入质量差了一个量级。前者让模型猜关系，后者把关系直接喂给它。

PropertyValue 那几个字段，各管一摊

additionalProperty 在 schema.org 里挂在 Product 上（Place 也能用），值类型是 PropertyValue。一个 PropertyValue 就是一组「参数名—参数值」，写成 JSON-LD 时，一台设备有多少个参数就挂多少个节点。

字段不多，容易写混的是后面几个：

valueReference 是这堆字段里最容易被写成字符串的，也是最能拉开差距的一个。它的取值范围包含 QualitativeValue、QuantitativeValue、Enumeration、DefinedTerm 等类型，选哪种取决于你要补的是什么语义：

• 说测量条件，比如「冷态实测」「满负载工况」，用 QualitativeValue；
• 说口径属于哪一档，比如「标称值 / 实测值 / 峰值」，用 MeasurementTypeEnumeration；
• 说这条参数还带一个附带量，比如「噪声 ≤ 78 dB，距机 1m 实测」，把距离写成 QuantitativeValue 挂在 valueReference 上；
• 说这条参数在行业标准里的定义，用 propertyID 指向外部词条。

跨站对齐靠的是 propertyID 而不是 name。同一件事，A 厂写「锁模力」，B 厂写「合模力」，用户两种问法都有，光靠中文名匹配很难判同义；两边都填同一个 eCL@ss 或 IEC CDD 词条 ID，引擎才有判断依据。

graph TD
  P[Product] --> AP[additionalProperty]
  AP --> V1[PropertyValue 锁模力]
  AP --> V2[PropertyValue 螺杆直径]
  V1 --> A1[name 锁模力]
  V1 --> A2[value 2600]
  V1 --> A3[unitText kN]
  V1 --> A4[valueReference 标称值]
  V2 --> B1[name 螺杆直径]
  V2 --> B2[value 65]
  V2 --> B3[unitText mm]
  V2 --> B4[valueReference 冷态实测]
  V2 --> B5[propertyID eCL 词条]

从参数表生成节点

环境：Python 3.9+，无第三方依赖。参数来自 PDM 导出的 CSV，字段顺序是名称、值、单位、口径。这段只做字典到 PropertyValue 节点的转换，不碰发布流程。

# 输入：PDM 导出的 CSV，字段顺序为 名称/值/单位/口径
def pv(name, value, unit=None, ref=None):
    # 底线：name 和 value 缺一个，这条等于没写
    node = {"@type": "PropertyValue", "name": name, "value": value}
    # 单位写 unitText，拿得到 UN/CEFACT 代码再补 unitCode
    if unit:
        node["unitText"] = unit
    # 口径和档位挂 valueReference，别塞进 value 字符串
    if ref:
        node["valueReference"] = ref
    return node
# 用法：批量转换后直接塞进 Product 的 additionalProperty

写 value 时有个细节：数值型参数传 int 或 float，别传 "2600"。传字符串之后，引擎做不了区间比较，用户问「锁模力大于 2000kN 的机型」这类问题就筛不出来。

页面里怎么嵌

环境：任意静态站点模板，嵌在设备详情页 body 末尾即可。依赖无，用 Schema Markup Validator 或 Google 的富媒体结果测试工具校验。

<!-- 环境：静态站点模板，嵌在设备详情页 body 末尾 -->
<!-- 依赖：无，用 Schema Markup Validator 校验即可 -->
<!-- 要点：value 写数字类型，区间比较才有效 -->
<script type="application/ld+json">
{
  "@context": "https://schema.org", "@type": "Product", "name": "XS-260 注塑机",
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "锁模力", "value": 2600, "unitText": "kN" },
    { "@type": "PropertyValue", "name": "螺杆直径", "value": 65, "unitText": "mm" }
  ]
}
</script>

上线前跑一遍自检

环境：Python 3.9+，挂在 CI 上，参数表一改就跑。三条规则都来自前面复盘出来的坑。

# 单位白名单按自家产品线维护，别照抄
UNITS = {"mm", "kN", "kg", "kW", "r/min"}
# 规则一：数值型参数必须带 unitText
miss = [p["name"] for p in props
        if isinstance(p.get("value"), (int, float)) and "unitText" not in p]
# 有输出就说明还有裸数值，AI 会自己替你猜单位
print(miss)

改造前后，同一台机器

改完之后我们按同样的 12 组问答又核了一遍，逐条记录作答内容。下面这张表是其中几条：

34 个参数的总体情况：表格版 19 个正确、6 个串列、9 个漏答；结构化版 31 个正确，剩下 3 个页面上本来就没写，属于内容缺口不是抽取问题。

这组数字是我们自己拿 12 组问答逐条核对出来的，样本小，只用来说明同一台机器前后两个版本的差异，不能外推成行业结论。

表格别删，改成同源

有一个容易走岔的方向：既然 JSON-LD 更准，就把表格砍了。别这么干。表格是给人看的，用户要扫参数、要复制到询价单里；而且结构化数据和可见内容不一致时，引擎倾向认为站点自相矛盾，反而降权。

正确的做法是同源。参数只维护一份（PDM 或 ERP 导出的 CSV），表格由它渲染，JSON-LD 也由它生成，两边不可能对不上。参数改了，CI 里重新生成一遍并跑自检，发布时同步上线。

这套流程落地之后，华岑机械那边新增一台机型要做的动作，从「改表格 + 改文案 + 祈祷 AI 读对」变成「改 CSV，等流水线跑完」。选型页的维护成本降下来的那一块，是顺带的好处。

往后看两年

多模态能力上来之后，参数表截图能被读出来，但字段名仍要靠文本锚点，单位换算仍要靠 unitCode 这类机器码。也就是说，图能解决「看得见」，解决不了「对得上」。

更值得留意的变化在词条侧：行业词表（eCL@ss、IEC CDD、UN/CEFACT）正在被更多引擎当作对齐依据，propertyID 这类字段的作用会从「可选补充」变成「能不能被判同义的前提」。现在花在词条映射上的功夫，后面不用重做。

你们那边设备参数是怎么管的？是放在 CMS 里手工填，还是有 PDM 可以导出？评论区聊聊，我看看能不能把校验脚本再补几条规则。

参考与延伸

• PropertyValue 类型定义：https://schema.org/PropertyValue
• MeasurementTypeEnumeration 口径枚举：https://schema.org/MeasurementTypeEnumeration
• Product 结构化数据说明：https://developers.google.com/search/docs/appearance/structured-data/product
• 结构化数据校验工具：https://validator.schema.org/

GEO｜additionalProperty｜PropertyValue｜JSON-LD｜设备参数结构化｜AI搜索｜schema.org