Flare 还是 Sunburst：GPT Image 2.5 双模型的默认规则与误配自查

这一页讲决策那一侧：先把默认定下来

多数团队不会为「用哪个模型」专门开一次会。做图的人打开生成器，按上一次的做法选一个，就往下走了。默认值往往就是这样长出来的——不是被决定的，是被沿用的。

这一页处理的正是这一段：既然没有人会为一次选型专门跑一轮对照，那就把默认本身写清楚——按什么定、什么时候该改、一批活里怎么排。

怎么自己验证两个变体的差异是另一件事。可复现的对照方法与判定标准在 Flare vs Sunburst 详细对比；单次出图的操作顺序见 GPT Image 2.5 怎么用。这一页假设你已经接受「两边各有各的活」，只处理怎么把这个判断固定下来。

默认只看一件事：这一步要交出什么

不用比参数，也不用比印象。只要问一句：这一步的产出，是还要往下改的，还是要直接交出去的。

还要往下改，数量的价值就高于精度；直接交出去，这一版就是终点，一致性的价值高于数量。两种产出对应两个方向，本页给它们两个短称：

• 速度侧：出得更快，适合把可能性铺开。
• 控制侧：单次更慢，适合把一版做到位。

这不是强弱之分，是「这一步要什么」之分。两个短称的完整来历与逐项差异，留在专门的一页里讲。

这条判据的好处是当场就能问出来——不必等跑完一轮，也不必先看结果好不好，看一眼这一步的交付物属性，默认就定了。

费用不进这条判据：两边的费率结构是同一套，走哪一侧都不改变单价怎么算。费率与档位的细节见 GPT Image 2.5 价格详解；接口这一侧，一次调用由哪几段拼出来，见 GPT-Image-2.5 API 计费详解。

三类活各自落到哪一边

落到具体动作上，日常要做的活大致分三类。每一类都能从「这一步要交出什么」直接推出来：

这一步在做的事	走哪一侧	判断信号
方向稿	速度侧	你自己也说不准要哪一版，需要先看到几种可能
成稿	控制侧	这一版要给别人看、要被复用，或者要出成多个尺寸
对稿件	控制侧	画面已经定了，只剩某几处要改

三类里最容易被做错的是方向稿。这一步的目的是把选择范围缩小，判断它做得好不好，不看单张有多好看，看的是手里有没有出现「可以往下走的那一版」。更容易看见这一版，正是速度侧的用处。

成稿的判断也不难：一旦到了会被别人看到的环节，返工的成本开始高于等待的成本，慢一点反而更接近最终要交出的那份东西。

对稿件则要压住手：改一处、看一处，一轮只放一个改动。改动的写法见 精准编辑完全指南；多轮之后画面还在往边上跑时，多轮编辑不崩的 8 条规则 里有一份顺序建议。

误配的两种表现：一种慢在半路，一种卡在末尾

默认被用反的时候，问题不会以「选错了」的形式出现，而是以两种很具体的形态出现。

第一种，把控制侧当成方向稿用。 你在探索阶段，需要看五六种可能，却每一步都走了慢的那一边。结果是每出一版都要等，不知不觉就开始减少尝试——本来该铺开十个方向，最后只跑了三个。问题不在于慢，在于慢改变了你的做法：你会更早锁定第一个看起来过得去的方案，而不是继续找更好的那个。这一类的代价，是那些始终没有出现的可能性。

第二种，把速度侧当成成稿用。 你在交付阶段，却每一步都走快的那一边。每次都能出图，看起来也顺利，但每改一轮，画面里动的都比你要改的多。到第五六轮，画面已经不是你最初想交付的那一版。这一类的代价，是白跑的轮次。

两种形态有一个共同点：代价都不落在单价上，而落在次数上。 一次调用花费多少由内容与档位决定，与走哪一侧无关；真正被拉开的是几次才拿到能用的那一版。哪些需求本身就不该走这条路，见 GPT Image 2.5 局限清单；这一代模型的能力范围整体描述，从 GPT Image 2.5 是什么 看起。

一批活怎么排：顺序、切换点与不进流水线的那类

