一個容易被忽略的版本差異：預設值變了

這篇是本週唯一直接碰模型層的內容，跟前面四篇的平台層控制形成「平台 + 模型」雙層防線。開始之前有個重要的版本差異要先講清楚：較舊的 Gemini 模型，預設的安全過濾閾值是 BLOCK_MEDIUM_AND_ABOVE；但 Gemini 2.5 與 Gemini 3 系列模型，預設閾值已經改成 OFF。這代表如果你的應用程式沒有明確設定 Safety Settings，直接沿用新版模型的預設值，等於完全沒有安全過濾在跑——這對企業客服、內容生成這類場景是重大風險，多數團隊升級模型版本時容易忽略這個變化。

這個版本差異建議正式發布前再次核對 Gemini API Safety Settings 官方文件 當下的最新狀態，因為預設行為屬於 Google 可能持續調整的產品設定。

四個核心可調整的危害類別

Gemini API 的可調整安全過濾涵蓋四個主要類別：

（部分 SDK 版本另有 HARM_CATEGORY_CIVIC_INTEGRITY，與選舉相關內容有關，建議實測時一併確認是否適用你使用的 SDK 版本。）

每個類別可以設定過濾強度，從最寬鬆的 BLOCK_NONE 到最嚴格的 BLOCK_LOW_AND_ABOVE。有一點容易被誤解：過濾依據的是「內容屬於該類別的機率」（HIGH/MEDIUM/LOW/NEGLIGIBLE），不是「危害的嚴重程度」——這代表有些內容即使機率判定較低，實際嚴重性仍可能很高，不能只靠機率閾值當作唯一防線。

內建、無法關閉的防護

在可調整的類別之外，Gemini API 對於某些核心危害（例如危及兒童安全的內容）有內建、不可調整的防護機制，這類防護即使你把所有可調類別都設成 BLOCK_NONE，也依然生效。

實測規劃：企業上線前該測的組合

正式發布前，建議實際跑過以下測試矩陣，把結果填進表格：

待實測提醒：這張表是測試框架骨架，不是實測結果。正式發布前務必實際呼叫 API 跑過這幾個情境，把「實際結果」欄位換成真實輸出（含 block_reason、機率分級），這是這篇文章最有價值、也最不能省略的部分。

這篇的檢查清單

• [ ] 是否已確認目前使用的模型版本，預設 Safety Settings 是 OFF 還是有過濾？
• [ ] 是否已針對應用場景明確設定四個類別的閾值，而非依賴預設值？
• [ ] 是否已用真實測試案例驗證過設定是否如預期運作？