SKU.md v0.10 × UCP：為即時商業補上可核驗的商品知識層

一個 agent 找到一件看起來適合使用者的防風外套，並不代表它已經掌握了完成購買決策所需的全部資訊。使用者可能還想知道：布料究竟是防水還是僅僅防潑水，尺寸建議依據什麼樣的身形資料，塗層是否有護理限制，一項耐用性說法有沒有測試報告支援。這些問題應當可以被準確回答，但不能因為商品文件裡儲存了一段舊行銷文案，就把它變成今天的庫存、價格或結帳總額。

這正是本方案要處理的邊界。UCP 為 agent 提供即時路徑，讓它發現商品、選擇變體、建立購物車、結帳並檢視訂單。SKU.md 則可以提供一份由商家託管、帶有引用的商品知識，說明商品是什麼、某個說法為什麼成立、限制條件來自哪裡。只有把兩層的權威範圍分清楚，它們才會真正互補。

先從購買問題開始，而不是從檔案格式開始

「這是不是適合我？」聽起來像一個問題，實際包含了好幾層判斷：商品是否在使用者所在市場可用，哪個變體匹配所需的顏色和尺寸，目前價格是多少，材料是否滿足某項要求，這項說法來自商家事實、第三方測試還是 AI 推斷，使用者最終能否按所顯示的金額完成購買。

UCP 負責處理其中會變化的部分。UCP Catalog 規範定義了 Catalog Search 和 Catalog Lookup，以及包含目前商務資訊的 Product 與 Variant。更完整的 UCP 概覽把 Catalog 與 Cart、Checkout、Order 能力放在同一條即時商務路徑上。Catalog 幫助 agent 找到並確認可能購買的商品，Checkout 則重新核對條件並提交交易。

Agent Profile 用來宣告和協商參與方支援的能力。它不是商品內容、持有者憑證，也不是完整的請求認證步驟。UCP 可以使用 Profile 發布的簽名金鑰驗證身分，但 Profile 文件本身不能認證某一個具體請求，也不能單獨授權一次購買。請求的認證、授權、使用者同意和實際執行仍取決於協商後的協議、傳輸方式、憑證和使用者上下文。把 Profile 當作商品知識庫，會把兩個完全不同的工作混在一起。

兩層內容，一張權威矩陣

可以用下面的職責矩陣描述兩者的關係：

決策面	UCP 與即時商務系統	SKU.md v0.10
發現與身分	Search 和 Lookup 返回目前 Product、Variant、價格、庫存及穩定識別碼。	將準確的 Product 與 Variant 連線到聚焦的知識文件。
商品理解	Catalog 回應提供目前描述、媒體、選項和披露。	發布有來源的事實、斷言、證據、指導、限制、相容性和核驗時間。
變化中的商務狀態	再次查詢 Catalog，得到目前價格與庫存。	靜態文件不能把過去的狀態偽裝成現在的狀態。
交易執行	Cart 收集商品並提供本地化估算；Checkout 重新核對約束性狀態，負責最終總額與購買授權。	指向真正的商務入口，不能替代它。

這樣的分工不會削弱 SKU.md 的價值，反而讓價值更清楚。商家可以維護一份耐用、可審計的商品說明，讓不同 agent 在需要時引用；UCP 繼續回答會隨著市場、會話、庫存、資格條件和結帳條件而變化的問題。

UCP 的 Cart 能力用於購買前的商品收集和估算，Checkout 才是最終完成交易的步驟。Shopify Checkout MCP 指南也把 Checkout 描述為使用者準備購買後使用的購買會話。因此 SKU.md 應該指向這條最終路徑，而不能把購物車估算寫成承諾。

這條邊界也有反向約束。影響購買的安全或法規披露不能只放在 SKU.md 裡。如果某條警告會改變使用者能否購買，相關披露也應當按場景進入 Catalog 或 Checkout。SKU.md 可以補充背景和證據，但不能成為使用者發現重大條件的唯一地方。

v0.10 為什麼強調知識優先