单张的默认定了之后，一批活只需要再定三件事。

顺序。 先跑方向稿，再跑成稿。反过来做没有意义——方向没定，成稿就没有可以对照的标准。

切换点。 换到控制侧的那一刻，应当是「方向被确认」的时候，而不是「图看起来差不多了」的时候。判据很简单：你能不能一句话说清这一版好在哪。说得清，方向就已经定了；说不清，说明还在探索，留在速度侧继续。更稳的做法是在说清之后再切，而不是边切边找。

不进流水线的那类。 有两类活不适合放进批量：一类是画面里要出现成段文字或精确字形的物料，另一类是必须逐张人工确认品牌要素的物料。这两类不是模型做不到，而是它们本身就需要人工参与，混进批量里会把整个批次的节奏拖住。这一代模型能做什么、做不到什么，GPT Image 2.5 完整指南 里有整体划分。

切换时最容易漏掉的一件事：把上一版的结果带过去，而不是用一段文字重新把它描述一遍。文字能说清「我要什么」，说不清「现在到哪一版了」；只给文字，模型就得从画面之外重新推一遍。

把默认写下来：三条要写进组内约定的内容

默认之所以叫默认，是因为它不必每次重新讨论。但「不必讨论」不等于「不用写」——不写下来，它就会退化成每个人凭印象选，同一步在不同人手里走成两条路。

要写的只有三条：

1. 默认项：哪一类活走哪一侧。用上一节那张表就够，不必附理由。
2. 例外：什么情况下可以不走默认，由谁来判断。例外写得越少越好，但必须写——不写例外，等于默认随时可以被推翻，也就等于没有默认。
3. 交接物：切换时手上要交出什么。这一条最容易被跳过，也最容易造成返工。

这三条不需要写成长文档。一张表，加一句例外说明，已经足够让新人按同一套判断走。GPT Image 2.5 提示词库 里那批可以直接复制的模板，用的是同一种思路：把一次判断的结果固定下来，后面就不必重新判断。

收尾：把判断收成三条约定

默认项、例外与交接物写下来的那一刻，选型这件事基本就结束了。它从一道每次都要重新回答的题，变成一条可以照着走的规则。

回头看，这一页处理的其实是一个时间分配问题：把需要判断的部分集中到一次，把不需要判断的重复交给规则。规则的好处不在于更准确，而在于更稳——同一步在不同人、不同时间做，走出来的路径是一样的。

三条约定之外还剩一件事：两个变体本身差在哪。这一页只用了「速度侧」「控制侧」两个短称，完整的来历与差异留给专门的一页，上面已经指过路。

想继续看别的内容，教程都收在 教程索引 里；模型本身的常见疑问，另有 GPT Image 2.5 常见问题 按主题分好组。

常见问题

不做对照实验，直接定默认会不会选错？+

会，但这类错的代价可逆：两边共用同一套接口，改的只是模型名，前面出过的图还能接着当输入用。真正不容易撤的是把一次临时的做法写成流程，所以这一页才建议把默认写成约定，同时把例外也一并写清楚。

默认一定先走速度侧吗？+

看在做的活的性质。要铺开方向、要一次看到好几种可能时先走速度侧；手上已经是一张定稿、只需要动某一处时，直接进控制侧更省事。

一批活只用一个侧可以吗？+

可以，只要这批活的性质单一。整批都是方向稿，就整批走速度侧；整批都套同一个模板的成稿，就整批走控制侧。只有性质混在一起时才需要排顺序。

切换时最容易漏掉的是什么？+

漏掉上一版的图。用一段文字重新描述「我要的那一版」，模型就得从画面之外把这个版本再推一遍；把上一版的结果直接带过去，偏移会小得多。

误配的代价体现在哪里？+

不体现在单次花费上，体现在次数上。方向没铺开就提前收窄，或者交付阶段反复微调，都是把时间花在本可以避免的轮次里。

这条规则多久复核一次？+

任务形态变了就复核。同一批活连续几轮都在推翻默认，说明要改的是默认本身，而不是这一次需要例外。