Offer、价格与库存：AI 最容易被你骗的地方

周一早上，一家做户外装备的独立站客服收到三张截图：买家在聊天助手里看到的价格是 89 美元，标注“现货”；点进商品页却是 109 美元，预计两周发货。技术排查发现，商品 feed 停在上周四的导出，页面价格由另一个系统写入，库存字段在 CDN 上缓存了六小时。

AI 推荐不了一个它无法确认价格的商品：Offer 不是商品页的附属字段，而是价格、库存、货币与时效的唯一可引用事实源；它一旦自相矛盾，你失去的不是一次点击，而是候选资格。

模型不核对事实，它挑一个最像真的版本

同一件商品在 AI 眼里有若干份互相竞争的副本，谁更新鲜、更结构化、被引用得更多，谁就被采信。

检索系统看到的价格：页面上的可见价、结构化数据里的价、feed 里的价、搜索引擎缓存的上一版、比价站与评论页转述的价。模型没有你的后台，也没有“以官网为准”的默认信任。它做的是在这些副本之间挑一个置信度最高的，或者干脆加一句“价格可能变动，请以商家页面为准”。

三种后果最常见。第一，报价停在上一轮促销，买家点进来发现贵了二十块，直接离开。第二，有货与缺货说反，agent 走到下单那一步失败。第三，多市场货币与税制混用，页面上是欧元含税，结账时换成英镑再加一遍税。

所以价格与库存不是内容字段，是交易字段。文案写错可以改，交易字段写错会当场切断转化；到了 agent 下单，中间没有人工兜底，一步对不上就是零。

反例很常见：把促销价写进 meta description 和广告文案，结构化数据与 feed 仍是原价。页面肉眼看着没问题，机器读到三套价格。这类“骗”能换来几天点击，代价是模型对无法验证的商家最常见的处理——不是纠错，是不提。价格只是 AI 答案里的一层，其余几层怎么拼，见AI 答案里的商品长什么样。

不一致的四个来源

把不一致当成运营手滑，就会一直修不完。它通常是四个结构性缺口，按缺口修，比逐个 SKU 改便宜得多。

来源	典型表现	谁最容易漏	怎么查
系统割裂	ERP、PIM、店铺后台、feed 各算一次价，促销规则只在一处生效	运营与工程的交界	同一个 SKU 在四个系统各取一次值
时间差	feed 每日导出、页面缓存、爬虫上次抓取停在促销之前	工程	对比页面、结构化数据与 feed 的更新时间
市场差异	货币、含税与不含税、区域定价、运费门槛、清关费用	市场与财务	用目标市场的语言与地区各看一遍
层级与单位	变体价差、订阅价、组合装、每件与每箱、划线价与实际售价	内容与商品	抽二十个多变体 SKU 逐一对账

第四类最隐蔽。一个父商品下挂五个尺码，价格只写在父级，变体页就会继承一个错的数字；组合装按箱卖，页面写每件价，买家算出的总价对不上。价格必须挂在正确的节点上，而“正确节点”取决于商品图怎么建，见Product Graph：AI 眼里的商品不是一条 SKU。

还有一条常被当成营销问题：划线价。欧盟市场对折扣宣传有此前价格的披露要求，划线价写得随意，既可能被投诉，也会让 AI 采信一个并不存在的“原价”。

五步：让四个出口从同一个地方取值

目标不是“把四个地方改一致”，而是让它们没有第二个值可读。一致性是架构结果，不是运营纪律。

步骤	做什么	谁来做	怎么算过
1 定源	指定一个价格库存主系统为唯一写源，其余系统只读，促销规则只在这一层生效	工程与商品	任取一个 SKU，能说清价格由谁算出
2 建模	Offer 只放能确认的事实：price、priceCurrency、availability、priceValidUntil、seller、运费与时效；变体各自成 Offer	工程	字段缺失清单为零
3 同步	事件推送加明确 TTL，TTL 不超过你能承诺的价格稳定窗口；促销切换时主动失效缓存	工程	改价后下一个缓存周期内四个出口一致
4 表达	货币、含税、运费门槛写成表格；库存不要只有有货与缺货，schema.org 的 availability 已有 InStock、PreOrder、BackOrder、OutOfStock	内容与市场	用目标市场语言读一遍不产生歧义
5 验证	每日抽样比对页面可见价、结构化数据、feed 与结账价，差异进告警而不是进周报	增长	差异率可量化，且能归因到某个出口

第 3 步的 TTL 是判断题，不是技术参数。你能对外承诺价格多久不变，缓存就只能活多久；促销一天换两次，缓存却设成一天，前面所有建模都白做。

第 5 步容易做成形式。差异率只是过程指标，真正要回答的是引用与成交有没有跟着变，方法见AI 可见度基线；差异清零之后仍被引错价，问题就不在价格层了。

示例：一次价格打架的排查

示例（假设场景，不含真实品牌与数据）。团队抽二十个 SKU，在同一时刻从四个出口各取一次值，七个不一致：三个是 feed 没跟上促销价，两个是变体继承了父级价格，一个是含税价写成了不含税，还有一个缺货仍标 InStock。

改法不是逐条改数据，而是收口：价格服务对外暴露一个内部报价接口，商品页、结构化数据与 feed 都调它；库存改三态（InStock、BackOrder、OutOfStock），缺货时保留页面并写清到货窗口；多市场请求带 market 参数，货币与税在响应里一次算完；缓存按促销日历主动失效；结账前二次校验，价格变动时明确告知，而不是静默改价。

验收看连续七天的每日抽样：四个出口一致率百分之百，才恢复促销投放。第一次跑完，团队发现最难的不是技术，是让市场部接受“促销价必须在主系统里改，不能直接在落地页覆写”。

边界：什么时候不该追“实时”

第一，成交集中在平台内。亚马逊、Shopee 的价格与库存由平台渲染，你能保证的是后台与 feed 一致，改不动它的商品页模板，先修后台。

第二，闪购与高频动态定价。真正的实时要报价接口与更贵的缓存层；价格十分钟一变，任何引用都会过期，这时给出“价格区间加有效期”比伪装成精确价更诚实，也要接受部分引擎因此不引用你。

第三，定制与报价型商品。没有单一价格，就给“起价加计价因素”，不要硬编一个 Offer 数字，那等于把可核验的事实换成一句谎。

第四，库存极浅。标 InStock 换来的是取消订单，在 agent 场景里代价更高；宁可 BackOrder 并写清到货窗口。

第五，站点还很早期。先把商品页与结构化数据对齐，别上实时接口。缺货与变体页面的另一套规则，见商品变体与缺货页：别让 AI 读到 404。

如果只做一件事：挑二十个在投的 SKU，在同一分钟里从页面可见价、结构化数据、feed 和结账页各取一次值，做成一张四处对账表；只要差异不为零，就先别写新内容。这条线上其他文章在技术底座主题页。