让 AI 读懂你的商品：SKU.md v1.0.0 如何为 Agent 购物做好准备
v1.0.0 专题
用旅行杯示例理解商品发现、事实审核与条件比较，了解 SKU.md 如何帮助独立站商家为 Agent 购物准备商品信息。
当用户把购物需求交给 AI，他可能不会先指定品牌，而是描述一个用途：“找一只容量至少 300 毫升、能保温的蓝色旅行杯。”对商家来说，机会不只取决于商品有没有展示出来，也取决于系统能否判断它是否适合这个人。
SKU.md v1.0.0 帮助商家把这类判断所需的知识整理成可发现、可追溯、可比较的内容。它让商家有机会减少商品被误解或因信息不足而无法判断的情况，不能保证外部 Agent 一定读取、引用或推荐商品。
同一只杯子，为什么可能得到“信息不足”
以下是虚构示例，不是真实店铺、用户测试或曝光实验。某旅行杯页面写着“容量 350 毫升”，并提供蓝色款，但没有明确蓝色款是否保温。
如果容量只记录在商品整体范围内，系统不能直接把它当作蓝色变体的已知属性。蓝色款保温信息缺失，也不能被解释成“不保温”。这两处不确定都会影响针对蓝色款的条件判断。
| 购买条件 | 起初掌握的信息 | 下一步 |
|---|---|---|
| 蓝色变体至少 300 毫升 | 只有商品整体的 350 毫升说明 | 查证该规格是否适用于蓝色款，并记录变体范围与来源 |
| 蓝色款可以保温 | 未知 | 寻找明确说明；没有证据就保留未知 |
| 现在有货、周五前送达 | 静态知识不能确认 | 回到店铺实时系统核实 |
这个区别很重要：信息不足提示需要补充证据；明确不符合则提示该商品不适合这个条件。把两者混为一谈，会误导商家和消费者。
可发现：给愿意读取知识的消费者一个入口
商家可以在网站发布根目录 /sku.md，把目录与可选商品知识文档连接起来。消费者因此获得明确的访问起点，不必猜测哪些链接承载商品事实。当前规范也定义了根路径返回精确 404 后才能考虑的首页声明式备用入口。
发布入口是商家可控制的工作，消费者是否实现并访问它则由对方决定。网站原有商品页面、搜索优化和渠道 Feed 仍需维护。文件通过验证，不意味着搜索引擎已收录，也不意味着 AI 平台已接入。
可理解：让每条事实带上身份、范围和证据
旅行杯的容量、颜色、保温性能应该对应到具体商品或变体。测量条件、限制和来源也应一并保留。例如，存在特定测试条件的性能数据不能被改写成无条件承诺。
规范允许记录证据摘录和审核状态。审核时需要确认原文确实支持这项属性，而不仅是确认网址可访问。未得到支持的卖点应保持待审核或未知，不应为了让表格完整而补写。
这些知识帮助消费者看清商品的适用范围，也让商家更容易追查“这条说法从哪里来”。
可比较：观察事实变化，而不是追求一个 AI 分数
在示例中，商家查证蓝色款确实为 350 毫升后，可以为这个变体补上有证据的容量记录。容量条件由信息不足变为符合；只要保温仍然未知，整体仍不能判定符合两个条件。
如果后续证据明确支持保温，且审核完成，两个静态条件才可能同时满足；如果明确不保温，则应被排除。容量只要单位兼容，也可以按升与毫升转换比较。
这是同一组条件下可复现的规则判断，不是模型对商品的喜爱程度，也不是平台展示位置。增加一条准确的限制让商品不再入选，有时恰恰说明知识变好了。
在现有工具中走一遍
- 打开商品优化工具，先用内置示例熟悉流程，再按界面支持的方式载入自己的商品资料。
- 查看缺失、冲突和证据问题，确定哪些属性值得补充。
- 回到公开来源核对摘录、商品范围和测量条件，明确确认后再接受修改。
- 在比较工作台使用相同条件对照修改前后，分别观察符合、不符合与信息不足。
- 导出审核后的 Markdown，或需要人工审核的渠道结构化数据建议，再检查导出内容。
渠道建议不会替你发布到商店或广告系统，也不保证获得搜索展示资格。价格和库存等商业字段仍应由原有系统维护。工作草稿可下载保存，不应把当前浏览器里的编辑状态当作已经上线。
用一个商品建立自己的基线
先记录这个商品有哪些条件能回答、哪些缺证据，以及文件是否能被公开访问。补充事实后，用相同输入再检查一次，保留前后结果。
如果将来开展真实 Agent 测试，应记录所用产品与版本、提问、是否访问文件及引用了哪些来源。把访问、引用、到站和购买分开观察，才能判断变化发生在哪一步，不能把本地条件比较当成曝光增长数据。