交付圖片怎樣避免反覆壓縮：原稿、編輯稿與分享稿

開始前先確認

單純複製文件不會重新編碼，也不會因此損失畫質。真正需要留意的是編輯、縮放和導出時發生的處理，以及發送平臺是否改變文件。不要把“經過幾個人轉發”直接等同於“壓縮了幾次”。

三類文件，各自承擔一個任務

原稿不一定是相機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種方案。目標大小不保證達到，下載結果仍需覈對，它也不能替代原稿與編輯工程的留存。