---
title: "GPT的推理強度怎麼選？品質、速度、成本一起算"
description: "選推理強度是在決定一件工作值得讓模型投入多少推理：規則清楚用low、需要判斷用medium、要追查原因才上high；答案不好先分辨缺資料還是漏條件，成本要算到能交付為止，而不是有回答就好。"
canonical_url: https://www.datum.page/zh-tw/docs/models/choosing-gpt-effort
site: "Datum"
author: "CJ Mario"
author_url: https://www.datum.page/zh-tw/about
language: zh-TW
published: 2026-09-05
last_updated: 2026-09-05
topic: "模型與選型"
kind: concept # 概念
level: intermediate # 中級
tags: [reasoning, models, openai, cost]
cite_as: https://www.datum.page/zh-tw/docs/models/choosing-gpt-effort
---

# GPT的推理強度怎麼選？品質、速度、成本一起算

> 選推理強度是在決定一件工作值得讓模型投入多少推理：規則清楚用low、需要判斷用medium、要追查原因才上high；答案不好先分辨缺資料還是漏條件，成本要算到能交付為止，而不是有回答就好。

請GPT改一封信，和請它找出系統偶爾重複扣款的原因，應該使用同一種設定嗎？

直覺上，後者值得多花一點時間。前者的要求通常很明確：保留意思，把語氣修順就好；後者卻得追查流程、比較可能原因，還要確認修改後不會產生新的問題。

選擇推理強度（reasoning effort），就是在決定：**這件工作值得讓模型投入多少推理？**

