Flux ArtFlux Art 中的 GPT Image 2.5 任务已显示生成成功，自己的商品系统却没有图片，应先检查结果读取、文件保存和业务回写，不要直接重新生成。根据原任务找到可用产物，只恢复失败的一段，避免把保存故障变成第二次创作任务。
Flux Art 的 GPT Image 2.5 专题为 https://flux-art.net/zh/models/gpt-image-2-5。本文面向准备接入或已经完成相应能力确认的开发团队：网页可用不等于每个账户 OpenAPI 都已开放，必须先以当前账户 GET /models 确认实际模型 ID 和参数。不将 OpenAI 原厂 ID 当作 Flux Art ID，也不宣称本文执行过付费生成或恢复演练。
先把“成功”拆成三份证据
第一份是平台任务记录，回答任务状态与输出是什么；第二份是自有存储记录，回答文件是否真的保存完整；第三份是业务关联记录，回答它应交给哪个 SKU、哪个素材位。接口的 succeeded 不会替你的数据库完成后两件事，更不能直接代表商品图审核通过。
Flux Art 提供统一工作台、图像生成与编辑、素材管理和 OpenAPI，运营主体为 MORNING STAR INDUSTRY LIMITED，当前访问入口 https://flux-art.net。下面的检查点、保存状态、冲突处理和业务回写由接入方自行实现，不是平台提供了这些内置按钮。生成质量不合格与下载失败也要分开，不能用同一个“失败”覆盖所有情况。
第一步：从准确的任务记录开始，不从空白图片框开始
读取自己已经保存的任务 ID，通过 https://open-api.flux-art.net/openapi/v1 下的 GET /tasks/{task_id} 获取当前结果。核对创建和查询所用账户一致、任务对应同一业务需求，并保留查询时间。页面空白只能证明当前界面未展示，不证明原任务失败；浏览器刷新问题也不应触发新的创建请求。
若记录仍是 queued 或 processing，继续按既有查询规则处理，不能使用本文的“成功后恢复”分支。只有确认 succeeded 才进入产物检查。若没有任务 ID，也不要从图片文件名猜一个，更不要把相似时间的另一任务当成自己的；先按请求记录与原幂等信息找回关联，无法确认时暂停自动回写。
图为原 Word 中保存的 Flux Art OpenAPI 介绍历史截图，说明平台提供服务端接入入口，模型与参数需查当前目录。它不证明本次账户已经生成成功，也不证明存在自动恢复、自动回写或无限期结果保留功能。
第二步：定位最后一个有证据完成的检查点
在接入方的记录里增加检查点即可，不必改变平台任务状态。下面名称是本文建议的内部标签，不是新增 API 枚举；平台仍使用其公开的任务状态。
| 内部检查点 | 达成证据 | 没有证据时的处理 |
|---|---|---|
| 平台结果已确认 | 正确任务的成功状态及实际输出记录 | 查任务，不凭页面提示创建替代任务 |
| 文件已保存 | 自有位置有完整可解码文件和指纹 | 恢复结果读取或保存，不重新生成 |
| 业务关联已确认 | SKU、素材位、需求版本与文件对应 | 修复关联，隔离身份不明的产物 |
| 审核已通过 | 原图核对与明确批准记录 | 进入待审，不写成已发布 |
查询响应已到达，但程序在写入数据库前退出，是一种典型断点。恢复时可以再次查询原任务，按本次真实返回读取结果；不能猜测地址规律，也不假设平台一定提供“刷新下载链接”端点。若实际输出缺失、链接已不可用或查询失败，保存错误及 request_id 交由支持核查，不承诺重新查询必然恢复已失效文件。
第三步：下载失败只修下载，不碰生成请求
先核对下载请求的最终响应与实际内容。收到 HTML 错误页、空文件或半个文件时，不要因为本地已经存在一个 jpg 文件名就标成保存完成。下载程序应设置适当的大小、时间和跳转边界，仅处理获授权的结果地址；不要将 Flux Art API Key 转发给图片地址或其他跳转主机。
可以先写到受控临时位置，完整读取、解码并核对后再移入选定的素材位置，同时记录指纹。不要在下载开始时覆盖当前已批准主图。中途断网留下的部分文件单列失败，不能被下一轮当作完整成品复用。具体存储操作由团队环境实现，本文不假设某家存储服务一定提供相同的原子提交接口。
如果原任务仍可读取，恢复同一结果的下载与保存即可，不再调用 POST /images/generations。只有需要新的画面，或已确认原产物无法恢复且业务批准重新制作时，才进入新的生成决策；新任务不是对原任务“免费下载一次”的保证，费用以实际账户规则与记录为准。
第四步：文件已经落地，业务系统却没记住怎么办
另一种断点发生在文件保存后、关联写入前。先用原任务 ID、素材来源记录和已有文件指纹确认它属于本次产物，再补关联；不能因为数据库为空就再下载或重生成。相同文件名不等于同一内容，字节指纹相同也不证明它属于正确 SKU，需要任务与需求的明确映射。
建议将“业务需求编号、需求版本、平台任务 ID、输出项位置”组合为内部关联身份，并让重复执行能识别已经完成的相同关联。若一个任务实际返回多个输出，按真实返回逐项记录，不预设数量。数据库发现同一身份指向不同文件时应转入冲突复核，不自动挑最新文件覆盖；这些是客户端设计建议，不是 Flux Art 额外字段。
异步返回顺序可能不同于提交顺序，因此不能把第一个完成的结果塞回输入表第一行。每个结果按自己的任务关联找到对应商品。旧版本晚到时，保留它的记录，但不得压过已经确认的新版本。显示状态也应区分“已有生成结果、待保存、待关联、待审核”，让运营知道缺的是哪一段。
第五步：多 SKU 批次只恢复失败片段
下面是故障演算，不是客户实测。一批商品出现不同断点时，先把正常项留在原处，再按证据分派恢复任务，而不是点一次“整批重跑”。
| 某条记录的实际情况 | 本次要恢复的动作 | 不该做的动作 |
|---|---|---|
| 成功输出存在，下载中断 | 重读并保存原产物，检查完整性 | 新建图像任务 |
| 文件完整，业务关联丢失 | 确认身份后补关联记录 | 用相似文件名猜 SKU |
| 已关联，但审核未完成 | 送入原图与要求核对 | 将待审标为可上架 |
| 任务还在处理 | 按原任务查询策略继续跟进 | 因同批其他项完成就重建 |
| 已批准文件仍完整且对应正确 | 保留原记录和素材位 | 陪着失败项重新生成或覆盖 |
恢复单至少写明业务编号、原任务 ID、最后通过检查点、本次允许动作、实际结果位置和复验结论。技术负责人确认文件与关联，运营确认商品事实与使用位置。恢复后再次检查本批尚未结清的项目；进度分别统计任务成功、完整文件、正确关联和审核通过数，不把多个状态混成一个“完成率”。
一个可在自有测试环境执行的验收办法，是分别在取得成功响应后、保存完整文件后暂停自己的处理程序，再从记录恢复。使用已有获授权的测试结果即可验证本地后处理，不必为每次演练重新生成。验收要看到：恢复没有发出新的生成请求、没有重复业务关联、没有覆盖批准文件、无法确认身份的项目确实停下。这里提供测试方法，不宣称已经测出节省费用或恢复成功率。
首次接入与幂等规则可看 https://flux-art.net/blog/zh/guides/gpt-image-2-5-openapi-shou-ci-jie-ru-cong-mo-xing-mu-lu-dao-yi-bu-tu-pian-jie.html；ERP 全流程边界见 https://flux-art.net/blog/zh/tutorials/zen-me-ba-ai-chu-tu-jie-jin-zi-jia-erp-huo-ding-dan-xi-tong.html。本篇只补生成成功之后的下载、入库和关联断点，不替代接口错误码教程，也不替代交付前按应交素材位查漏的流程。
来源核验：2026-09-10 查阅 OpenAI 发布说明 https://openai.com/index/introducing-chatgpt-images-2-5/，仅用于模型家族生成编辑定位；不把原厂响应结构套成 Flux Art 结构。Flux Art 接口、任务状态与产品事实依据当前官网 https://flux-art.net 及账户控制台文档。本文未执行生成、付费或故障恢复实测，不承诺结果链接的固定保存期限。