模組三｜AI 生圖與生片產線（Day 10–19）
前兩天講產線怎麼建。今天講產線卡住的時候怎麼辦。
這篇的主角是一次內容審核誤判。它本身不大，但排查的過程是可以直接搬走的，而我當時走了三步冤枉路。
情境：我要生一張章節封面。用 Day 10 講過的雙參考做法：三視圖 + 立繪一起餵進去，prompt 鎖住角色設定，另一段描述場景。
第一次送出，回來的是內容審核拒絕。
這種事偶爾會發生，通常換個說法就好。於是我改寫了 prompt，把可能敏感的措辭都換掉。
第二次，一樣被擋。
再改，用更中性的字。第三次，一樣。
第四次，一樣。
**同一個組合，連續四次，全部被同一個模型的審核擋下。**而我每次都改了 prompt 的文字。
現在回頭看，第二次失敗的時候我就該停下來了。
因為我做的事情是這樣：
| 嘗試 | 我改了什麼 | 結果 |
|---|---|---|
| 1 | — | 擋 |
| 2 | prompt 措辭 | 擋 |
| 3 | prompt 措辭（更中性） | 擋 |
| 4 | prompt 措辭（再中性） | 擋 |
四次嘗試，只動了一個變數，而且那個變數動了三次都沒有任何反應。
這在除錯上是很明確的訊號：
改動 X 而結果完全不變，代表 X 不是原因。
我當時沒有這樣想，因為「內容審核 = prompt 有問題」這個聯想太強了。文生圖的直覺就是「文字有問題就改文字」。
但這次的輸入不只有文字，還有兩張參考圖。
想通這件事之後，整件事就合理了。
現代的圖像生成服務，內容審核通常是多模態的：
三者都可能進入判定，而且它們是組合判定的：單獨看每一項都沒問題，組合起來可能觸發。
我這次的情況就是：參考圖本身的一項體型特徵，加上場景裡需要的一件道具，兩者組合被判定為需要攔截。
單獨拆開來看，兩者都毫無問題。 這也是為什麼我改文字沒用。文字從來就不是觸發點，而那件道具是場景的必要元素，改掉就不是我要的圖了。
因為審核回應通常不告訴你是哪一部分觸發的。
你收到的是一個籠統的拒絕。沒有「是第三句話」、沒有「是參考圖 B」、沒有信心分數。
這跟一般的 API 錯誤很不一樣。400 Bad Request 至少會告訴你哪個欄位錯了；內容審核基於很合理的理由（防止有人反推繞過機制），故意不給你細節。
於是你只能靠控制變數自己二分。 而每一次二分都要花一次生成的錢和時間。
最後的解法很簡單：換一個模型。
原本用的是一個模型（Seedream 4.5），改用另一個（nano_banana_2，實際跑的是 nano_banana_flash）。
同樣的參考圖、同樣的場景需求，一次過。
因為內容審核的判定標準是各家自己訂的，不是產業標準。A 家判定為需要攔截的組合，B 家可能完全不覺得有問題。
這不代表 B 家比較寬鬆或比較不負責，是它們的閾值和分類器不一樣。
開發足跡.md 裡當天的紀錄，最後一句是這樣：
此參考圖組合日後封面直接用 nano banana，別浪費 Seedream 額度。
這句話比解法本身重要。
因為這種誤判是可重現的：同樣的參考圖組合，下次還是會被擋。如果我不記下來，三個禮拜後我會再燒四次額度重新發現一次。
排查的成本要一次付清，不要每次重付。
代價一：四次失敗的額度是真的燒掉了。
而且是燒在完全沒有產出的方向上。如果我第二次就轉向去驗證「是不是圖的問題」，成本會少一半。
代價二：換模型不是免費的。
兩個模型的畫風不完全一樣、輸出解析度不一樣（這直接導致了明天要講的解析度補齊問題）、參數名稱也不同。
「換一個能跑的」會在別的地方產生新的不一致。 這次的封面因此走了跟其他圖不同的後製流程。
代價三：我沒有真正確認觸發原因。
我的紀錄裡寫的是「疑似」。我沒有做完整的控制變數實驗：沒有拆掉道具單獨測、沒有換一張參考圖單獨測。
因為做那些實驗要再燒好幾次額度，而我已經有一條能走的路了。
這是務實的選擇，但它的代價是我對這件事的理解停留在假設。 下次遇到類似情況，我沒辦法預測會不會發生。
一、同一個變數改三次沒反應，就換變數。
這是最基本的除錯紀律，但在有「強烈直覺」的領域特別容易忘記。
「內容審核 = 文字問題」「畫面不對 = prompt 不夠細」「效能慢 = 資料庫」，這些聯想愈強，你愈可能在錯的變數上耗掉整個下午。
具體做法：在第二次失敗之後，強迫自己寫下「還有哪些輸入我沒動過」。 我這次沒寫，所以四次都在改文字。
二、列出你的完整輸入清單，不要只列你想到的那個。
送出一次生成請求，輸入其實有：文字 prompt、negative prompt、參考圖（可能多張）、模型、參數（尺寸、品質、seed）、以及服務端的審核設定。
卡住的時候，先把清單寫出來，再決定要動哪一個。 憑直覺挑通常會挑到最顯眼的那個，而最顯眼的那個往往不是原因。
三、外部服務的策略性拒絕，「換一家」是合法的第一選項。
我們對自己寫的程式會有「一定要找出根因」的堅持，這是對的。但對外部服務的內容審核：
在這種條件下，追根因的期望報酬很低。 先換一家試試看，能過就過，然後把「這個組合走 B 家」記下來。
判斷句：這個系統的規則我看得到嗎？ 看得到就查根因；看不到而且有替代品，就先換。
四、把排查結論寫成規則，不然你會付兩次。
這種誤判可重現。今天花四次額度學到的東西，如果沒寫下來，三個月後會再花四次。
紀錄要包含三件事：什麼組合會出事、換成什麼可以過、下次直接用哪個。 「什麼組合會出事」最容易被省略，但它是最值錢的那一項。
明天 Day 14，繼續講外部服務的實務問題：參考圖怎麼傳上去。兩條路：走簽名上傳流程，或把圖丟到自己的靜態站當圖床再給 URL。我選了後者，理由不只是比較省事。
iThome鐵人賽
看影片追技術