選 Gemini 時，先分清楚模型名稱、思考設定與產品方案。它們不是三種互不重疊的能力，也不能簡化成「Flash 不思考、Pro 不推理」。
2026 年 9 月更新：本篇保留原網址，修正舊版分類與重複內容，改用可以隨版本更新的選型方式。
三個常被混在一起的名詞
模型名稱是你實際使用的模型或 API 識別碼，例如某一代的 Flash 或 Pro。思考設定是特定模型與產品提供的推理配置。訂閱方案則決定你的帳號權益與用量。名稱中有 Pro，不代表聊天產品、API 與企業帳號都使用同一套條件。
Google 的模型與停用清單持續更新，舊文章裡的 Gemini 1.5、2.0 或某個 preview 名稱，不應直接拿來當現在的新專案選項。要串接 API，請核對完整模型 ID、是否已停用，以及官方建議的替代型號。官方模型停用清單
用任務決定比較方式
若是將短筆記改成格式一致的週報，先比較格式遵守、遺漏與等待時間。若是多份資料交叉比較，重點則是引用、矛盾辨識與是否能指出資料缺口。
程式或試算表任務需要另外驗證實際執行結果，不能只用回答看起來專業來判斷。高階模型也可能寫錯公式，快速模型也可能足以處理結構清楚的任務。
任務一：簡短文件整理
把以下筆記整理成週報。
固定欄位：已完成、進行中、待確認。
只用原文資訊；沒有負責人或期限就保留待確認。
不得新增成果數字。
驗收時看三個欄位是否完整、是否漏掉原文事項，以及有沒有把預計完成寫成已完成。
任務二：多文件比較
比較附件 A 與 B 的申請流程。
每個差異列出兩份文件各自的依據與版本日期。
資料矛盾時不要自行選邊；缺少資訊明確列出。
最後整理需要向窗口確認的問題。
驗收時回到原文抽查引用。若模型只是寫出流暢的比較，但引用不支持結論，應調整來源與指令，不能只往更貴的方案升級。
每次比較固定四個條件
使用相同材料、相同問題、相同驗收表，並記錄日期與當下選項。至少看正確性、完整性、人工修改量，以及整體完成時間。比較結果只適用於這類任務與當時條件，不應外推成所有工作都由某個模型勝出。
如果你在做 API 應用，再加上實際輸入輸出用量、錯誤處理與模型生命週期。模型名稱看起來相近，也要確認參數與能力是否相容；先在測試環境驗證，再修改正式流程。
為什麼不把所有事都開最高思考？
處理更多推理未必會改善一個資料不足的問題。來源不完整、欄位定義不明或任務範圍混亂，應先改善輸入。
我的做法是先用足以完成工作的設定，觀察在哪一種錯誤上遇到限制，再比較其他模式。這樣才能知道升級改進了什麼，而不是因為等得久就覺得更可靠。
阿峰觀點：選型的答案在你的驗收表
你是機長，AI 是機組人員。先交代任務、提供材料、定義完成標準，再選擇工具與設定。不要讓功能選單反過來決定你要做什麼工作。
個人採購請看 Gemini 訂閱方案選擇；串接應用可看 Gemini API 入門；企業培訓需求可透過 官網諮詢 對焦。
關於作者： 黃敬峰（AI峰哥／阿峰老師），企業 AI 實戰培訓專家。更多實作觀點可 訂閱電子報。聯絡：ai@autolab.cloud｜電話／LINE：0976-715-102。