一份好的 SKU.md 应该告诉 AI 什么？
v1.0.0 专题
用一份商品知识剖面说明事实、建议、限制、兼容性、标识符和来源应该如何协同，而不把 Markdown 变成 Feed。
当前状态： 本文依据当前 v1.0.0-beta 边界撰写，只陈述方法和证据要求，不把尚未验证的平台采用、排名、引用、推荐或销售结果写成事实。
一份好的 SKU.md 不是缩短后的商品页，而是围绕 Agent 必须做出的决策组织的商品知识记录。审核它时，可以选一件具体商品，逐段检查每类信息究竟如何影响推荐。
示例：一款小型旅行充电器
假设商店销售一款 65 W 双口充电器，并提供多个插头变体。商品页可以承载照片、上市文案、评论和购买按钮；知识文档则要明确稳定的决策事实：输出规格、随附插头、支持设备、不适用情况、型号标识符和来源。
文档必须说明正在讨论的具体变体。如果插头和电压条件随市场变化，“全球可用”就不是一个足够精确的事实。
Facts 描述产品是什么
Facts 应当具体且可以观察，例如端口类型、最大总输出、尺寸、重量、材料和包装组件。每条事实都要有消费者可以检查的来源。除非明确标注为有出处的宣传主张，否则不要把“旗舰”“最佳”等形容词当成事实。
Facts 也不是易变商业字段的收纳区。当前价格和库存仍属于实时权威。
Guidance 解释适用方式
Guidance 把事实转成有条件的使用建议，同时避免替用户做未经证实的假设。对充电器而言，可以说明哪些设备组合处于功率预算内，或在什么情况下一个适配器可以替代两个。所有建议都应能够回到产品能力。
好的 Guidance 会帮助 Agent 提出更好的问题。如果同时充电会改变功率分配，这个条件必须写入说明。
Limitations 与 Compatibility 防止高成本错配
Limitations 说明哪些情况不应推荐，例如不支持的高功率笔记本、潮湿环境或需要其他插头模块的地区。Compatibility 则列出必须匹配的接口、版本、附件、尺寸或环境条件。
这两节对决策的影响通常大于普通卖点。一个不兼容条件就足以否决看起来很吸引人的推荐。
Identifiers 连接记录，但不静默合并
SKU、MPN、GTIN 和变体标签的作用域不同。文档应把每个标识符绑定到它真正识别的产品或变体。商品页、Feed 和 JSON-LD 不一致时，应保留冲突供审核，而不是悄悄选择最方便的值。
标识符让系统可以关联记录，却不能自动证明所有记录完全等价。
Sources 让陈述可以检查
来源链接应靠近它支持的陈述。一个主页很难支持技术兼容性结论，应优先使用包含相关信息的商品页、说明书、支持文档或正式政策。
文档还要记录更新时间。消费者既要保留知识资源地址，也要保留底层陈述来源。
商品知识剖析表
| 部分 | 回答的问题 | 要避免的失败 |
|---|---|---|
| Facts | 产品是什么？ | 把营销语言当事实 |
| Guidance | 何时适用？ | 无条件给建议 |
| Limitations | 何时应排除？ | 用卖点覆盖否决条件 |
| Compatibility | 哪些条件必须匹配？ | 假设接口或版本 |
| Identifiers | 究竟是哪条记录或变体？ | 合并产品与变体标识 |
| Sources | 为什么可以相信？ | 没有出处的摘要 |
发布前测试
把文档交给一位没有看过商品页的审核者，请其识别产品、选择合适用例、拒绝一个不兼容场景，并追溯每条决定性陈述。任何需要猜测的答案都说明文档仍有缺口。
拆开一份真正有用的商品知识
以一只带两种杯盖的不锈钢水瓶为例。Facts 可以写容量、材质、尺寸和保温测试条件；Guidance 可以说明吸管盖适合直立的日常使用；Limitations 应说明倒置时吸管盖不防漏、产品不适合碳酸饮料；Compatibility 可以写杯架直径和可替换杯盖；Identifiers 则区分商品组和具体颜色、杯盖组合。每条决定性信息都应回到公开来源。
这些类别能阻止宣传语承担过多职责。“适合所有冒险”不是可验证事实；“适配直径至少 76 毫米的杯架”是兼容阈值；“安装吸管盖时不要装热饮”是限制。Agent 可以按不同规则处理它们，前提是商家先明确了每句话的用途。
说法强度不能超过证据
如果测试只覆盖某个型号、颜色或配置，结论不能默默扩展到所有变体；来源只写“防泼水”，文档就不能升级成“防水”；尺寸若不含可拆卸把手，也应说明测量条件。Source 证明信息从哪里来，准确措辞决定是否忠实于证据。
未知就应保持未知。与其从照片或相邻商品推断，不如暂时省略；若缺失事实会频繁影响推荐，可以进入内容补全队列。消费者也必须把缺失当成缺失，不能当成肯定或否定值。
用真实购买问题做编辑审核
字段齐全不代表内容有用。审核时应提问：谁适合、谁不适合、与什么兼容、指的是哪个变体、结论由哪个来源支持？当问题转向当前库存、价格、配送、税费或支付时，文档能否明确触发实时交接？
对每个重要变体边界都运行问题，并让第二位审核者从答案追溯到原句和来源。目标不是堆最多文字，而是维护最小、可靠的事实集合，使正确匹配、明确拒答和实时交接都能发生。
追求有边界的完整，而不是复制整个数据库
把 PIM 的每个字段全部复制进来，会淹没真正影响推荐的内容。应从决策出发：身份、用途、不兼容、变体选择、证据和实时交接。只有能帮助这些决策且有长期维护来源的事实才加入；内部物流字段和重复营销文案应排除。
这样，文档对编辑和消费者都更轻，diff 也能展示真实说法变化，而不是数千个再生成属性。完整不是镜像整个数据库，而是足以支持声明的使用场景，并明确未知项。