GPT-5.5 vs Claude Sonnet 4.6 vs Gemini 3.1 Pro：沒有任何基準測試會告訴你的事

在每個建立在前沿 LLM 之上的團隊裡，都會發生一種特定的會議。有人分享最新的基準測試排行榜。另一個人指出自上個月以來排名已經洗牌。第三個人則注意到，他們團隊目前使用的模型在三週前還沒聽過的某個指標上滑落了兩位。會議結束時，沒人確定是否該遷移，於是這個話題被安排到下季再討論。

這類會議的問題不在於與會的人，而在於基準測試衡量的是合成任務，而你的產品不是合成任務。排行榜告訴你模型在 MMLU、在SWE-bench Verified、在 GPQA Diamond 上的表現——這些測試由研究人員設計，以便跨模型可度量。可這些測試都不像你的應用在生產環境裡實際發出的提示，也無法捕捉模型如何處理用戶產生的那種凌亂、帶有領域形狀的輸入。

這篇文章帶你做一個基準測試無法完成的實驗。三個具體提示，透過相同的相容於 OpenAI 的端點，以相同的溫度設定、無額外提示詞，發送給 GPT-5.5、Claude Sonnet 4.6 與 Gemini 3.1 Pro。這些提示涵蓋三個觸及大多數生產工作負載的類別：從凌亂文件做結構化擷取、需要大量推理的規劃任務，以及在約束下的程式碼生成。以下觀察是團隊在執行這類比較時一致回報的行為模式——如果你在自己的環境上跑這些提示，也會看見同樣的現象。

在排行榜上，這三個模型在 SWE-bench Verified 的分數相差不到 0.8 個百分點。實際上，它們的行為截然不同。選擇不是誰的基準分數高，而是誰的行為模式更符合你的工作負載。

基準測試測了什麼，錯過了什麼

基準測試之所以存在，是因為它們必須存在。模型供應商需要標準化測試來提出能力主張，研究人員需要它們來發表比較，其餘的人則需要一個客觀的起點來評估模型。它們有用，但在對生產使用至關重要的方面並不完整。

有三個具體限制值得明說，因為在下面的提示示例中都會出現。

• 基準測試衡量的是孤立能力，而非行為模式。SWE-bench Verified 告訴你模型是否能解決某類 GitHub issue。它不會告訴你模型是否傾向對簡單問題過度工程化、在提示含糊時是否會提出釐清問題、或是否會一次就輸出符合你要求結構的結果。這些才是你在生產中每天會觀察到的事。
• 基準測試會被對準調校。當一個模型發佈強調它在某個基準上的分數時，這意味著該模型至少部分地為該基準做了最佳化。一旦離開該基準設計的條件，真實世界表現與基準表現可能出現偏差——有時相當顯著。
• 基準測試會聚合。SWE-bench Verified 上 0.8 個百分點的差異，可能掩蓋了模型 A 在某一特定任務類別大幅領先，卻在另一類落後，而模型 B 在各方面較為一致。聚合壓縮了你做決策所需的資訊。

下面的練習旨在揭示基準測試因聚合而抹去的資訊。重點不是宣布勝者，而是讓你在對自己的提示做同樣練習時，知道該問哪些問題。

設定

三個提示，因為它們對應到大多數生產工作負載會碰到的類別。設定如下：將每個提示以相同參數（temperature 0.3、無系統提示覆寫、預設回應格式）發送給三個模型，透過單一相容於 OpenAI 的端點，以確保比較公平——沒有供應商特定 SDK 的差異、沒有不同的參數對應、也不會因為請求構造差異讓某個模型受到特殊待遇。

提示如下方代碼區塊，可直接複製執行。每個提示後的行為描述是團隊在執行這類比較時一再觀察到的模式——這些模式在 2026 年多個第三方研究中有所記錄，也是在你用自己的環境跑這些提示時應該預期會看到的現象。自己動手跑才是重點；本文提供框架與起始提示，幫你開始。

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["COMET_API_KEY"],  # or replace with your API key
    base_url="https://api.cometapi.com/v1",  # one endpoint, multiple models
)

MODELS = [
    "gpt-5.5",
    "claude-sonnet-4-6",
    "gemini-3.1-pro",
]


def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
    """
    Send the same prompt to all three models and return their responses.
    """
    responses = {}

    for model in MODELS:
        result = client.chat.completions.create(
            model=model,
            messages=[
                {
                    "role": "user",
                    "content": prompt,
                }
            ],
            temperature=temperature,
        )

        responses[model] = result.choices[0].message.content

    return responses


