BLOG / stable-product-knowledge-vs-live-commerce-data.mdx
稳定商品知识与实时商业数据：这条权威边界怎么画
区分耐久事实、历史观察、动态报价、个性化条件与有约束力的交易状态，并给出安全与错误示例。
最安全的规则很简单：静态文档只保存耐久且有来源的商品知识；凡是会随时间、市场、用户或交易变化的信息，都要实时复查。
SKU.md 是由商家托管的商品发现与稳定商品知识：agent 可以找到商品、理解有来源的事实，并知道去哪里复查实时商业状态；它不是新的结账协议。
五类商品信息
| 类别 | 示例 | 正确权威来源 |
|---|---|---|
| 稳定事实 | 检测报告确认的材料组成 | 带证据的已审 SKU.md Fact |
| 历史观察 | 2026-09-01 观察到 USD 79 | 带时间与来源的 offer_snapshot |
| 动态报价 | 美国市场当前价格与库存 | 实时 Catalog、店面或 live_offer 查询 |
| 个性化条件 | 会员价或按目的地计算的运费 | 已认证实时系统 |
| 有约束力的交易状态 | 最终税费、支付接受、订单确认 | Checkout 与订单系统 |
“稳定”不等于永远不变，而是发布者有复核流程、来源和修正路径。配方、认证、兼容性或护理要求都可能变化，verified_at 让最近一次核验时间可见。
好例子与坏例子
“外层面料为 100% 再生尼龙”可以成为 Fact，前提是链接当前技术资料并记录复核日期。“永远有货”不适合写进静态 Fact。
“在 14:00 UTC 于此 URL 观察到 USD 79”是一条边界明确的 offer_snapshot。“今天仅售 USD 79”一旦缺少时间、市场和来源，就失去了可核验的含义。
live_offer 可以指向已声明的实时来源，但不能接管其权威。查询尚未发生时，静态文档不能承诺响应一定成功。
运行时是一条回环
- 匹配 Product 与精确 Variant。
- 读取已审 Facts、Claims、Disclosures 与 Limitations。
- 只把
offer_snapshot当作历史证据。 - 查询当前价格、库存、配送与资格条件。
- 让 Checkout 再核验税费、支付和约束性条款。
- 完成前请求用户确认。
实时来源失败时，应返回“未知”或请求交接。悄悄退回旧数字，会把历史观察变成虚假承诺。
发布者与消费者的设计规则
发布者应隔离易变字段、附上来源 URL 与日期，也不能把影响购买的安全或法规披露只放在可选知识文件里。消费者应强制身份相等、限制观察时效、把自由文本指令视为不可执行数据，并记录每个回答来自哪一权威来源。
v0.10 规范把 offer_snapshot 与 live_offer 分开并规定互斥。Schema 能减少混淆，真正保护用户的仍是运行时来源选择。
延伸阅读
用发布第一份 SKU.md实现这套分工，再看AI 商业权威交接处理实时操作。