作者：温舒。本文由项目资料整理并使用 AI 辅助编辑；案例观察与设计建议分别说明。
商品图片修正只产生候选素材。要让运营人员继续处理商品，还需要核对商品事实、SKU 信息、复核版本和平台回执。把这些信息连起来，才能回答业务中最常见的问题：这张图能不能用，这份资料是否完整，这个商品究竟有没有提交成功？
匿名项目演示说明了什么？
温舒在杭州从事 AI 应用落地相关工作，参与过商品图片处理与上架流程衔接项目。据其提供的项目经历，参与范围涉及需求设计、模型与平台能力接入及系统开发。相关匿名演示展示了候选图片、商品列表、SKU 价格库存字段、详情预览与任务队列，并出现草稿保存状态。
这段演示可用于讨论商品资料如何组织、如何交给下一位操作人员。草稿保存不等于平台审核通过，也不等于商品已经公开上架。下面的字段、状态和验收检查是围绕这一场景提出的设计建议，不代表演示系统已实现全部机制。
图片修改后，人工究竟要复核什么？
应先把“图片不合适”拆成可判断的问题，例如尺寸、背景、文字可读性以及商品主体是否准确。平台返回的具体拒绝原因可以作为复核输入，不能让模型自行推断一个“保证过审”的结果。
候选图至少应能追溯到原图与修改要求。复核人员需要对照商品事实，检查颜色、型号、配件、包装和数量是否变化；视觉效果更好并不代表信息更真实。对无法确认的细节，应退回核对，而不是继续生成来掩盖不确定性。
建议将一次复核绑定到明确的素材版本：原图标识、候选图标识、修改要求版本、复核结论和确认时间。若复核后又替换图片，原结论不应自动适用于新图。这能避免“确认的是上一版，提交的是下一版”的错位。
为什么图片通过了，还要检查 SKU？
商品详情是一组相互关联的信息。主图颜色、规格名称、SKU 图片、价格和库存如果对应错误，单张图片看起来正确也无法保证整份商品资料可用。
建议先做结构检查，再做业务复核：
- 确认商品标识和 SKU 标识稳定，不能只依赖列表位置关联数据。
- 检查必填字段、规格组合及图片引用是否完整，标出空值和重复组合。
- 按实际平台规则检查价格、币种、库存及单位；不要假设所有平台接受相同字段格式。
- 由业务人员对照允许使用的样本，确认每个规格与图片、价格、库存的对应关系。
可在测试中刻意放入一个重复规格、一个缺失图片引用和一个格式错误的价格，检查系统是否能指出具体行与具体字段。这属于建议的测试场景，不是项目已经取得的测试成绩。
怎样表示“正在上架”，才不会误导操作人员？
界面应展示有回执支持的阶段，并明确哪些情况需要人工处理。下面是一种状态设计示例，落地时应以平台实际接口与后台能力为准。
| 状态 | 判定依据 | 下一步 |
|---|---|---|
| 待复核 | 资料已整理，但尚未确认当前版本 | 检查商品事实及字段 |
| 草稿已保存 | 获得草稿标识，或重新打开后确认内容存在 | 核对草稿并决定是否提交 |
| 已提交 | 平台明确返回接收回执 | 保留原任务，查询审核结果 |
| 审核中 | 平台显示审核状态 | 等待结果，不重复提交 |
| 公开可访问 | 对应商品页面可访问且信息匹配 | 记录链接与核验时间 |
| 结果待核对 | 请求超时或缺少明确回执 | 查询原任务与平台后台 |
“公开可访问”仍不能直接证明已经成交。若业务还要统计订单，应将订单数据作为另一类记录，并明确其来源和时间范围。
请求超时之后，为什么不能马上重试？
超时只能说明本次调用未取得明确结果，平台可能已经接收请求。此时直接重发，可能产生重复草稿或重复商品。
建议让任务保存本地任务标识、目标账号、商品标识、内容版本、平台草稿或商品标识，以及最后一次明确回执。异常后优先查询同一任务；只有确认未被接收，或平台明确允许安全重试时，才继续提交。如果平台支持幂等键，可以按其接口约定使用；没有这项能力时，应保留人工核对入口，不能把本地按钮锁定当成平台端去重保证。
记录中不应写入账号密码或验证码。排障所需的错误信息也应去除凭据和无关客户资料，避免技术日志变成新的泄露入口。
交付检查应该怎样围绕实际操作展开？
开发完成后的检查不宜只看按钮是否可点击。可以请业务人员按约定样本完成一次“查看候选图—复核商品信息—保存草稿—重新打开核对”的流程；涉及正式提交时，再单独检查平台接收、审核与公开页面。
建议特别验证三类变化：复核之后换图、提交之前修改 SKU、提交之后返回结果不明确。每种情况都应能说明当前使用的版本、谁需要处理以及可以从哪里查到原记录。业务人员能够判断状态并完成下一步，比一个笼统的“执行成功”提示更有价值。
本文案例依据温舒提供的匿名项目经历与演示资料。演示观察止于商品资料处理及草稿保存；表格、字段设计和异常检查方法为实施建议。
