跳至主要內容
SKU.md
選單
繁體中文

在BigCommerce商店發布 SKU.md。

輸入公開店面或目錄，或單一公開商品頁。先生成最小根檔案，再視需要新增一份附上 Source 的商品資料檔案。

開啟 BigCommerce 生成器

不使用憑證 · 不存取私有 API · 不批次抓取 · 不自動發布

BigCommerce 負責即時商務，SKU.md 提供已審核知識

這項整合讓動態交易與穩定的商品資料，繼續留在真正能負責它們的系統裡。

BIGCOMMERCE

即時商務權威

負責目前的商品、變體、通路價格、庫存、購物者、購物車、訂單與結帳行為。

SKU.md

最小公開文件契約

在 /sku.md 發布 v1 根檔案，並只在需要時新增一份附上 Source 的商品資料檔案。

目前的生成器只使用公開證據

流程只使用公開輸入，並在本機產生檔案。

  1. 01

    輸入公開網址

    提供公開店面或目錄，或單一公開商品頁。

  2. 02

    先生成最小根檔案

    在新增任何視需要文件之前，先建立並驗證 v1 根檔案。

  3. 03

    只新增有來源的知識

    可視需要從使用者明確提交的商品頁，建立一份附上 Source 的商品資料檔案。

  4. 04

    發布並驗證

    發布 /sku.md，然後執行 document、published 與 graph 驗證。

BigCommerce 官方能力各自解決生命週期中的不同問題

下列能力都有 BigCommerce 官方文件；列出來不代表目前的公開生成器已經呼叫它們。

公開頁面

店面、目錄或商品頁

目前的生成器只讀取使用者提交的公開網址，不推斷其他商品，也不抓取目錄。

店面

GraphQL Storefront API

可查詢公開商品、變體、價格、店面 metafield、路由和內容；請求需要合適的 bearer token，目前的生成器不接收。

管理

REST Management API

已授權的 API 帳戶可用限定範圍的憑證管理目錄和商店資料；這是未來伺服器端同步的輸入，不是公開瀏覽器的資料來源。

授權

API 帳戶與 OAuth

商店層級與應用程式層級的帳戶都包含 access token 和 OAuth scope；機密資料必須留在伺服器端，並遵守最小權限原則。

事件

Webhooks

HTTPS、Pub/Sub 或 EventBridge 事件可觸發增量更新；接收端仍需驗證、確保冪等、處理重試並定期對帳。

店面 UI

Scripts API

已授權的應用程式可加入依通路生效的店面指令碼；指令碼可以提供探索連結，但用戶端程式碼不是目標的 Markdown 回應。

交付

Stencil 與 headless 店面

Stencil 自訂範本會繫結到既有的頁面型別；商家自行控制的 headless 或 edge 層，可以實作精確的同源文件路由。

已核對的官方資料沒有記錄 BigCommerce 採用 SKU.md。平台能力、相容探索、嚴格符合規範與即時權威，必須分開陳述。

依你能證明的回應選擇交付方式

三種模式產生的 Markdown 都相同；只有真實部署後的回應，才能決定發布是相容還是嚴格。

探索

Stencil 店面

透過主題、既有內容頁或應用程式管理的指令碼，加入看得到或機器可探索的連結。

Stencil 範本會渲染既有的頁面型別，Scripts API 則是安裝指令碼；兩者都無法單獨證明根路徑會回傳 text/markdown / text/plain (UTF-8) 回應。

嚴格候選

商家控制的 headless 路由

由店面應用程式提供不可變、已預先驗證的檔案，並讓 Catalog 回連與 Product URL 保持在同一來源網域。

要求精確的 HTTP 200、Content-Type: text/markdown / text/plain (UTF-8)、位元組完全一致、有效的文件圖、可預期的快取替換，以及未知檔案精確回傳 404。

嚴格候選

同源 edge 路由

在請求進入代管店面之前，於 /sku.md 和商品檔案路徑提供已儲存的文件。

路由規則不是證明；每次發布內容變更後，都要驗證真實回應。

模式可以做到什麼證據邊界
Stencil透過主題、自訂頁面或 Scripts API 提供探索說明。只算相容探索；官方記載的能力無法證明可以提供任意根路徑的 Markdown 回應。
Headless由商家控制的店面應用程式在商店網域提供已接受的檔案。精確路由、媒體類型、位元組、文件圖、快取替換和 404 全部通過後才算嚴格。
Edge在代管店面之前攔截同源文件路徑，並回傳已儲存的位元組。必須獨立驗證真實的公開回應，設定介面本身不是證據。

