图片已经选好了，为什么还不能交付？

从裁切、压缩到批量下载，保住一次人工审阅的价值

商家终于选中了一张主图。商品轮廓正确，颜色接近实物，包装文字也已经检查过。接下来只是准备上架：竖版尺寸、JPEG 格式，再把文件控制在体积上限以内。

如果此时让模型“按新尺寸再生成一张”，用户刚完成的审阅就可能失效。杯盖换了结构，标签多了一个字，背景里又出现了新的物件。文件问题被转成一次新的内容生成，时间、费用和校对工作都重新发生。

我在 ProductFlow 里将生成与交付分开，最直接的原因就在这里：用户选中的图片已经包含一份审阅决定，后续处理应该尽量保留这份决定。

不过，“只做裁切和压缩”也远非没有取舍。改比例可能删掉文字，降质量可能损伤商品纹理，下载包也可能装入错误版本。交付模块要完成的工作，是把这些变化变成明确、可检查的文件合同。

1 被选中的图片，已经是一份有价值的中间结果

ProductFlow 帮助商家制作主图、卖点图和场景图。生成提供视觉候选，用户选图时则投入了对商品真实性、文案和画面表达的判断。

这部分人工投入通常不在模型账单里，却是制作成本的重要组成。重新生成一张看起来相似的图片，需要重新确认那些容易出错的细节。

因此，我们把工作区分为几个阶段：

当前交付渲染在已有图片上执行方向修正、几何处理和编码，不调用生成模型。这使改变尺寸或格式时，不必再次引入生成随机性。

但交付仍然会改变视觉结果。完整保留原图内容、铺满新画布、保持比例且不增加背景，在不同宽高比之间无法同时成立。确定性处理的优点是变化可解释，不代表变化没有损失。

2 “尺寸”至少有四种不同含义

很多图像接口从一个 size 字段开始。随着供应商、渠道与导出方式增加，这个字段会逐渐承担过多含义。

用户要求生成竖图，适配器可能转换成供应商支持的档位，供应商实际返回又需要从文件中读取。最终上架需要的宽高，还可能与生成尺寸不同。

只有把这些信息分开，错误才容易定位。供应商忽略比例、渲染器裁错区域、导出拿错文件，都可能表现为用户说“尺寸不对”，却需要修改不同位置。

图 1. 交付基于实际文件工作。 请求参数描述目标，输出核验才说明目标是否成立。

3 每份交付都应该能够回到来源

假设同一张图片要制作方形主图和竖版详情图。如果先裁成方形，再把方形结果拉成竖图，第一次裁掉的内容已经无法从这个文件中恢复；如果反复解码和有损压缩，损失还会继续累积。

因此，交付派生应保留来源，不覆盖原始素材。不同规格可以从同一份已选源图独立产生。这里的“源图”也可能是用户认可的编辑结果，关键是明确本次派生从哪一个对象开始。

已选源图
  ├─ 方形交付文件
  ├─ 竖版交付文件
  └─ 另一格式的交付文件

ProductFlow 保留来源与派生关系。这让“重新导出”具有更清楚的含义：在明确来源上重新应用规格，而不是继续处理某个碰巧找到的下载文件。

来源关系还会影响后续复用。相同源图、相同规范化规格可以成为查找已有派生的依据；但要证明字节级可复现，还需要固定编码器版本、配置和环境。保存一份规格，并不自动保证未来更换图像库后得到完全相同的文件。

选中的图，不能跟着节点重跑一起改变

来源明确以后，还要固定“这次选了哪几张”。工作台会继续生成新的候选，如果导出只是临时读取每个节点的最新图片，用户上午选好的主图，下午下载时就可能被新结果替换。

ProductFlow 为采用操作保存不可变版本：记录每个图位选中的资产、用途、顺序和交付规格，再把商品的当前采用指针指向这个版本。重新选择会产生下一版，节点继续运行不会改写已经采用的一版。

这里没有再复制一套图片字节。采用版本保存稳定资产引用，渲染和导出沿这些引用找到源文件。这样既能继续试图，也能回答“上一次交付的到底是哪一组”。

这与文稿候选的采用是两次不同的决定。前者决定用什么方案生成，交付采用决定把哪些实际图片交出去。把两次决定分开保存，返工时才不必重新猜测用户已经认可了哪一层。

4 改比例时，系统必须知道用户愿意失去什么

4.1 一张方图变成竖图

用一组具体尺寸看这个问题。源图为 1200 × 1200，交付目标为 1200 × 1600。以下只是几何示例，不对应某个渠道的现行规格。

选择 contain，图片完整放入目标画布，保持 1200 × 1200，居中时上下各增加 200 像素背景。

选择 cover，图片按比例放大到 1600 × 1600，再从左右裁去共 400 像素。目标被铺满了，但源图两侧的信息可能丢失。

