OpenAI、Google Gemini、xAI Grok 到底差在哪？先學會分清楚公司、模型、App 與 API

AI 世界最容易讓新手混亂的地方之一，是同一家公司常同時有：

• 公司名稱
• 模型家族
• 具體模型
• 聊天 App
• API
• Coding Agent
• 圖片 / 語音 / 影片服務

所以你會聽到：

OpenAI
GPT
ChatGPT
Codex
OpenAI API

也會聽到：

Google
Gemini
Gemini App
Gemini API

以及：

xAI
Grok
Grok API

如果全部混成「那個 AI」，後面談價格、能力、資料流向與工具支援時就很容易講錯。

先記住五層

可以先用這張圖：

公司 / Provider
↓
模型家族
↓
具體模型版本
↓
產品 / App
↓
API / 開發介面

這不是每家公司都完全照同一結構，但很適合建立基本方向感。

第一層：Provider 是誰？

供應商（Provider） 就是提供模型或 AI 服務的公司 / 平台。

例如：

• OpenAI
• Google
• xAI

Provider 決定很多外部條件：

• API 認證方式
• 可用模型
• 計價方式
• 地區與帳號限制
• Tool / Function Calling 規格
• 速率限制
• 服務條款

所以你在寫 App 時，常常先選 Provider，再選它下面的模型。

第二層：Model Family

模型家族（Model Family） 是一系列有共同品牌或技術血統的模型。

例如 GPT、Gemini、Grok 都可以被理解成模型品牌 / 家族名稱。

但「Gemini」不一定只代表一個固定模型；「GPT」也不是永遠只有一個版本。

因此看到文章寫：

我用 GPT

對工程問題來說常常不夠精確。

更重要的是：

到底是哪個具體模型、哪個日期、透過哪個介面使用？

第三層：Specific Model

供應商會在模型家族下推出不同模型。

它們可能針對：

• 速度
• 成本
• Reasoning
• Coding
• Context
• Multimodal
• Tool Calling

做不同取捨。

而且模型名稱更新很快。

所以 SATIN SYNTAX 這篇刻意不做「2026 永久排行榜」。

真正要學的是看官方文件中的：

• Model ID
• Input / Output modality
• Context limit
• Tool support
• Structured Output
• Pricing
• Deprecation / lifecycle

這些才是你寫程式時真正會用到的資訊。

第四層：App 不等於 API

Lesson 018：API 已經講過：API 是讓程式用規格化方式呼叫服務的介面。

聊天 App 則是給人直接使用的產品介面。

例如你在網頁或手機 App 裡聊天，產品可能幫你加上：

• System Instructions
• Memory
• File Handling
• Search
• UI
• Safety Layer
• Tool Integration

而 API 使用者通常要自己決定更多應用層行為。

因此：

同一家公司的聊天 App 行為
≠
直接 API 呼叫一定得到完全相同行為

這個差異之後做實驗、Benchmark 或 Agent 時非常重要。

OpenAI：公司、GPT、ChatGPT、Codex 不要混在一起

可以先這樣分：

OpenAI = 公司 / Provider
GPT = 模型家族名稱之一
ChatGPT = 面向使用者的產品
Codex = Coding Agent / 開發產品線之一
OpenAI API = 開發者呼叫模型與相關能力的介面

Lesson 033：Cursor、Codex 已經講過 Coding Agent：它不只是模型，而是模型 + 指令 + 工具 + 執行環境。

所以「Codex」不能簡單理解成「某一顆 GPT 模型的另一個名字」。

Google Gemini：品牌也同時跨模型與產品

Google 的 Gemini 名稱也會出現在多個層次。

你可能看到：

• Gemini 模型
• Gemini API
• Gemini 使用者產品
• Google AI Studio

對開發者來說，最重要的是回到官方 Gemini API 文件確認目前支援：

• 哪些 Model ID
• Function Calling
• Structured Output
• Multimodal Input
• API 格式

例如 Google 的 Function Calling 文件明確區分：模型可以產生 Function Call 的名稱與參數，但真正執行 Function Code 是你的應用程式責任。

這和 Lesson 020 的 Tool Calling / Agent 是同一個核心概念。

xAI 與 Grok

同樣可以先分：

xAI = 公司 / Provider
Grok = 模型 / 產品品牌
xAI API = 開發介面

當你在程式裡看到 Grok Model ID，實際能用哪些能力、Context、Tool 與價格，都應以當下 xAI 官方文件為準。

為什麼不要問「哪家最好？」就結束？

因為「最好」缺少任務。

你真正可能在問：

• 哪個 Coding 表現比較適合我？
• 哪個 Latency 比較低？
• 哪個 API 比較便宜？
• 哪個支援某個 Tool？
• 哪個能處理圖片 / 音訊？
• 哪個資料治理符合公司要求？

不同答案可能不是同一個 Provider。

寫程式時最重要的是 Model ID

概念上 API Code 常有類似：

model = "provider-model-id"

這一行的作用是：

告訴 Provider 這次 Request 要由哪個模型處理。

不要只看 App UI 上顯示的市場名稱，就假設 API Model ID 一模一樣。

實際值要看官方 API 文件。

API Key 千萬不要寫死在程式裡

很多 SDK 範例都需要 API Key。

錯誤示範：

api_key = "sk-your-real-secret-key"

如果這支程式被 Lesson 027 的 git push 推到公開 GitHub，Key 可能直接外洩。

比較常見做法是用環境變數（Environment Variable）：

import os

api_key = os.environ["OPENAI_API_KEY"]

這段在做什麼？

import os

載入 Python 的作業系統介面工具。

os.environ["OPENAI_API_KEY"]

從目前 Process 的環境變數讀取名為 OPENAI_API_KEY 的值。

程式不需要把祕密直接寫在 Source Code。

同樣概念也可以用在其他 Provider 的 Key。

.env 和 .gitignore 為什麼常一起出現？

很多開發流程會把本機祕密放進：

.env

然後在：

.gitignore

加入：

.env

作用是告訴 Git：這個檔案不要被正常追蹤與 Commit。

但注意：

如果 Secret 已經被 Commit 過，再加 .gitignore 不會把歷史裡的 Secret 自動消失。

這時通常要立即撤銷 / Rotate Key，並處理 Git 歷史與安全事件。

Provider SDK 只是包裝 API

你可能看到：

from openai import OpenAI

或：

from google import genai

SDK（Software Development Kit）可以先理解成 Provider 提供給開發者的程式工具包。

它幫你：

• 組 Request
• 處理認證
• 解析 Response
• 提供 Type / Helper

底層仍是在和 Provider 的服務介面溝通。

OpenAI、Gemini、Grok 可以同時存在一個 App 嗎？

可以。

你的程式可以根據需求切換 Provider。

例如：

Coding → Provider A
圖片理解 → Provider B
低成本大量分類 → Provider C

但多 Provider 也會增加：

• API 格式差異
• Error Handling
• 成本追蹤
• Prompt 行為差異
• Safety Policy 差異

這也是為什麼 Lesson 032：LangChain 這類 Framework 會提供統一模型介面的抽象。

一句話帶走

OpenAI、Google、xAI 是 Provider；GPT、Gemini、Grok 是模型 / 品牌家族；聊天 App、Coding Agent 與 API 又是不同產品層。先把層次分清楚，再比較模型能力、價格與工具支援，才不會把整個 AI 生態混成一個名字。