一份好的 SKU.md 應該告訴 AI 什麼？
v1.0.0 專題
用一份商品知識的拆解說明事實、建議、限制、相容性、識別碼和來源如何彼此配合，而不把 Markdown 變成 Feed。
目前狀態： 本文依據目前 v1.0.0-beta 邊界撰寫，只陳述方法和證據要求，不把尚未驗證的平台採用、排名、引用、推薦或銷售結果寫成事實。
一份好的 SKU.md 不是把商品頁縮短，而是順著 Agent 必須做的決策，把商品知識重新組織一遍。審核時可以挑一件具體商品，逐段檢查每類資訊會怎麼影響推薦。
範例：一款小型旅行充電器
假設商店銷售一款 65 W 雙口充電器，並提供多個插頭變體。商品頁可以放照片、上市文案、評論和購買按鈕；知識文件則要明確穩定的決策事實：輸出規格、隨附插頭、支援裝置、不適用情況、型號識別碼和來源。
文件必須說明正在討論的具體變體。如果插頭和電壓條件隨市場變化，「全球可用」就不是一個足夠精確的事實。
Facts 描述產品是什麼
Facts 應當具體且可以觀察，例如埠類型、最大總輸出、尺寸、重量、材料和包裝元件。每條事實都要有消費者可以檢查的來源。除非明確標註為有出處的宣傳主張，否則不要把「旗艦」「最佳」等形容詞當成事實。
Facts 也不是易變商業欄位的收納區。目前價格和庫存仍屬於即時權威。
Guidance 解釋適用方式
Guidance 把事實轉成有條件的使用建議，同時避免替使用者做未經證實的假設。對充電器而言，可以說明哪些裝置組合處於功率預算內，或在什麼情況下一個介面卡可以替代兩個。所有建議都應能夠回到產品能力。
好的 Guidance 會幫助 Agent 提出更好的問題。如果同時充電會改變功率分配，這個條件必須寫入說明。
Limitations 與 Compatibility 防止高成本錯配
Limitations 說明哪些情況不應推薦，例如不支援的高功率筆記本、潮溼環境或需要其他插頭模組的地區。Compatibility 則列出必須匹配的介面、版本、附件、尺寸或環境條件。
這兩節對決策的影響通常大於普通賣點。一個不相容條件就足以否決看起來很吸引人的推薦。
Identifiers 連線記錄，但不靜默合併
SKU、MPN、GTIN 和變體標籤的作用域不同。文件應把每個識別碼綁定到它真正識別的產品或變體。商品頁、Feed 和 JSON-LD 不一致時，應保留衝突供審核，而不是悄悄選擇最方便的值。
識別碼讓系統可以關聯記錄，卻不能自動證明所有記錄完全等價。
Sources 讓陳述可以檢查
來源連結應靠近它支援的陳述。一個主頁很難支援技術相容性結論，應優先使用包含相關資訊的商品頁、說明書、支援文件或正式政策。
文件還要記錄更新時間。消費者既要保留知識資源地址，也要保留底層陳述來源。
商品知識構成表
| 部分 | 回答的問題 | 要避免的失敗 |
|---|---|---|
| Facts | 產品是什麼？ | 把行銷語言當事實 |
| Guidance | 何時適用？ | 無條件給建議 |
| Limitations | 何時應排除？ | 用賣點覆蓋否決條件 |
| Compatibility | 哪些條件必須匹配？ | 假設介面或版本 |
| Identifiers | 究竟是哪條記錄或變體？ | 合併產品與變體識別碼 |
| Sources | 為什麼可以相信？ | 沒有出處的摘要 |
發布前測試
把文件交給一位沒有看過商品頁的審核者，請其識別產品、選擇合適用例、拒絕一個不相容場景，並追溯每條決定性陳述。任何需要猜測的答案都說明文件仍有缺口。
拆開一份真正有用的商品知識
以一隻帶兩種杯蓋的不鏽鋼水瓶為例。Facts 可以寫容量、材質、尺寸和保溫測試條件；Guidance 可以說明吸管蓋適合直立的日常使用；Limitations 應說明倒置時吸管蓋不防漏、產品不適合碳酸飲料；Compatibility 可以寫杯架直徑和可替換杯蓋；Identifiers 則區分商品組和具體顏色、杯蓋組合。每條決定性資訊都應回到公開來源。
這些類別能阻止宣傳語承擔過多職責。「適合所有冒險」不是可驗證事實；「適用直徑至少 76 毫米的杯架」是相容閾值；「安裝吸管蓋時不要裝熱飲」是限制。Agent 可以按不同規則處理它們，前提是商家先明確了每句話的用途。
說法強度不能超過證據
如果測試只覆蓋某個型號、顏色或設定，結論不能默默擴充到所有變體；來源只寫「防潑水」，文件就不能升級成「防水」；尺寸若不含可拆卸把手，也應說明測量條件。Source 證明資訊從哪裡來，準確措辭決定是否忠實於證據。
未知就應保持未知。與其從照片或相鄰商品推斷，不如暫時省略；若缺失事實會頻繁影響推薦，可以進入內容補全佇列。消費者也必須把缺失當成缺失，不能當成肯定或否定值。
用真實購買問題做編輯審核
欄位齊全不代表內容有用。審核時應提問：誰適合、誰不適合、與什麼相容、指的是哪個變體、結論由哪個來源支援？當問題轉向目前庫存、價格、配送、稅費或支付時，文件能否明確觸發即時交接？
對每個重要變體邊界都執行問題，並讓第二位審核者從答案追溯到原句和來源。目標不是堆最多文字，而是維護最小、可靠的事實集合，使正確匹配、明確拒答和即時交接都能發生。
追求有邊界的完整，而不是複製整個資料庫
把 PIM 的每個欄位全部複製進來，會淹沒真正影響推薦的內容。應從決策出發：身分、用途、不相容、變體選擇、證據和即時交接。只有能幫助這些決策且有長期維護來源的事實才加入；內部物流欄位和重複行銷文案應排除。
這樣，文件對編輯和消費者都更輕，diff 也能展示真實說法變化，而不是數千個再生成屬性。完整不是映象整個資料庫，而是足以支援宣告的使用場景，並明確未知項。