BLOG / sku-md-adoption-flywheel.mdx
SKU.md 采用飞轮：先有证据，再谈生态
分析发布者—验证器—消费者的现实采用路径：生成器、平台默认、合规套件、参考消费者、案例与社区治理。
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产出可测试的发布者证据。