SKU.md 採用飛輪：先有證據，再談生態
BLOG / sku-md-adoption-flywheel.mdx
分析發布者—驗證器—消費者的現實採用路徑：生成器、平台預設、合規套件、參考消費者、案例與社群治理。
SKU.md 已經具備採用飛輪的幾個要素，但獨立使用的證據還不足以證明飛輪真的轉起來。衡量進展要看能不能重複的真實使用，而不是只數檔案數量，或引用過度樂觀的生態說法。
SKU.md 是由商家託管的商品發現與穩定商品知識：agent 可以找到商品、理解有來源的事實，並知道去哪裡複查即時商業狀態；它不是新的結帳協議。
哪些參與者缺一不可
| 側面 | 需要什麼 | 進展證據 |
|---|---|---|
| 發布者 | 低摩擦生成、審核與精確交付 | 公開有效文件能長期維護 |
| 驗證器 | 穩定 Schema、語義檢查與線上資源測試 | 獨立實作對結果達成一致 |
| 消費者 | 清楚發現、安全解析與有邊界用例 | 帶引用回答正確，失敗也正確 |
缺少任何一方，迴圈都會停下。生成器產出的檔案需要消費者實際使用；消費者若不遵循同一套合規契約，會產生互不相容的方言；驗證器也需要可發布路徑，才能檢驗真實交付。
六項相互增強的投入
- 生成器產出小而可審的草稿，不發明事實。
- 平台主動支援時，平台預設可以把精確、商家可控交付變成常規能力。
- 合規套件分別測試離線文件、公開資源和文件圖。
- 參考消費者展示安全來源選擇與安全失敗。
- 案例公開可重複任務、成本、失敗和維護，而不只展示好評。
- 社群治理為變更定版、記錄決策，防止單一廠商重定義相容性。
這些仍是路線元件。現有本機生成器、fixtures 與 Reference Consumer 證明專案做過工作，不代表平台預設或生態採用已經成真。
拒絕虛榮指標
| 弱指標 | 更強替代 |
|---|---|
| 生成檔案數 | 90 天後仍有效的公開資源數 |
| 驗證器執行次數 | 獨立驗證器是否返回相同結果 |
| Logo 清單 | 有官方來源且真實路由已測的具名整合 |
| 演示回答 | 帶引用、含負向用例的可重複任務 |
| 流量峰值 | 記錄混雜因素後的持續 cohort 趨勢 |
專案還應公開負面結果：會跳轉的路由、無法控制 /sku.md 的平台、身分不匹配、過期證據，以及拒絕危險操作的消費者。這些結果能說明契約在哪裡有效，又在哪裡停止。
治理要求
變更需要公開規範、固定 Schema URL、遷移說明、測試 fixtures 與明確生命週期；擴充 namespace 應表明自己的權威。任何提到 MCP、UCP 或 WebMCP 的提案，在這些專案明確採用前都必須保持獨立。
v0.10 規範、合規 fixtures 與參考評測只是起點。下一步可信度來自外部審查和獨立實作，而不是把 draft 改名為 standard。
一輪負責任的實踐
先選一個範圍小的發布者問題，發布最小文件並執行線上檢查，再讓獨立消費者回答一個有邊界的問題。記錄失敗，把結果回饋到規範。擴大主張前，換一個實作再做一次。
這條迴圈未來可能支援平台工具或預設能力；現在只能誠實地稱為進行中的採用工作。
延伸閱讀
從什麼是 SKU.md開始，再用發布第一份 SKU.md產出可測試的發布者證據。