做定制商品图稿时，一张最终图片通常同时承担了太多信息：买家传了什么照片、这笔订单选了什么内容、商品用哪套版式、团队是否已经确认可以进入生产。
当它只是一张文件时，任何一处需要修改都会把人带回聊天记录、文件夹和表格里重新找答案。
这里从 XERP 面向 Amazon Custom 定制订单的处理方式，讨论一个更工程化的问题：原始内容、商品设计方案和生成结果为什么应该是三类不同的对象。 这是项目方的技术工作流分享，不是客户案例或性能测评。
图 1：账户分别授权、订单集中处理。公开门户说明和独立演示，不包含客户订单。
订单内容回答“这一次发生了什么”
买家照片、名字、尺寸和款式都属于订单事实。卖家账户可以分别授权后统一查看，但订单仍需保留账户、站点和商品归属。
这层的失败方式也很明确：照片缺失、选项不完整或授权不可用。它们不是“图片生成失败”，也不该靠模型猜补。先把输入问题定位在输入层，后续处理才有依据。
图 2：同一款商品的不同规格可以有不同画布和布局要求。
方案回答“应该怎样制作”
设计方案保存画布、照片位置、文字区域、底图和装饰。订单只是把本次内容带进已确认的商品要求。
这一区分让草稿、当前发布和历史版本各自有意义：保存一个调整，不应该悄悄改变正在处理订单的制作合同。多规格也应分别验证，而不是把一张输出图简单拉伸。
图 3：照片可按需要处理，排版仍由商品方案决定。
照片处理改变材料，不应重写整个商品
主体提取、修复和补全只处理选定照片。结果回到对应位置，名字、底图和固定装饰仍按方案组合。原图合适时，直接使用原图；处理异常时，保留原图并要求核对。
这样，模型输出和版式几何可以分别检查。一次 API 调用成功，并不等于人物没有被裁掉、长名字没有溢出，或规格没有匹配错。
图 4：局部修改、按方案完整重建和人工替换有不同范围。
修改方式必须暴露范围和确认含义
局部修改适合一个照片位置的问题；完整重建适合相关处理要求变化；人工修好的 PNG 可以上传替换。
三者不是同义按钮。尤其人工替换在确认后会标记通过，上传前必须检查尺寸、透明区域和内容。模型改完后则应回到审图，而不是把任务提交状态当作业务确认。
图 5：生产资料、面单和包裹按批次处理。
结果回答“现在可以交给谁做什么”
生成图关联订单和生产编号，调整说明与遗漏项随生产资料交接。面单、包裹和实际交运是不同阶段；文件已生成，不等于已经发货。
这类边界对系统设计很朴素，但对团队协作很重要：下一位处理人不应从最终图片反推整个历史。
图 6：从订单接入、方案执行、确认到生产交接的流程概览。
用小范围验证，而不是先承诺“全自动”
适合先选择一款版式稳定的商品，试验长短文本、横竖照片和不同规格。每一类输入都检查三件事：内容是否对应、方案是否正确执行、异常是否能留在工作流内处理。
自动化的价值不是隐藏确认，而是让重复动作有稳定执行路径，让关键结果仍能由人确认。
