對 Gemini 2.5 flash 和 Claude 3.7 Sonnet 模型作為代理引擎的評估。

我在為Ozigi選擇 LLM 時遵循一條簡單的原則：不要根據基準排行榜來選擇。 v2 版本發布後，在收到回饋時，一位使用者建議我使用 Claude 模型，因為它們比 Gemini 模型更適合內容生成。雖然這個建議聽起來很誘人，但我必須根據我的生產流程無法克服的四個限制來選擇模型。

大多數「Gemini vs Claude」的比較都專注於評估通用能力，例如編碼、推理和創意寫作。如果你正在開發一款通用產品，這非常有用。

我不是。

Ozigi 是一個內容引擎。你可以輸入 URL、PDF 或原始筆記。它會傳回一個結構化的 3 天社群媒體行銷活動方案，以 JSON 格式傳回，前端可以直接將其對應到 UI 卡片中。

這種具體性使得評估比我預想的要容易：兩個模型，四個限制條件。其中一個模型在其中三個約束條件下都明顯勝出。

這是Ozigi 更新日誌系列的第三篇文章。如果您想了解 Ozigi 誕生的緣由，請從我最初如何根據直覺編寫出後來成為 Ozigi 的內部工具，以及引入模組化架構的v2 版本更新日誌開始閱讀。

以下是完整的架構決策記錄。

設定：管道實際運作的內容

Ozigi 的核心 API 路由實現了以下功能：

1. 接受包含 URL、原始文字和/或文件（PDF 或圖像）的multipart/form-data有效負載

2. 建立一個帶有嚴格編輯約束的提示，這些約束是在系統層級注入的。

3. 透過Vertex AI Node.js SDK將所有資料傳送到 LLM。

4. 直接將原始文字回應傳回給客戶端。

前端隨後執行以下操作：

const parsed = JSON.parse(responseText);
setCampaign(parsed.campaign);

不使用中間件。不進行模式驗證。正常流程中不進行錯誤復原。直接解析原始資料，並將其寫入 React 狀態。

正是這一個原因，決定了模型的選擇。

限制條件 1：比較 Gemini 模型和 Claude 模型在 JSON 輸出穩定性的差異

要求：模型必須每次都回傳一個有效的 JSON 物件，不能將其包裝在 markdown 程式碼區塊中，不能加上對話式的前言，也不能憑空想像出一個會破壞JSON.parse()尾隨逗號。

目標架構如下圖所示：

{
  "campaign": [
    { "day": 1, "x": "...", "linkedin": "...", "discord": "..." },
    { "day": 2, "x": "...", "linkedin": "...", "discord": "..." },
    { "day": 3, "x": "...", "linkedin": "...", "discord": "..." }
  ]
}

它在三天內跨三個平台發布了九篇帖子，所有字段均為必填項。

使用者介面會將每個欄位渲染成單獨的卡片，並提供編輯、複製和發布操作。如果缺少某個鍵，不會顯示任何可見的錯誤訊息，而是靜默地渲染一張空白卡片。

本次比較專門針對強制執行responseSchema Gemini 和使用提示式 JSON 的 Claude，而非比較各模型的結構化輸出上限。 Claude 使用tool_choice: {type: "tool"}的工具在解碼層強制執行模式，可以達到相同的可靠性。這裡的相關限制在於，我現有的技術堆疊中哪種強制執行機制可用且實用。下文將對此進行更詳細的闡述。

我針對這兩個模型執行了 500 次自動化測試生成，目標是該模式，並測量了JSON.parse()接受而不出現異常的反應百分比。

| 模型 | 格式遵循率 |

|---|---|

| Gemini 2.5 閃光燈 | 99.9% |

|克勞德 3.7 十四行詩（提示） | ~88.5% |

11.5% 的差距直接導致真實使用者遇到介面顯示異常的問題。作為一項核心功能，我無法接受這樣的結果。

使用 Gemini 的responseSchema可以徹底解決這個問題。根據Google 的受控生成文件，該功能會從物理層面阻止模型返回不符合 schema 的輸出。它並非提示層級的指導，而是在解碼層強制執行。以下是 Ozigi 的生產環境實作：schema 在路由頂部定義一次，並直接附加到模型配置中：

