很多 AI 生圖討論其實卡錯地方了。
大家很愛比較 prompt 怎麼下、哪個模型比較會畫手、哪個服務的色調比較順。這些當然重要，但在真正要把圖片放進文章、產品頁、社群貼文或文件裡時，最常讓人停下來的不是「生成失敗」。
是生成成功以後，才發現它還不能用。
這張圖比例不對。放到首圖後主體被裁掉。縮成縮圖時看不清楚。檔案太大。背景有怪邊。某個角落有標記。社群預覽裁切後，最重要的資訊剛好消失。工程師、設計、行銷各自下載一份，最後資料夾裡出現 final-2-real-final.png。
AI 生圖真正麻煩的地方，不是拿到一張圖，而是把那張圖變成別人可以放心使用的資產。
這個差別很大。
現在的圖片生成 API 已經不只是「文字變圖片」。你可以指定尺寸、品質、輸出格式，也可以用參考圖、遮罩、編輯流程去修局部。Gemini 的圖片生成也把生成和編輯放在同一條視覺工作流裡看。
這代表模型輸出本來就不是一個神聖的最後結果。
它比較像原料。
原料的價值在於方向快、成本低、探索空間大。你可以很快拿到情緒、構圖、顏色、場景雛形。但原料進到發布流程時，還要經過品管。工程師不會因為 AI 寫出一段看起來能跑的程式，就直接 merge 到 production。圖片也一樣。
一張可發布圖片至少要回答幾個問題：
這些問題聽起來很瑣碎，但這才是內容流程裡真正會消耗時間的地方。
最糟的做法，是看到一張圖「大概可以」就立刻拿去裁尺寸。
因為 resize 只會把問題變得更難看。
AI 圖片常見的破綻，有些在大圖裡不明顯，放到實際版面才會刺眼。像是背景邊緣不自然、字形像字但讀不出來、陰影方向不對、反光怪怪的、人物肢體細節有問題，或是平台輸出本身帶有可見標記。
這些問題應該在尺寸處理前先看一次。
如果圖片來自 Gemini，而且工作流裡真的需要處理可見的 Gemini 標記，可以把 Gemini 去浮水印線上工具 當成清理階段的一個具體選項。重點不是把整篇流程變成某個工具的介紹，而是把「可見清理」放回素材管線裡：先確認哪些東西是品質瑕疵，哪些東西是來源標記，哪些東西不該為了乾淨而亂動。
這裡要小心一個界線。
來源治理和視覺品質不是同一件事。像 SynthID 這類嵌入式標記，解的是來源判讀問題；右下角可見標記、錯字、破圖、怪邊，解的是版面品質問題。把兩者混在一起，很容易讓團隊以為「清乾淨」就等於「可以負責」。
不是。
你可以為了版面品質做後製，但仍然要保留生成來源、工具、版本和用途紀錄。乾淨的圖片不代表乾淨的流程。
清理完以後，才輪到比例和尺寸。
很多人把 resize 當成最後的小修圖，我覺得這是低估它。尺寸不是美工喜好，而是交付規格。尤其圖片要去不同地方時，規格差異會直接決定它能不能用。
同一張 AI 圖可能要放在：
這些場景要的不是同一張圖。1:1、4:5、9:16、1.91:1，每一種比例都會重新決定主體位置、留白、文字安全區和視覺重心。你如果只把一張原圖丟給平台自動裁，最後通常會得到一個勉強能顯示、但沒有人真正驗收過的版本。
做社群版本時，我會把 resize 當成一個明確步驟處理。比如要準備 Instagram 用圖，就先決定是 1080 x 1080 的方形、1080 x 1350 的直式貼文、1080 x 1920 的限動或 Reels，還是 1080 x 566 的橫式版面。這種時候，用像 Resize Image for Instagram 這類瀏覽器端工具，把原圖放進指定比例、預覽裁切結果，再輸出可發布尺寸，會比把圖丟進聊天視窗問「幫我改成 IG 尺寸」更可控。
原因很簡單：你需要看的不是模型會不會重畫，而是最後那張圖在平台框架裡長什麼樣子。
AI 內容工作流有一個很弔詭的地方：我們已經把圖片丟給模型生成一次了，後面卻常常又把同一張圖丟到一堆雲端工具做裁切、壓縮、轉檔。
有時候這沒問題。有時候很不必要。
前端其實早就有處理這類工作的基礎。File API 可以讓使用者在瀏覽器裡選檔或拖放檔案。Canvas API 可以把圖片畫到畫布上，做裁切、縮放、合成和輸出。更重的批次處理還可以用 worker 把主執行緒壓力降下來。
這不是什麼新潮魔法，是很普通的 web engineering。
但在 AI 圖片變多以後，它的重要性反而被放大了。因為後製步驟越多，你越需要問：這一步真的需要再上傳一次嗎？還是可以在本機瀏覽器完成？
尤其是產品截圖、尚未公開的 campaign 圖、內部文件素材、客戶案例草稿，這些檔案不一定適合到處上傳。瀏覽器端處理不是萬能，但它讓很多「只是裁切、補框、壓尺寸、預覽輸出」的工作，可以留在比較小的信任邊界裡。
這也是工程師應該關心圖片流程的原因。它不只是設計部門的小工具，而是檔案、隱私、效能和交付品質的交會點。
如果要把 AI 生圖納入一個比較穩的流程，我會把它拆成這幾步。
第一，保留原始輸出。不要只留修過的版本。原始圖、prompt 摘要、模型或工具名稱、日期，都應該能找得到。
第二，用實際使用場景檢查瑕疵。不要只看下載後的大圖。放進文章框、產品頁、社群預覽、手機尺寸看一次。很多問題只有在真實尺寸才會出現。
第三，先做清理，再做尺寸。清掉可見破綻、標記、怪邊和明顯錯誤，再開始裁切。不然你是在替瑕疵做多版本輸出。
第四，針對每個平台輸出獨立版本。不要期待一張萬用圖解決所有場景。文章首圖和直式社群圖本來就是兩種交付物。
第五，控制檔案大小和格式。web.dev 的圖片效能建議講得很實際：圖片尺寸、壓縮和傳遞方式會影響使用者體驗。漂亮但過大的圖，不是合格資產。
第六，檔名要能讀。hero-ai-workflow-1080x1350-v1.png 比 image-final-new.png 有用太多。未來要替換、回溯、交給別人接手時，檔名就是最低成本的文件。
第七，留下驗收紀錄。不一定要很正式。至少知道哪個版本上了哪裡，誰看過，什麼尺寸，是否有保留來源資訊。
這些都不是很炫的事。
可是內容流程能不能長期穩定，靠的通常就是這些不炫的事。
AI 生圖工具會繼續變強，這點大概不用懷疑。prompt 技巧也還是有價值，因為它會影響你拿到的原料品質。
但如果一個團隊只會生成，不會交付，最後還是會卡在很無聊的地方：比例不對、檔案太大、裁切失敗、來源不清、版本混亂、沒人知道哪張才是正式版。
這不是模型能力問題，是流程能力問題。
我越來越覺得，AI 圖片的成熟用法不是「一次生成完美成品」。那太像 demo 了。比較像真的工作方式是：快速生成方向，嚴格清理瑕疵，明確輸出規格，保留來源脈絡，最後把它交付成別人可以拿去用、也敢負責的資產。
會下 prompt，只是會拿到原料。
能把原料變成交付物，才是真的把 AI 放進工作流。
ryanvale
iThome鐵人賽
看影片追技術