适用读者：电商平台后端开发、商品中心工程师、做价格监控与比价业务的团队

一、从一个怪现象说起：AI 报价永远慢半拍

起因是一个业务方的吐槽：他们某款爆品上周就降价了 50 元，官网页面价格早就改了，但用户问豆包"某某蓝牙耳机现在多少钱"，AI 回答的还是老价格；更有意思的是，问 DeepSeek 得到的价格和问 Kimi 得到的价格还不一样——一个引用了官网，一个引用了某比价站，两个都不对。

这不是玄学，是价格信号的结构化质量问题。价格是电商内容里最动态、也最需要机器准确读取的数据，但恰恰是它，在大多数电商站的结构化数据里写得一塌糊涂：价格元素没绑定 Schema、优惠价和原价混写、库存状态永远 InStock、货币符号直接嵌在文本里。AI 引擎读不准，只能猜，猜出来的答案就是用户看到的"慢半拍报价"。

这篇文章把 schema.org 里与价格相关的 Offer 规范做一次完整解读，配上我们实测的"AI 读价"验证方法和改造数据。写法本身不复杂，复杂的是把规范里那些容易想当然的字段掰扯清楚。

二、Offer 的骨架：AI 读价的最小完备集

一个 AI 引擎能可靠读取的价格声明，最小完备集是这些字段：

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "无线蓝牙耳机 Pro",
  "sku": "EHP-PRO-001",
  "offers": {
    "@type": "Offer",
    "price": "299.00",
    "priceCurrency": "CNY",
    "priceValidUntil": "2026-10-15",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/product/ehp-pro-001",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

逐个说容易想当然的地方：

price 必须是纯数字字符串，不带货币符号和千分位。写 "¥299"、"299,00"、"299 元" 都会让解析失败或产生歧义。货币信息只放 priceCurrency，这是 ISO 4217 代码（CNY/USD/EUR）。我们审计过的 12 个电商站，有 7 个在 price 字段里带符号——这是 AI 读价错误率的第一大来源。

priceValidUntil 是被严重低估的字段。它的语义是"这个价格的报价有效期"，AI 引擎会参考它判断价格新鲜度：声明了有效期且未过期的报价，可信权重高于没有时效声明的报价。这解释了开头那个"慢半拍"现象的一半原因——没写 priceValidUntil 的价格，引擎只能靠抓取时间戳猜新旧，而抓取可能滞后几天。补上这个字段等于主动给引擎一个"价格保质期"信号。

availability 必须如实反映库存。永远写 InStock 的站点，价格信号的可信度会被整体拉低——库存和价格是同一个数据可信度评估里的两个维度。

url 必须指向当前页面或该商品的规范页。它帮引擎把价格锚定到正确页面，做比价聚合时不会张冠李戴。

三、进阶场景：多规格、多渠道、促销价怎么写

真实电商的价格结构远比单一 Offer 复杂，规范里有对应的解法。

3.1 多规格商品：AggregateOffer

颜色/容量多 SKU 共用一个商品页时，不要列一堆 Offer，用 AggregateOffer 给出价格区间：

{
  "@type": "AggregateOffer",
  "lowPrice": "259.00",
  "highPrice": "459.00",
  "priceCurrency": "CNY",
  "offerCount": "6",
  "offers": [
    { "@type": "Offer", "sku": "EHP-PRO-001-BLK", "price": "259.00", "availability": "https://schema.org/InStock" },
    { "@type": "Offer", "sku": "EHP-PRO-001-WHT", "price": "279.00", "availability": "https://schema.org/PreOrder" }
  ]
}

实测中 AI 引擎对区间商品回答价格时几乎总是引用 lowPrice 起步，所以 lowPrice 必须是当前真实可成交的最低配置价——把下架规格的价格算进 lowPrice 是常见错误，会直接导致 AI 报出一个买不到的低价。

3.2 促销价：priceSpecification 说清"哪来的价"

促销期间，页面同时存在原价、划线价、到手价。规范解法是用 priceSpecification 拆开：

{
  "@type": "Offer",
  "price": "259.00",
  "priceCurrency": "CNY",
  "priceSpecification": [
    { "@type": "UnitPriceSpecification", "price": "309.00", "priceType": "https://schema.org/ListPrice" },
    { "@type": "UnitPriceSpecification", "price": "259.00", "priceType": "https://schema.org/SalePrice", "eligibleQuantity": { "@type": "QuantitativeValue", "value": "1" } }
  ]
}

核心原则：offers.price 永远是当前用户实际能成交的单件价，原价信息放 priceSpecification，页面可见的划线价必须与之对应。AI 引擎报"到手价"读 price，报"原价降了多少钱"读 Specification，两者混写是比价错误的第二大来源。

四、验证方法：直接问 AI，别只跑校验器

Schema 校验器只能验证语法合法性，验证不了"AI 是不是真的读对了"。我们做了一套实测流程：准备 20 个价格相关的问题（"XX 现在多少钱"、"XX 和 YY 哪个便宜"、"XX 降价了吗"），在价格变更后的 1/3/7 天分别问三个引擎，记录回答的价格、来源和时效：

改造前我们的实测成绩：价格正确率 55%，时效达标 40%，三引擎一致 60%。这个数字意味着一半以上的 AI 问答在向用户传递错误价格。

五、改造后 60 天的数据

价格字段按上述规范全站改造（约 8000 个商品页）后观察 60 天：

价格正确率提到 93% 之后，剩下 7% 的残留错误全部集中在快照滞后的长尾商品——这部分靠提高抓取频次解决不了，最终方案是给高变动商品开价格变更推送（priceValidUntil 设短 + 变更时主动更新 sitemap lastmod）。"引用本站比例"的提升是隐藏收益：引擎倾向引用价格信号最可信的来源，数据准的站点会被优先归因。

附一：多币种外贸场景的两个坑

外贸电商的多币种价格在 Schema 里有专门的处理方式，我们踩过两个坑。第一坑是"一页多币"：页面用 JS 按用户地区切换显示 USD/EUR/JPY，Schema 里也跟着塞了多个 Offer 各带不同 currency——这会造成歧义，AI 引擎可能拿日元价格回答美元用户的提问。正确做法是 Schema 里只声明商品的基准结算币种价格（通常 USD），页面上的其他币种只是汇率换算展示，不进 Schema。

第二坑是汇率波动导致的价格漂移：基准价 29.99 USD 换算成人民币展示，页面每天随汇率变，但 Schema 里的 CNY 价格一周没更新，一致性校验直接报警。解法是承认"Schema 价格只有一个事实源"：Schema 里写基准币种，页面上换算币种区域不参与 Schema 一致性比对。如果业务确实需要多币种 Schema（比如区域独立站），那就为每个区域建独立页面、独立 Offer、独立 priceCurrency——一页一币种，URL 区分，用 hreflang 关联。半吊子的"一页多币 Schema"只会两头不讨好。

附二：价格数据的存储设计建议

Schema 输出的质量取决于上游数据的质量，价格表的设计有几个直接影响 GEO 效果的要点。核心是价格事件化：不要只存一个 current_price 字段，而是维护一张价格变更事件表（SKU、原价、新价、变更原因、生效时间），Offer 的 priceValidUntil 由最近一次变更事件推算，促销的起止时间在事件里显式记录。这样促销结束自动切回常规 Offer 就是一条 SQL 的事，不依赖任何人记得去改。

CREATE TABLE price_events (
    id          BIGINT PRIMARY KEY AUTO_INCREMENT,
    sku         VARCHAR(64) NOT NULL,
    old_price   DECIMAL(10,2),
    new_price   DECIMAL(10,2) NOT NULL,
    event_type  VARCHAR(16) NOT NULL COMMENT 'PROMO_START/PROMO_END/ADJUST',
    valid_until DATETIME NULL COMMENT '促销价的自动回收时间',
    created_at  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    KEY idx_sku_time (sku, created_at)
) COMMENT='价格变更事件表';

另一个要点是价格精度统一：数据库 DECIMAL(10,2)、Schema 字符串两位小数、页面展示的分隔符只在渲染层加。三层各自的格式职责划清楚，一致性校验才有稳定的基准。我们改造中发现的 23 处价格不一致，其中 19 处根源是存储层精度不统一（有的字段 FLOAT 有的 DECIMAL），在数据层修好之后，Schema 层的错误自然消失。

六、三个误区与一个趋势

误区一："价格在页面上显示对了就行，Schema 无所谓"——恰恰相反，价格是所有商品数据里最依赖 Schema 的字段，因为它是数字型、高频变动、强交易意图，引擎不会从文案里去猜数字。误区二："促销结束了忘记改回原价没关系"——过期的 SalePrice 和过期的 priceValidUntil 都是可信度减分项，促销 Schema 必须有自动回收机制，促销结束时间一到自动切换回常规 Offer。误区三："AI 报价会实时抓取页面"——不会，绝大多数 AI 回答里的价格来自索引缓存，你的工作不是让页面价格正确，而是让索引里的价格信号正确且新鲜，priceValidUntil 和主动的 sitemap 更新就是干这个的。

趋势判断：AI 比价和购物助手正在成为电商流量的新入口，各家引擎都在强化交易类实体的数据要求，Offer 规范的字段完备度会直接影响商品在 AI 购物场景的曝光资格。价格数据是电商 GEO 里投入最小、见效最明确的一块——两个字段的规范写法，换来的是 AI 报价从一半错误到九成正确。做电商的同学，建议先跑一遍第四节的实测流程看看自己站的真实正确率，大概率会吓一跳。测出问题的，评论区交流改法。

关键词：GEO、AI优化AIO、Offer Schema、priceValidUntil、AggregateOffer、电商SEO、AI比价、结构化数据