發布第一份 SKU.md：平台無關的精確交付教學
BLOG / publish-your-first-sku-md.mdx
從來源準備、Basic 生成到根路徑交付與線上檢查，完成 HTTP 200、text/markdown、canonical 和位元組一致驗證。
只有當審核通過的文件，能從宣告的 HTTPS URL 直接回傳，並通過線上交付檢查，第一份 SKU.md 才算真正發布。本機上看起來合法的檔案，終究只是本機檔案。
SKU.md 是由商家託管的商品發現與穩定商品知識：agent 可以找到商品、理解有來源的事實，並知道去哪裡複查即時商業狀態；它不是新的結帳協議。
第一步：準備最小且誠實的來源
收集店面來源網域、公開目錄入口、預設語言與市場、穩定商家身分，以及審核者願意負責的公開來源。先做 manifest-basic，不要為了填滿欄位而虛構 MCP endpoint、即時查詢、識別碼或商品 Fact。
| 輸入 | 可以接受 | 應拒絕或延後 |
|---|---|---|
| 商家身分 | 穩定公開名稱與來源網域 | 猜測的法律主體 |
| 目錄入口 | 已存在的同源 URL | 私有管理端介面 |
| Knowledge | 已審陳述與來源 | 自動升級的行銷文案 |
| 報價 | 帶時間的觀察或已宣告查詢 | 沒有時間邊界的價格承諾 |
第二步：生成並做離線驗證
使用 Basic 生成器或其他能輸出 sku.md/0.10-draft 的實作。確認 canonical、內容語言、市場與文件類型，再執行 offline_document，檢查安全 YAML、Schema、語義一致與正文對齊。
離線通過只證明這些位元組能組成可接受文件；它證明不了 DNS、路由、狀態碼、媒體類型、快取、parent 鏈或公開可讀性。
第三步：發布到精確根 URL
發布者指南要求根清單位於精確 HTTPS /sku.md。回應契約必須逐項滿足：
- 請求
https://merchant.example/sku.md，禁止自動跟隨跳轉。 - 要求精確 HTTP 200，不能是 301、302、206 或通用成功頁。
- 要求
Content-Type: text/markdown，只允許合法可選參數。 - 確認 frontmatter 的
canonical等於請求 URL。 - 對比回應正文與已審核、已接受的位元組。
託管 HTML 檢視、CDN 資源 URL、主題 alternate 或跳轉可以提供相容展示，但不屬於嚴格根路徑發布。
第四步：做線上與文件圖檢查
先對每份公開文件執行 published_resource，再從根執行 document_graph。檢查 canonical、parent、語言、連結狀態、媒體類型、可解析性、遍歷深度與失敗行為。未知文件路徑不能用 HTTP 200 返回通用 HTML。
| 範圍 | 能證明 | 不能證明 |
|---|---|---|
offline_document |
本機結構與語義 | 公共交付 |
published_resource |
單個精確線上資源 | 完整文件圖 |
document_graph |
可達的父子契約 | 外部採用或排名 |
第五步：補充發現入口與營運循環
從合適的公開頁面或已記錄的發現途徑連結 /sku.md，讓 Sitemap、Product JSON-LD、llms.txt 與 agents.md 保持各自職責。記錄已接受位元組雜湊，並在路由、主題、CDN 或網域變化後重跑線上檢查。
增加 Product Document 時，繼續保持穩定身分與來源審核；目前價格、庫存、配送、稅費、支付和訂單必須回到即時 Catalog 或 Checkout。
延伸閱讀
用Schema 通過但還不能發布排查交付錯誤，再用穩定知識與即時資料給欄位分類。