给AI喂参数前，我把客服聊天里的「大概」「左右」全标了容差，结果它答得更准了

上周在改产品参数的结构化数据，本来想让 AI 直接读规格表就完事。结果抽了 50 条客服实录比对，发现 AI 答「续航多久」时把「约 8 小时」直接说成「8 小时」，用户拿去跟实测 6.5 小时对不上，回来投诉。

我拉了一下官网 Product schema 里 additionalProperty 的字段，续航写的是 value: "8"，单位 h，但客服原话是「大概 8 小时，重度用 6 个多小时」。结构化数据里这个「大概」和「重度」全丢了，AI 只能按绝对值答。

我的处理是先锁口径，不急着改 schema：

1. 把客服聊天记录里所有带模糊词的参数捞出来，按品类列了张表。续航、承重、适配尺寸这三类模糊表述占比最高，分别 23%、18%、15%。
2. 给每个参数加 valueReference 和容差字段：minValue / maxValue 用 QuantitativeValue 嵌套，unitText 拆到最小单位。续航写成 6.5–8，而不是 8。
3. 在 description 里保留一句客服原话，别全删。AI 抓正文时能拿到语境，答出来会带「重度使用约 6.5 小时」的限定。

跑了一周，抽 100 条 AI 回答人工核对，参数类回答的偏差率从 31% 掉到 9%。剩下 9% 主要是跨品类对比场景，AI 还是会拿 A 品的 max 对 B 品的 min，这个得靠 sameAs 和对比页的结构化补，不是单页能解决的。

踩坑记两个：一是 minValue / maxValue 在 Google 的富媒体测试里不报错，但 Bing 的校验工具会把嵌套 QuantitativeValue 标成警告，得留个心；二是别为了容差把 value 改成区间字符串，"6.5-8" 这种 AI 解析会直接崩，还是得走数值字段。

页面速度这块顺带提一句，加了这些嵌套字段后单页 JSON-LD 从 4KB 涨到 11KB，LCP 没明显变化，但 TTFB 在弱网下多了 40ms 左右，量大的站建议把 schema 拆到独立 endpoint 异步注入，别全塞首屏。

想问问各位：你们给参数加容差时，是塞在 schema 里还是放正文表格？我这边正文表格 AI 抓取率反而比 schema 高，但维护成本翻倍，一直没定下来。