SKU.md v0.9：互通性、分範圍合規與安全消費

SKU.md v0.9 是一次互通性與一致性收斂。它沒有增加 Shopify 專屬欄位、排名 分數或第二套結帳系統；它明確的是發布者如何宣告自己檢查了什麼、消費方如何 理解這份證據，以及雙方必須在哪些地方回到即時商業系統。

wire format 保持不變

v0.9 Schema 保留 v0.8 的文件類型、Profiles、欄位、必填項、列舉、擴充規則與 安全邊界。因此，資料層遷移刻意保持簡單：

1. 把 schema_version 更新為 sku.md/0.9-draft；
2. 把 Schema URL 更新為 https://sku.md/schema/sku-md/0.9/schema.json；
3. 對準備宣告的合規範圍執行全部必需檢查。

消費方可以為了相容繼續讀取 v0.8 文件，但不能把它標為 v0.9 合規。版本身分 與合規證據是兩項不同宣告。

完整的英文 v0.9 規範 是唯一規範性文本。公開的 v0.9 JSON Schema 只檢查結構，不能單獨得出完整合規結論。

三種合規範圍

v0.9 要求驗證器準確寫出自己檢查的範圍。

範圍	可以證明	不能證明
offline_document	安全 frontmatter 與 YAML、Schema、單文件語義和正文一致性	HTTP 交付、資源可達性或父鏈完整性
published_resource	一個真實 URL 的 HTTP 狀態、跳轉、MIME、canonical、soft fallback 和可達性	整個文件家族的一致性
document_graph	父鏈、表示、外部 Profile、引用資源和跨文件一致性	購買、支付或修改商業狀態的權限

報告還把語法、Schema、語義與線上檢查分層記錄。任一必需檢查失敗，總狀態 就是 failed；沒有失敗但有必需檢查未執行時，總狀態是 incomplete，絕不 能寫成 passed。

可跨工具交換的驗證報告

報告是關於文件的證據，不進入 SKU-MD frontmatter。一份通過驗證的根文件報告 可以是：

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

穩定錯誤程式碼讓不同工具可以處理相同問題，例如 YAML_DUPLICATE_KEY、 SCHEMA_VALIDATION_FAILED、CANONICAL_MISMATCH、 GTIN_CHECK_DIGIT_INVALID、KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN 與 BODY_PARITY_INVALID。網路超時不能被轉換為通過。

本站生成器目前只生成 offline_document 報告。上傳之後，仍需檢查 HTTP 狀態、text/markdown、soft fallback、canonical、parent、表示入口與外部 Profile 引用。

Reference Consumer 的完整流程

Reference Consumer 是消費方行為契約，不是新的 wire format。它規定一條安全 順序：

1. 發現商家託管的根檔案，核對來源與表示；
2. 只沿宣告的目錄入口和分割槽遍歷，不猜測隱藏商品；
3. 使用穩定識別碼、選項、市場、語言和 canonical Variant URL 精確選擇變體；
4. 區分 Facts、Claims、Disclosures、Guidance、Limitations、Compatibility、 來源 URL 與核驗日期；
5. 把 offer_snapshot 視為觀察結果，透過 live_lookup 或 live_verification 查詢目前價格、庫存、配送、稅費與總額；
6. 把購物車、結帳、支付與訂單交回宣告的即時權威，並獲得使用者明確確認。

身分、證據、新鮮度或權威不足時，消費方必須 fail closed，不能用模型推斷 填補缺口。

來源治理保留在工具層

發布工具需要管理一些不應暴露給消費方的狀態。私有 Source Map 可以記錄每個 值的來源，以及它屬於 Detected、Derived 還是 Verified。隨後透過 Audit–Plan–Apply，對比 HTML、Product JSON-LD、Merchant Feed、平台 Catalog 與現有 SKU-MD；準備可審核差異；最後在人工確認後發布。

Source Map、審核記錄、草稿狀態、發布 diff、問題日誌與通路指標都不進入公開 Schema。增量重建或線上驗證失敗時，交付系統應保留最後有效版本，不能用不完整 結果覆蓋。

與平台協同，而不是複製平台

SKU-MD 負責穩定知識和明確來源邊界。平台 Catalog 繼續負責即時商品分發、價格 與庫存；即時 API 或 UCP/MCP 負責動態查詢；Checkout 負責買家認證、最終總額、 支付與訂單建立。

截至 2026-08-01，Shopify 已公開 Shopify Catalog，以及符合 UCP 的 Catalog、 Cart、Checkout 與 Order 介面。但 Shopify 沒有說明這些系統、ChatGPT 或其他 Shopify 通路會讀取或採信 SKU-MD。因此，整合指南使用外部指標和權威邊界， 不會複製支付或訂單狀態。

用可測指標審視 SEO、GEO 與 AEO

有價值的問題不是靜態檔案是否「提升 AI 排名」，而是透過受控實驗衡量：

• Variant 精確解析率；
• 是否引用有來源的 Fact，而不是行銷文案；
• 披露與限制是否被正確召回；
• 時效敏感回答前是否執行即時回查；
• HTML、Product JSON-LD、Merchant Feed、平台 Catalog 與 SKU-MD 是否一致。

這些指標可以判斷發布契約是否減少歧義與過期答案，但不能證明爬蟲一定抓取， 也不保證平台一定排名、引用、推薦或帶來轉換。

實際遷移順序

先更新版本識別碼並生成離線報告，人工審核後再發布；隨後驗證真實資源與完整文件 圖。把動態商業資料留在 Knowledge 之外，在自動化失敗時保留最後有效 revision， 並透過受控實驗比較效果，不使用無證據的採用或排名主張。

延伸閱讀

按照發布第一份 SKU.md應用目前交付契約。