批次去背：整份商品目錄一次處理完

把一張商品照的背景去掉，只要幾秒鐘。要把四千張的背景都去掉，就完全是另一回事了——不是因為工作變難，而是因為它永遠做不完。在第 50 個到第 500 個 SKU 之間的某一刻，每一位商品目錄的負責人都會有同樣的體悟：這已經不是修圖工作，而是一個流程問題。

批次去背就是解方。與其讓一個人整天把檔案拖進編輯器，不如讓腳本把每張圖送到 API，再取回乾淨的去背圖。結果一樣，過程中不需要人，而且不管有沒有人坐在位子上，待處理的佇列都會被清空。

以下就是這套流程實際的運作方式、它能接進你系統的哪些位置，以及在沒有人逐張盯著看的情況下，如何維持高品質。

一張一張修，什麼時候會撐不住

手動修圖有個難以啟齒的問題：它永遠是線性成長的。第一百張花的時間和第一張一樣多。所以隨著商品目錄變大，三件事之中必有一件會發生：

• 待辦清單贏了——新商品因為圖片「還在排隊」而遲遲無法上架。
• 品質開始飄移——不同的修圖人員、不同的日子，對同一個棘手邊緣做出不同判斷。
• 開始偷工減料——遮罩越描越鬆、陰影乾脆省略、裁切前後不一，整個賣場就這樣悄悄地被侵蝕。

這些都不是人的問題，而是流程的問題，而電商的其他環節早就用自動化解決了——定價、庫存、推薦。圖片往往是最後一塊還在靠手工的領地，這也正是我們在 AI 與電商 一文中提出的論點。

API 工作流程：送出一張圖，取回一張去背圖

選單裡並沒有藏著什麼「批次上傳」按鈕——在 remover.bg 上，批次處理指的就是 API，而這是刻意的設計，不是權宜之計。API 呼叫可以放進任何人力到不了的地方。

原理幾乎稱得上無聊：你的腳本用 HTTP POST 送出一個圖片檔，回應就是同一張圖去掉背景之後的版本——透明、可以直接合成。把這個呼叫包在一個掃過整個資料夾的迴圈裡，再加上基本的重試邏輯，一個下午你就有了批次處理器。完整的請求與回應細節，請見我們的 去背 API 指南。

兩個實務上的提醒。第一，留著你的原始檔——把每個來源檔都存檔，日後要重新處理時就不必重拍。第二，事先決定輸出格式：WebP 的上傳與輸出都有支援，如果你的賣場本來就提供 WebP，在流程中一併轉檔可以省下一整個步驟——這裡說明了 WebP 為什麼重要。

適合真實商品目錄的整合方式

怎麼串接，取決於圖片是從哪裡進到你的系統：

• 上傳即處理——適合賣家自行上傳照片的購物平台。圖片一進到你的伺服器就送去去背，實際存下來的是去背圖。賣家上傳的是一團混亂，買家看到的是整齊一致。
• 夜間批次腳本——成長中商店的主力做法。排程工作掃描「原始」資料夾，處理所有新檔案，把結果丟進「完成」資料夾。你一覺醒來，整份商品目錄就做完了。
• PIM/DAM 流程——對比較大的團隊來說，去背會變成素材生命週期中的一個步驟：照片進到 DAM，被處理與標記，PIM 再把核准的去背圖連結到對應的 SKU。檔案從頭到尾都不會碰到桌機。

先從能清掉你待辦清單的最簡單做法開始。一個 cron 排程加上一套資料夾命名規則，勝過一個下一季才能上線的優雅架構。

一致性與品管：信任，但要抽樣

自動化不等於撒手不管，而是把注意力從每一張圖，移到聰明挑選的樣本上。

從每一批中固定抽出一部分，對照一份簡短的檢查清單來看：頭髮、毛皮與蓬鬆材質的邊緣；背帶、線材這類細長細節；玻璃與半透明材質；整組照片的構圖一致性。沒過的就標記起來重新排入佇列——人負責處理例外，而不是處理全部。

也要把 AI 管不到的變數鎖死：整份商品目錄用同樣的輸出尺寸、同樣的留白、同樣的背景處理方式。購物平台對這件事很嚴格——Amazon 的圖片規範，可以視為買家現在到哪裡都會期待的標準預告。

不用試算表也看得懂的時間帳

你不需要精確的數字，也看得出大致的樣貌。手動修圖的成本會隨著商品目錄大小直線上升，而且每張圖所花的時間其實不太會進步。自動化流程翻轉了這件事：力氣集中在一次性的前期設定，之後每多一張圖，幾乎不再耗費任何人力注意。

而且省下來的還會複利。原本消失在遮罩裡的那些時間，會回到攝影、商品文案，以及那份品管抽樣上——都是真正能讓成果更好的地方。

重點整理

如果你的商品目錄已經大到一張一張修不完，別想著靠增加人手解決——想辦法把它變成一條流程線。把圖片送到 API、挑一個符合圖片進來方式的整合模式、抽樣檢查輸出，並鎖定設定以維持一致。結果就是一份永遠跟得上、外觀統一，而且不再是任何人待辦清單的商品目錄。