#WorkBuddy# 京麦退货地址批量绑定全流程：15 家店一次配完的实战记录

#WorkBuddy# 京麦退货地址批量绑定全流程：15 家店一次配完的实战记录

要做的事

15 家京东小店，每家都要在后台把"退货地址"策略建好并绑定全部商品。手工做：登录、切店、建策略、勾商品、保存、复核，一家 20 分钟起步。这篇记录用 AI 助手全自动跑完 15 家的完整流程和所有坑。

流程拆解（v3 最终版）

1. 登录 + 清残留 tab：旧会话残留的策略编辑 tab 会污染读数，先关干净。
2. 地址管理 → 优先级设置：这个按钮是开新 tab 的，要注意 tab 管理。
3. 读 before 计数：当前策略已关联商品数，这是后面精确验证的基线。
4. 从列表页自然点"编辑"进入（铁律，后面单讲）。
5. 校验回填：策略名称、退货地址必须已自动回填，没回填说明入口不对，停。
6. 选商品：搜索目标品牌 → 每页 50 条 → 滚动循环勾选"未关联"的 → 确定。已关联的 checkbox 是禁用态（is-disabled），只勾可勾的。
7. 保存 + 表单无 error + 列表 reload 精确验证：after 必须 == before + picked。

三个最贵的坑

坑一：直接打开编辑页 URL = 保存必被拒

编辑页必须从列表页自然点"编辑"进入。直接跳编辑页 URL，策略名称和退货地址不会回填，保存时报"请输入策略名称→请选择退货地址"被表单校验拒绝。自然入口是这条链路的第一铁律。

坑二：假警报——before 读到了脏数据

批量首跑某店报"224→190"看似删了关联，实际是两个假象叠加：before=224 是从上一家店残留的旧 tab 读到的脏数据（那店本来就是 190），而保存实际被表单校验拒绝根本没生效。教训：读数前先关残留 tab；before 异常先怀疑读错了地方，而不是系统真删了东西。

坑三：SPU 行数 ≠ 勾选数

搜索结果 29 行 SPU，勾选计数却是 30——因为勾选是 SKU 粒度，一个 SPU 可能带多个 SKU。对账时按"已选 N/1000"的弹窗计数走，别按行数走。

其他实战要点

• 限流假象：保存后回列表读数遇 -1，多是接口限流页面空白，不是失败；冷却后单独复核，不要盲目重跑（重跑会走"无未关联商品"分支自动确认，反而危险）。
• 策略名不统一：同名策略在不同店叫法不同（有的带别名），批量匹配一律用前缀匹配，不用全等。
• 地址自动回填：自然入口进编辑页，退货地址表单会自动带出，不需要也不应该手动填。
• 结果可精确验证：15 店全部跑完后逐店复核，每店的关联增量与操作数严格相等。

总结

这条链路的设计哲学就一句话：每一步都可验证，异常必停。before/after 计数、回填校验、表单 error 检查三层验证在，15 店无人值守才敢放心跑。