# Example usage
if __name__ == "__main__":
    prompt = "Summarise the key risks in this contract."

    outputs = run_comparison(prompt)

    for model, response in outputs.items():
        print(f"\n--- {model} ---")
        print(response)

提示 1：從凌亂文件做結構化擷取

這是 2026 年一半 LLM 功能的基本盤。將非結構化輸入——電子郵件、支援工單、會議逐字稿、掃描表單——擷取出特定欄位，放入結構化物件。下面的提示要求每個模型，從一封刻意凌亂的客服郵件中擷取七個欄位，郵件包含部分資訊、相互矛盾的訊號，還有一個在原文中不存在的欄位。

提示

You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing",  "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned) 

Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.

注意觀察

三件事。首先，模型是否在不杜撰的前提下遵循要求的 JSON 結構。其次，模型如何處理來源中不存在的欄位（escalation_history——客戶沒有提到對此特定問題的任何先前聯絡）——它會承認缺失，還是會合理但虛構？第三，模型是否在 JSON 外生成額外說明，需要下游解析去剝掉包裝。還有一點值得留意：urgency 欄位——「5 天」並非立刻，但客戶顯然焦慮，留下了判讀空間。

團隊一再報告的觀察

• GPT-5.5：通常第一次就能產出乾淨的 JSON。結構遵循性強；每個要求的欄位都在，格式可直接解析，不需預處理。對於缺失欄位，GPT-5.5 傾向回傳明確的 null。它通常不會用 Markdown 程式碼框包住 JSON，也不會附帶文字解釋，使下游解析變得簡單。在像這裡這類有歧義的判讀（如緊急程度）上，GPT-5.5 比起另外兩個模型更保守——Claude 與 Gemini 可能會基於客戶情緒將工單評為「high」，而 GPT-5.5 常錨定在具體的 5 天時間窗，落在「medium」。
• Claude Sonnet 4.6：同樣會產出乾淨 JSON，且通常是三者中在遵循結構要求上最精確的。當 GPT-5.5 將缺失欄位留為 null 時，Claude 常會額外加入未被要求的欄位以標記數據品質問題——例如一個「notes」或「data_quality_notes」鍵，雖未被要求，但裡面包含確實有用的資訊。對人工審核者有用，但如果你的下游剖析器對結構嚴格，會因此失敗。這是 Claude 的反覆模式：品質高，但有時比提示要求更周到，需要明確的提示約束。
• Gemini 3.1 Pro：通常產出三者中最精簡的結果。每個要求的欄位都有，沒有多餘欄位，也沒有周邊說明。結構遵循度完全如要求。需要注意的一點：對缺失欄位，Gemini 傾向回傳空字串而非 null。嚴格區分兩者的 JSON 剖析器會抓到差別；寬鬆的則不會。這個行為在多次運行中足夠一致，顯示更像是模型偏好而非偶然。

告訴你的事

三個模型都能做結構化擷取。差異在於請求結構邊界上的行為。如果你的下游系統對結構嚴格，將多餘欄位視為錯誤，Gemini 3.1 Pro 與 GPT-5.5 更安全。如果你希望模型在未被要求時也能揭示數據品質問題，Claude Sonnet 4.6 更有幫助。這些都不會出現在基準測試裡。

提示 2：以推理為主的規劃任務

這個提示要求模型規劃一個多步調查：一個研究問題，帶有三個隱含約束，需要細心的模型在排序任務之前辨識出來。這類任務像是一個代理型應用會在任何工具被調用前，請 LLM 做的規劃步驟。

提示

I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.

值得關注的隱含約束：問題從未定義「churn」的含義（帳號關閉？沒有登入？沒有購買？）、沒有說明如何控制混雜變數（低參與的用戶因多種與 feature X 無關的原因流失）、也沒有建立基準比較組。細心的規劃者應在產出步驟前明確點出這三點。

注意觀察

模型是否真正推理問題，或僅產出看似合理、實際經不起檢視的步驟序列。是否在未被告知的情況下辨識出隱含約束。以及步驟間的依賴是否正確——看似可行但把第三步依賴於第五步的結果，在實務中是無用的。

團隊一再報告的觀察