實作上，可以先採用一個簡單的起點：規則清楚的工作用low，需要一般判斷的工作用medium，條件複雜、需要深入分析的工作用high。至於xhigh、max等更高設定，最好等實際比較過成果，再決定是否值得使用。這個歸納與[官方部署檢查清單](https://developers.openai.com/api/docs/guides/deployment-checklist)（擷取2026-09-05）的建議同向——原文的分法是：extraction、routing、分類與簡單改寫用low；要診斷問題、比較方案、寫計畫或對程式做推理，用medium或high。

但要把GPT用得有效率，光記住這三個檔位還不夠。更重要的是知道：什麼時候該提高推理強度，什麼時候其實該補資料、換模型，或重新說清楚需求。

## 先分清楚：模型、推理強度和回答長度是三件事

可以把模型想成負責工作的那個人，推理強度則是這次願意讓他投入多少推理。兩者相關，但不能互相取代。

換成能力更強的模型，是在改變處理工作的能力基礎；提高同一個模型的推理強度，則是調整它在這次任務中的推理投入。推理強度並不是固定的思考秒數，也不能直接換算成固定費用——[官方reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)（擷取2026-09-05）的說明是模型會隨任務難度自適應地推理：簡單任務用較少token，複雜任務想得更完整。

回答長度又是另一回事。在支援的API設定中，`reasoning.effort` 和控制回答詳略的 `text.verbosity` 是分開的兩個參數：前者決定回答前想多深，後者決定輸出多長多細（[部署檢查清單](https://developers.openai.com/api/docs/guides/deployment-checklist)，擷取2026-09-05）。因此，深入分析後只給三句結論，和快速產出一大段文字，是兩種不同的組合。

例如，你可以要求：

> 比較這三個方案的成本、維護難度和失敗風險。最後只推薦一個方案，用三段話說明理由，並指出最可能讓你改變建議的條件。

這個任務需要的是有品質的判斷，不是長篇大論。評估答案時，應該看它有沒有抓到關鍵取捨，而不是字數夠不夠多。

至於模型本身，以2026-09-05查核的[官方models頁](https://developers.openai.com/api/docs/models)定位來看：Luna為成本敏感的工作負載最佳化；Terra平衡智力與成本；Sol是複雜專業工作的旗艦；Astra則是OpenAI最有能力的模型，面向最難的端到端工作。

下面這張表可以當成實作起點。右欄是選用建議，不是保證每種工作都適用的實測排名。

| 模型 | 適合先拿來測試的工作 | 建議起始推理強度 |
| --- | --- | --- |
| GPT-5.6 Luna | 大量分類、欄位擷取、固定格式處理 | low |
| GPT-5.6 Terra | 一般摘要、標準化文件、規格清楚的任務 | low／medium |
| GPT-5.6 Sol | 專業寫作、方案比較、一般程式工作 | medium |
| GPT-6 Astra | 複雜除錯、架構取捨、多步驟分析 | medium／high |

Astra是什麼、強在哪，另見[Astra厲害在哪裡](https://www.datum.page/zh-tw/docs/models/gpt-6-astra)。

模型與介面支援的選項不一定相同。推理強度的全集是none到max七檔，但部分模型只支援子集——例如Astra就不支援none（[reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-05）。以下主要用low、medium、high說明選擇方法，實際操作仍要以使用中的模型和介面為準。

## 從三種常見工作開始，練習選推理強度

### 工作一：意思已經確定，只需要整理或改寫

假設你寫好一封工作郵件，希望GPT把語氣改得自然一點。

這時我會先用low。原因不是郵件不重要，而是這個階段不需要重新決定內容，主要工作是保留資訊、調整表達。

Prompt可以這樣寫：

> 請把下面這封信改成同事之間自然、直接的口吻。保留日期、交付項目與原本的承諾，不要新增資訊。刪除重複的客套話，只輸出修改後的版本。
>
> 原文：
> ［貼上郵件］

完成後，先核對日期和承諾有沒有被改動，再看語氣是否符合期待。

如果文字還是太正式，我會先補一段喜歡的寫法，或指出具體問題，例如「不要使用『敬請協助』，改成平常同事會說的話」，而不是立刻把推理強度調到最高。

這裡的操作重點是：**先把「自然」說清楚，不要期待增加推理就能自動猜中你的語感。** OpenAI的[reasoning最佳實務](https://developers.openai.com/api/docs/guides/reasoning-best-practices)（擷取2026-09-05）也建議把目標、限制與成功標準明確交代；範例則是先不給——zero-shot先試，必要時再補few-shot。

### 工作二：資料已經有了，需要比較和建議

假設你手上有三個客服系統的功能和報價，要選出適合小團隊的方案。

這比改寫多了一層判斷。我會先用medium，並把決策條件一起交給模型：

> 請根據下面提供的資料，比較三個客服系統。團隊有五人，目前最重要的是降低重複回覆的時間，其次是導入難度，最後才是進階功能。
>
> 請先給建議，再說明主要取捨。資料沒有提到的功能，請標成「未確認」，不要自行補齊。最後指出：還缺哪一項資訊，最可能改變你的建議？
>
> 方案資料：
> ［貼上資料］

驗收時，不是看它有沒有做出漂亮的比較表，而是看它是否真的按照你的優先順序判斷。

例如，你明明最在意導入速度，它卻因為某個方案功能最多就推薦，那就是沒有遵守決策條件。這時可以要求它重新依照條件評估；若仍反覆漏掉重要限制，再比較high是否能改善。

### 工作三：問題不明確，必須追查原因

假設一個訂單系統偶爾會建立重複訂單，平常測試卻沒有問題。

這類工作，我會直接從high開始。因為任務不是把已知步驟寫成程式，而是從不完整的線索中找出可能原因，並設計方法驗證。

Prompt可以這樣寫：

> 以下是訂單建立流程、相關程式碼與錯誤紀錄。請協助排查偶發的重複訂單問題。
>
> 請區分已確認的事實與待驗證的假設。對每個主要假設，說明支持它的證據，以及能用來確認或排除它的測試。不要只因為某個原因常見，就把它當成這次的根因。
>
> 最後提出最小修改方案、必要的回歸測試，以及修改可能帶來的風險。資料不足的地方請直接指出。

這裡要驗收的不是「解釋聽起來很合理」，而是它提出的原因能不能被證據支持，測試能不能重現問題，修改後能不能通過檢查。

同樣是寫程式，「把日期轉成指定格式」和「找出偶發重複訂單的原因」，需要的設定可以差很多。

**選推理強度時，先看這一步需要多少判斷，不要只看工作被歸在哪個類別。**

另外，上述prompt是在描述工作，並不等於已經設定推理強度。使用API時，要透過 `reasoning.effort` 設定；使用ChatGPT時，則選擇介面提供的對應推理選項。單純在prompt裡寫「請使用high」，不能當作已完成參數設定。

## 答案不好時，先找原因，不要只往上調

拿到不滿意的答案，最直覺的做法是換更強模型、開更高推理強度。但在實作中，我會先把問題分成幾種。

**缺資料，就先補資料。**
例如你要比較供應商目前的價格，模型卻沒有最新報價。這時應該取得報價或使用搜尋，不是要求它再深入思考一次。操作上，可以先要求它列出已知資訊、缺少資訊，以及哪些結論暫時不能下。

**漏掉條件，再測試更高推理強度。**
資料都在，但模型忽略了限制，或沒有處理方案之間的衝突，才比較像是值得增加推理投入的情況。這時也要指出漏掉什麼，避免只是原封不動重問。

**核心理解一直不對，就比較其他模型。**
不要只測「同一個模型的medium和high」。也可以比較「較便宜模型的high」和「較強模型的medium」，看哪一個更容易達到要求。結果應以實際任務測試為準。

**表達不符合期待，就修改交付要求。**
太長、太像公文、太多抽象詞，先從語氣、範例、篇幅與受眾下手。這些問題不需要全部交給推理強度處理。

這套做法的出發點，是先找出阻礙品質的原因，再選擇對應的調整方式。[官方的模型選擇指南](https://developers.openai.com/api/docs/guides/model-selection)（擷取2026-09-05）的順序也一樣：先把準確度做到目標，再用最便宜、最快的模型維持它——原文直說，模型達不到準確度目標時，成本與延遲都無關緊要。

## 同一份工作，不必從頭到尾使用同一個推理強度

以一篇競品分析報告為例，裡面其實包含幾種不同的工作。

把各家公司提供的功能、價格和限制整理出來，可以先測low；根據這些資料分析差異、評估取捨，可以提高到medium或high；方向確定後，寫成完整初稿可以用medium；最後只剩修句子、統一格式，就再降回low。

不過，拆分工作時要注意資料不能失真。

例如前一步把「某方案的部分功能需要加購」省略掉，後一步即使用high，也可能根據不完整資料做出錯誤比較。我的做法是保留來源位置，並讓負責分析的模型能回到原始資料核對，而不是只看壓縮後的摘要。

也不用為了分配推理強度，把每件事都拆成很多輪。短郵件、簡單摘要，一次完成通常更直接。多一次請求就多一段流程；減少不必要的請求、降低輸入token並讓輸出更精簡，本來就是[官方成本最佳化指南](https://developers.openai.com/api/docs/guides/cost-optimization)（擷取2026-09-05）列出的方向。

比較實用的原則是：

> 工作內容真的改變了，再考慮切換設定；不要為了切換設定而拆工作。

## 成本要算到「能交付」，不是算到「有回答」

使用ChatGPT和API，首先要分開看。[官方Help Center](https://help.openai.com/en/articles/9039756-managing-billing-for-chatgpt-and-the-api-platform)（擷取2026-09-05）寫明ChatGPT與API平台是分開的計費系統，API用量與ChatGPT訂閱分開計費。

在ChatGPT中，你需要考慮的是方案、可用模型、額度，以及等待是否值得。不能直接拿API單價，換算成每則聊天訊息額外收了多少錢。

在API中，則要看實際用量。除了輸入與可見答案，模型產生的推理token也會計費——它們在API裡看不到，但仍占context window，而且按輸出token費率計算（[reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-05）。因此，最後只看到一小段答案，不代表這次請求一定便宜。

但對實際工作來說，帳單還不是全部。

假設人工時間以每小時新台幣600元估算，也就是每分鐘10元。下面只是計算示範，不是模型報價或效能實測：

| 方案 | 模型費用 | 人工修改時間 | 人工修改成本 | 合計 |
| --- | ---: | ---: | ---: | ---: |
| A：較低成本設定 | 1元 | 8分鐘 | 80元 | 81元 |
| B：較高成本設定 | 5元 | 2分鐘 | 20元 | 25元 |

B的模型費用比較高，但完成這件工作的總成本反而比較低。

反過來，兩個設定的結果都能直接交付，高檔又沒有減少檢查或修改工作，那麼較低成本的設定就更有吸引力。

等待時間也要看使用情境。你可以在模型處理時做別的事，和你必須等它回答才能進行下一步，對工作效率的影響並不相同。

所以，我會把比較單位改成：

**完成一份合格成果，總共花了多少模型費用、人工時間，以及必要的等待？**

這比單看「每次請求多少錢」更接近實際使用感受。

## 用一輪小測試，找出適合自己的設定

經常重複的工作，不需要每次憑感覺選模型。可以先做一輪小規模比較。

挑十個實際會遇到的任務，裡面同時放入簡單題、一般題和容易出錯的題目。先把合格標準寫好，再開始測。

例如，郵件改寫的標準可以是「日期與承諾不能改動、語氣符合對象、沒有新增資訊」；資料整理則是「關鍵欄位正確、缺漏有標記、能追溯來源」；程式修改則需要對應測試與人工審查。

先固定模型，比較medium和high，避免模型、prompt、資料與推理強度一起變動，最後無法判斷差異來自哪裡。找到有希望的設定後，再加入較便宜或較強的模型比較。

測試時，我會記錄一次驗收是否通過、有沒有嚴重錯誤、人工修改多久、模型費用，以及整體等待時間。對重要或容易出錯的題目，可以多跑幾次，避免因為某一次答得特別好，就認定設定穩定。

模型輸出並非完全固定。[官方的模型最佳化指南](https://developers.openai.com/api/docs/guides/model-optimization)（擷取2026-09-05）直接寫：LLM輸出是非決定性的，行為會隨model snapshot與模型家族改變，所以要用貼近生產環境的代表性任務持續評估。十題適合拿來初步篩選，但不足以證明某個設定在所有情境都比較好。

還有一點很重要：**較強模型的答案也不能自動當成標準答案。** 驗收依據應該來自原始資料、測試、計算或人工判斷，而不是只讓另一個模型說「看起來沒問題」。

## 最高檔，留給知道自己要改善什麼的時候

xhigh、max值不值得用，關鍵不在於工作名稱聽起來多重要，而在於增加投入後，是否改善了有意義的缺口。

例如high已經能產出符合規格的郵件，最高檔只是換了幾個形容詞，就沒有明確的升級理由。相反地，如果一份複雜分析仍有未處理的矛盾，而更高設定能辨認出影響結論的關鍵條件，增加的時間就可能值得。

Pro也要分開理解。在支援的API中（目前是GPT-5.6系列），Pro是推理模式，不是排在max後面的下一級推理強度。模式與推理強度是獨立設定：模式決定用標準或pro執行，`reasoning.effort` 決定該模式內投入多少推理。Pro會做更多模型工作，token用量與成本都會增加（[reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)，擷取2026-09-05）。

實作上，不必因為「這件事很重要」就直接開滿。可以先問：

> 現在的成果還差在哪裡？提高設定後，我要看到什麼改善，才算值得？

答得出這個問題，就有辦法比較；答不出來，往往只是用更多等待換取心理上的安心。

## 從下一個任務開始，換一種選法

下一次使用GPT，先用一句話定義交付物，再判斷這一步是在整理資訊、做一般判斷，還是處理複雜問題。

意思確定、規則清楚，就先用low。需要比較與建議，就從medium開始。必須追查原因、處理多個相互影響的條件，則值得直接測high。

收到結果後，先驗收，不要只憑流暢度判斷品質。缺資料就補資料，漏條件就調整推理與要求，語氣不對就修正表達設定。對反覆出現的工作，再把測試結果留下來，慢慢形成自己的選用標準。

**好的設定，是讓工作更容易做到合格，而不是讓模型每次都想得最久。**

---

## 本文引用來源

- [官方部署檢查清單](https://developers.openai.com/api/docs/guides/deployment-checklist)
- [官方reasoning指南](https://developers.openai.com/api/docs/guides/reasoning)
- [官方models頁](https://developers.openai.com/api/docs/models)
- [reasoning最佳實務](https://developers.openai.com/api/docs/guides/reasoning-best-practices)
- [官方的模型選擇指南](https://developers.openai.com/api/docs/guides/model-selection)
- [官方成本最佳化指南](https://developers.openai.com/api/docs/guides/cost-optimization)
- [官方Help Center](https://help.openai.com/en/articles/9039756-managing-billing-for-chatgpt-and-the-api-platform)
- [官方的模型最佳化指南](https://developers.openai.com/api/docs/guides/model-optimization)