GPT Image 2.5 核心概念：可控性、可复现性与验收 在 Arcloop 使用 GPT Image 系列开展创作时，我们把每次交付组织为“参考、指令、输出、验收”四部分。围绕 GPT Image 2.5 的质量评估，也应保留同样的任务结构，让好结果有明确的复用起点。
一张图通过审核后，团队经常只保存成品。下一次需要换标题、换场景或换产品颜色时，却找不到原来的参考和指令。我们把“保存图片”扩展为“保存一次任务”：图像负责呈现结果，参考与 Prompt 负责说明如何开始，验收记录负责说明为什么通过。
这篇手册把前七篇的练习变成一个小型验收包：角色、编辑、产品、文字、草图、序列帧和透明素材各出一道题。在 Arcloop 画布中保留候选图，逐项记录通过与失败，才能判断哪些步骤可以稳定重复。
用固定任务比较，不用印象比较
选择三项最接近你的业务的任务，而不是一次测遍所有风格。短剧团队先测角色保持与分镜，电商团队先测产品结构与编辑，内容团队先测文字与多比例构图。
可以把每项任务初始运行三次作为小样本检查。这个数量只是帮助发现重复问题，不足以得出模型普遍优劣的统计结论。保留所有输出，并记录哪一张进入交付，避免只保存最好的一张。
固定任务的价值在于让两次测试只改变一个变量。比较模型时保持参考图、Prompt、比例和质量档位一致；比较 Prompt 时保持模型与参考图一致。若同时更换模型、参考和构图，就无法判断改进来自哪里。每次测试给候选图编号，并把失败原因写成可以观察的描述，例如“杯盖比例改变”或“标题多了一个字”，不要只写“感觉不对”。
正式评审前先确定必须通过项和可接受偏差。产品主图通常把轮廓、标识和颜色列为硬条件；气氛海报可以允许背景细节变化，但人物身份与标题必须稳定。硬条件有一项失败就退回，软条件则用于候选图排序。这样能避免团队在看到漂亮画面后临时降低标准。
| 测试题 | 保持项 | 通过条件 |
|---|---|---|
| 人物换场景 | 脸型、发型、服装 | 同一身份可辨认，服装结构无明显漂移 |
| 商品改色 | 轮廓、标识、位置 | 仅指定颜色变化，没有重画商品 |
| 两行中文封面 | 字符、层级 | 逐字正确，小图下仍能阅读 |
| 草图构图 | 位置、前后关系 | 主体与留白按草图组织 |
| 透明单体 | 结构、边缘 | 实际透明，边缘在多种底色上可用 |
建议给每道题保存以下记录：输入文件校验值、完整 Prompt、模型与可见参数、开始时间、输出文件名、通过状态和评审备注。多人协作时，再加上操作人与评审人。记录不需要复杂系统，一张固定字段的表格就能让后续对比有据可查。
先确认选择了什么模型
“图片文件变大了”“感觉更锐利了”“某个测试能出透明图”都不是可靠的模型身份证明。记录实际界面显示的模型名称、选择日期与可见参数；如果界面没有提供精确版本，就写“界面未标明”，不要补写推测。
Arcloop 的当前公开入口仍使用 GPT Image 2 名称，具体可选模型以登录后的界面为准。评估 GPT Image 2.5 时，也沿用相同的记录方式；让模型版本与素材文件一起归档，后续复用时才有可核对的依据。
OpenAI 发布页把 Flare 定位于更快的常规生成，把 Sunburst 用于更精细的创意编辑。这是供应方定位；实际选择应回到你自己的图片验收结果，不预设相同费用、相同等待时间或相同成功率。
如果同一模型名称在不同日期产生明显差异，先核对输入文件、自动压缩、比例、质量和随机性设置，再把日期作为一个可能变量记录下来。不要覆盖上一轮结果；保留并排对照，才能判断这是偶发失败、输入变化还是稳定趋势。
Prompt 档案保存“任务结构”
收藏一段很长的 prompt，却忘了它配的是哪张参考图，复用价值会大幅降低。建议每次交付同时记录用途、参考文件、可变项、保持项和验收条件。
任务名：旅行水杯 / 书桌场景 / 第一版
参考：product-master-v1.png
界面模型：按本次实际选择填写
目标：生成一张书桌使用场景图
保持项：杯体比例、盖子、把手、涂层与标识位置
变化项：背景、环境光、陪衬物件
输出：比例与尺寸按实际文件填写
验收：商品完整；标识无误；不被遮挡；光影方向合理
结果：通过 / 需要修复 / 放弃，并写明原因
这是给团队的归档模板，可存在文档或表格里。Arcloop 用来组织图像和素材；本文不假设系统会自动生成全部字段。保存文件时，保留参考与输出的对应关系，比文件名里不断追加“最终”更有价值。
归档时把字段分成“固定项”和“可变项”。固定项是商品比例、角色身份、品牌色、标题文字等不能漂移的内容；可变项是背景、动作、时间和陪衬物。下一次复用时只替换可变项，并在 Prompt 中再次列出固定项。若新任务连固定项也要改变，应复制为一条新任务，而不是覆盖已经通过的母版。
一张图的验收顺序
- 先看任务是否完成：主体、场景和动作是否符合目标。
- 再看保持项：参考对象的身份、比例、标识和关键结构是否漂移。
- 逐字检查文字：标题、数字、标点和大小写都要单独核对。
- 放大检查结构：手指、把手、边缘、反射与遮挡是否合理。
- 缩小检查阅读：在卡片或信息流实际尺寸下是否仍能识别。
- 检查交付文件：比例、像素、色彩模式、透明通道和命名是否正确。
评审顺序固定后，任何一项失败都能对应下一步动作。不要在已经明确失败的图上继续争论审美，也不要因为风格漂亮就跳过文字和文件格式检查。
出现失败时，修改最小的一块
如果主体正确而文案错误，只修文字；如果主体身份错误，回到角色母版；如果构图错误，重新给布局参考；如果透明背景失效，走背景处理与文件格式检查。让下一步对应失败原因，避免每次都改完整段 prompt。
本轮只修复参考图中的一个问题：标题第二行出现多余字符。
第二行必须仅为“第三集”，不增加空格、英文、标点或其他字。
保留人物、背景、主标题、构图、色彩和标题区的整体位置。
如果无法在保持人物的前提下完成，请优先输出没有第二行文字的版本。
这条指令表达的是优先级，不保证模型会按要求选择分支。生成后仍须检查人物与主标题，不能把“文字改对”当作整张图通过。
如果一次修复同时引入新问题，把它作为新的失败版本保存，并回到上一张已知稳定的图。连续在失败结果上继续编辑，容易累积身份、比例和色彩漂移。每轮只改一个问题，并为版本写明“从哪张图开始、改了什么、结果如何”。
常见失败可以直接映射到处理路径：
| 失败类型 | 回到哪里 | 下一步 |
|---|---|---|
| 人物身份漂移 | 角色母版 | 重申脸型、发型、服装等保持项 |
| 商品结构改变 | 产品标准图 | 锁定轮廓、把手、盖子和标识位置 |
| 文案错误 | 最近一张结构正确的图 | 只修指定文字，保留其他内容 |
| 构图偏离 | 布局草图 | 明确主体框、标题区和留白 |
| 边缘或透明失败 | 未去背的清晰单体 | 重新处理背景并做多底色检查 |
把七篇练习组织成团队自己的任务库
这套 Handbook 以角色“林遥”、NOMA 旅行水杯、短剧《雨夜侦探》与咖啡店分镜为练习对象。团队可以把它们替换为自己的角色、商品与故事，同时保留每篇的任务结构：输入什么参考，允许改变什么，最后检查什么。
每种业务先确认一个通过的版本，再为它保留一份可修改模板。例如换季上新只更新商品配色和场景，短剧新一集只更新地点与动作。发生失败时，在任务旁记录原因和下一次修改项。这样积累的是与团队实际业务对应的制作方法，成员交接时也能从同一组条件开始。
任务库需要定期复测，但不必每次全部重跑。模型入口、关键参数或业务标准发生变化时，选择三到五条高频任务回归：一条身份保持、一条产品编辑、一条文字、一条构图和一条透明素材。若核心条件仍通过，再逐步扩大；若失败集中在同一环节，就先更新对应 Prompt 或验收规则。
最后得到一份真正能继续用的素材包
把通过图、失败图、参考图和指令记录放在一起。通过图进入素材库，失败图用于下一轮判断，参考图留作重建起点。下次需要同样的封面或商品场景时，修改可变字段即可开始，而不必重新摸索整套条件。
最终目录至少包含 references、outputs-pass、outputs-fail 和 prompts 四类内容，并附一份清单连接任务编号与文件名。删除失败图会失去边界信息；保留失败原因能告诉后来者哪些写法、参考或参数已经验证过不可用。
交付前由未参与生成的人抽查一轮更有效。操作者容易记住 Prompt 的预期内容，从而忽略画面实际多出的字或变形结构。评审人只看任务目标、保持项和候选图，独立完成检查，再与操作者记录合并。
你可以从角色参考图或电商系列图选择一个具体任务，在 Arcloop 图片入口建立自己的第一组对照。先获得一条能复用的流程，再逐步增加场景。