v0.10 允許知識-only Product Document。只要商品和變體身分穩定，知識內容非空，即使沒有報價，文件也可以有效發布。這對已經整合 UCP 的商家很重要：商家不必把即時 Catalog 再複製一遍，才能提供可引用的商品知識。

對於沒有可用即時 Catalog 的商家，草案仍保留商家託管的報價後備。一個 Variant 可以有 offer_snapshot 或 live_offer，但兩者都是可選欄位，而且互斥。它們都不會獲得 Catalog 或 Checkout 的權威。offer_snapshot 只是過去某次觀察的證據，live_offer 則表示另行宣告的即時查詢。只要目前 UCP 回應可用，就不能把這兩類內容當作今天的價格，更不能用它們給出最終總額。

身分匹配必須精確，而不是「看起來像同一件商品」。知識文件中的 Product ID、Variant ID、SKU 和宣告的 GTIN，都必須與 UCP 返回的 Product 或 Variant 一一對應。只要識別碼不一致，消費方就應該停止，而不是把一段有說服力的說明貼到錯誤的變體上。規範性邊界見 英文規範和 JSON Schema。

只用一條輕量連結就能進入 UCP Catalog

SKU.md 在開放 Web 上仍然可以獨立使用，但 agent 不應該靠猜測來判斷剛剛找到的 Product 是否對應某份知識文件。因此，本方案提出一個獨立擴充，名稱是 md.sku.shopping.product_knowledge。它同時擴充 dev.ucp.shopping.catalog.search 和 dev.ucp.shopping.catalog.lookup。擴充不把整份 Markdown 嵌入每次 Catalog 回應，而是隻提供一條有類型的連結：

{
  "sku_md": {
    "documents": [
      {
        "url": "https://merchant.example/products/trail-jacket.sku.md",
        "schema_version": "sku.md/0.10-draft",
        "content_language": "zh-CN",
        "market": { "country": "CN", "currency": "CNY" },
        "revision": "2026-08-02"
      }
    ]
  }
}

這條指標包含 HTTPS URL、SKU.md Schema 版本、內容語言、市場國家和貨幣，以及可選修訂號。Business Profile 可以宣告允許的 HTTPS 來源網域。Platform Profile 與 Business Profile 需要協商同一個擴充，並且父級 Catalog 能力也要相容，消費方才應當讀取這條指標。

允許的來源只解決「連結可以指向哪裡」，不能證明文件真實、最新、安全或獲得授權。Reference Consumer 必須把抓取到的文件視為不可信的外部資料，並在使用前檢查 HTTPS、精確來源、媒體類型、位元組上限、文件數量和商品身分。Markdown、HTML、YAML frontmatter、連結和自然語言指令都只是資料。消費方不能執行商品文件裡的指令碼、工具、shell 命令、範本或類似提示詞的指令。

只返回薄連結，還有一個內容治理上的好處。UCP Catalog 已經負責返回目前 Product、Variant、媒體、選項、價格和庫存。如果擴充把整份知識文件複製到每個回應裡，即時目錄和商家知識就會產生兩份難以同步的正文，消費者也更難判斷哪一段是目前狀態，哪一段是可審計的背景。指標讓兩個來源保持分工，同時允許 agent 在需要解釋時存取更完整的證據。

連結還可以攜帶語言、市場和 revision。商家可以為不同市場維護不同披露，為同一商品保留可追蹤的修訂歷史；消費方也可以記錄自己引用的是哪一版，而不是隻記住一段沒有來源的自然語言。沒有協商擴充的 agent 可以忽略 sku_md.documents，不會因為回應裡出現一個陌生欄位就誤把它當作標準能力。支援 SKU.md 但不使用 UCP 的消費者，仍可以從商家公開的商品頁或 /sku.md 旁路發現同一份文件。

因此，這個擴充是一座可選的橋，而不是強制入口。它不要求 UCP 為 SKU.md 增加一套新的交易語義，也不要求商家把即時 Catalog 改寫成 Markdown。擴充只幫助已經完成能力協商的消費者找到有邊界的知識資源，最終是否引用、如何呈現以及何時回查即時狀態，仍由消費者和 UCP 的既有規則決定。