contain：缩放比例 = min(目标宽 / 源宽, 目标高 / 源高)
cover：  缩放比例 = max(目标宽 / 源宽, 目标高 / 源高)

如果两侧写着商品参数，居中裁切可能删掉恰好最重要的内容。若原图具有完整背景，上下补白又可能破坏版式。两种结果都满足目标宽高，视觉上却有不同后果。

因此，仅传宽高远远不够。适配方式必须成为用户意图的一部分。

4.2 锚点不认识商品

当前渲染使用中心、上、下、左、右等裁切锚点。锚点只控制几何位置，不会理解杯盖、包装文字或商品标签的重要性。

成熟图像工具也会显式区分 fit、position 与 background，例如 Sharp 的尺寸调整接口。对产品而言，值得借鉴的是这些选项表达的取舍，而不能因为某个库提供了默认裁切，就默认它适合所有商品。

自动主体识别可以帮助选择区域，但还需要验证小文字、细长商品、透明材质和多件套。交付预览仍有明确作用：让用户看到最终裁切区域，而不只看到一个“规格已通过”。

4.3 显示方向需要在几何处理之前解决

照片的像素排列与显示方向可能不同。EXIF 可以表示旋转和翻转，如果直接按未经方向修正的宽高计算，图像可能被横着裁切，锚点也会落在错误位置。

当前渲染器在缩放之前处理方向，并有 JPEG、PNG 和 WebP 的方向测试。

测试样图需要具有方向辨识度：四角不同颜色、可识别文字或不对称主体。用一张中心圆形图验证旋转，可能所有错误方向都看起来差不多。

5 交付规格表达的是一组约束

在上面的竖版示例里，若用户选择完整保留、白色背景、JPEG，并要求不超过 800000 字节，一份规格可以这样表达：

{
  "width": 1200,
  "height": 1600,
  "format": "jpeg",
  "fit": "contain",
  "background_color": "#FFFFFF",
  "crop_anchor": null,
  "max_byte_size": 800000
}

其中存在组合关系。contain 不需要裁切锚点；cover 不使用填充背景。ProductFlow 的规格校验拒绝矛盾组合、未知字段，以及不合法的尺寸和体积参数。

明确拒绝有实际好处。调用方传了一个不会生效的背景色，如果接口悄悄忽略，用户可能误以为已经得到白底效果。后续换一个渲染库，这个原本被忽略的字段又可能突然生效。

但有些条件提交时无法确认。尺寸、格式与字段组合可以提前校验，文件体积能否满足则取决于真实画面和编码结果。它们分别属于结构校验与实际处理，不能只靠一份 JSON schema 完成全部验收。

6 文件压小以后，图片可能更难用了

6.1 在有限质量集合中寻找可行结果

相同尺寸和格式下，大面积纯色与密集纹理的文件体积可能差很多。统一设置较低质量，会损失原本能够保留的细节；统一高质量，又可能让部分文件超限。

当前 JPEG 与 WebP 在没有体积限制时使用质量 95；有上限时，按下面的质量阶尝试，从高到低选择第一个满足限制的结果：

95, 90, 85, 80, 75, 70, 60, 50, 40, 30, 20, 10, 5, 1

每次编码都从已经完成几何处理的像素数据开始，避免拿前一次有损文件继续压缩。PNG 使用另一条规则：当前进行压缩编码，不通过颜色量化换取体积，超限时返回失败。

质量阶让尝试次数有界。选中质量 80，说明它是这组预设档位里第一个满足体积要求的结果；质量 83 可能也符合要求，但当前算法没有继续细搜。不同编码器的同一 quality 数值也不可直接横向比较。

6.2 为什么没有自动缩小尺寸直到成功

如果所有质量阶都无法满足上限，继续缩小尺寸通常还能得到更小的文件。但用户明确要求的宽高已经改变。

当前实现因此返回无法满足规格，而不悄悄降分辨率。接下来由调用方决定放宽体积、调整尺寸或更换格式。

这个选择会降低接口的表面成功率，却能保住规格的含义。否则任务记录写着 1200 × 1600，下载到的文件实际更小，后续排查、复用和批量处理都不知道该相信哪一份数据。

图 2. JPEG 与 WebP 的有界体积搜索。 每次循环降低一个质量阶；编码错误会直接结束，PNG 不进入这条质量阶循环。

6.3 字节数通过，仍然需要看图

质量降到很低时，文件可能满足上限，文字边缘、材质纹理和小标识却已经不可用。编码器的质量参数不是用户的可接受质量评分。

交付因此至少有两个验证层次：机器检查实际格式、宽高和字节数，人或专门的视觉评估检查文字、主体和细节。不能把文件规格通过当作商品图片质量通过。

