SKU.md v0.9：互操作、分范围合规与安全消费

SKU.md v0.9 是一次互操作与一致性收敛。它没有增加 Shopify 专属字段、排名 分数或第二套结账系统；它明确的是发布方如何声明自己检查了什么、消费方如何 理解这份证据，以及双方必须在哪些地方回到实时商业系统。

wire format 保持不变

v0.9 Schema 保留 v0.8 的文档类型、Profiles、字段、必填项、枚举、扩展规则与 安全边界。因此，数据层迁移刻意保持简单：

1. 把 schema_version 更新为 sku.md/0.9-draft；
2. 把 Schema URL 更新为 https://sku.md/schema/sku-md/0.9/schema.json；
3. 对准备声明的合规范围运行全部必需检查。

消费方可以为了兼容继续读取 v0.8 文档，但不能把它标为 v0.9 合规。版本身份 与合规证据是两项不同声明。

完整的英文 v0.9 规范 是唯一规范性文本。公开的 v0.9 JSON Schema 只检查结构，不能单独得出完整合规结论。

三种合规范围

v0.9 要求验证器准确写出自己检查的表面。

范围	可以证明	不能证明
offline_document	安全 frontmatter 与 YAML、Schema、单文档语义和正文一致性	HTTP 交付、资源可达性或父链完整性
published_resource	一个真实 URL 的 HTTP 状态、跳转、MIME、canonical、soft fallback 和可达性	整个文档家族的一致性
document_graph	父链、表示、外部 Profile、引用资源和跨文档一致性	购买、支付或修改商业状态的权限

报告还把语法、Schema、语义与在线检查分层记录。任一必需检查失败，总状态 就是 failed；没有失败但有必需检查未执行时，总状态是 incomplete，绝不 能写成 passed。

可跨工具交换的验证报告

报告是关于文档的证据，不进入 SKU-MD frontmatter。一份通过的根文档报告 可以是：

{
  "spec_version": "sku.md/0.9-draft",
  "validator": { "name": "sku-md-generator", "version": "0.2.0" },
  "target": {
    "url": "https://example.com/sku.md",
    "document_type": "catalog_manifest"
  },
  "scope": "offline_document",
  "status": "passed",
  "checked_at": "2026-08-01T00:00:00Z",
  "layers": {
    "syntax": "passed",
    "schema": "passed",
    "semantics": "passed",
    "online": "not_applicable"
  },
  "issues": []
}

稳定错误代码让不同工具可以处理相同问题，例如 YAML_DUPLICATE_KEY、 SCHEMA_VALIDATION_FAILED、CANONICAL_MISMATCH、 GTIN_CHECK_DIGIT_INVALID、KNOWLEDGE_DYNAMIC_STATE_FORBIDDEN 与 BODY_PARITY_INVALID。网络超时不能被转换为通过。

本站生成器目前只生成 offline_document 报告。上传之后，仍需检查 HTTP 状态、text/markdown、soft fallback、canonical、parent、表示入口与外部 Profile 引用。

Reference Consumer 的完整流程

Reference Consumer 是消费方行为合同，不是新的 wire format。它规定一条安全 顺序：

1. 发现商家托管的根文件，核对来源与表示；
2. 只沿声明的目录入口和分区遍历，不猜测隐藏商品；
3. 使用稳定标识、选项、市场、语言和 canonical Variant URL 精确选择变体；
4. 区分 Facts、Claims、Disclosures、Guidance、Limitations、Compatibility、 来源 URL 与核验日期；
5. 把 offer_snapshot 视为观察结果，通过 live_lookup 或 live_verification 查询当前价格、库存、配送、税费与总额；
6. 把购物车、结账、支付与订单交回声明的实时权威，并获得用户明确确认。

身份、证据、新鲜度或权威不足时，消费方必须 fail closed，不能用模型推断 填补缺口。

来源治理保留在工具层

发布工具需要管理一些不应暴露给消费方的状态。私有 Source Map 可以记录每个 值的来源，以及它属于 Detected、Derived 还是 Verified。随后通过 Audit–Plan–Apply，对比 HTML、Product JSON-LD、Merchant Feed、平台 Catalog 与现有 SKU-MD；准备可审核差异；最后在人工确认后发布。

Source Map、审核记录、草稿状态、发布 diff、问题日志与渠道指标都不进入公开 Schema。增量重建或在线校验失败时，交付系统应保留最后有效版本，不能用不完整 结果覆盖。

与平台协同，而不是复制平台

SKU-MD 负责稳定知识和明确来源边界。平台 Catalog 继续负责实时商品分发、价格 与库存；实时 API 或 UCP/MCP 负责动态查询；Checkout 负责买家认证、最终总额、 支付与订单创建。

截至 2026-08-01，Shopify 已公开 Shopify Catalog，以及符合 UCP 的 Catalog、 Cart、Checkout 与 Order 接口。但 Shopify 没有说明这些系统、ChatGPT 或其他 Shopify 渠道会读取或采信 SKU-MD。因此，集成指南使用外部指针和权威边界， 不会复制支付或订单状态。

用可测指标审视 SEO、GEO 与 AEO

有价值的问题不是静态文件是否“提升 AI 排名”，而是通过受控实验衡量：

• Variant 精确解析率；
• 是否引用有来源的 Fact，而不是营销文案；
• 披露与限制是否被正确召回；
• 时效敏感回答前是否执行实时回查；
• HTML、Product JSON-LD、Merchant Feed、平台 Catalog 与 SKU-MD 是否一致。

这些指标可以判断发布合同是否减少歧义与过期答案，但不能证明爬虫一定抓取， 也不保证平台一定排名、引用、推荐或带来转化。

实际迁移顺序

先更新版本标识并生成离线报告，人工审核后再发布；随后校验真实资源与完整文档 图。把动态商业数据留在 Knowledge 之外，在自动化失败时保留最后有效 revision， 并通过受控实验比较效果，不使用无证据的采用或排名主张。

延伸阅读

按照发布第一份 SKU.md应用当前交付合同。