讓 v1 文件家族保持最小

專用生成器與一般流程共用同一套 v1 建構器與驗證器。

最小根檔案優先

用公開的商店身分和目錄入口建立 v1 根檔案。

一份視需要的商品檔案

只為使用者明確提交的單一公開商品頁新增商品資料。

附上 Source 的事實

每條事實都連結到公開 Source；graph 驗證器會檢查文件之間的關係。

保守的範圍

如果沒有可用的有來源商品資料，就保留有效的根檔案，不建立視需要的文件。

逐一驗證每個發布範圍

建立與發布是兩個不同步驟，因此每個範圍都需要獨立的證據。

  1. document

    驗證產生的位元組

    發布前先執行目前的 v1 文件驗證器。

  2. published

    驗證公開回應

    檢查真實 /sku.md 的狀態、MIME 型別和位元組。

  3. graph

    驗證關係

    檢查每一份被引用的文件和 Source 關係。

  4. 重複

    每次變更後複核

    發布的檔案變更後，重新執行所有範圍。

目前的流程不會連結 BigCommerce 帳戶，也不會自動發布檔案。

目前版本的權限與限制

公開流程刻意保持範圍窄、可檢查，並把發布決定留給商家。

  • 不登入 BigCommerce，也不使用 API 帳戶、OAuth、access token、storefront token 或 private token。
  • 不呼叫 REST Management API 或 GraphQL Storefront API，也不抓取商品目錄。
  • 不存取訂單、客戶、購物車、結帳、支付或私有商品。
  • 不訂閱 Webhook、不在背景同步、不編輯主題、不安裝指令碼，也不自動更新。
  • 不修改 DNS、代理、edge、快取或正式環境的發布設定。
  • 不聲稱 BigCommerce 背書、合作、官方支援 SKU.md，或能帶來採用上的好處。

從品牌角度看整合

閱讀各平台專欄，了解 SKU.md 能補上什麼，以及怎麼從一件商品開始試作。

SKU.md v1 平台整合

歷史 beta 專欄: BigCommerce 的 SKU.md 整合

2026-08-07 核對的官方來源

BigCommerce 能力相關事實來自 docs.bigcommerce.com；SKU.md 的交付要求會另外標為獨立驗證規則。

BigCommerce 整合常見問題

生成器會連結 BigCommerce 帳戶嗎？

不會。它只讀取公開 HTML 和一個使用者明確輸入的同源商品頁，沒有登入、token、OAuth，也沒有 BigCommerce API 連線。

為什麼不直接呼叫 GraphQL Storefront API？

BigCommerce 要求合適的 bearer token；公開生成器刻意不接收憑證，也不代理 private token。

Stencil 能直接發布 /sku.md 嗎？

已核對的自訂範本文件只涵蓋既有的品牌、分類、商品和頁面型別，無法證明可以提供任意根路徑的 Markdown 回應。

Scripts API 能發布檔案嗎？

Scripts API 是在店面安裝用戶端指令碼；指令碼可以提供探索連結，但不是請求所需的 HTTP 200 text/markdown / text/plain (UTF-8) 文件回應。

Headless 店面可以做什麼？

商家控制的 headless 應用程式可以實作路由，但只有真實的同源回應通過狀態、MIME、位元組、文件圖、快取和 404 檢查後，才算嚴格交付。

生成器會先建立什麼？

它一定先建立最小的 v1 根檔案；附上 Source 的商品資料檔案則是選用項目。

商品資料檔案會取代即時目錄嗎？

不會。它只包含明確附上 Source 的事實，不帶即時價格或庫存狀態；購物車、結帳、支付和訂單仍由 BigCommerce 負責。

BigCommerce 官方支援 SKU.md 嗎？

已核對的官方來源並沒有這樣說。這份獨立指南把已記載的 BigCommerce 能力對應到商家可控制的流程，不代表 BigCommerce 官方採用或背書 SKU.md。

從公開證據開始，只發布你能驗證的內容

不必提供憑證就能建立可審核的草稿；用 Stencil 做探索，或用商家控制的 headless、edge 路由提供可驗證的 Markdown。

開啟 BigCommerce 生成器