我在評估Gemini 2.5 Flash-Lite時，想先處理一個很常見的需求：把訂單說明整理成系統需要的欄位。

它在一筆訂單上正確保留了缺少的金額，卻在另一道帳單題目多算60元。換一種回答要求，同一道帳單又算對了。

這讓我把重點放回流程：哪些工作可以先交給它，哪些結果一定要由程式或人工確認？以下從這幾次呼叫出發，介紹模型能力、接入注意事項與適合的使用者。

一、先認識模型，別只看Lite這個名字

Gemini 2.5 Flash-Lite是Google著重成本效率、面向大規模使用的模型。呼叫時的模型識別碼是gemini-2.5-flash-lite。

它支援的功能不只有聊天，也包含結構化輸出、函式呼叫與思考功能。Lite是產品定位，不能直接推論成「不會推理」。

依Google模型文件，主要規格如下：

token是模型處理內容的計量單位，不能直接當成中文字數。輸入上限代表一次能容納多少材料，並不是擷取正確率。

圖像、音訊和影片可以當輸入，生成的結果仍是文字。要直接產生圖片或配音，就需要對應的生成模型。

本文的實際案例是短文字，沒有驗證長PDF、音訊或影片的處理品質。不能因為規格表列出支援，就把這些工作都視為已測試通過。

二、第一個用途：把短文字整理成欄位

這次有一條原始輸入：「订单号A2201，客户张伟，金额未注明，交货城市南京。」要求擷取訂單號、客戶、金額和城市，未提供的資訊不要推測。

模型回傳了對應的訂單號、人名與城市，金額位置填入null，意思是沒有提供值。

對資料整理來說，這種結果可以讓系統辨認出缺少金額的訂單，再請人補齊。若模型自行補上一個數字，後續反而更難發現。

不過，這只代表它在這筆資料上處理正確。我不會據此宣稱「它不會編造」。有同名客戶、兩個不同金額或前後矛盾的敘述時，仍要另外測試。

另一條短紀錄先說5月10日交付，接著改為5月18日，最後確認5月22日。詢問最終交付日，模型回答了5月22日。

這類資訊定位值得先試，因為答案就在原文中，驗收時可以回頭比對。訂單欄位整理、郵件資訊擷取、短工單分類，都可以從小範圍開始評估。

分類規則、翻譯或摘要品質，仍須用自己的材料驗證；上面兩個例子沒有涵蓋這些工作。

三、帳單算錯後，我調整的是工作分配

另一道題目有幾項條件：設備每台1200元、購買2台，9月下單、10月出貨，按出貨月份計費，10月享九折。

此外，先前已支付的60元運費「不退還，也不計入本次費用」。這裡沿用原始題目的金額單位，不另作幣別換算。

正確計算是1200×2×0.9＝2160元。要求只輸出數字時，它回答2220元，多了60元。

差額與那筆運費相同，但回答沒有計算過程，無法確定它究竟在哪一步出錯。

我接著要求它先列條件、逐步計算，再給答案。這次得到2160，也明確寫出運費不計入。

這是更改回答要求的結果，不能直接等同於啟用了原生思考功能。它說明提示方式可能影響答案，也提醒我不能用一次失敗判定整類任務都做不到。

但回答變長，輸出用量與費用也會增加。即使過程寫得完整，最後的金額仍要確認。

在實際流程裡，我會讓模型擷取單價、數量、折扣與排除條件，交給程式執行固定的計算規則。缺欄位、規則衝突或無法確認的情況，再轉人工。

這個分工仍需要檢查擷取內容。若模型把折扣或運費條件讀錯，後面的程式也可能算出錯誤金額。

四、能讀懂，不等於程式能直接使用

前面的訂單擷取還有個問題：模型把結果包在Markdown程式碼區塊內。

人閱讀時沒有障礙，但如果下游只接受純JSON，直接解析整段回答就可能失敗。JSON是常用的資料交換格式，語法有固定要求。

所以我會分別驗證兩件事：欄位值是否符合原文，整段輸出是否符合介面約定。

介面若支援結構化輸出，優先採用它提供的格式限制，再檢查必填欄位、數值範圍與業務規則。單靠提示詞寫「只輸出JSON」，不能取代驗證。

格式錯誤可以觸發重試，但同樣錯誤一直出現，就該調整約束或流程。不能把「可以重跑」當成適合接入業務的充分理由。

這次案例透過Crazyrouter的OpenAI相容介面呼叫。Google也有原生Gemini API。換接入管道時，須重新確認檔案支援、思考參數與結構化輸出方式，不能只換網址就假設功能相同。

五、價格要和驗收成本一起算

以下為2026年10月20日核對的Google Gemini API標準付費價格，單位是美元／百萬token。

假設有1000次純文字請求，每次輸入1000個token、輸出100個token，共輸入100萬、輸出10萬。

按這份價格估算，Flash-Lite是0.14美元，2.5 Flash是0.55美元。這是假設用量，不是本次實付帳單，也不是相同業務效果的比較。

估算沒有計入快取、批次處理、外部工具、重試與管道價差。需要長篇回答時，輸出費用也會改變。

我會先用實際材料確認哪些錯誤能自動發現，再算產出合格結果所需的總費用。省下的呼叫費若被人工修正吃掉，低單價就未必有優勢。

總結：哪些人適合先試

• **個人開發者與小型團隊：**想做欄位擷取、短文字分類或資訊定位工具，可以先用它驗證需求。格式與內容檢查也要一起做進工具。
• **客服與營運人員：**每天要整理郵件、工單和訂單資訊，可以透過接入它的工具先做初步處理，讓人員確認缺漏與衝突。
• **需要批次處理標準化材料的團隊：**若規則清楚、結果容易驗收，可以把它列為候選，測完自己的資料再比較總成本。

**共同前提是任務明確、重複量大、結果能檢查。**只是偶爾聊天的一般使用者，不必只因API單價低就換工具。

複雜推理、重要決策和大型程式修改，需要另外驗證。涉及金額時，我會讓模型整理條件、程式負責運算，異常交由人工複核。

資料核對：2026年10月20日。主要依據Google模型文件、官方定價及結構化輸出說明。規格與基礎單價另參考models.dev及OpenRouter模型清單交叉核對。實際介面限制以接入管道為準。

案例來自2026年10月20日的低隨機性呼叫紀錄，帳單對照更改了回答要求。案例不作整體能力排名；配圖是規格與建議流程示意。

本文使用AI工具協助整理與編輯，案例及數值依原始紀錄與公開資料核對。