這是 FDE RKK 最常被忽略的題型。
不是考你技術，是考你能不能站在客戶的問題面前，
用他聽得懂、信得過的語言，說清楚為什麼這條路值得走。
說不清楚，再好的架構都沒用。
面試情境
面試官：「你去拜訪一家金融科技客戶，他們的 CTO 開場就說：『我們已經在用 OpenAI GPT-4o，整個團隊很熟悉，工程師也不想換。你能說服我為什麼要考慮 Vertex AI 嗎？』你怎麼回應？」
一、核心錯誤：不要打規格戰
大多數人聽到這個問題，第一反應是拿出比較表：
❌ 錯誤的回應方式：
「Vertex AI 支援 Gemini 1.5 Pro，context window 有 2M token，
比 GPT-4o 的 128K 大很多，而且...」
問題：
├── CTO 不在乎規格，他在乎的是業務風險和遷移成本
├── 規格比較是零和遊戲，你說 A 強，對方說 B 強，沒有結論
└── 即使你贏了規格戰，他還是可以說「那我等 GPT-5 出來再看」
正確框架：從客戶的場景出發，而不是從產品規格出發。
二、FDE 的定位對話框架：SCQA
面對競品比較，用 SCQA（Situation → Complication → Question → Answer） 結構引導對話：
S（Situation）：確認客戶目前的狀況
「您現在用 GPT-4o 主要在跑什麼工作負載？」
C（Complication）：找出他們已有或潛在的痛點
「在這個過程中，有沒有遇到什麼讓你們比較頭痛的地方？
比如成本、合規、延遲，或是跟現有系統的整合？」
Q（Question）：把問題聚焦到一個具體的關鍵問題
「如果把這些問題解決了，對你們的業務影響是什麼？」
A（Answer）：這時候才開始說 Vertex AI 能怎麼幫他
「基於你說的這些，我想跟你分享 Google 在這塊是怎麼做的...」
關鍵：讓客戶先說出自己的問題，你再說解法。
你說的不是「Vertex AI 很好」，而是「你剛才說的問題，Vertex AI 有具體的解法」。
三、金融科技場景的差異化論點
根據客戶場景，有不同的切入角度。金融科技最常觸動的是：
論點 A：資料主權與合規
場景觸發：
客戶說「我們有金融監管要求，資料不能出境」
或「我們的 AI 審計要求越來越嚴」
Vertex AI 的具體優勢：
┌──────────────────────────────────────────────────────┐
│ OpenAI API（Direct） Vertex AI │
├──────────────────────────────────────────────────────┤
│ 資料送往 OpenAI 的美國 資料留在客戶指定的 │
│ 伺服器 GCP Region（如 asia- │
│ east1 台灣節點） │
├──────────────────────────────────────────────────────┤
│ OpenAI 的資料使用政策 Google 不使用客戶資料 │
│ 有使用者需自行確認 訓練模型（BAA 可簽） │
├──────────────────────────────────────────────────────┤
│ SOC 2 Type II SOC 2 + ISO 27001 + │
│ FedRAMP（視需求） │
└──────────────────────────────────────────────────────┘
你給客戶的語言：
「如果你們的資料合規要求是資料不能離開特定地理區域，
直接呼叫 OpenAI API 在架構上就有一個天花板。
Vertex AI 讓你在 GCP 的 Region 邊界內完成整個推理，
這對你們的合規審計報告來說，是可以直接說清楚的架構。」
論點 B：企業整合與 Google Workspace
場景觸發：
客戶說「我們全公司都用 Google Workspace（Gmail, Docs, Drive）」
Vertex AI 的具體優勢：
用戶 → Gmail / Drive / Docs
↓（原生整合）
Google Cloud Identity（IAM / OAuth）
↓
Vertex AI Agent Builder
↓
Gemini（在 GCP 內部）
vs.
用戶 → Gmail / Drive / Docs
↓（需要額外 connector）
OpenAI API（需要自建 auth bridge）
↓（額外 API key 管理）
GPT-4o
你給客戶的語言：
「你們用 Google Workspace，代表員工身分、文件權限都在 Google IAM 裡。
如果 AI Agent 要讀 Drive 上的合約、查 Calendar 排程，
用 Vertex AI 可以直接繼承現有的權限模型，
不需要另外維護一套 OAuth 橋接層。這是一個工程複雜度的問題。」
論點 C：大規模部署的成本控制
場景觸發：
客戶說「我們的 token 用量很大」或「成本是我們的考量」
┌────────────────────────────────────────────────────────────┐
│ 使用量級 OpenAI GPT-4o 估算 Vertex AI Gemini 1.5 Pro │
├────────────────────────────────────────────────────────────┤
│ 1M input $5.00 $3.50 │
│ tokens/月 │
├────────────────────────────────────────────────────────────┤
│ Committed 無長期承諾折扣 CUD（Committed Use │
│ Use Discount）最高 ~60% 折扣 │
├────────────────────────────────────────────────────────────┤
│ 跑在 GCP 無 egress 優化 Vertex AI + GCS + BigQuery │
│ 上的資料 在同一個 VPC，無 egress fee │
│ 傳輸成本 │
└────────────────────────────────────────────────────────────┘
你給客戶的語言：
「如果你們的工作負載是確定性的——每天大概 X 個 request，
Y token 量——我可以幫你們算一個 Committed Use 的方案，
通常比 pay-as-you-go 省 30-50%。這不是規格問題，是採購策略。」
四、如何處理「工程師不想換」
這是最硬的阻力，不是技術問題，是人的問題。
❌ 錯誤：
「Vertex AI 的 SDK 其實很好用，你們工程師學一下就會了。」
（暗示對方工程師的顧慮不重要，或他們能力不夠）
✅ 正確策略：降低遷移成本，而不是說服人換
具體做法：
做法 1：提出「不換，只加」方案
「你們不需要把現有的 OpenAI 工作負載全部遷移。
我們可以先在一個新的 use case 上用 Vertex AI，
讓工程師在真實環境裡評估，而不是抽象比較。」
做法 2：指出 SDK 互通性
from openai import OpenAI
# 只換 base_url，其餘程式碼不變
client = OpenAI(
api_key="YOUR_GOOGLE_API_KEY",
base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
)
# 工程師熟悉的介面照用
response = client.chat.completions.create(
model="gemini-1.5-pro",
messages=[{"role": "user", "content": "Hello"}]
)
「Gemini 支援 OpenAI 相容的 API 格式。
你們工程師熟悉的呼叫方式可以幾乎不動，
只換 endpoint 和 API key。」
做法 3：把決定還給工程師
「我不是要說服你今天就切換。
我想做的是：給你們工程師一個 2 週的 POC 環境，
讓他們親自跑自己的 benchmark。
如果跑完他們覺得沒有差異，那就沒有理由換——
但至少你們有了第一手的數據。」
五、競品對話的禁忌
禁忌 1：說競品的壞話
❌ 「OpenAI 有資料外洩的風險」
✅ 「對於金融業，我們通常會建議評估資料留存地點的合規性」
禁忌 2：在客戶面前說「我們比他們好」
❌ 「Gemini 的能力已經超過 GPT-4o 了」
✅ 「讓我們跑一個你們實際業務的 benchmark，數字說話」
禁忌 3：否定客戶現有的選擇
❌ 「你們用 OpenAI 的架構其實有這些問題...」
✅ 「你們現在跑得怎麼樣？有什麼是希望可以做得更好的？」
禁忌 4：在不了解場景的情況下開始推薦
❌ 第一句話就說「Vertex AI 有哪些功能...」
✅ 先問「你們最主要的 AI 工作負載是什麼？」
六、面試官最想聽到的一句話
這道題面試官真正在測的，不是你知不知道 Vertex AI 的功能清單。
他在測：你能不能讓一個不想被說服的人，願意坐下來做一個 POC？
最後的 CTA（Call to Action）框架：
「基於你剛才說的，我不會請你今天做決定。
我想建議的是：我們花兩週時間，針對你們的
[具體場景：例如合約審閱 Agent]，
在 Vertex AI 上做一個最小可行的 Proof of Concept。
評估標準由你們的工程師定，我來幫你們跑。
如果數字不讓你滿意，你們繼續用 OpenAI，沒有任何損失。
如果數字讓你有興趣，我們再談下一步。」
這個框架的邏輯：
├── 降低客戶決策風險（不要求立刻承諾）
├── 把控制權還給客戶（你們的工程師定標準）
├── 給一個具體的下一步（POC，不是繼續開會）
└── 讓數字說話，而不是你說話
七、快速參考：常見客戶類型與切入點
客戶類型 主要痛點 切入論點
─────────────────────────────────────────────────────
金融 / 醫療 資料合規、審計 資料主權、Region 隔離
要求 BAA 可簽
全 Google Workspace 整合複雜度、工程 原生 IAM 整合
用戶 維護成本 Drive / Gmail 直連
大規模推論用量 token 成本 CUD 折扣、Gemini 定價
同 VPC 零 egress
已有大量 GCP 資源 平台碎片化 統一 billing、單一
（BigQuery / GKE） 管理負擔 Cloud Console 管理
AI 新手客戶 不知從哪裡開始 Vertex AI Agent Builder
（無 AI 工程師） 低程式碼，快速上線
這道題的答案永遠不是規格表。
是：先聽懂客戶的問題，再用他的語言說清楚 Google 能解決什麼。
