SKU.md 不是商品 Feed：為什麼我們故意不放即時庫存和交易狀態
v1.0.0 專題
用職責邊界說明商品知識、商業 Feed 與交易系統的差異，以及為什麼靜態 Markdown 不應包含持續變化的報價。
目前狀態： 本文依據目前 v1.0.0-beta 邊界撰寫，只陳述方法和證據要求，不把尚未驗證的平台採用、排名、引用、推薦或銷售結果寫成事實。
讓 SKU.md 迅速失去可信度的最簡單方式，就是把它當成更新較慢的商品 Feed。Markdown 檔案看起來仍然正式，卻可能保留昨天的庫存、已經結束的優惠或不再成立的配送承諾。更穩妥的設計是把產品含義、變化中的報價和交易決策分開。
三個層次回答三個不同問題
知識層回答「這是什麼產品，在什麼條件下適合使用」；Feed 回答「外部通路要接收哪些商業欄位」；交易系統回答「這位使用者此刻能否在目前市場以目前價格購買這個變體」。把三者合在一個檔案裡，會讓文件比審核流程更快過期。
| 層次 | 典型內容 | 變化速度 | 權威來源 |
|---|---|---|---|
| 商品知識 | 事實、建議、限制、相容性、識別碼、來源 | 低 | 商家審核的文件 |
| 商品 Feed | 報價欄位、可售快照、通路屬性 | 中到高 | Feed 管道或平台目錄 |
| 交易系統 | 可執行價格、庫存分配、稅費、配送、支付、訂單狀態 | 即時 | 商業後端 |
「參考值」也必須說明存在理由
把一個數值稱為「參考價格」或「大致庫存」，並不會自動消除誤解。使用者和 Agent 仍可能把它當成目前報價。只在足夠新鮮時才有意義的商業欄位，應由能夠同時說明時間、市場、幣種和失敗狀態的即時介面負責。
SKU.md 可以連結公開商品頁或即時服務，但穩定文件只負責解釋何時交接。遇到價格或庫存問題時，消費者應要求即時來源，而不是複述靜態 Markdown。
職責分離讓失敗更容易處理
描述性事實缺失時，可以保留未知並繼續追問；Feed 延遲時，可以報告資料陳舊；結帳失敗時，商業系統可以返回目前原因。三類失敗的恢復方式不同，一個檔案無法在不丟失差異的情況下同時表達。
審核也因此更有意義。商家可以獨立檢查某條限制是否準確，不必把每小時變化的庫存加入同一輪評審；營運團隊更換定價系統時，也無需重寫商品使用建議。
建立欄位權威矩陣
為每個欄位寫明允許回答它的系統，以及可以接受的最大資料年齡。某一型號的尺寸可能長期穩定，相容性可能隨著韌體支援變化，庫存只在很短時間內有效，送達時間還取決於地址。這個矩陣應同時控制發布流程和 Agent 行為。
如果兩個系統發生衝突，消費者不能靜默合併。它應保留來源，為目前問題選擇指定權威，並在衝突影響推薦時明確說明。
哪些內容適合進入 SKU.md
材料、尺寸、適用場景、明確排除條件、相容要求、保養方式、型號識別碼和來源連結都很合適。Updated 表示知識文件何時修改，並不保證庫存新鮮。
可執行價格、庫存、折扣、配送預計、稅費、支付可用性、結帳和訂單狀態應留在即時系統。只要 Agent 知道何時跳轉，一個連結就足夠。
發布前的逐句檢查
檢查檔案中的每條陳述：「普通使用者會不會把它理解為購買瞬間仍然成立？」如果答案依賴時間、市場、客戶、地址或剩餘數量，就把它移交給即時權威。最終文件會更短、更持久，也更適合被引用。
同一件商品處在三種時間尺度裡
以一盞充電露營燈為例。防水等級、介面、尺寸和「不可水下使用」的限制可能數月不變；通路 Feed 中的價格、促銷文案和地區可售性可能每天變化；結帳時的庫存預佔、稅費和配送承諾可能在幾秒內變化。如果把三類資訊塞進同一個靜態文件，整份知識都被迫按照最快的欄位重新整理，而且快取稍有延遲就會誤導購買。
正確的分工是：SKU.md 儲存經審核的商品含義並連結來源；Feed 按通路要求分發報價；交易系統在最後時刻確認是否可買。Agent 可以組合三層資訊，但必須保留每條資訊來自哪裡、何時確認，不能把不同時間的值壓平成一個看似「目前」的記錄。
混在一起會產生哪些故障
第一類是過期的確定性：最後一件商品已經被預佔，快取檔案仍寫著「有貨」。第二類是市場混淆：一個地區含稅的價格被當成所有市場的通用價格。第三類是政策漂移：承運商或截單時間改變後，舊配送承諾仍留在知識檔案中。這些不是格式錯誤，而是權威邊界錯誤。
更新頻率不同也意味著流程不應耦合。若每次庫存變化都要生成、審核、部署並清除整個知識圖，穩定知識會被大量噪音淹沒；若讓慢速內容審核承擔交易狀態，顧客又會看到舊答案。把系統拆開，才能分別為準確性、時效性和責任人設定合適的標準。
設計清楚的即時交接
當問題涉及用途、相容性、限制、識別碼或穩定事即時，Agent 可以依據 SKU.md 回答並附上來源；涉及目前價格、庫存、稅費、配送、支付或訂單時，應呼叫或開啟權威商業系統。混合問題可以分兩步：先確認產品是否適合，再確認指定變體此刻能否購買。
交接時應攜帶已解析的商品和變體識別碼、市場、數量，以及仍需確認的事實，不應攜帶推測出來的價格或庫存。這樣，商家既能改善 AI 對商品的理解，又不會把一份可審閱的靜態知識檔案變成脆弱的交易快取。
用四個問題判斷欄位歸屬
增加欄位前先問：誰是權威來源、變化有多快、快取錯誤會造成什麼後果、決策時由哪個介面確認。經審核的材質組成屬於知識層；可能導致下單失敗的庫存數屬於庫存服務。穩定識別碼可以進入知識檔案，但引用該識別碼的通路報價仍是通路資料。
這套問題也決定快取策略。穩定知識可以正常快取並帶更新時間；即時呼叫要有獨立的新鮮度與故障規則。商業服務暫時不可用時，Agent 仍可解釋適用性，但不能把故障推斷成「有貨」或「可購買」。