交付图片怎样避免反复压缩：原稿、编辑稿与分享稿

开始前先确认

单纯复制文件不会重新编码，也不会因此损失画质。真正需要留意的是编辑、缩放和导出时发生的处理，以及发送平台是否改变文件。不要把“经过几个人转发”直接等同于“压缩了几次”。

三类文件，各自承担一个任务

原稿不一定是相机RAW，也可能本来就是JPEG。这里的“原”指你当前可获得的来源文件，不代表它从未压缩。编辑稿则优先保留可修改的工程；若只能保存平面图片，也应留一份尚未为低体积交付再次压缩的版本，并说明它的限制。

不要因为文件名里有“高清”就认定它适合继续加工。应打开检查像素、细节和来源；大文件也可能只是模糊小图被放大后的结果。

一个改稿场景，怎样保留分支

示例：假设原照片名为photo-01.jpg，尺寸3000×2000像素。制作方在编辑工程banner-v01中完成裁剪和文字排版，再按要求输出banner-web-1200-v01.jpg作为网页稿。

后来需要宽600像素的预览稿，可以从保留的编辑源生成，而不必把网页稿再次压到更小。若对方还要改标题，回banner-v01修改并保存为banner-v02，再输出新分享稿，避免在已经合成的文字上覆盖一层新文字。

如果保持原照片3:2比例，宽1200时高为800，宽600时高为400；若版式已另行裁剪，应按实际编辑稿比例计算。以上只说明版本和尺寸关系，没有预测JPEG体积或宣称这些文件已经生成。

为什么不把分享稿当成长期编辑源

常见JPEG使用有损压缩，重新编码可能继续改变细节，程度取决于编码设置、图像内容和具体操作，不能说每保存一次损失就必然成倍增加。PNG使用无损编码，但把已经模糊的JPEG转成PNG，也不会把此前缺失的信息找回来。格式特性可参考MDN图片格式指南。

同样需要分清缩放与编码。先把图片缩小，即使之后用无损格式保存，减少的图像细节也不会凭空恢复。因此，保留大尺寸编辑源和选择合适编码是两件事，不能只凭输出为PNG就称全流程无损。

查看图片、复制文件、重命名通常不要求改变图像数据；编辑软件的“保存”或“另存”是否重新编码，则要看实际行为。没有核验时，不应替某个软件作绝对保证。

交付前先把要求写清楚

记录接收方允许的格式、目标宽高、体积上限，以及是否需要透明背景、文字或水印。若目标还不明确，不要先随意压到一个很小的文件，再等要求来后设法放大。

把构图和内容修改尽量集中在编辑阶段。通常先确定裁剪与尺寸，再加适合该版式的文字或水印，最后针对交付要求检查编码与体积。实际步骤会受工程类型影响，通用整理思路可参考图片处理顺序指南。

每次比较压缩候选，从同一份保留的源稿开始。否则一个候选基于原图，另一个基于上一轮压缩图，很难判断差异到底来自哪个设置。

命名要表达用途，别堆“最终版”

文件名至少区分主题、用途和版本，例如banner-web-v02.jpg与banner-preview-v02.jpg。需要把尺寸写进名称时，也要核对实际宽高，文件名只是提示，不是属性证明。

可以分别使用original、edit、delivery目录。工程引用了外部图片或字体等资源时，要确认接收方需要什么、你能交付什么，并检查工程在交付环境中能否正常打开。不要只发一个工程文件就默认所有依赖都在里面。

收到返修时，先确认对方指的是哪一版。不要仅凭聊天窗口中的缩略图认文件，也不要默认修改时间最新的一份就是已经确认的交付稿。

检查实际文件，再选择发送方式

打开最终导出文件，核对文字内容、裁剪边缘、宽高、格式和大小。将最小文字、细线和主体细节与编辑源对照，再按目标展示尺寸看是否够用。

如果接收方要求原样接收，选择能保留文件的交付方式，并让对方检查下载件；不能把某个平台的“原图”按钮理解成所有场景下都不改文件的保证。传输后有疑问时，比较文件属性，必要时核对文件哈希，以确认是否收到同一份文件。

少量重要素材可以逐张核对；批量文件也应检查数量和版本对应关系。交付完成后保留原稿、必要编辑源和明确版本的成品，不必让所有试验输出都混在正式目录里。

需要控制分享稿体积时，可打开AI Lab图片压缩。公开说明中的基础体验免费、固定请求WebP输出；9积分完整版可比较格式、目标体积与8种方案。目标大小不保证达到，下载结果仍需核对，它也不能替代原稿与编辑工程的留存。