一张图更像我们想要的样子，为什么评分反而下降了？这篇文章从几张真实生成图说起，记录 ProductFlow 最近的一段调整。
下面三张图，来自同一款空气炸锅的三次生成实验。
左边是原版。标题、引导线、底栏都在努力解释商品：看得见进度、少翻面、热风循环、容量、内腔和配件，几乎能说的都说了。中间是第一轮调整后的结果，我们希望它只讲一个购买理由，于是画面围绕热风循环和底盘结构展开。右边是继续收窄后的复验，主文案回到一个能直接看见的特点：通过窗口观察烹饪进度。
从左到右：原版、首轮内容策略候选、收窄后复验。均为 2026 年 9 月 7 日保留的真实生成结果，每个版本生成一次。只做等比缩放和拼版，未修图或统一原图比例。打开大图查看文字与细节。图中文字也是被检查的生成内容，不代表本文认可其中的商品功效。
如果只谈表达方式，这几张图之间的变化很容易理解。但当时多模态评审给出的商品保真分依次是 5、4、4，四项均分则是 5.0、4.0、4.5。
中间那张更接近“一张图讲一个理由”的策略，评分却下降了。最后那张通过了当时的比较规则，商品保真仍然没有回到原版。
这段经历很适合用来讲 ProductFlow 最近为什么调整生图链路。我们确实改了提示词，也开始区分主体合成、排版和生成的职责，还换了任务队列。但这些改动没有共同组成一条整齐的上升曲线。有些解决了明确的问题，有些还缺使用证据，也有一项听起来合理的改动，最后被撤了回来。
把一套图组织起来以后，问题开始落到每张图里
之前写画布设计时，讨论得最多的是如何组织一套商品素材。商品资料和参考图提供依据，创作要求和系列风格约束方向，画面方案交给人编辑，具体图位保存自己的差异和结果。
这些安排解决了很实际的操作问题。想改第二张卖点图，就不必推翻整套方案；主图已经满意，可以留下来继续试场景图；换一个商品，也能复用部分制作方法。
但流程变得清楚以后，图片里的问题会更显眼。
我们在早期结果里见过“卖点1／卖点2”直接进入成片，也见过几个不同图位反复展示相似的摆拍。主图、场景图和细节图虽然分开了，买家从它们身上得到的信息却没有增加多少。
顺着生成输入往回找，还发现了一个具体冲突：一处要求单张卖点图包含三到五条利益，另一处要求一页只讲一个购买理由。两种要求最终都进了模型。此时再叮嘱它“简洁一点”，其实没有替它解决该听谁的问题。
第一轮修改因此很朴素：统一这些要求，让卖点有一个主要理由，让场景包含真实的使用关系，让细节回到参考中可见的材质与结构。我们没有为此增加一套新的节点体系。
代码和提示词改完了，接下来要看它究竟把图片带向了哪里。
完整看完八个图位，结论就没那么漂亮了
这轮对照选了空气炸锅和家纺两款商品，每款分别生成主图、卖点、场景和细节图。原版与候选共用审核后的商品文字输入、参考图和运行配置，每个图位各生成一次。
下面放出全部八组工作台结果。两张长图都按主图、卖点、场景、细节排列，左边是原版，右边是候选。它们保留各自的构图和比例，没有为了让比较显得整齐而重新裁切。
空气炸锅：从上到下为主图、卖点、场景、细节；左原版，右候选。打开大图。
家纺：同样保留四个图位，左原版，右候选。打开大图。
有些变化确实值得继续。空气炸锅的细节图把注意力更多放在窗口和把手附近，家纺的细节图也有了更清楚的材质表达。另一些变化就很难概括成进步：场景可能更简单，也可能失去了原来有用的氛围；卖点更集中，却可能靠结构示意补出了另一种不确定性。
当时的四维均分汇总是：四个图位提高，两个持平，两个下降。 按固定规则计算，通过数仍然是 2/8，只是通过的图位变了。
分数是多模态模型对商品保真、图种适配、信息效用和美观的判读，量表为 1—5 分。它们帮助定位问题，并不等于商家采用结果。
这里还有一个容易被数字遮住的细节。我们的比较同时包含一句话直调和商家原图，而两轮的直调结果分别生成。空气炸锅场景图的工作台均分两次都是 5，对应直调却从 3.75 变成了 5。于是工作台评分没变，“高于直调”这条要求却不再满足。
如果只报通过率，就会把比较对象的变化也算到新策略头上。这也是为什么文章要把实图、绝对评分和比较结果放在一起看。它们分别提供线索，不能彼此代替。
卖点少了一些，商品就更准了吗
回到开头那张空气炸锅图，继续追查后，我们发现问题还藏在最后的拼装步骤里。
上游已经开始强调一个理由，最终发给生图模型时，多条卖点却仍会被串在一起。模型收到的任务没有真正收窄。与此同时，底栏容易重新长成利益列表，线框、剖视和内部结构示意又会把注意力从参考中可见的商品引开。
后续调整同时落在这两个地方：卖点图只发送第一条主要购买理由，围绕本体可见证据来表达，避免用臆造的内部结构增强说服力。
开头右侧的图片就是这次复验的结果。它把“烹饪进度看得见”放到主要位置，用窗口引导线支持这句话。容量仍在角落，但没有再展开成一排平行卖点。
这次均分从 4.0 回到 4.5，比较结果也通过了。保真分仍为 4。
我们能据此保留的是更窄的判断：这次修改让一张图的表达和比较结果有所改善，商品身份还需要继续检查。把后半句省掉，文章会更好看，下一次设计却会失去依据。
调提示词也有成本。确定性测试可以证明“一条主要理由”真的被送了出去，却不能证明生成结果因此更准确。每一个效果假设，仍然要经过新图、评审和实际查看。随着这样的尝试增加，我们也需要决定：哪些问题值得继续交给生成去试，哪些应该改变处理方式。
有些地方，应该让模型少改一点
主体保留和排版的建设，与前面的实验在时间上交错进行。单凭那几张卖点图，推导不出一种架构必然更好。不过，它们都把问题推向了同一个地方：一次修改，究竟应该允许改变多少东西？
设想一项很普通的要求：商品外观已经确认，只想换个背景，再把标题缩短。这是一个设计场景，还不是我们记录过的用户订单。
如果把它作为整图生成交给模型，刚刚确认过的杯盖、包装、纹理和文字又可能变化。用户真正付出的费用，除了生成账单，还包括重新把这些地方看一遍。
ProductFlow 开始把这几种工作分开。需要新的场景和视觉候选时，使用生成式出图；参考图适合提取主体时，尝试保留主体，再组合背景和位置；精确的文字与布局交给持有图层结构的排版；选好的图片最后按交付规格处理尺寸与格式。
保留主体，关键在最后保存了哪张图
主体保留路线中，提取和合成成功后，系统直接保存合成 PNG，跳过这个图位的图片模型调用。来源记录可以追到参考图、抠图和合成结果。
这项机制的收益比较明确：成功分支少一次图片生成请求，主体使用已有来源。它不保证所有商品都能走这条路。当前提取方法适合近似纯色底的参考图，复杂背景、透明和反光材质、遮挡边缘还需要进一步处理。已有合成能力也比较有限，不能理解并完成任意场景设计。
更麻烦的是失败以后怎么办。当前实现仍可能转而生成图片，但要留下主体路线未合格、外观可能变化的记录。用户看到一张结果，与系统有依据宣称保留了主体，是两个不同的判断。
截至本文记录的 9 月 9 日版本，成功分支已有代码与回归证据，专项真实环境冒烟还没完成验收。因此我们没有给它写一个省费百分比，也没有在这里放一张新制作的演示图充当实验结果。
改一个字号，不必重新决定商品长什么样
排版承担的是另一种精确修改。已有图片层和文字层以后，改标题或字号可以重新渲染这些层，复用同一份主体源资产。
我们用固定夹具把字号从 28 改到 36，检查到输出图片发生变化，主体源文件的内容摘要保持一致。预览与导出的另一组检查把层框误差限制在 1 像素以内。这说明底层处理能把修改范围控制住，但层框一致还不代表浏览器和服务端的字形逐像素相同。
这里也有一段尚未完成的产品工作：目前交付的是组合器和预览辅助，完整的 HTTP 接口与工作台编辑器还没有接齐。任意上传图片也不会自动变成可编辑图层。
我们希望最终减少的是用户为了改一句话而重新检查商品的次数。这个目标很具体，实际能省下多少时间，要等完整入口能够使用以后继续测量。图片交付模块则继续从选定源图派生文件，负责裁切、缩放和编码，保留它原来的职责。
也有一次尝试，最后被我们撤了回来
还有一项摄影指令候选，值得和这些正在建设的能力放在一起讲。
我们在暗色商品图里观察到部分部件与内腔不够容易辨认，于是尝试增加一项有条件的要求：在保留真实颜色、材质和用户指定背景的前提下，通过补光或轮廓光改善局部可读性。
听起来是合理的摄影建议。为了看它有没有实际作用，我们固定一款灰色耳机，并用一件白 T 恤作控制样本；原版与候选各生成三次，共得到 12 张图片。六组配对再各判读三次，共 18 次。
暗色组的九次判读中，候选两次更强、六次持平、一次更弱。保真、适配和效用的平均配对分差都是 0，美观分差约 +0.111，重复判读的胜负也不稳定。
白 T 恤还提醒了我们另一件事：一组候选出现模特穿着，原版是单品展示。冻结要求允许这两种构图，模特出现本身没有违规，但两张图的展示目的不同。这组的三次判读被单列，没有为了凑齐胜负强行比较。
最后，我们删除了这次增加的摄影指令，保留实验图片、评分和此前的调用失败记录。没有再补一句更长的提醒来替换它。
这次结果并不能证明补光建议普遍无效。在这组输入与预算下，我们没有找到足够稳定的收益，暂时没有理由让它成为每次生产请求都要携带的负担。对早期产品而言，能作出这样的停止判断，与保留一次有效修改同样重要。
图片之外，还有一段用户一直在等的时间
生成方式在调整，执行底座也在同一阶段迁向 PostgreSQL / River。
它解决的是另一类问题。此前的超时文章讨论过数据库、发送阶段、Redis 队列和供应商之间的中断窗口。我们用持久投递记录把这些步骤接起来，也因此要自己维护发送对账、消息领取和基础设施恢复。
迁移后，业务记录与队列任务进入同一笔 PostgreSQL 事务，正常投递、延后和基础设施重试由 River 承担。产品继续管理商家公平、生成容量，以及外部请求已经发生以后能不能重试。
固定候选的变更净减少了 2,306 行，包含源码、测试与文档。维护工作不会按相同比例减少：新依赖、迁移和数据库压力依然要有人负责。但应用不再维护原来的整段队列生命周期，责任边界缩短了。
实际等待怎样变化，还需要测。隔离实验中，商家 A 提交 100 项任务，B 每五秒提交一项、共 20 项，三个生成槽连接每次耗时两秒的假供应商。120 项全部完成，B 从收到提交响应到供应商开始处理的等待 p95 为 4.749 秒，最大 4.966 秒。
另外一轮确认三个槽都被约 15 秒的长任务占满后，再提交新任务，等待是 14.602 秒。公平调度不会抢占已经发出的请求，长任务仍然占着时间。
这些数据支持新方案在这组负载下工作，不能写成“迁移后快了多少倍”，因为我们没有同配置旧版对照。它也没有让外部调用的不确定性消失：请求已经发出、结果尚未保存时进程退出，系统仍然需要保守地留下未知，而非自动再付费生成一次。
收益要算到下一次修改结束
回看这段演进，最容易量化的东西往往并非最终最重要的东西。代码行数可以马上统计，模型分数可以很快汇总，用户少做了多少重复校对却需要跟完一段真实工作。
我们目前能指出一些具体收益：一次拼装不再把多条卖点全部发出去；主体合成成功时跳过图片模型；排版可以在改字时复用主体源资产；业务任务与队列入队共同提交。也能指出没有取得的收益：那条摄影指令没有让两组样本稳定变好，主体保真没有因为卖点表达更集中而自动恢复。
接下来，评价单位应该是一套素材和它后面的修改。做完第一版以后，换一次背景、改一句标题、更新一个规格，再看哪些图片最终被采用，哪些地方需要重新检查，花了多少模型费用、等待和人工时间。
合成可能省一次请求，却增加抠图检查；排版减少重生成，也会增加字体与编辑操作。把这些都算进去，才能知道流程对商家是否更有用。
我们仍然需要画布来组织工作，也仍然需要模型创造候选。最近的变化，是开始更仔细地决定每一步可以改什么，以及应该怎样证明这次修改值得留下。
开头那三张卖点图就保留在这里。它们让人看到方向确实发生了变化，也让我们记得：更符合设计意图的表达，还需要经得起商品准确性和实际使用的检查。
关于这些图片和数据
本文记录截至 2026 年 9 月 9 日的实现与实验；9 月 10 日补入实图并重新组织行文，未为文章重新生图。首轮两款商品的八个图位完整展示，卖点复验另列。展示的是本次工作流的生成结果，未把商家原图或一句话直调图冒充候选；图片保留原比例，仅等比缩放、留白和拼版，文中可打开大图查看。
首轮每图位每版本只生成一次，两臂还分别生成直调图，合计 16 张工作台图、16 张直调图、16 次三方评分。通过规则要求工作台均分高于直调、保真不低于直调；有商家原图时，均分与保真也不能低于它。这个相对规则不等于可交付率，模型评分和开发方复核也不能代替独立用户评价。
摄影候选的 18 次判读来自六组图片的重复比较，不能当作 18 个独立商品样本；旧配置的两个图片调用未知结果保留，新配置批次单列。队列使用假供应商与固定负载，排版和主体合成目前引用机制回归，均不证明生产时限或整体商业收益。
评论