• GPT-5.5：通常產出最具可操作性的計畫。推理可見——GPT-5.5 會在列出步驟前枚舉對隱含約束（流失定義、對照組、混雜變數）的假設，讓你容易看出它與你預期的差異。步驟依賴能可靠識別與標註。輸出常包含一節指出哪些步驟可並行處理，雖未被要求，但確實有價值。這類任務能看出 GPT-5.5 的工具使用與代理訓練——規劃行為被塑造成下游會執行的假設。
• Claude Sonnet 4.6：通常產出最「深思熟慮」的計畫——字面意義上。Claude 的計畫常包含另外兩者沒提出的考量。面對此類問題，Claude 可能會提示「相關性 vs 因果性」的方法論問題，指出「未使用 feature X」本身可能是流失症狀而非原因，並明確識別未被說出的限制。缺點是：計畫可能比必要的更長，個別步驟有時對問題過度工程化。這與 Claude 在其他任務上的表現一致——專家級的細緻，有時超出任務所需。
• Gemini 3.1 Pro：通常產出結構最清晰、依賴圖最明確的計畫。推理品質高——Gemini 能可靠辨識隱含約束，將問題拆解為可辯護的序列，並產出可實際執行的逐步指示。缺點：計畫讀起來略顯機械。它完成任務，但較少提出 Claude 所強調的方法論細節，也不像 GPT-5.5 那樣附帶並行化洞見。這符合 Gemini 一般的模式——強在推理品質，在周邊判斷上較為務實工整。

告訴你的事

此任務上三個模型的推理品質都很高。差異在於超出字面請求之外，模型會額外做什麼。GPT-5.5 加入運作上的務實性（並行化、執行提示）。Claude 加入專家級的細緻（方法論、邊界情況、統計細節）。Gemini 則帶來清晰與經濟。這些都不是對錯的問題，而取決於你希望模型在完成你要求的任務後，還能做什麼。

提示 3：具體約束下的程式碼生成

這個提示要求模型實作一個小而不 trivial 的函式：接收帶時間戳的事件列表，回傳相鄰事件之間的最長間隔（秒），並處理四個邊界情況。約束是明確的；意圖是測試在約束下的程式碼生成，而非能力上限——每個模型都能寫出這個函式。不同在於它們如何處理這些約束。

提示

Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases:  1. Empty list (return 0.0 or raise — your choice, but be consistent)  2. Single event  3. Duplicate timestamps  4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.

注意觀察

模型是否處理了四個邊界情況，或默默遺漏其中一些。型別提示是否精確而非樣板。實作是否採用可辯護的演算法（排序後線性掃描）而非奇技淫巧。以及模型是否遵守最後的「不要附測試與用法示例」的限制——這種放在提示末尾的指令，能測出指令遵從能力強的模型是否會遵守，而較弱者是否會悄悄違反。

團隊一再報告的觀察

• GPT-5.5：通常產出工程性最完整的程式碼。四個邊界情況以明確分支處理，型別提示精確（常包含 Optional 或 Union 以涵蓋邊界回傳），並帶有附示例的 docstring。實作通常選擇明顯的演算法——排序、掃描、追蹤最大間隔——而且正確。值得注意：即使提示明確要求只回傳函式，GPT-5.5 常仍會附帶單元測試或用法示例。這是偏向務實的模型的取捨——它會加上自認你接下來會需要的東西，即使你叫它不要。
• Claude Sonnet 4.6：通常產出可讀性最佳的程式碼。函式精簡，邊界情況以頂部的守衛子句（guard-clause）乾淨處理，型別提示精確且最小化。Claude 常會附上一段周到的註解，說明提示未規定的判斷——例如對重複時間戳，視為零長間隔並解釋原因，這是可辯護的選擇。Claude 比起 GPT-5.5 更能可靠地遵守「不要測試」的限制。本身函式最易維護。與 Claude 在程式碼品質上的口碑一致：乾淨、慣用、帶有專家手感。
• Gemini 3.1 Pro：通常產出三者中最精簡的程式碼。函式正確、邊界情況已處理、實作最短。docstring 通常一行。型別提示存在且正確。Gemini 很少加入測試或大量註解，不會過度工程化——這正是提示的要求。對希望拿到可用函式、打算自行加入測試的開發者而言，這是最直接的路。對希望模型也做周邊工作的開發者，另外兩者會給更多（無論你是否要求）。

告訴你的事

