Feed 增量更新 Playbook：小批、可回滚、按处理结果放大

直接判断：Feed 批量更新的完成标准不是“新文件已生成”，而是目标字段按预期变化、非目标字段未变化、GMC 已处理结果正确、页面仍一致，并且出现异常时能回到上一个可用版本。

先做判断

先给变更分级：

• 高风险：ID、链接、价格、库存、标识符、父子关系、目标目的地。
• 中风险：标题、产品类型、关键变体属性、主图、配送与促销覆盖。
• 低风险：内部标签、分析字段和不改变商品事实的注释。

风险取决于影响，不取决于编辑是否简单。一条“把空值设为某值”的短规则，可能覆盖整个目录；一批复杂标题改写如果只影响受控样本，反而更容易验证。

决策框架：七步增量更新

第一步锁定基线。保存当前最终 Feed、规则版本、商品计数、关键状态与代表性页面。第二步写变更契约：改什么、为何改、影响哪些商品、不应改变什么、失败如何回滚。

第三步生成 diff。至少比较记录新增、删除、ID 变化、字段变化和空值变化；不要只看文件总行数。第四步选择代表性小批，覆盖常规、促销、缺货、多变体、无标准标识符和边界品类，而不是只选最容易成功的商品。

第五步先在输出层验证。检查规则顺序、最终值和非目标字段。第六步提交后回读 GMC 已处理值、问题状态和平台展示，再走前台与结账路径。第七步只有在成功标准满足后才扩大下一批，并持续比较异常率与目录规模。

出现大比例删除、身份变化、价格库存异常或网站不一致时，应立即停止扩大，保留已知可用版本，先解释原因。平台是否提供数据保护、自动更新或暂停能力，以及具体入口，必须按当前官方资料确认，不能把历史功能当永久保险。

价格与库存时间问题可配合 不一致诊断；迁移类风险可参考 变体互相覆盖复合案例。

常见误判

• “Feed 工具预览通过，就等于 GMC 会按同样方式处理。”
• “只改标题，不可能影响别的字段。”规则顺序、连接键和模板变量可能产生连锁变化。
• “全部更新更快，出错再回滚。”重新处理、历史连续性和账户风险未必能即时恢复。
• “抽查随机几条就够了。”随机样本可能漏掉促销、空值与多变体边界。
• “没有新增报错就成功。”字段可能被错误覆盖但仍合法，需要语义与页面验证。

验证清单

• 保存变更前文件、规则、计数、状态与页面基线。
• 写清目标字段、目标商品、非目标字段和回滚条件。
• 生成新增、删除、ID 与字段级 diff。
• 代表性小批覆盖高风险商品形态与边界值。
• 在最终输出、GMC 已处理值、展示和页面四层回读。
• 观察至少一个完整生成、抓取和处理周期。
• 扩大后再次抽样，不把小批成功直接等同全量成功。
• 记录平台动态能力并在执行当日复核官方文档。

适用边界

本文适用于 Feed 规则修改、目录迁移、字段补全、促销切换和批量优化。它不替代生产系统的备份、权限与发布审批，也不建议用手工文件长期充当商品真源。极高频库存或动态定价可能需要 API 与更实时的监控；即使技术链路不同，“基线—diff—小批—处理回读—扩大—回滚”的控制原则仍适用。