如果你經常使用 ChatGPT、Claude 或 Gemini，你一定對這種體驗不陌生：當你送出問題後，AI 的回答並不是「啪」一聲整篇出現，而是像有一個隱形的打字員，一個字、一個字地在螢幕上敲出來。
為什麼 AI 要這樣設計？這背後涉及了兩種 API 資料傳輸模式的選擇：非串流 (Non-Streaming) 與 串流 (Streaming)。這兩種模式的核心差異，在於「資料回傳的時機」以及「使用者的等待體驗」。為了讓你秒懂，我們用「上餐廳吃飯」來做個比喻。
一、非串流模式 (Non-Streaming)：像是點「精緻套餐」
這是一般傳統程式與 API 最常見的運作方式。
情境想像： 你走進餐廳點了一份套餐。點完餐後，你必須在位子上等待。廚師在後台忙著準備前菜、主餐、甜點。直到所有餐點都做好了，服務生才會一次把整個托盤端到你面前。
技術運作流程：
- 你發送問題（Request）。
- 伺服器開始運算（可能需要 5 到 10 秒）。
- 這段時間你的畫面通常是顯示「載入中」或轉圈圈。
- 等伺服器算完「所有」文字後，一次性把幾千字的完整內容丟回來（Response）。
它的優缺點：
- 優點： 程式寫起來非常簡單，開發者收到就是一個完整的資料包（JSON），處理起來很方便。
- 缺點： 如果 AI 回答很長，使用者會覺得「怎麼卡住這麼久？」，甚至誤以為當機了。
- 適用場景： 適合「給程式看」的任務。例如：讓 AI 分析 PDF 後直接存入資料庫、或是自動重新命名檔案。因為程式不需要看過程，它只需要最後的結果。
二、串流模式 (Streaming)：像是吃「鐵板燒」
這是目前所有主流 AI 聊天機器人的預設模式。
情境想像： 你坐在鐵板燒台前。廚師切好一塊肉、炒好一樣菜，就馬上夾到你盤子裡。你不用等到所有菜都煮好，可以一邊看著廚師料理、一邊開始享用。
技術運作流程：
- 你發送問題（Request）。
- 伺服器算出「第一個字」，馬上傳給你。
- 畫面立刻顯示出那個字。
- 伺服器接著算出第二個、第三個字……源源不絕地傳送過來，直到結束。
它的優缺點：
- 優點： 反應速度感（TTFT）極快。雖然 AI 寫完整篇文章的總時間其實沒變，但因為你馬上看到字在跑，心理上會覺得「它反應好快」，閱讀體驗也比較好。
- 缺點： 開發難度稍高。前端程式需要持續接收破碎的數據流並將其拼接起來，無法像前者那樣一次拿到完整結構。
- 適用場景： 適合「給人看」的介面，如聊天機器人、客服系統。
三、該如何選擇？關鍵差異總整理
為了幫助大家更清楚地做選擇，我們將兩者的核心差異整理如下：
1. 關於資料傳輸
- 非串流： 全部算完，一次打包快遞給你。
- 串流： 算出一點，就先傳一點（Chunk by chunk）。
2. 關於等待時間
- 非串流： 等待時間長，因為要等全部生成完畢才能看到東西。
- 串流： 等待時間短，幾乎是即時就能看到第一個字。
3. 關於視覺效果
- 非串流： 轉圈圈等待 → 突然出現一大段文字。
- 串流： 文字逐字打出，具有「打字機」的視覺動態。
4. 關於 API 設定 (以 Gemini 為例)
- 非串流： 通常參數設定為
stream: false。 - 串流： 通常參數設定為
stream: true。
結語：看對象決定模式
總結來說，選擇哪種模式，取決於你的終端用戶是「人」還是「機器」：
如果你正在開發一個聊天視窗，請務必選擇 串流 (Streaming)，否則長達 10 秒的空白等待會讓使用者失去耐心。但如果你是用 AI 來做背景自動化處理（例如整理報表、標註資料），那麼 非串流 (Non-Streaming) 會讓你的程式邏輯更簡單、更穩定。
