模型可以換，流程不能靠運氣
Oracle 與 Google Cloud 在 2026 年 7 月 30 日宣布擴大合作，計畫把 Gemini 模型帶進 Oracle AI Agent Studio for Fusion Applications，也將評估在 Oracle Fusion Applications 與 NetSuite 的內建 AI 情境中使用 Gemini。公告提到 Gemini 3.1 Flash-Lite 與 Gemini 3.5 Flash，分別面向價格效能與較複雜的推理、影片及簡報任務。
這則消息對台灣中小企業真正重要的，不是「又有一個模型可以選」，而是企業軟體正把模型選擇接進財務、人資、供應鏈、銷售與客服等真實流程。模型可能讀資料、呼叫工具、等待核准，最後影響交易；換模型自然不能只看一則回答漂不漂亮。
7Pyramid 觀點
換模型就像換一位會操作公司系統的新同事。履歷再漂亮，也要先拿固定案例試做，確認他知道何時能做、何時要問、何時必須停下來交給主管。
單次回答看不見流程層級的錯誤
如果只測一個正常案例，很容易漏掉真正會出事的地方：少一個必要欄位時，系統會要求補充，還是自己猜？兩份資料互相衝突時，會標示差異，還是挑一份順眼的答案？工具回傳錯誤時，會重試、回報，還是假裝工作已完成？
Oracle AI Agent Studio 文件把 Human Approval、節點輸入輸出除錯、儲存與重跑情境的 run profiles，以及上線前評估列為工作流能力。這支持一個很實際的原則：不要拿正式流程抽盲盒，先把常見與高風險情境存成可重複測試的案例。
建立 5 組最小回歸測試
| 測試案例 | 要觀察什麼 | 通過標準 |
|---|---|---|
| 正常案例 | 資料完整、規則清楚 | 答案正確，且呼叫正確工具。 |
| 缺資料案例 | 少一個必要欄位 | 主動要求補充，不自行猜測。 |
| 衝突案例 | 兩份資料給出不同答案 | 標示衝突與來源，交由人員判斷。 |
| 需核准案例 | 付款、折扣、對外發送或資料修改 | 停在人工核准點，不繞過關卡。 |
| 敏感資料案例 | 放入不應擴散的測試欄位 | 權限、遮罩與紀錄符合規則。 |
每一組只比較四件事：答案是否正確、工具是否叫對、核准點是否保留、失敗時是否明確回報。把「輸入、預期結果、實際結果、是否需人工覆核」做成試算表四欄，就能先建立一套不依賴特定模型的最小測試流程。
先做測試表，再談換模型
今天挑一條每週重複使用的 AI 流程，例如客服回覆草稿、報價摘要、發票分類、庫存提醒或社群內容審稿，把五組案例寫進同一張表。未來不論換成 Gemini、其他模型，或只是更新提示詞，都用原案例重跑。
Oracle 的公告也附有未來產品免責聲明，功能、時程與價格仍可能變動。因此現階段應使用「計畫提供」與「預計使用」等措辭，不能寫成所有客戶都已全面啟用。供應商選擇變多是好事，但真正讓自動化可以放心擴大的，是可重複、可比較、保留人工關卡的測試方法。
常見問題
只換模型，也需要重跑工作流程測試嗎？
需要。同一個提示詞與工具流程換了模型後，缺資料、衝突、工具錯誤與核准行為都可能不同，應用固定案例比較。
最少要測哪些情境？
先測正常、缺資料、資料衝突、需要人工核准與敏感資料五種情境，並記錄預期與實際結果。
Oracle 的 Gemini 功能已經全面提供了嗎？
公告描述的是計畫提供與評估中的用途，且附有未來產品免責聲明；功能、時程與價格仍可能變動。