给产品页加JSON-LD后，AI抓错参数从17次降到6次，但字段顺序又踩了新坑

上周把一批产品页的 JSON-LD 从 Product 裸奔改成带 additionalProperty 的参数表结构，AI 答案里抓错规格的次数从 17 次降到 6 次（同一批 40 个问句重跑三遍取均值）。但降完我发现剩下的 6 次全卡在字段顺序上。

具体现象：参数表里 weight 和 netWeight 两个字段我按业务习惯写了 gross 在前，结果 AI 在回答「多重」时直接取了第一个 weight 值，把毛重当净重报。我用的是 PropertyValue 数组，name 和 value 都全，唯一变量就是数组里对象的先后顺序。做了个对照实验：同一份数据，只把 netWeight 的对象挪到数组第一位，重跑 40 个问句，抓错次数从 6 降到 2。说明抓取端对参数表的解析存在「首个匹配即采纳」的倾向，而不是按 name 精确匹配。

我判断依据是：抓取行为跟页面加载速度基本无关，我测了 LCP 从 1.2s 拉到 2.1s，抓错次数没变；但字段顺序一动，结果立刻漂移。所以问题不在性能，在结构化数据的解析策略。

现在的临时方案是：

1. 参数表按「AI 最可能问的字段」排序，净重、容量这类高频问句字段前置；
2. additionalProperty 里每个 PropertyValue 加 description 写清口径，比如「净重，不含包装」；
3. 保留原始顺序的备用版本，方便 A/B 对照。

但这里有个歧义我还没解：如果抓取端真是「首个匹配即采纳」，那 name 字段的语义就形同虚设，我是不是应该干脆把所有别名收敛成一个规范字段名？还是说不同 AI 引擎的解析策略不一样，得按引擎分版本喂？有谁测过不同引擎对 additionalProperty 顺序的敏感度差异吗？