摘要： OpenRouter 於 2026 年 9 月 9 日發布 Nano Banana 教學，把現有圖片的文字編輯濃縮成單一 HTTP 請求。來源圖可用 URL 或 base64，回傳則是可寫入檔案的 base64 圖像；教學建議逐輪小改，並重新交代要保留的部分。這種形狀便於包成可測試的 API 流程，但模型能力、格式與目錄變動仍需自行驗證。
一次請求，兩個要緊的欄位
OpenRouter 於 2026 年 9 月 9 日發布的教學，把「依照文字指令修改一張現有圖片」這件事濃縮成單一個 HTTP 請求：來源圖交給 input_references，修改指令交給 prompt，處理完的圖以 base64 出現在 data[0].b64_json。
教學的預設模型是 google/gemini-3.1-flash-image，OpenRouter 稱之為 Nano Banana 2。文中解釋，「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 記下來，然後再判斷要不要把編輯流程接進產品。