讓 AI 讀懂你的商品：SKU.md v1.0.0 如何為 Agent 購物做好準備
v1.0.0 專題
用旅行杯範例理解商品發現、事實審核與條件比較，瞭解 SKU.md 如何幫助獨立站商家為 Agent 購物準備商品資訊。
當使用者把購物需求交給 AI，他可能不會先指定品牌，而是描述一個用途：「找一隻容量至少 300 毫升、能保溫的藍色旅行杯。」對商家來說，機會不只取決於商品有沒有展示出來，也取決於系統能否判斷它是否適合這個人。
SKU.md v1.0.0 幫助商家把這類判斷所需的知識整理成可發現、可追溯、可比較的內容。它讓商家有機會減少商品被誤解或因資訊不足而無法判斷的情況，不能保證外部 Agent 一定讀取、引用或推薦商品。
同一個杯子，為什麼可能得到「資訊不足」
以下是虛構範例，不是真實商店、使用者測試或曝光實驗。某旅行杯頁面寫著「容量 350 毫升」，並提供藍色款，但沒有明確藍色款是否保溫。
如果容量只記錄在商品整體範圍內，系統不能直接把它當作藍色變體的已知屬性。藍色款保溫資訊缺失，也不能被解釋成「不保溫」。這兩處不確定都會影響針對藍色款的條件判斷。
| 購買條件 | 起初掌握的資訊 | 下一步 |
|---|---|---|
| 藍色變體至少 300 毫升 | 只有商品整體的 350 毫升說明 | 查證該規格是否適用於藍色款，並記錄變體範圍與來源 |
| 藍色款可以保溫 | 未知 | 尋找明確說明；沒有證據就保留未知 |
| 現在有貨、週五前送達 | 靜態知識不能確認 | 回到商店即時系統核實 |
這個區別很重要：資訊不足提示需要補充證據；明確不符合則提示該商品不適合這個條件。把兩者混為一談，會誤導商家和消費者。
可發現：給願意讀取知識的消費者一個入口
商家可以在網站發布根目錄 /sku.md，把目錄與可選商品知識文件連線起來。消費者因此獲得明確的讀取起點，不必猜測哪些連結帶有商品事實。目前規範也定義了根路徑返回精確 404 後才能考慮的首頁宣告式備用入口。
發布入口是商家可控制的工作，消費者是否實作並存取它則由對方決定。網站原有商品頁面、搜尋最佳化和通路 Feed 仍需維護。檔案通過驗證，不意味著搜尋引擎已收錄，也不意味著 AI 平台已整合。
可理解：讓每條事實帶上身分、範圍和證據
旅行杯的容量、顏色、保溫效能應該對應到具體商品或變體。測量條件、限制和來源也應一併保留。例如，存在特定測試條件的效能資料不能被改寫成無條件承諾。
規範允許記錄證據摘錄和審核狀態。審核時需要確認原文確實支援這項屬性，而不僅是確認網址可存取。未得到支援的賣點應保持待審核或未知，不應為了讓表格完整而補寫。
這些知識幫助消費者看清商品的適用範圍，也讓商家更容易追查「這條說法從哪裡來」。
可比較：觀察事實變化，而不是追求一個 AI 分數
在範例中，商家查證藍色款確實為 350 毫升後，可以為這個變體補上有證據的容量記錄。容量條件由資訊不足變為符合；只要保溫仍然未知，整體仍不能判定符合兩個條件。
如果後續證據明確支援保溫，且審核完成，兩個靜態條件才可能同時滿足；如果明確不保溫，則應被排除。容量只要單位相容，也可以按升與毫升轉換比較。
這是同一組條件下可重現的規則判斷，不是模型對商品的喜愛程度，也不是平台展示位置。增加一條準確的限制讓商品不再入選，有時恰恰說明知識變好了。
在現有工具中走一遍
- 開啟商品最佳化工具，先用內建範例熟悉流程，再按介面支援的方式載入自己的商品資料。
- 檢視缺失、衝突和證據問題，確定哪些屬性值得補充。
- 回到公開來源核對摘錄、商品範圍和測量條件，明確確認後再接受修改。
- 在比較工作台使用相同條件對照修改前後，分別觀察符合、不符合與資訊不足。
- 匯出審核後的 Markdown，或需要人工審核的通路結構化資料建議，再檢查匯出內容。
通路建議不會替你發布到商店或廣告系統，也不保證獲得搜尋展示資格。價格和庫存等商業欄位仍應由原有系統維護。工作草稿可下載儲存，不應把目前瀏覽器裡的編輯狀態當作已經上線。
用一個商品建立自己的基線
先記錄這個商品有哪些條件能回答、哪些缺證據，以及檔案是否能被公開存取。補充事實後，用相同輸入再檢查一次，保留前後結果。
如果將來展開真實 Agent 測試，應記錄所用產品與版本、提問、是否存取檔案及引用了哪些來源。把存取、引用、到站和購買分開觀察，才能判斷變化發生在哪一步，不能把本機條件比較當成曝光增長資料。