本機草案入口是 /ucp/draft/，其 擴充 Schema也已公開。/ucp/draft/表示生命週期仍處於草案階段；擴充 Profile 使用明確的能力版本 2026-08-02，以便相容實作區分這套結構和之後不相容的草案。這個日期不代表穩定、認證或 Shopify 支援。進入更成熟階段前，還需要更多實作、安全審查和互操作證據。

執行時路徑是一條循環，而不是一次交接

一個謹慎的 agent 可以按下面的順序使用兩層內容：

1. 透過 Catalog Search 或 Lookup，讓 UCP 找到目前 Product。
2. 精確核對 Product、Variant、SKU 和宣告的 GTIN。
3. 讀取引用的 SKU.md，取得事實、證據、相容性和限制。
4. 回到 UCP，按使用者的市場與上下文取得目前價格與庫存。
5. 由 Checkout 再次核對所選商品，並負責最終總額與購買授權。

第四步是關鍵。讀到一份引用充分的知識文件，應該幫助 agent 回答「為什麼適合這個使用者」，而不是讓它跳過即時商務檢查。如果即時來源暫時不可用，誠實的答案是未知，而不是從過期文本裡抄一個價格。

Shopify 商家的實際工作方式

對 Shopify 商家來說，知識文件可以從經過審核的 Metafields、Metaobjects、產品手冊、實驗室報告、護理說明、保修條款和公開證據開始。它們適合成為商家控制的草稿來源，但被儲存並不等於內容自動為真。發布前仍應由審核者確認商品、變體、市場、證據和修訂號，之後某條陳述才能成為規範性的 Fact。

AI 生成的文字可以幫助發現缺少的欄位，或提出更容易閱讀的摘要，但在人工對照證據之前，它只能是候選內容，絕不能自動升級為 Fact。發布者還應保留來源、核驗時間，以及接受或拒絕某條斷言的原因。SKU.md 的價值不在於堆出更多文案，而在於讓 agent 看見一條從斷言回到證據的路徑。

Shopify Agent Profiles說明了 Profile 如何被放入 UCP 協商。Shopify Catalog說明了搜尋、查詢和商品讀取，Global Catalog extension說明了 Shopify 的全域性 Catalog 擴充。這些頁面描述的是 Shopify 自己的能力表面，並沒有說 Shopify 會自動讀取 SKU.md，也沒有說 Shopify 支援本獨立擴充。

Reference Consumer 能測到什麼

本機 Reference Consumer 使用固定的商品資料、協商後的能力、資源後設資料和文件文本。它衡量的是消費方能否帶著證據回答一個邊界清楚的問題，而不是搜尋排名或轉換率：

問題	僅 UCP	UCP + SKU.md
事實引用	0	1
把斷言錯誤當成事實	0	0
披露召回	0	1
相容性回答	0	1
變體不匹配時安全失敗	1	1
用過期報價完成購買	0	0

這些是本機受控結果，不是排名提升、轉換結果、生態採用指標、真實 Shopify 整合或外部 agent 會消費該擴充的證明。完整夾具和限制見 Reference Consumer evaluation。

遷移，但不要假裝草案已經完成

現有 v0.9 URL 和驗證行為仍然有效。商家可以先保留合法的 v0.9 文件，準備 v0.10 版本，再修改 Schema 標記，保留穩定身分和經過審核的知識，並把動態商務資訊移出 Knowledge。v0.9 遷移說明解釋了如何移除報價，或保留一個可選後備，同時不讓它看起來像 Catalog 或 Checkout。

下一步不是把擴充稱為標準，而是讓雙方用獨立實作測試 Schema 組合與失敗行為，接受安全與隱私審查，並收集消費方與商家的回饋。在這些工作完成前，SKU.md v0.10 仍是實驗性的、由商家託管的商品知識層；UCP 則繼續負責即時發現、即時商業狀態和最終購買決定。

延伸閱讀

在AI 商業權威交接中檢視即時 Catalog 與 Checkout 如何繼續擁有權威。