这也提出一个后续产品方向：允许用户明确最低可接受质量，或在压缩损失明显时提醒审阅。该能力需要基于实际图片与用户标准设计，不能仅给 quality 设一个数字就宣称视觉安全。

6.4 换库时，参数同名不代表行为一致

迁到 Go 的过程中，ProductFlow 修正过 WebP 编码：质量阶需要进入真正的有损编码路径，压缩投入参数不能代替它。

几何默认值、透明背景、色度采样和编码模式，都可能在迁移时改变输出。当前 JPEG 测试也检查 4:4:4 编码与质量阶，WebP 编码依赖 CGO。

这次问题值得展开。无损编码中的压缩投入，可以让编码器多花时间寻找更紧凑的表示，却不会像有损 quality 一样通过丢弃细节降低体积。如果把两者当成同一个旋钮，程序仍然能输出合法 WebP，质量阶循环也会正常结束，但这套“降低质量直到满足上限”的算法已经失去了原来的含义。WebP 编码 API将编码模式与质量、压缩方法分别表达。

所以回归测试会检查实际文件是否进入有损编码路径，再对同一张有区分度的图片比较高低质量输出。比起断言函数收到了 quality=1，文件结构更能说明究竟执行了什么。

JPEG 还有色度采样这层差异。4:2:0 会降低色度分量的空间分辨率，4:4:4 则保留完整色度采样。对照片而言减少色度数据常能节省体积，但商品图还包含彩色小字、标签和高对比边缘。当前渲染保留 4:4:4，把质量阶作为另一项明确选择；提高 quality 不能把此前减少的色度采样直接补回来。

这也是迁移时只比参数名容易出问题的地方。默认色度采样、透明像素、方向处理和编码模式都藏在“返回了一张图片”之下。它们只有落到实际文件里，才会暴露是否还符合原来的交付要求。

7 最后一公里是交出正确的一包文件

单张文件合格以后，批量下载仍然可能失败。

例如用户选了六张图片，打包到第四张时发现文件缺失。如果 ZIP 已经直接写入 HTTP 响应，服务端无法再把之前发出的成功响应改成结构完整的错误；用户可能收到一个中断或不完整的包。

ProductFlow 当前在发送下载响应之前完成临时 ZIP。商品图库批量下载还会固定所选条目的元数据，逐文件读取时再次核对身份、尺寸、体积与内容摘要等信息；打包期间发生变化时返回冲突。

固定元数据的意义是防止“用户选中的对象”与“后来读到的字节”悄悄分离。数据库事务可以固定选择，但随后读取存储文件时，仍需要核对实际内容。

当前选择第三种。它让准备失败与传输失败更容易区分，仍不能保证网络下载一定完成。若包变得很大，长时间等待 HTTP 已经不适合，就应评估后台准备；触发条件应来自真实文件规模和使用方式。

8 容量要按处理阶段计算

一张压缩文件只有几 MB，不代表处理时只占几 MB。

以 4000 × 4000、每像素四字节的缓冲估算，仅一份像素数据就是 64000000 字节，约 61 MiB。解码、缩放目标、方向变换和编码还可能需要额外空间，进程峰值会高于只计算这一份缓冲的结果。

批量渲染因此要关心源图像素、目标画布与并发数；临时 ZIP 更关心整包磁盘占用和并发下载；传输又取决于带宽与客户端速度。

用一个统一的“最大文件大小”无法约束整条链。大尺寸低体积图片会放大解码内存，许多普通图片同时导出则会占用大量临时磁盘。

因此，渲染、打包和下载要分开算资源。限制压缩文件的字节数挡不住一张像素很多的图片，限制单个 ZIP 的大小也挡不住许多下载同时占用临时盘。我们在测试里分别观察输出、打包和中断清理，避免把“整包没有放进内存”误解为整条交付链都很省内存。

9 交付验证从真实文件开始

交付相较于随机生成，有一个优势：可以使用固定源图重复验证，不必每次重新请求模型。

一组有区分度的素材应包含透明背景、密集文字、细纹理、极端比例和带方向信息的图片。对输出重新解码，检查真实宽高、格式与体积；对裁切结果检查可识别区域；对 ZIP 检查条目名称、内容身份与缺失处理。

这些检查分别证明不同性质。尺寸正确不能证明没有裁掉标签；包能够解压不能证明装的是用户选定版本；临时文件删除了也不能证明渲染内存足够。

我们希望用户最终拿到的文件，既符合规格，也仍然保有之前认可的商品与内容。每一次交付如果都能解释来源、处理方式和实际结果，用户就不用为了一个格式或体积问题，重新付出整次生成与审阅的成本。

延伸阅读

• Sharp：尺寸、适配方式、位置与背景。

继续阅读

• 人和 AI 都在改，工作流究竟执行哪一版？
• 生图超时以后，能不能再试一次？
• 从单张生图到整套商品素材：ProductFlow 的画布设计与产品取舍