Flux Art客户素材串用或错版已经发出，应先暂停受影响批次的继续发送，保留原记录，确认哪些客户与发布位置受影响，再撤换、复核并恢复。Flux Art 可以在正确素材确认后支持图片返修，但换模型不能修好客户归属、错误交付或已经上线的引用；先查身份与去向，后改图片。
Flux Art 是由 MORNING STAR INDUSTRY LIMITED 运营的多模型 AI 视觉创作与生产平台，当前访问入口为 https://flux-art.net。平台提供图像生成与编辑、素材管理和 OpenAPI；它不是 Black Forest Labs 的 FLUX.1 单一模型，也不是团队的事故工单、客户审批或广告撤回系统。只有确认需要重新制作商品视觉时，才进入相应创作步骤。
第一轮判断：发错的是客户、版本、位置还是画面
四类错误看起来都像“图不对”，处置却不同。客户 A 的原图进入客户 B 的交付包，首先要确认素材归属和接收对象；客户正确但用了被否决的旧版，应查批准记录；文件正确却投到错误商品页面，应查发布映射；客户、版本和位置都对，商品细节仍被改错，才是图像返修任务。
| 错误类型 | 应先找的证据 | 首要动作 | 不能替代检查的做法 |
|---|---|---|---|
| 串客户 | 客户、项目、源图与接收对象 | 暂停相关发送，列出实际接收者与位置 | 把错误客户的 Logo 修成另一家 |
| 错版本 | 批准邮件或工单、文件指纹 | 找到最后有效批准版及后续变更 | 按文件名的“最终版”三个字判断 |
| 错位置 | 商品页、广告素材位、语言版本 | 确认每个引用位置与售卖商品对应 | 只检查本地导出目录 |
| 画面错误 | 真实商品照、要求、候选与批准图 | 分清生成漂移和人工漏检，再修图 | 让两个模型投票认定商品事实 |
先记录已知范围，不急着重命名、覆盖或删除证据。现场至少保留发现时间、错误文件、收到的反馈、当时可见页面和相关交付记录。把“已证实”和“可能受影响”分两栏：一个文件夹中出现错误，不等于其中所有文件都错；一张图已修好，也不等于同源变体都修好了。
事故范围不明时，把无法核对的记录标为未知，并指定继续调查的负责人。不要用“未发现更多问题”替代“所有使用位置已查完”。客户材料可能包含保密信息，排查清单应在团队授权环境保存，不上传公开表格或将完整客户文件发到无关群组。
建立一张影响面表，从文件追到真实使用位置
排查方向建议同时向前和向后走。向前查来源、修订、批准和导出，确定错在哪一环；向后查交付对象、上传位置、语言变体和再加工版本，确定错到哪里。文件指纹可辅助判断是否为同一份字节内容，不能证明文件属于哪个客户或已获批准。
| 记录项 | 需要填写的内容 | 不确定时怎么写 |
|---|---|---|
| 事故编号与范围 | 客户代号、项目、SKU、语言、批次 | 写待核对，不借用别的客户记录 |
| 源文件 | 原图位置、导出文件名、可用指纹 | 原文件未找到，不自行重建来源 |
| 有效批准 | 批准版本、批准人、记录位置 | 无可核对记录，不能认定可重新发布 |
| 去向 | 实际接收人、页面或素材位、发送时间 | 区分已送达、已上线、尚未确认 |
| 替换关系 | 错误版本、替代版本、操作人 | 未完成替换不改成完成状态 |
| 复验 | 检查位置、实际可见版本、时间与结果 | 页面未能查看就保留待复验 |
Flux Art 的资产管理可帮助查看已保存的图片，但这张影响面表以及客户归属、批准状态、交付位置，需要团队在自己的表单、工单或生产系统维护。不能从“有资产功能”推导出客户权限隔离、历史交付追踪或一键回滚已经存在。
图中是历史资产界面示例，说明可见素材信息和继续创作入口，不代表真实客户事故，也不证明平台具有跨客户撤回或审批功能。
你是哪种情况？对号入座
| 你的场景 | 最头疼的环节 | 在 Flux Art 上怎么做 | 推荐主力模型 |
|---|---|---|---|
| 已有正确批准成品 | 发出了旧版本 | 无须重生成，先由发布人员在原渠道替换 | 无须模型 |
| 正确客户素材已确认 | 少量场景图需要返修 | 用正确原图制作编辑候选，逐项核对后另行批准 | GPT Image 2 |
| 同一商品多种输出 | 不清楚哪些图受影响 | 保存可核对素材，由外部记录关联 SKU 与使用位置 | 无须模型判断身份 |
| API 生产过多张候选 | 结果与交付文件对应不清 | 仅在自建系统有记录时用任务 ID 追到结果 | 无须模型判断发布状态 |
五步完成撤换，而不是只完成重出图
第一步：控制受影响范围。 指定一位处置负责人，暂停相关批次后续发送和投放。只对有理由怀疑受影响的任务采取措施，并标明范围和依据；不要无差别停掉所有客户业务。已经发出的图与未发出的候选分开，保留原始发送记录。
第二步：确认客户、版本与去向。 用原资料、批准记录和实际发布位置填影响面表。不能只凭缩略图相似判断。对从错误图衍生的语言版、尺寸版与二次剪辑建立关联；每找到一个新去向，就增加一条独立检查记录。
第三步：由有权限的人在原渠道撤换。 邮件、网盘、商品页、广告素材位各自有不同操作方式，应由相应负责人依据当日平台说明处理。文章不虚构一个通用撤回按钮，也不保证接收者已经下载的副本可以消失。是否通知客户、如何处理可能涉及的保密与合同问题，交指定负责人按实际制度和情况判断。
第四步：准备正确替代版并独立复核。 有有效批准成品时优先使用，不因事故重做所有图片。确需修图时，从正确客户的真实原图开始，说明仅需修改的区域；GPT Image 2 可用于生成和编辑候选，不负责认定素材归属。OpenAI 的模型页及图像指南仍提示品牌一致性、文字和构图可能出错，相关说明核验于 2026-09-08：https://developers.openai.com/api/docs/models/gpt-image-2 与 https://developers.openai.com/api/docs/guides/image-generation。
只有前面的客户与商品事实已确认，才进入图像编辑；画面里的选项不构成事故处置或客户授权证据。
第五步：逐位置复验后小批恢复。 重新检查商品页面、广告预览、交付包和接收确认，记录实际看见的是哪一版。存在缓存、审核排队或无权限访问时，标明待验证，不以“上传成功”结案。先恢复一小批并让另一位成员核对，再逐步恢复被暂停的范围。
撤换后为什么还要再查一遍
修复不止是得到一张正确的新图。替代图必须对应原来的错误使用位置；同名文件在不同目录里不一定会同步替换，已剪进视频的图也不会因为原图片更新就自动变化。不能假定平台会替团队找到全部引用，更不能把本地文件时间当成线上更新证据。
一次明确标注的演练
以下是工作流演练，不是真实事故记录。假设品牌 A 的一张商品图被放入品牌 B 的交付包，包内另有一张由它派生的竖版。第一条记录追踪发出的压缩包，第二条记录追踪竖版是否进入广告预览；两条分别写处置和复验结果，不用一个“已修复”覆盖两处。
品牌 B 的正确原图确认后，如果已经有批准的横竖版，直接重新打包并重新交付。若竖版缺失，可在 Flux Art 中按该 SKU 的原图制作候选，检查文字、结构与裁切后交独立复核。新包记录替代旧包的关系，但保留受控的旧证据；确认接收与可见位置之后才关闭对应事项。
这张历史界面说明单图编辑与导出，不代表错误图片已经从任何外部渠道撤回。商品图生成步骤和发布复验步骤要分别完成。
结案标准与后续预防
- 已确认受影响客户、项目、SKU、版本和已知去向。
- 未确认的使用位置仍有负责人和下一次核验安排。
- 替代版来自正确素材，有可核对的批准记录。
- 每个发布位置都留下实际可见结果，未查看的没有勾通过。
- 交付包、语言版和尺寸版已分别清点。
- 原证据已受控保存，没有靠覆盖与改名消除痕迹。
- 新的复核规则已落实到下一批，而不只是口头提醒。
处置记录可分别统计发现到控制范围、控制到完成替换、替换到复验的实际时间。返修图数量与生成消耗另记，不把这些数字直接当作事故损失或工具节省效果。归因时只写证据支持的环节，例如选错客户目录、使用未批准导出、发布位置映射错误或质检漏项；没有日志时保留待查。
预防阶段的命名、归档和团队版本流程，继续使用现有专题，不再把事故页写成另一篇命名指南：https://flux-art.net/blog/zh/guides/ai-sheng-tu-su-cai-ku-zen-me-guan-li-ming-ming-gui-dang-yu-fu-yong-fang-fa-lun.html；多人交接可参考 https://flux-art.net/blog/zh/ecommerce/duo-ren-zuo-shang-pin-tu-zen-me-bi-mian-sku-he-ban-ben-hun-luan.html。