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 变更记录与本地验收记录：准备和检查依据，不替代线上发布验证。