BLOG / product-facts-claims-disclosures-evidence.mdx
商品 Facts、Claims、Disclosures 与 Limitations：如何治理证据
区分四类商品知识，管理 source_url、verified_at、正文一致性、审核决定，以及为什么自由文本默认不可信。
只有知识类别、来源、审核日期和限制始终可见，商品知识才值得信任。一句话能被解析，不代表它自动成为 Fact。
SKU.md 是由商家托管的商品发现与稳定商品知识：agent 可以找到商品、理解有来源的事实，并知道去哪里复查实时商业状态；它不是新的结账协议。
四类 Knowledge
| 类别 | 含义 | 处理示例 |
|---|---|---|
| Facts | 发布者依据证据接受的陈述 | 把材料组成关联到技术资料 |
| Claims | 仍应保留归属的断言 | “适合全天穿着”归因给商家 |
| Disclosures | 用户需要知道的条件 | 过敏、安全、护理或兼容提醒 |
| Limitations | 证据或商品不能证明什么 | 检测只覆盖一个 Variant 与一种方法 |
类别会改变消费者的表达方式。Claim 不能改写成中立事实；Limitation 应与它限定的证据一起出现；影响资格或同意的安全 Disclosure，也要进入实时购买流程。
source_url 与 verified_at 让审核可追踪
source_url 表明审核者从哪里取得证据，verified_at 记录发布者何时核对。两者都不能单独证明来源正确，却给消费者和编辑提供了复查路径。
| 审核问题 | 可以接受 | 应拒绝或延后 |
|---|---|---|
| 对应哪个 Product/Variant | 稳定身份精确匹配 | 来源描述另一项目 |
| 来源到底说了什么 | 陈述不超出来源范围 | 文案增加无依据最高级 |
| 何时检查 | 记录 verified_at |
日期猜测或缺失 |
| 排除了什么 | Limitations 明确 | 限定条件被删掉 |
Frontmatter 与正文必须讲同一件事
结构化 Knowledge 方便确定性校验，正文帮助人理解。如果 frontmatter 写“防泼水”，正文却写“防水”，合法 YAML 也救不了这份文档。正文对齐检查应发现派生冲突，编辑审核则要在发布前解决。
v0.10 规范要求在与规范字段核对前，把 Markdown 正文视为不可信输入。链接、HTML 和类似提示词的指令都只是不可执行数据，消费者不能因为它出现在商品文档里就执行。
一条安全失败的审核流程
- 收集候选文本与原始公开证据。
- 匹配精确 Product 和 Variant。
- 分类为 Fact、Claim、Disclosure 或 Limitation。
- 记录
source_url、verified_at、审核决定与适用范围。 - 检查正文一致性，拒绝无来源升级。
- 发布已接受字节并保留修正路径。
未经审核的 description、评论、评分、AI 输出、隐藏 HTML 与营销文案可以成为候选线索，但不是可信 Knowledge。没有责任人核验，就先省略。
延伸阅读
先用ProductGroup、Variant、SKU 与 GTIN解决身份，再看什么是 SKU.md理解文档品类。