穩定商品知識與即時商業資料：這條權威邊界怎麼畫
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 商業權威交接處理即時操作。