SKU.md v1.0.0 正式發布：從商品描述到 AI 可讀的商品知識

SKU.md v1.0.0 正式發布。對獨立站商家、開發者，以及打造購物 Agent 的實作者來說，這一版提供的是一套開放的商品知識規範：讓商家用可閱讀、可維護的 Markdown，說明自己賣什麼、商品有哪些經過審核的事實，以及資訊來自哪裡。

這次發布交付的不只是檔案格式。圍繞同一份知識，商家可以檢查缺失和衝突、審核證據、按明確購買條件比較商品，並匯出審核後的內容。它為 Agent 理解商品建立了可檢查的基礎；SKU.md 仍是一項開放提案，正式版本號不代表它已經成為行業標準。

起點：商品頁面之外，還缺少什麼

獨立站已經有商品詳情、規格表、常見問題和交易系統。但當購買問題從「搜尋一個商品名」變成「找一件適合具體用途的商品」，事實往往散落在不同位置：尺寸屬於哪個變體，相容性有哪些前提，某個效能數字在什麼條件下成立。

SKU.md 的出發點，是讓商家能夠主動維護這些上下文，而不是把理解過程完全交給機器猜測。專案倉庫在 2026 年 7 月留下了最初的網站和規範探索記錄；這是開發歷程的起點證據，不是某個版本已經對外發布的證明。

從早期探索到 v1：逐步明確該負責什麼

早期 v0.8 草案嘗試組織目錄、商品文件和不同資訊來源。v0.9 進一步討論互通性、分範圍驗證和安全消費：文件可解析、線上可存取、關聯關係正確，應當分別檢查，不能互相替代。

v0.10 階段探索了商品知識與商業系統的關係，包括商品知識入口、即時商業資訊的交接，以及頁面工具的邊界。這些嘗試幫助專案回答一個問題：開放商品知識規範應該承擔多少職責？

v1 的選擇是收斂。舊版 YAML 清單、分割槽和商業設定不再進入目前格式；基礎由根目錄檔案和可選商品知識文件組成，均使用純 Markdown。歷史規範保留為檔案，目前工具只接受 1.0.0，不自動轉換舊文件。正式版的進步因此既包括新增能力，也包括清楚地減少職責。

為什麼保留 Markdown，並堅持事實有來源

商家應當能直接讀懂自己發布的內容，也能透過普通網站託管檔案。Markdown 讓文字、連結和版本差異保持可見；商品記錄則用明確結構表達身分、變體、屬性和證據，不需要再維護另一套發布格式。

來源連結讓讀者可以回到原始頁面核對。商家還可以記錄證據摘錄、審核狀態和檢查日期。但「連結能開啟」與「內容支援這條事實」是兩件事；審核標記記錄的是發布者的判斷，不是系統自動頒發的認證。

同樣，未知值不會被悄悄改成否定值，商品整體的屬性不會自動繼承到每個變體。適用範圍越清楚，消費者越容易發現資訊不足，而不是得到一個看似完整的錯誤答案。

正式版提供了什麼

層次	可以完成的工作
開放規範	發布目錄和帶來源的商品知識，明確身分、變體、屬性、條件與即時系統連結
商品最佳化工具	檢查缺失與衝突，審核事實和證據，儲存工作草稿並匯出已審核內容
比較工作台	按明確條件返回符合、不符合或資訊不足，並比較補充資訊前後的結果
CLI、Agent Skill 與唯讀 MCP	在不同使用環境中沿用規則；各工具的具體能力和發布狀態以對應說明為準

規範版本與工具包版本獨立。宣佈規範 1.0.0，不等於所有工具包同步升級為 1.0.0，也不代表候選 Skill 軟體包已經單獨發布。網頁工具、下載包與服務入口仍需分別核對。

知識負責解釋，即時系統負責交易

價格、庫存、配送、稅費、支付和訂單狀態會變化，不能靠靜態商品知識替代。SKU.md 可以指向負責這些資訊的系統，但一個連結不等於交易授權。

比較工作台驗證的是提交的資訊是否滿足給定條件，不是模型排名或銷量預測。專案的本機驗收記錄覆蓋規範、工具和八語言流程；真實外部 Agent 的採用情況和商家的通路效果，需要另外取得證據。

從一個可核對的商品開始參與

商家可以從一個有完整公開資料的商品開始，開發者可以實作解析與消費流程，也可以提交最小可重現的問題。準確的失敗案例、缺失資訊和平台限制，都比泛泛的支援宣告更有助於改進規範。

閱讀 1.0.0 規範，用商品最佳化工具審核一個商品，再到比較工作台觀察資訊變化如何影響條件判斷。需要整合 Agent 工作流時，可分別檢視 Skill 與 MCP 的能力和狀態。

歷程與版本依據

• 專案提交記錄：開發過程，不作為公開發布日期。
• v0.8、v0.9、v0.10：歷史設計依據。
• 1.0.0 變更記錄與本機驗收記錄：準備和檢查依據，不替代線上發布驗證。