一個請求，兩個欄位
OpenRouter 在 2026 年 9 月 9 日發布的教學，把「用文字指令改一張既有圖片」壓縮成一個 HTTP 請求：來源圖放進 input_references，修改指令放進 prompt，改好的圖以 base64 回傳在 data[0].b64_json。
這篇教學預設的模型是 google/gemini-3.1-flash-image，也就是 Nano Banana 2。OpenRouter 說明「Nano Banana」是 Google Gemini 圖像模型的暱稱，而這個 slug 是該家族中預設的快速模型。對產品團隊來說，真正有用的不是暱稱，而是請求形狀：同一個 endpoint 同時吃本地檔案與公開 URL，回傳格式也固定。
值得注意的是編輯與生成的差別。教學明確區分：編輯是改一張既有圖片，生成是從文字產生新圖；這份教學只涵蓋編輯，所以每個請求都必須帶來源圖。如果你要的是從零生成，得走另一份文件。
來源圖怎麼送：base64 或 URL
input_references 接受兩種輸入：base64 data URL，或一般的 HTTP(S) 連結。教學的建議很直接——圖片已經公開託管就用 URL，請求 body 會小得多；本機或私有檔案才用 base64 編碼。
教學列出 Gemini 可接受的輸入格式為 image/png、image/jpeg、image/webp、image/heic、image/heif，但同時提醒支援格式因模型而異，送之前要確認模型頁面。這類細節在 demo 階段很容易被忽略，到了正式流程就會變成隨機失敗。
回傳端也一樣單純：把 b64_json 解碼後寫入檔案即可。教學另外提到 OpenRouter SDK 有對應的 images resource，呼叫同一個 endpoint，不想自己處理原始 HTTP 的話可以改用。
編輯提示詞的寫法，以及為什麼要一次改一件事
教學對提示詞的建議是：先講要改什麼，再講什麼必須維持不變。它給的例子包括物件替換、換背景、風格轉換、改招牌文字，每一種都附帶「保留原本的某部分」這種約束。
它還提到可以把提示詞寫成一小段 JSON 文字，把 edit、preserve、style 分開。但教學說得很清楚：API 只把它當純文字處理，這不是特殊模式，只是可能幫助模型區分「要改」與「不要動」。要不要用，得在自己的圖上試。
多輪編輯的做法是把上一輪回傳的圖再當成下一輪的來源圖，一次只下一個指令。教學提醒模型不會記得先前的提示詞，所以每一輪都要重述該保留的部分。這個限制直接影響你的產品設計：如果你打算做「連續微調」的介面，狀態得存在你自己的系統裡，而不是期待模型記得。
換模型只改一個欄位，但前提是模型真的支援
教學裡最實用的一段，是換模型的方式：model 欄位改掉，來源圖、提示詞、回應處理程式碼都不用動。它列出同家族的四個選項——Nano Banana 2 當快速預設、Nano Banana 2 Lite 最便宜最快、Nano Banana Pro 較慢但品質較高、初代 Nano Banana 則是暱稱起源的舊模型。也可以換成其他供應商的模型來比較品質、成本與速度。
但這個「只改一個欄位」有前提：模型必須接受圖像輸入，且支援同樣的 input_references 形狀。教學反覆強調要先確認模型具備編輯能力，因為圖像目錄變動頻繁，今天釘住的 slug 之後可能被淘汰或改價。這種抽象層的價值，和我們在把模型參數移出程式碼談過的設定管理是同一件事：把會變的東西集中到一處，程式邏輯才不用跟著重寫。
錯誤處理與成本，才是能不能上線的分界
教學點出三種常見失敗：模型拒絕不支援的格式或連不到的 URL；圖片過大導致逾時，建議先縮圖；以及把提示詞寫成問句（例如「這張照片裡有什麼？」）會讓模型回文字而非圖片，API 會以 400 錯誤回傳，而不是空回應。最後一點對產品特別重要——錯誤要以 HTTP 狀態判斷，不能靠解碼結果猜。
成本方面，教學說回應會在 usage 資料可用時回報每次請求的美元成本，建議記錄下來追蹤支出。批次作業則要遵守速率限制，對 429 與 5xx 用遞增延遲重試，並限制同時進行的編輯數量；每張回傳的圖要先存檔再進行下一輪，避免單一失敗帶走已完成的工作。
這份教學沒有談到延遲數字、品質評測方法，也沒有談多使用者併發下的配額規劃——這些得靠你自己的測試補上。實務上的下一步很具體：拿一張自己的圖跑一次請求，把 usage 記下來，再決定要不要把編輯流程接進產品。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。