商品召回数据怎么做成通知服务：从公告抓取到受影响批次匹配

商品召回数据已经公开，为什么消费者和商家仍会错过与自己有关的召回？因为公告回答的是“发生了什么”，而通知服务必须回答“这条公告是否对应我手里的这件商品，以及现在应该做什么”。两者之间隔着商品识别、批次匹配、证据分级、持续修订和可靠送达。

r/newproducts 的一则召回提醒产品介绍提出用照片保存已购商品、在相关召回出现时提醒。这个帖子只说明一种待验证的用户任务，不能证明识别准确率、即时性或付费需求。真正值得研究的，是“我拥有的商品”如何与监管机构发布的召回范围可靠连接。

难点不是抓到公告，而是判断是否命中

召回标题通常包含品牌、品类或产品系列，但真正决定是否受影响的条件可能藏在型号、生产日期、批次、序列号、UPC、包装规格、销售地区和销售时间里。只按商品名称做全文匹配，会把相似但不受影响的商品也推给用户；条件过严，又可能漏掉字段不完整的记录。

CPSC 的召回 API提供公开召回信息的 JSON 或 XML 机器可读访问，并支持按标题、描述和产品名称等条件查询。这为稳定采集提供了入口，但 API 可查询不代表每条记录都包含统一的商品标识。产品必须允许“字段不存在”和“只能人工确认”成为正常状态。

第一版不要承诺“拍照后自动判断一切”。更可行的承诺是：保存用户能够提供的标识，在新公告出现或旧公告修订后运行匹配；高置信命中立即提示，疑似命中要求用户查看型号或批次，无法判断时明确说明缺少什么。

不要把不同监管来源压成一个万能字段表

消费品、食品、药品、车辆和不同国家或地区的召回记录，来源与法律语境不同。openFDA 的食品 API 入口把 enforcement 等数据集分开，食品执法报告查询示例则展示了日期范围和分类过滤。它们能支持食品执法报告检索，但不应被改写成“所有商品召回的统一实时 API”。

内部数据层可以使用共同外壳，同时保留来源原貌。共同字段用于检索和交付，来源字段用于复核：

• 统一标识、来源机构、来源记录 ID、公告日期与最后核对时间。
• 产品名称、品牌、型号、代码、批次、销售地区和销售时间；缺失值必须保留为空。
• 风险描述、处置方式、消费者联系渠道与原始公告链接。
• 当前状态、上一个版本、字段变化以及采集失败状态。
• 原始记录或可追溯快照，避免标准化过程抹去关键限定词。

共同外壳不是强迫不同来源拥有相同精度。某条记录只有自然语言描述，就应继续标为自然语言；不能为了让数据库整齐而推导一个并不存在的 SKU。

匹配结果至少要分成确认、疑似和无证据

召回通知系统需要一条可解释的匹配阶梯。最强证据通常是精确标识组合，例如 UPC 与批次同时命中，或型号与序列号区间同时命中。其次可能是型号和销售时间命中，但缺少批次。只有品牌与模糊名称相似时，应当是待确认线索，而不是“你的商品已被召回”。

可以把匹配输出设计为三类：

1. 确认命中：记录中的关键标识与用户登记信息一致，仍附原始公告供核对。
2. 疑似命中：部分条件一致，但缺少批次、日期或地区信息；通知直接告诉用户去哪里找缺失标识。
3. 未能判断：来源没有足够结构化字段，或照片识别结果不稳定；保留观察但不下结论。

“未命中”也不能等于“安全”。它只表示在已覆盖来源、当前数据和现有标识下没有找到匹配证据。这个措辞看起来保守，却直接决定用户是否会错误地停止进一步检查。

图片识别适合帮用户抄录标签，不适合成为最终裁决。OCR 可以给出候选型号和条码，再让用户确认；低质量照片、包装换版和相似字符都可能产生错误。产品应保存用户确认过的字段，而不是每次都从旧照片重新猜。

召回记录会修订，通知也要有版本

CPSC 召回页面明确提示 remedy 信息可能变化。处置方式、企业联系状态或适用范围更新后，旧通知不应继续作为唯一答案。因此，采集层要区分首次发现、内容修订和来源暂时不可用，而不是每天把同一公告当成新召回。

适合召回记录的事件键通常由来源机构与来源记录 ID 组成。每次核对保存内容摘要与重要字段差异：范围扩大需要重新匹配全部相关商品；只修改排版不必打扰用户；处置方式改变则应向此前收到通知的人发送更正。通知本身也要记录基于哪个版本生成。

如果来源页面短暂失败，界面应显示“本次未完成核对”，不能显示“没有新召回”。站内的API 错误与自愈指南解释了为什么超时、限流、权限与上游错误需要分开处理；用于召回场景时，覆盖中断尤其不能伪装成安全状态。

用户要的是下一步，而不是一段摘要

有效通知应把最重要的动作放在前面：停止使用、查看批次、联系商家、申请退款、维修或等待进一步信息。动作必须来自当前官方公告，不要让模型自行补充处置建议。对高风险场景，摘要后应直接提供原始来源和官方联系入口。

通知节奏也要区分严重程度和匹配置信度。确认命中的高风险记录可以立即发送；低置信疑似命中更适合进入待确认队列，并在用户补充标识后更新。日报适合一般观察，却不应为了减少消息而延迟明确相关的安全通知。

商家版产品还需要内部任务：停售相关商品、定位库存、查找订单、联系受影响客户、记录处置结果。采集只触发任务，不能替代商家对订单、仓库和客户身份的权限控制。将结果接入工作流时，可以参考站内的统一数据 API 设计指南，把原始证据、标准化字段和业务动作分层。

商品清单本身是敏感资产

家庭拥有的商品可能透露健康、婴幼儿、住所和消费习惯；商家的库存与订单则属于经营数据。召回通知产品不应因为“安全用途”就默认无限保存图片、收据和完整订单。

第一版可以让用户只保存完成匹配所需的最小字段，并允许随时删除。若要从邮箱、订单或零售账户自动导入，应另行取得明确授权，展示访问范围，并让用户知道同步停止后哪些数据仍被保留。照片完成识别后是否继续保存，也应由清晰的产品规则决定。

对商家，召回来源数据、内部 SKU 映射和客户联系信息应分层授权。负责核对召回的人不一定需要看到完整客户资料；负责通知的人也不应能修改来源证据。审计记录至少说明谁确认了匹配、使用了哪个公告版本、向哪些对象触发了什么动作。

MVP 应验证匹配闭环，而不是累计公告数

一个可控试点可以只覆盖一种监管来源、一个商品类别和一小批自愿登记的商品。先人工复核所有候选，再观察系统在哪些字段上失败。此时，收录了多少年历史公告远不如是否能准确解释一条相关通知重要。

建议记录四类指标：可匹配记录比例、疑似命中需要补充的字段、确认命中的送达与查看、从通知到完成处置的状态。误报和漏报要分别复盘，来源字段缺失、商品登记错误与匹配规则错误也要分开。只有这样，后续自动化才知道应该改数据、交互还是规则。

本文讨论的是一种数据产品设计方法，不代表 EveryInfra 已发布召回通知服务。真正的商品召回通知产品，不是把公告抓得更多，而是让“官方记录—具体商品—明确动作—后续更正”形成可核对的闭环。只有当系统敢于表达不确定性，提醒才可能长期被信任。