RFC 0001：SKU.md 的宣告式發現、結構化識別碼與參考價
規範筆記
一份草案：讓託管平台上的商店可以在 /sku.md 之外宣告目錄，讓 GTIN、MPN、品牌和 SKU 有可解析的寫法，並增加一個帶日期、永遠不作為報價的參考價。
SKU.md 1.0.0-beta 刻意保持很小：一個位於 /sku.md 的根目錄、可選的商品知識文件，以及每條事實上的 Source 連結。這樣的規模便於驗證，但也留下了三個缺口，而它們在 AI 對話購物中對獨立站很重要。RFC 0001 是彌補這些缺口的一份草案。
這份 RFC 不屬於目前規範。目前沒有任何驗證器、生成器、CLI、MCP 工具或 Agent Skill 實作它；即使它被採納，所有 1.0.0-beta 文件也依然有效。完整文本見 RFC 0001。
缺口一：託管平台上的商店無法使用根路徑
規範要求目錄路徑必須正好是 /sku.md。專案自己的 Shopify 指南 記錄了該平台託管商店根路徑、並限制 App Proxy 前綴。其他平台的檔案庫託管通常依賴會改變最終路徑的重新導向。這些商家往往可以從另一個同源路徑提供同樣的 Markdown，但現在這樣做不合規。
RFC 保留 /sku.md 作為讀取方首先檢視的位置。根路徑不存在時，商店可以透過五種提示之一宣告另一個同源目錄 URL，讀取方按固定順序檢查：
- 保留路徑
/.well-known/sku.md，需要先向 IANA 註冊。 - 首頁回應中的 HTTP
Link頭，帶rel="alternate"、type="text/markdown"和title="SKU.md"。 - 首頁中表達同一關係的 HTML
link元素。 llms.txt的Product knowledge章節中，文字為SKU.md catalog的連結。agents.md中以SKU.md catalog:開頭的一行。
後兩種正是 發現入口指南 現在推薦的寫法，所以現在就新增這些引用的商店，將來已經具備了宣告。
每個提示都必須同源，被宣告的檔案和根目錄一樣接受完整驗證。兩個提示互相矛盾時會報告衝突。RFC 還要求讀取方優先採用需要控制首頁的提示，而不是平台可能重新生成的檔案中的提示，因為放寬路徑規則會增加把商家並不控制的內容宣告為目錄的風險。
缺口二：識別碼只是自由文本
購物系統依靠 GTIN、MPN、品牌和商家 SKU 判斷兩處提及是否指同一件商品。在 1.0.0-beta 中，它們可以寫在 Identifiers 章節，但只能是自由文本。RFC 增加一種解析器無需猜測就能讀取的結構化寫法：
## Identifiers
- GTIN: 00012345678905 [Source](https://www.example-outdoor.com/products/tent)
- MPN: UL2P-24 [Source](https://www.example-outdoor.com/products/tent)
- Brand: Example Outdoor Gear [Source](https://www.example-outdoor.com/pages/about)
- SKU: TENT-UL2P-GRN [Source](https://www.example-outdoor.com/products/tent)GTIN、MPN、Brand、SKU 和 ISBN 是保留標籤。GTIN 必須透過 GS1 驗證位檢查；以保留標籤開頭但不符合規則的條目直接判為無效，而不會悄悄當作普通文本。不同規格有不同識別碼時，可以在值後面加上 for 和規格名稱。結構化 GTIN 與 Product JSON-LD 或商品 Feed 衝突時，讀取方應報告衝突並引導顧客去即時頁面，而不是自行選一個值。
缺口三：價格完全沒有位置
在對話購物中，價格常常是第一道篩選條件。1.0.0-beta 不允許靜態檔案包含即時價格，RFC 保留這條規則，只是增加一個可選的 Reference price 章節，帶日期和來源：
## Reference price
- USD 349.00 as of 2026-08-11 [Source](https://www.example-outdoor.com/products/tent)
- USD 299.00 to 349.00 as of 2026-08-11 for all variants [Source](https://www.example-outdoor.com/products/tent)幣種使用 ISO 4217 程式碼，金額用小數點且不帶千分位，as of 日期不能晚於文件的 Updated 日期。這一章節不能寫促銷價、優惠碼、會員價、運費、稅費或庫存。讀取方使用這個值時，必須把它作為帶日期的參考呈現，不得用於購物車或結帳，並且應把超過 90 天的日期視為過期。
這是草案中最有爭議的部分。理由是：按預算篩選的助手會跳過完全沒有價格資訊的商品，而一個日期和來源都清楚的參考價，會把顧客帶到即時頁面去確認。
RFC 暫不處理的內容
同一輪評審中的若干想法留給後續提案：根目錄中表示銷售地區、語言和幣種的 Markets 章節；根目錄中可選的 Brand 和 Categories 章節；把 31 個文件的圖譜上限從規範中拆出來；面向讀取方的寬鬆解析模式；以及 Markdown 資源與 Sitemap、規範頁面之間關係的指引。RFC 把它們列出來，是為了讓對這份草案的討論保持聚焦。
待決問題與如何回饋
草案直接提出了四個問題：現在就申請 well-known 註冊，還是等出現第二個獨立實作？平台可能覆蓋 llms.txt 和 agents.md，這兩種提示還要保留嗎？對價格變化快的品類，90 天的過期閾值是否合適？根目錄是否也應允許寫 Brand？
歡迎在 專案倉庫 中回饋。推進計劃要求在任何正式版本採納之前，先在驗證器中以預覽開關實作、為每個新問題程式碼增加一致性測試樣例、至少有一家託管平台商家透過宣告的 URL 發布，並有一個獨立讀取方讀取它。在此之前，請按 目前規範 實作。