三個模型都能寫出該函式。行為差異在於各自會在字面要求之外做多少周邊工作——以及它們對明確「不要加入 X」指示的遵守程度。GPT-5.5 偏向徹底，即使你說可以省略。Claude 偏向工藝（可讀性高的程式碼、對判斷點的周到註解）。Gemini 偏向經濟（只做要求的事，不多不少）。在代理型工作流程中，當模型輸出直接進入生產程式碼庫時，你要的行為取決於下游審查流程的預期——以及你對負向指令的嚴格程度。

演變出的模式

在上述三個提示中，從 2026 年發表的比較研究與開發者回報中，出現了三個一致的行為模式。這些不是能力主張——每個模型在每項任務上的表現都很高水準。它們是傾向，只有當團隊觀察同一模型處理數十個提示時才會顯現。將上述提示在你的環境上跑一遍，你會看到相同模式；本文存在的目的，是幫你建立辨識這些現象的框架與起始提示。

重要但需留意的前提。 這些模式是傾向，不是定律。只要提示得當，每個模型都可以被引導成上述任何一種行為——足夠詳細的系統提示能讓 Gemini 加入測試，或約束 Claude 輸出到極簡，或者讓 GPT-5.5 不產生單元測試。重點在於每個模型的預設行為，也就是在你還沒開始引導之前它會做什麼。預設行為是你在生產中會長期相處的，除非你主動用提示去對抗它。

如何在你的工作負載上測試

上述練習可以在任何工作負載上複製，且應該去做。基準分數作為第一道篩選很有用，但對你的特定應用真正重要的模型行為模式，只有當你看著模型處理你的特定提示時才會顯現。

一個在你自身流量上執行此練習的實用指南：

1. 選三個具代表性的提示類別。不是隨機三個提示——是三個能覆蓋你的工作負載的類別。大多數生產系統可以拆解為少數幾種提示類型（擷取、分類、生成、推理、程式碼、摘要）。挑出佔流量大宗的那些。
2. 每類策劃 20–30 個範例。最好來自真實流量，必要時匿名化。重點是這些提示應該像你的應用實際看到的，而不是像基準測試題。每類 20 個足以看出模式；30 個足以建立信心。
3. 透過單一端點，跑所有模型。相容於 OpenAI 的聚合端點會讓這件事比分別跑各家 SDK 快很多。本文頂部的代碼就是全部設定。相同的溫度、相同參數、相同提示——輸出差異就是模型差異。
4. 先做質性評分，再做量化。在打分前先用眼睛看。行為模式通常在前十來個提示內就很明顯。一旦你對各模型在你的工作負載上的行為形成假說，再依此構造評分規則——但假說應來自觀察，而非事先做好的評分模板。
5. 注意模型「額外做了什麼」。基準問題是模型是否答對。行為問題是它還做了什麼。它有加測試嗎？有解釋推理嗎？有提出顧慮嗎？有產生你沒要求的額外欄位嗎？模型差異就在這裡。
6. 選擇與下游流程匹配的模型。如果你的下游流程是自動化的，你要預設輸出乾淨、可解析的模型。如果你的下游流程是人工審查，你要預設會加入人類審查者想看到的判斷的模型。正確答案取決於模型之後的那一步是什麼。

結語

在 GPT-5.5、Claude Sonnet 4.6 與 Gemini 3.1 Pro 之間的選擇，不是誰最好，而是誰更符合你的工作負載形狀——而基準測試看不見這個形狀。只要你已經準備好提示，以上練習一個下午就能完成；它的價值在於讓你停止猜測，開始觀察。

對自行執行此練習的團隊：最簡易的設定是單一相容於 OpenAI 的端點，讓三個模型都在同一組憑證後面。CometAPI 是一條路；你把現有的 OpenAI SDK 指向另一個 base URL，用 model 參數作為變數即可。配套文章《2026 LLM API 價格比較》涵蓋同一決策的成本面——兩者合併，能提供你做出良好選擇所需的行為與財務全貌。

基準測試告訴你模型能做什麼。行為模式告訴你模型在你的提示上「預設會做什麼」。前者的答案已公開，後者需要你親自觀察。每類 20 個提示，一個下午，你就能得到排行榜永遠無法產生的答案。

準備好可靠整合了嗎？前往CometAPI與API 文件，在同一平台體驗無縫的 Claude Fable 5 與其他前沿模型、統一計費與企業級可靠性。立即註冊，開通新用戶豐厚額度——你的下一個突破專案正等著你啟程。