商品图批量排版 前，先确认素材是否齐全。假设团队已经有一份 manifest.csv ，每行记录一个 SKU 与应有图片文件名。即使后续使用批量图像工具，缺图、重名和多余文件也应尽量在入口处发现；否则成图后再找错，成本会更高。
商品图批量排版前，先确认素材是否齐全。假设团队已经有一份 manifest.csv，每行记录一个 SKU 与应有图片文件名。即使后续使用批量图像工具，缺图、重名和多余文件也应尽量在入口处发现；否则成图后再找错，成本会更高。
这个脚本还有一个边界：它只比较文件名集合。mug-white-front.jpg 即使装的是黑色杯子的照片，也会被判为“存在”。如果要在团队里使用，可以在清单里增加视角、颜色和审核状态，由人工逐行确认；自动检查先处理机器擅长的缺图与多图，再把有内容判断的部分留给人。
最小清单与核对脚本
清单包含两列 sku,filename，例如 MUG-WHITE,mug-white-front.jpg。把原片放在 originals 目录，脚本只比较文件名，不会解析图片内容，也不会判断照片是不是该 SKU。csv.DictReader 的行为可查阅 Python 官方文档。
import csv
from pathlib import Path
folder = Path("originals")
with Path("manifest.csv").open(encoding="utf-8-sig", newline="") as handle:
rows = list(csv.DictReader(handle))
expected = {row["filename"] for row in rows if row["filename"]}
actual = {path.name for path in folder.iterdir() if path.is_file()}
print("缺图:", *sorted(expected - actual), sep="\n")
print("清单外文件:", *sorted(actual - expected), sep="\n") 示例的 manifest.csv 可以看作一个简单约定：每行一张预期图片，列名固定。真实项目里还可加入 view、color 或 review_status，但不要在脚本还没写校验逻辑时，就把这些字段当作已被检查。特别是同一个文件名被两个 SKU 引用的情况，集合运算会把重复折叠掉，需要额外统计每个文件名的出现次数才能发现。
目录结构也会影响判断。若原片按 SKU 放在不同子目录，脚本当前只检查 originals 顶层文件，不会自动发现子目录里的图。改成递归遍历后，清单里要记录相对路径，不能只留最后一个文件名；否则两个 SKU 的 front.jpg 仍会撞名。文件系统检查的范围必须和团队的存储约定一致，不能把工具没看到的内容误判为不存在。
核对结果最好输出成可复查的报告，而不是看一眼终端就关掉。记录处理批次、清单版本和缺失项，补图后再运行一次，才能知道问题是否真的关闭。即使机器显示“缺图零项”，仍要抽查高相似度商品。脚本能证明某个名字的文件存在，不能证明文件里的杯子颜色、容量和 SKU 相符。
可以把这段程序放在批量处理前的自动检查里，但失败时应让流程停下来并提示负责人，而不是只把错误打印在无人看的控制台里。尤其是缺图名单，需要有人判断是补拍、撤掉该 SKU，还是清单写错。机器发现不一致，人来决定如何修复；这个分工比一句“全自动上新”更可靠。
运行前确认目录存在、CSV 列名一致。若不同 SKU 使用了同名文件，这个集合写法不会识别重复映射，生产流程还应检查 filename 在清单中是否唯一。核对通过后再做背景、画布和导出处理；最后仍要人工确认颜色、视角、配件和商品对应关系。自动化擅长查漏，不擅长替你判断杯子是不是另一种容量。
参考资料