const distributionSchema = {
  type: "OBJECT" as const,
  properties: {
    campaign: {
      type: "ARRAY" as const,
      description: "A list of 3 daily social media posts.",
      items: {
        type: "OBJECT" as const,
        properties: {
          day:      { type: "INTEGER" as const, description: "Day number (1, 2, or 3)" },
          x:        { type: "STRING"  as const, description: "Content for X/Twitter." },
          linkedin: { type: "STRING"  as const, description: "Content for LinkedIn." },
          discord:  { type: "STRING"  as const, description: "Content for Discord." },
        },
        required: ["day", "x", "linkedin", "discord"],
      },
    },
  },
  required: ["campaign"],
};

const model = vertex_ai.getGenerativeModel({
  model: "gemini-2.5-flash",
  generationConfig: {
    responseMimeType: "application/json",
    responseSchema: distributionSchema,
  },
});

現在， response.text()的結構保證了其傳回的 JSON 是有效的。 JSON.parseJSON.parse()`不會因為缺少欄位、結尾有逗號或對話式前導語而失敗——模型本身就被阻止產生這些內容。

Claude 的工具使用和函數呼叫也能實現類似的保證，但這需要截然不同的整合架構。而使用 Vertex SDK，只需一個配置區塊即可。

獲勝者：雙子座。

限制條件 2：在公開的即時沙盒環境中比較 Gemini 和 Claude 的延遲

要求： Ozigi 提供免費的、無需身份驗證的沙盒環境。任何人無需註冊即可建立完整的 3 天廣告活動。

這徹底改變了模型選擇的經濟模式。付費高級用戶可以容忍20秒的等待時間，只要輸出品質夠好。但透過我那些古怪的行銷手段找到產品的匿名用戶則不會。他們會在10秒後關閉頁面，而且很遺憾，很可能不會再回來。

我使用 Vercel 無伺服器函數（我的生產環境）對這兩個模型進行了基準測試，輸入有效負載為標準的 10,000 個令牌：

| 模型 | 平均反應時間 |

|---|---|

| Gemini 2.5 閃光燈 | 約 6.2 秒 |

| 克勞德 3.7 十四行詩 | 約 21.5 秒 |

方法：每個模型測試 100 次請求，從 Vercel 函數呼叫到完整回應進行端到端測量。結果受環境影響，僅用於方向性比較，並非絕對基準。

無論有效載荷大小如何，這種差距始終存在。 Gemini Flash 的耗時始終在 10-15 秒以內。而 Claude 3.7 Sonnet 在相同輸入、相同環境下，耗時始終超過 20 秒。

採用串流後，這種延遲差距將顯著縮小：用戶可在 2-3 秒內獲得首批令牌。串流傳輸將徹底改變使用者感知到的等待時間。然而，這是 v4 架構的一個方面，目前正在開發中。對於使用公共沙箱的非串流管道而言，3.5 倍的延遲差異是產品決策，而不僅僅是工程決策。

贏家：Gemini Flash－對於非串流媒體公共沙盒來說，這完全是一場一面倒的競爭。

限制條件 3：比較 Gemini 和 Claude 在原生多模態攝取方面的表現

需求：使用者可以直接上傳 PDF 和圖像作為上下文文件。流程需要無需外部預處理步驟即可處理這些文件。

透過Vertex AI Node.js SDK和 Gemini，整個 PDF 處理流程如下：

// /app/api/generate/route.ts
if (file && file.size > 0) {
  const arrayBuffer = await file.arrayBuffer();
  const base64Data = Buffer.from(arrayBuffer).toString("base64");

  parts.push({
    inlineData: {
      data: base64Data,
      mimeType: file.type, // "application/pdf", "image/jpeg", etc.
    },
  });
}

const result = await model.generateContent({
  contents: [{ role: "user", parts: parts }],
});

可以看到，SDK 以原生方式處理緩衝區。 Gemini 直接讀取 PDF，將其作為多部分請求的一部分與文字提示一起發送——無需 OCR 步驟、預處理或單獨的服務呼叫。谷歌的多模態文件證實，Gemini 從一開始就被設計為透過inlineData原生處理 PDF 和影像緩衝區。

本文早期版本聲稱 Claude 需要外部 OCR 步驟才能匯入 PDF 檔案。這是錯誤的。 Claude 的 Messages API 直接支援透過文件內容區塊匯入原生 base64 PDF 檔案－無需 OCR 預處理，也無需外部服務。其結構與 Vertex AI 的 inlineData 類似，但欄位名稱不同。

真正的限制因素是生態系統，而非功能。我評估了 Claude 3.7 Sonnet，它已在 Google Model Garden 中提供，並且可以整合到我現有的 Vertex AI 環境中。如果切換到 Claude 的原生 PDF 導入功能，則表示要完全遷移到 Anthropic Messages API——不同的供應商、不同的 SDK、不同的計費方式。對我現有的技術棧而言，Vertex AI 的方案更為簡單。

勝出者：Gemini－就此技術棧而言。兩款機型均支援原生多模態資料攝取，無需外部OCR。此次勝出的關鍵在於生態系相容性，而非根本功能差異。

限制條件 4：比較 Google Gemini 和 Claude 在音調工程方面的效能

要求：產生的社群媒體貼文必須聽起來像是人寫的。具體來說，它們必須透過人工智慧內容檢測，並且避免出現容易被辨識為人工智慧生成內容的可預測語調模式。

在這種限制條件下，克勞德憑藉基礎表現就能輕鬆獲勝。

我們對 50 篇技術文章進行了內部盲測 A/B 測試（根據實用的句子結構和是否使用 AI 術語進行評分），結果顯示 Claude 3.7 Sonnet 的「人類語調品質得分」為 9.5/10。 Gemini Flash 的基礎得分為 5.5/10。

這是一個很大的差距。而這正是 Ozigi 的核心價值所在。

為什麼選擇 Gemini 進行音色工程？

因為這個差距是可以人為解決的。

我們建構了禁用字典——一種在系統提示層級注入的程式化約束，它明確地懲罰那些使人工智慧複製行為可被偵測到的詞彙模式。您可以在Ozigi 文件中閱讀完整的實作：

THE BANNED LEXICON: You are strictly forbidden from using the 
following words or their variations: delve, testament, tapestry, 
crucial, vital, landscape, realm, unlock, supercharge, revolutionize, 
paradigm, seamlessly, navigate, robust, cutting-edge, game-changer.

結合明確的節奏設計：

BURSTINESS (CADENCE): Write with high burstiness. Do not use 
perfectly balanced, medium-length sentences. Mix extremely short, 
punchy sentences (2-4 words) with longer, detailed explanations.

PERPLEXITY: Avoid predictable adjectives. Use strong, active verbs 
and concrete nouns. Talk like a pragmatic subject matter expert 
explaining a concept to people, not a marketer selling a product.

FORMATTING RESTRAINT: You are limited to a MAXIMUM of 1 emoji per 
post. Use a maximum of 2 highly relevant hashtags per post.

在這些限制生效後，Gemini 的人類節奏得分從 5.5 躍升至 9.2——在 Claude 的基準 9.5 的可接受範圍內。

關鍵在於：Claude 的音色優勢是一種預設優勢，而非絕對優勢。 Gemini 的輸出在提示限制下更具可塑性。對於以音色控制為核心的產品而言，這種可塑性比更高的基準值更有價值。

勝出者：Gemini + 工程限制。音調方面的差距可以彌合，但其他限制條件下的延遲和 JSON 穩定性方面的差距則無法彌合。

雙子座模型與克勞德模型：成本真相

在 Ozigi 目前仍處於公開沙箱階段的情況下，每次匿名頁面載入都會觸發一次資料生成，而每次載入都會產生一次計費的 API 呼叫，這些呼叫會被產品吸收。 Ozigi 尚未開始盈利，因此這一點至關重要。

| 模型 | 輸入成本（每百萬代幣） | 產出成本（每百萬代幣） |

|---|---|---|

| Gemini 2.5 閃光燈 | 約 0.075 美元 | 約 0.30 美元 |

|克勞德 3.7 十四行詩 | ~$3.00 | ~$15.00 |

定價依據Google Cloud Vertex AI 定價和Anthropic API 定價。

專業提示：在做出生產決定之前，請核實當前的費率——過去一年中，費率和生產費率都多次發生變化。

投入成本相差 40 倍，產出成本相差 50 倍。對於一款沒有收入的免費產品來說，能否持續運作公共沙盒環境，決定了它能否建立轉換漏斗。

Ozigi的未來發展方向以及它將如何改變我未來的模式選擇

這是一份誠實的替代性爭議解決聲明。以下情況會改變我的答案。

當 Ozigi 最終實施付費模式時，延遲和成本就成了次要問題。付費用戶等待 20 秒才能獲得高級輸出，這與免費試用版的匿名用戶截然不同，用戶體驗的考量也大相逕庭。在這種情況下，Claude 的基礎音色品質就顯得更加引人注目了。我願意犧牲一些經濟成本來換取更優質的產出，而這種權衡或許是值得的。

當串流媒體技術實現後，針對 Claude 的延遲問題將顯著減弱。 Claude 3.7 Sonnet 透過串流媒體技術實現的首帖響應時間極具競爭力。用戶在 2-3 秒內看到第一條帖子，與盯著進度條 21 秒的用戶相比，體驗截然不同。串流媒體技術已列入開發計劃。

若要深入了解我們如何測試為這些決策提供資訊的管道，請參閱我們如何使用 Next.js 中的 Playwright 對 AI 代理進行端到端測試。

決策矩陣

| 約束 | 雙子座 2.5 閃光 | 克勞德 3.7 十四行詩 | 優勝者 |

|---|---|---|---|

| JSON 穩定性（反應模式）| 99.9% → 保證 | ~88.5%（提示）| Gemini |

| 延遲（非串流媒體）| 約 6.2 秒 | 約 21.5 秒 | Gemini |

| 原生 PDF/影像導入 | 透過 Vertex SDK 實現原生導入 | 透過 Messages API 實現原生導入 | Gemini（生態系相容性） |

| 低音品質 | 5.5/10 | 9.5/10 | Claude |

| 音質（+限制條件）| 9.2/10 | 9.5/10 | 接近並列 |

| 每百萬個輸入代幣的成本 | 0.075 美元 | 3.00 美元 | Gemini |

雙子座在六個維度中的五個維度上勝出。克勞德在一個維度上勝出——基調——而這個差距可以透過及時的工程調整來彌補。

在為您的代理專案/應用程式選擇LLM模型之前，需要問自己的四個問題

如果你要建立類似 Ozigi 的產品，在選擇 API 並開始建置之前，以下這些限制條件值得考慮：

**1. 你的使用者介面是否依賴結構化輸出？如果你的前端對原始模型回應呼叫了JSON.parse() ，那麼你需要 API 層級的模式強制執行，而不是只提供一些友善的提示資訊。 [Vertex AI 的responseSchema ](https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/control-generated-output)、Claude 的工具配合強制的tool_choice ，或[OpenAI.都在解碼層強制執行模式。問題不在於哪個模型支援它（大多數模型都支援），而是哪種強制執行方案最適合你現有的技術棧。

2. 你們有免費套餐或公共沙盒嗎？如果有，延遲和成本是影響轉換率的產品決策，而不僅僅是影響利潤率的基礎設施決策。

**3. 您的用例是否需要多模態輸入？目前大多數主流模型都支援原生 PDF 和影像導入，無需外部預處理。在考慮是否需要切換或新增基礎架構之前，請先規劃與現有 API 供應商的整合方案。

4. 基礎模型的弱點在哪裡？這種差距可以用工程手段彌補嗎？克勞德的音調優勢是真實存在的。但這並非實現人聲效果的唯一途徑。在提示音層面進行工程調整，可以彌補那些僅憑基礎基準測試難以超越的差距。

最適合你產品的模型很少是綜合得分最高的那個，而是那些在你無法克服的限制下表現最好的模型。

• 完整的 Ozigi 架構（包括產生 API 路由、停用字典實作和頂點 AI 配置）在GitHub上開源。

• 即時情境引擎位於ozigi.app 。

• 此ADR的互動式版本，包含Chart.js對每個基準的視覺化圖表。

• Ozigi 目前正在尋找使用者體驗測試員，希望他們能就使用產品的體驗以及需要改進的地方提供誠實的回饋。

• 我們在Github上有一些未解決的問題，歡迎社區成員貢獻力量。

PS：目前為止，這款應用程式完全是用 Vibe 寫的，因此我們也歡迎大家用 Vibe 寫程式來貢獻內容！

• 在領英上與我聯繫

• 請寄信至 [email protected]。

• 正在打造什麼很酷的東西？在評論區說說吧！

原文出處：https://dev.to/dumebii/gemini-25-flash-vs-claude-37-sonnet-4-production-constraints-that-made-the-decision-for-me-bib