案例 实测
让 64,000 件商品的线上目录保持准确
我们重构了一个约 64,000 件商品的线上目录的更新方式。供应商的价表、资料表和库存表现在走同一条流程——解析、匹配、诊断、人工批准、带回滚的批量写入、回读。生产中，386 条改价写入后逐条核对全部正确，556 条库存更新全部正确，范围外 0 件被误改。
问题
供应商更新价表和商品资料时格式五花八门，状态栏互相矛盾，图片链接大面积失效。一次全站体检发现：
812
件在售商品图片是坏的
3,948
件在售商品没有价格
7,793
件有货商品被隐藏、没在卖
24
个品牌页点进去是空的
几千件商品手工改不过来；没有退路的批量修改又不安全。
重构后的流程
- 供应商价表、资料表和库存表
- 线上目录只读快照
- 解析并清洗供应商文件
- 判断哪些该上架
- 对上现有商品
- 改价诊断
- 人工批准
- 带回滚的批量写入
- 回读对账
- 例外清单和供应商资料索取表
结果 实测
- 约 64,000 件商品、56 个品牌完成全量体检
- 单个品牌上线：5,887 个 SKU 的供应商价表对上 7,073 件现有商品；5,204 件商品上架
- 改价写入后核对：386 条全部正确，范围外 0 件被误改
- 库存写入后核对：556 条全部正确
- 3,378 个供应商图片链接逐一实测；上传 2,838 张，核验通过 2,829 张（99.68%）
- 前台品牌页从 55 个整理到 12 个
- 所有能写生产库的脚本都必须由人明确放行——34 个里 34 个
- 同一套流程之后已在更多品牌上复用
这个项目包含什么
上面的更新流程由十三项能力组成，每一项都在线上商品目录上实际跑过。
| 能力 | 做什么 | 已验证规模 |
|---|---|---|
| 线上目录只读快照 | 不碰生产环境，把线上目录拉成本地基线 | 5 张关联表一次备份 |
| 供应商表格解析 | 读懂格式混乱的供应商表格：重复的分页表头、被存成数字的日期、#N/A、互相矛盾的状态栏 | 5,887 个 SKU 的价表 |
| 售卖范围判定 | 根据价表、库存表和网站现状判断该卖什么，并核对每个型号都有着落 | 898 个型号，全部对上 |
| 型号精确匹配 | 把供应商 SKU 对上网站商品，不把变体之间真实的差异“清洗”掉 | 5,887 个 SKU 对 7,073 件商品 |
| 改价诊断 | 写入之前先判断：这次是小幅调整，还是整体换价 | 3,286 件可比商品 |
| 可撤回的批量写入 | 每次改动都附带执行脚本、回滚脚本和逐件变更记录；默认只预览 | 单次 2,000 行以上 |
| 写入后回读核对 | 重新读取目录，证明写进去的等于算出来的 | 改价 386 / 386，库存 556 / 556 |
| 图片流程 | 每个链接都用真实请求测试，失败分成七类，图片统一规格，上传后逐张核验 | 实测 3,378 个链接；上传 2,829 / 2,838 |
| 分类推断 | 根据已有商品的规律给新品定分类；拿不准的交给人 | 一个品牌全量分类 |
| 全站体检 | 把全站问题分类统计：坏图、缺价、有货却隐藏、空品牌页 | 约 64,000 件商品 |
| 供应商资料索取 | 把“为什么不能上架”整理成可直接发给供应商的英文索取表 | 两个品牌分别 327 件、102 件 |
| 前台整理 | 合并重复品牌、撤下空品牌页、批量调整上下架状态 | 品牌页 55 → 12 |
| 平台改造 | 部署网站功能修改，附回滚点、分步检查和上线后冒烟测试 | 完成一次版本升级 |
已设计、尚未搭建：自动找出两版供应商价表之间的差异；定时运行整条流程，自动核对、出错自动回滚。
哪些决定始终由人来做
有六个决定永远不自动化：
- 用哪一档价格
- 卖哪些商品品类
- 自动推断失败时的分类指定
- 每一次写入的放行
- 型号冲突时留哪一件
- 任何不可逆的操作
背后的三条规矩
- 实测，不猜。图片能不能用，看真实请求的结果，不看文件名。
- 每次写入都附带回滚，并且先预览。
- 下架，不删除。删除会断掉链接和订单历史，而且无法撤回。
核心原则 系统把每个选项和后果都算清楚，决定由老板来做。
哪项工作最花时间？
说说团队现在怎么做，用哪些软件和文件。我们一起看看，哪些地方可以通过工具或调整做法来改善。
聊聊你的项目