核心定義：Discovery to Constraints 是將「我們想要 AI」這類模糊客戶陳述，透過結構化探索問法，轉化為可驅動架構決策的精確技術約束清單的顧問工程能力。
大多數工程師聽到客戶說「我們需要 AI」就開始畫系統架構圖。成熟的 FDE 聽到同樣的話，先問五個問題——這五個問題決定了接下來五週的工作方向是否正確。
一、為什麼面試官問這個
面試官真正在評估的，不是候選人對技術的熟悉程度，而是候選人在資訊不完整的情況下是否能有效降低架構風險。建立在錯誤假設上的系統設計，輕則白板畫了兩小時、重則客戶 PoC 做到一半才發現方向錯了，損失 5–10 週工程時間。
- 測試顧問判斷力：FDE 的核心價值在於「問對問題」而非「給快答案」。面試官想看你是否知道在動手設計之前必須先挖掘約束。一個資深 FDE 能在 30 分鐘的 Discovery 會議中確認 10 個關鍵問題，節省客戶 4–6 週的返工成本。
- 區分資淺與資深候選人：弱答案是立刻開始畫系統架構圖，預設客戶規模、合規要求、延遲需求都是「一般水準」。強答案是先提出 SCALE 框架，依序詢問規模、合規、現有架構、延遲、經濟性，再用約束矩陣對比方案，最後才推薦架構。
- 測試風險意識：面試官會觀察候選人是否知道「推薦多區域主動-主動架構給每天只有 1,000 用戶的客戶」是一種顧問失誤，不是技術成就。過度設計浪費客戶預算；設計不足導致上線後系統崩潰。兩者都是 FDE 失職。
弱答案長什麼樣：「我會幫您建一個 RAG pipeline，用 Vertex AI Search 加上 Gemini，支援 HTTPS 加密，部署在 Kubernetes 上，具備自動擴展能力。」（沒問任何約束就給方案，而且可能嚴重過度設計）
強答案長什麼樣：「在我提出架構之前，我需要了解五個維度：規模、合規、現有系統、延遲 SLA、預算。讓我從最高風險的開始問——您的資料有跨境限制嗎？法務是否要求資料必須留在特定區域？這個答案會直接排除幾種架構選項。」
二、核心原理與技術深度
Discovery 問法的本質是約束空間收斂。客戶的初始陳述定義了一個龐大的可能解空間，每一個精準問題都在削減這個空間，直到剩下 1–3 個可行架構選項。
客戶陳述的模糊解空間
┌──────────────────────────────────────────────────────────────┐
│ "我們想要 AI 來處理客戶查詢" │
│ │
│ 規模維度：10 用戶 ───────────────────────────── 10M 用戶 │
│ 合規維度：無限制 ─────────────── HIPAA + PDPA + FSC │
│ 部署維度：公有雲 ──────── 混合雲 ──────── On-premise only │
│ 延遲維度：批次（分鐘）──────────────────── 即時（< 500ms） │
│ 預算維度：$1,000/月 ─────────────────── $100,000/月 │
│ │
│ 可能架構數量：> 200 種組合 │
└──────────────────────────────────────────────────────────────┘
│
每個 SCALE 問題削減 60–80% 的解空間
│
▼
SCALE 探索後的精確解空間
┌──────────────────────────────────────────────────────────────┐
│ 已確認約束： │
│ S: 5K DAU，峰值 50 QPS，12 個月成長 3x │
│ C: 需要 PDPA，資料不出 asia-east1，不需要 CMEK │
│ A: 現有 SAP ERP，REST API，無 On-premise GPU │
│ L: TTFT < 2 秒，可接受串流，批次報表可接受 30 秒 │
│ E: 月預算 $8,000，目標每查詢 < $0.02，優先 Managed Service │
│ │
│ 可行架構：2 個選項 │
│ A: Vertex AI Search + Gemini Flash（$3,000/月） │
│ B: 自建 RAG on Cloud Run + Gemini API（$5,500/月） │
└──────────────────────────────────────────────────────────────┘
SCALE 框架五個維度的技術意涵
每個維度的問題不只是蒐集資訊，更是在排除一整類的架構錯誤：
S ── Scale（規模）
│ 核心問題：DAU vs 並發用戶？峰值 QPS？文件庫大小？成長率？
│ 排除邏輯：
│ DAU < 10K → Cloud Run 足夠，不需要 GKE
│ DAU 10K–500K → GKE Autopilot，水平擴展
│ DAU > 500K → 多區域 + Global Load Balancer
│ 文件 < 100K → pgvector 或 Vertex AI Vector Search 小索引
│ 文件 > 10M → 分散式向量索引，需要 Shard 策略
│
C ── Compliance（合規）
│ 核心問題：資料落地？PII 類型？HIPAA / PDPA / FSC / GDPR？
│ 排除邏輯：
│ 無特殊合規 → 任何區域均可，降低延遲優先
│ 資料落地限制 → 鎖定特定 Region，排除 Multi-region 儲存
│ HIPAA → BAA 協議，Audit Logging 強制開啟
│ CMEK 要求 → Cloud KMS 整合，+$0.003/10K API 呼叫
│
A ── Architecture（現有架構）
│ 核心問題：現有系統？API 標準？On-premise 約束？資料格式？
│ 排除邏輯：
│ SOAP-only API → 需要 API Gateway 轉換層
│ On-premise DB → 需要 Datastream CDC 或 VPN 連線
│ Legacy Auth → 需要 Identity Platform Federation
│
L ── Latency（延遲）
│ 核心問題：用戶端 SLA？TTFT？可接受批次？同步或非同步？
│ 排除邏輯：
│ TTFT < 500ms → 必須串流 + 預載快取，禁用大型模型
│ TTFT < 2s → 串流可選，Gemini Flash 通常足夠
│ 可接受 > 5s → 非串流 Gemini Pro，更高品質輸出
│ 批次可接受 → Batch Prediction API，成本減少 50%
│
E ── Economics（經濟性）
核心問題：月預算？每查詢成本目標？自建 vs 買服務？ROI 週期？
排除邏輯：
預算 < $3K/月 → Vertex AI Search Managed，避免自建維護
預算 $3K–20K/月 → Managed + 部分自訂 RAG
預算 > $20K/月 → 自建完整 RAG，最大化控制與彈性
Make-or-buy → 自建節省成本但需 2 FTE 維護
問題品質的量化差異
弱問題與強問題的差異在於能否直接對應架構決策節點。以下是相同場景下的問法比較：
問題品質對比矩陣
┌──────────────────────────────────┬────────────────────────────────────────┐
│ 弱問題（形容詞型） │ 強問題（數字型 / 二選一型） │
├──────────────────────────────────┼────────────────────────────────────────┤
│ "你們需要什麼功能？" │ "查詢 3 秒 vs 1 秒，會打破業務案例嗎？" │
│ "安全需求高嗎？" │ "法務是否要求資料留在 asia-east1？" │
│ │ "需要 CMEK 還是預設加密就夠？" │
│ "用戶多嗎？" │ "是 10K DAU 還是 10K 並發？架構完全不同" │
│ "需要即時嗎？" │ "TTFT 上限多少？500ms 還是 2 秒？" │
│ "需要高可用嗎？" │ "SLA 是 99.9% 還是 99.99%？差 43 分鐘/月"│
│ "預算夠嗎？" │ "每查詢成本目標是 $0.01 還是 $0.05？" │
│ "有安全合規需求嗎？" │ "是否在 FSC / PDPA / HIPAA 管轄範圍？" │
└──────────────────────────────────┴────────────────────────────────────────┘
強問題的三個設計原則：
- 包含具體數字選項：讓客戶選擇而非填空，降低認知負擔
- 直接對應架構決策點：每個問題的答案能排除至少一個架構方向
- 暗示技術後果：「那會打破業務案例嗎？」讓客戶理解問題的重要性
合規約束的遞進問法
Compliance 是所有維度中排除力最強、改動成本最高的約束。一個合規問題問錯，後期修改代價可高達 6–10 週工程時間。遞進問法從寬到窄逐步確認：
合規約束遞進探索路徑
┌──────────────────────────────────────────────────────┐
│ Level 0：有沒有監管要求？ │
│ "貴公司所在產業有特定資安或隱私監管框架嗎？" │
│ → No：進入 Level 1 快速確認 │
│ → Yes：深入 Level 2 細節 │
└──────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ Level 1：資料落地與分類 │
│ "客戶資料能存在哪些國家的伺服器上？" │
│ "有 PII 嗎？是哪一類？（姓名/身分證/健保號碼）" │
│ → 無落地限制：任意 Region，優化延遲 │
│ → 有落地限制：鎖定 Region，+成本 10–30% │
└──────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ Level 2：加密與稽核等級 │
│ "法務是否要求客戶自管加密金鑰（CMEK）？" │
│ "是否需要 Audit Log 留存？保留幾年？" │
│ → 只需預設加密：無額外成本 │
│ → CMEK：+$0.003/10K API 呼叫，+2 FTE 管理 │
│ → Audit Log 5 年：Cloud Storage Coldline ~$1/GB/年 │
└──────────────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ Level 3：特定框架合規 │
│ HIPAA → BAA 協議 + PHI 不能送 LLM 原文 │
│ FSC（金管會）→ 系統落地台灣 + 源碼留存 │
│ GDPR → 右被遺忘 + DPO 指定 + 72 小時通報義務 │
└──────────────────────────────────────────────────────┘
每個 Level 的回答都能直接排除架構選項，並且確定成本範圍。FDE 在 Level 0 得到「Yes」後，不應在同一個會議中把 Level 1–3 全部問完，而是安排下一輪專門面向法務部門的 Workshop。
約束轉化的精確機制
客戶語言到技術約束的轉化需要語義解碼，FDE 必須在對話中完成這個翻譯：
客戶語言 → FDE 解碼問法 → 技術約束輸出
────────────────────────────────────────────────────────────────────────
"高安全性" → "法務要求 asia-east1？需要 CMEK → 區域鎖定 + Cloud KMS
還是預設加密就夠？" CMEK 成本 +$0.003/req
若只需預設：無額外成本
"很多用戶" → "10K DAU 還是 10K 並發？" → DAU: Cloud Run Min=2
並發: GKE + HPA
差距：成本 3–10x
"即時回應" → "TTFT 上限？500ms？2 秒？ → < 500ms: 串流必要
這決定是否需要串流輸出。" + KV Cache 預熱
< 2s: 非串流可行
節省 ~$800/月架構成本
"資料敏感" → "PII 欄位有哪些？是否需要 → DLP API 前置處理
去識別化後才能送 LLM？" $1/GB，延遲 +50ms
或 Tokenization Proxy
"擴充性強" → "12 個月後預期 QPS 成長幾倍？" → 3x: Cloud Run 夠用
10x: GKE Autopilot
30x+: 需要架構重設計
"國際化" → "用戶在哪些國家？資料能跨境嗎？" → EU 用戶: GDPR 適用
台灣金融: FSC 落地要求
多區域部署成本 2–3x
三、三個實作層次
Layer 1 — 最小可行（Minimal）
適用情境：初次客戶接觸、需求仍在探索階段、1–2 小時的 Discovery Workshop、預算評估前期
做法：
用口頭 SCALE 提問清單，在白板或共享文件上即時記錄客戶回答。不需要特殊工具，只需要一張 5 欄表：Scale / Compliance / Architecture / Latency / Economics。
每個維度問 1–2 個最關鍵問題，共約 10 個問題，目標在 30 分鐘內完成初步約束收集。問題順序按照排除效果從大到小：先問 Compliance（最高風險，排除最多選項），再問 Scale，然後是 Architecture，最後是 Latency 和 Economics。
Discovery Workshop 問題腳本（Layer 1）：
- 「資料有跨境或落地限制嗎？有 HIPAA/PDPA/FSC 等合規要求？」
- 「日活躍用戶預期多少？12 個月後的成長目標？」
- 「現有的核心系統是什麼？用什麼 API 介面？」
- 「用戶能接受等待多久？3 秒 vs 1 秒有差嗎？」
- 「這個解決方案的月預算範圍是？」
產出：一頁口頭確認的約束摘要，用 email 寄給客戶確認，作為後續架構討論的基礎。
限制：沒有系統化記錄格式，容易在多輪溝通中出現誤解；約束清單無版本控制，客戶需求變更時難以追蹤差異。
複雜度：低。無額外工具成本，但後期返工風險較高。
Layer 2 — 生產就緒（Production-Ready）
適用情境：正式 PoC 啟動前、有多個利害關係人參與、需要書面確認、$100K 以上級別專案
做法：
建立約束矩陣文件（Constraint Matrix），格式為結構化試算表，每一行對應一個已發現的約束，每一欄對應一個架構方案：
約束矩陣（Constraint Matrix）完整範例
┌────────────────────┬─────────────────────┬──────────────────┬──────────────────┐
│ 約束項目 │ 約束值 / 來源 │ 方案 A │ 方案 B │
│ │ │ Vertex AI │ 自建 RAG │
│ │ │ Search │ + Cloud Run │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ 資料落地 │ asia-east1 only │ ✓ │ ✓ │
│ │ （法務確認 06-03） │ │ │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ PDPA 合規 │ 必須 │ ✓（内建） │ ✓（需 DLP API） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ PII 去識別化 │ 客戶 ID 欄位 │ ✓（内建 DLP） │ ✓（+$1/GB） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ 峰值 QPS │ 50 QPS │ ✓ │ ✓ │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ TTFT │ < 2 秒 │ ✓（~1.2s） │ ✓（串流 ~0.8s） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ 月預算 │ $8,000 │ ✓（~$3,200） │ ✓（~$5,500） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ 每查詢成本 │ < $0.02 │ ✓（$0.015） │ △（$0.022） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ SAP ERP 整合 │ REST API │ ✓ │ ✓ │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ CMEK │ 非必要（可選） │ ✓（+$2K/月） │ ✓（+$800/月） │
├────────────────────┼─────────────────────┼──────────────────┼──────────────────┤
│ 12 個月擴展 │ 3x 到 150 QPS │ ✓（自動） │ ✓（需調 HPA） │
└────────────────────┴─────────────────────┴──────────────────┴──────────────────┘
✓ = 滿足 △ = 邊界值（需監控） ✗ = 不滿足
推薦：方案 A（Vertex AI Search）— 滿足全部約束，且每查詢成本符合目標
方案 B 的每查詢成本 $0.022 略超目標 $0.02，除非客戶需要更高自訂彈性
矩陣中每一打勾都必須附上估算依據（成本用 Pricing Calculator 驗算，延遲用同類客戶 P95 數據）。
產出：可交付的約束矩陣文件，請客戶 email 確認，作為架構推薦的決策依據。推薦書中直接引用矩陣，讓客戶看到「為什麼選 A 不選 B」是資料驅動的，而非 FDE 的主觀偏好。
複雜度：中。需要 2–4 小時整理，但顯著降低後期返工風險，對 $100K 以上專案 ROI 極高。
Layer 3 — 企業級（Enterprise-Grade）
適用情境：大型企業客戶、多部門利害關係人、正式 RFP 或合約前期、$1M+ 年度合約
做法：
在 Production-Ready 基礎上增加三個機制：
機制一：多輪 Discovery Workshop（按利害關係人分組）
不同利害關係人對同一問題往往有不同答案，甚至互相矛盾。需要分輪訪談再對齊：
Discovery Workshop 多輪結構
┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ 輪一：技術團隊 │ │ 輪二：法務 / 合規 │ │ 輪三：財務 / 採購 │
│ │ │ │ │ │
│ 確認： │ │ 確認： │ │ 確認： │
│ - Architecture │ │ - Compliance │ │ - Economics │
│ - Latency │ │ - 資料分類 │ │ - TCO 接受度 │
│ - Scale │ │ - Audit 要求 │ │ - Make-or-buy │
│ │ │ │ │ │
│ 常見衝突： │ │ 常見衝突： │ │ 常見衝突： │
│ 技術說可以公有雲 │ │ 法務說資料不能出境 │ │ 財務說預算只有 │
│ 法務說不行 │ │ → 排除 Multi-region │ │ 技術說的一半 │
└─────────────────────┘ └─────────────────────┘ └─────────────────────┘
│ │ │
└──────────────────────────┼──────────────────────────┘
│
FDE 彙整對齊衝突
│
▼
最終約束矩陣（含衝突解決記錄）
機制二：約束版本控制
每次客戶需求變更後更新矩陣，保留歷史版本（v1.0, v1.1, v2.0）。當客戶在第三週突然說「我們其實需要支援歐盟用戶」，可以立即顯示哪些約束被打破、哪些架構選項因此被排除，以及架構變更的成本影響。
機制三：假設日誌（Assumption Log）
記錄所有「客戶未明確告知、FDE 自行假設」的項目，在矩陣中標記為「待確認」：
假設日誌（Assumption Log）
┌──────────────────────────┬────────────────────────┬──────────┬──────────┐
│ 假設內容 │ 影響的架構決策 │ 狀態 │ 確認日期│
├──────────────────────────┼────────────────────────┼──────────┼──────────┤
│ 峰值 QPS = 平均 5x │ Cloud Run 最大實例數 │ 待確認 │ - │
│ 文件平均大小 2KB │ 向量索引記憶體估算 │ 已確認 │ 06-05 │
│ 不需要多語言查詢 │ 嵌入模型選型 │ 待確認 │ - │
│ 歷史資料不需要遷移 │ 資料管線設計 │ 待確認 │ - │
│ 用戶都在台灣境內 │ CDN 策略 │ 已確認 │ 06-03 │
└──────────────────────────┴────────────────────────┴──────────┴──────────┘
假設日誌防止隱性假設在架構評審時被當作已確認需求，也保護 FDE 免於因客戶事後否認而陷入責任糾紛。
產出：完整約束矩陣（含版本歷史）+ 假設日誌 + 多輪 Workshop 記錄 + 架構推薦書，可作為合約附件。
複雜度：高。需要 1–2 週的 Discovery 週期，但對於百萬元級別專案，這個投入可以避免六位數的返工成本。
各層次成本與風險對比
Discovery 層次對比
┌────────────────┬──────────────┬────────────────┬──────────────────┐
│ 指標 │ Layer 1 │ Layer 2 │ Layer 3 │
│ │ 最小可行 │ 生產就緒 │ 企業級 │
├────────────────┼──────────────┼────────────────┼──────────────────┤
│ Discovery 時間│ 30 分鐘 │ 4–8 小時 │ 1–2 週 │
│ 工具 │ 白板 / 紙 │ 試算表 │ 試算表 + Wiki │
│ 產出 │ email 摘要 │ 約束矩陣 │ 矩陣+假設日誌 │
│ 版本控制 │ 無 │ 手動 │ Git / Notion │
│ 返工風險 │ 高 │ 中 │ 低 │
│ 適用專案規模 │ < $50K │ $100K–$500K │ $1M+ │
│ 後期變更成本 │ 高 │ 中 │ 低（有記錄） │
└────────────────┴──────────────┴────────────────┴──────────────────┘
四、為什麼選 SCALE 不選其他框架
Discovery 方法有多種，FDE 面試中需要能說明「為什麼用 SCALE 而不用 X」：
選擇 選 SCALE 的理由 不選的理由
─────────────────────────────────────────────────────────────────────────────
SCALE 涵蓋技術決策的全部維度 -
vs 開放式問題 問「你需要什麼？」無法排除架構選項 形容詞答案無法對應技術決策
客戶不知道什麼技術約束重要 容易遺漏合規問題
SCALE 標準化框架，利害關係人容易追蹤 -
vs 臨場即興發問 每次問的問題不同，難以驗證完整性 遺漏 Compliance 概率高
對齊多輪 Workshop 記錄 無法版本控制約束
SCALE 5 個維度可在 30 分鐘內完成初輪 -
vs 完整需求分析文件 需求文件通常需要 2–4 週，啟動太慢 初期資訊不足，文件容易錯
（如 IEEE SRS） 目標是過濾選項，不是描述完整需求 客戶沒有耐心填大型問卷
SCALE 約束矩陣直接對應架構選項 -
vs 用例故事 User Story 描述功能，不描述技術邊界 「身為用戶我想要快」≠ TTFT < 2s
（User Stories） 無法直接排除架構方向 需要額外轉化才能對應技術決策
翻轉條件：當客戶已有明確的技術 RFP 文件時，SCALE 只需用於確認文件中未明確的邊界值（如「高可用」到底是 99.9% 還是 99.99%）；不需要從頭跑完整個框架。當客戶是純技術決策者（如 CTO 直接對話）時，可以省略 Economics 維度的基礎問法，直接討論 TCO 模型。
五、常見錯誤與陷阱
| 錯誤模式 | 後果 | 正確做法 |
|---|---|---|
| 客戶說「安全」就推薦 CMEK | 多付 $2,000/月，客戶法務後來說預設加密就夠了 | 問「法務是否明確要求客戶自管金鑰？CMEK 適用於高度監管環境如金融、醫療」 |
| 把「即時」預設為 < 200ms | 選了昂貴串流架構，客戶其實接受 2 秒，多花 $1,500/月 | 問「TTFT 上限是多少？」讓客戶給數字而非形容詞 |
| 以 DAU 計算並發容量 | 低估 10–100 倍，上線後系統崩潰，客戶在等候 3–4 小時 | 明確區分「日活躍用戶」與「同時在線用戶」，兩者架構完全不同 |
| 跳過 Compliance，假設公有雲即可 | PoC 完成前兩週才發現需要資料落地，整個架構重來損失 6 週 | Discovery 第一個問題就問合規，法務約束影響最大且最難後期修改 |
| 沒問現有系統，設計全新技術棧 | 客戶有 SAP ERP 只支援 SOAP，新架構完全不相容 | Architecture 維度必問「現有系統？API 標準？有 On-premise 約束嗎？」 |
| 約束只靠口頭確認，無書面記錄 | 三週後客戶說「我沒說過那個需求」，責任不清，FDE 被動 | 每次 Discovery 後輸出約束矩陣，請客戶 email 確認，保留書面紀錄 |
| 過度探索，問了 30 個問題 | 客戶失去耐心，認為 FDE 沒有方向感，信任度下降 | SCALE 框架限制在 10–12 個核心問題，其餘在架構設計階段補充 |
六、與其他核心主題的關聯
- Topic 9 — 資料落地與主權 AI：Compliance 維度的問題直接決定是否需要 VPC Service Controls、區域隔離、或 On-premise 部署，是 Discovery 中最高風險的約束類型，回答「需要」會排除 50% 以上的架構選項。台灣金融業（FSC）和醫療業（健保署規範）有明確的落地要求，必須在 Discovery 第一輪就確認。
- Topic 16 — TTFT 與吞吐量最佳化：Latency 維度的問答決定是否需要串流輸出、KV Cache 預熱、或 Speculative Decoding，TTFT 目標從 2 秒改為 500ms 會讓架構成本增加 30–60%，且需要更換模型（Flash → Flash-8B 或更小的蒸餾模型）。
- Topic 10 — CMEK / BYOK 信封加密：Compliance 問題中「是否需要客戶自管金鑰」是 CMEK 的觸發條件，必須在 Discovery 階段確認，後期加入需要重新配置所有 GCS、BigQuery、Vertex AI 的加密設定，工程成本 2–3 週。
- Topic 8 — PII 去識別化：Architecture 維度中確認 PII 類型後，需要評估是否在資料送進 LLM 前先做 DLP API 去識別化，這會增加 50–100ms 延遲和 $1/GB 成本，影響整體 Latency 約束的可行性。
- fde-interview-guide parts 33–38（Production Engineering Gap 分析）：這些部分的面試情境模擬都預設 FDE 已完成 Discovery，約束矩陣是進入架構設計討論的前提，沒有約束矩陣就開始設計等於重蹈弱 FDE 的錯誤。Parts 35–38 的 Mock Scenario 中，面試官給出的客戶描述刻意使用模糊語言，考驗候選人能否主動用 SCALE 框架提問。
七、系統效應：有無 Discovery 的架構結果對比
以下是同一客戶需求（「我們想要 AI 客服」），有無執行 SCALE Discovery 的最終架構結果對比：
效應對比（同一客戶、相同需求描述）
┌────────────────────────┬─────────────────────────┬────────────────────────────┐
│ 指標 │ 無 Discovery（直接設計） │ 有 Discovery（SCALE框架） │
├────────────────────────┼─────────────────────────┼────────────────────────────┤
│ 初期設計時間 │ 4 小時 │ 4 小時 + 30 分鐘 Discovery │
│ 架構選型 │ GKE + 多區域（過度設計）│ Cloud Run 單區域（精準） │
│ 月成本 │ $18,000 │ $3,200 │
│ 合規風險 │ 上線前才發現落地問題 │ Day 1 已確認 │
│ PoC 成功率 │ 40%（方向常需調整） │ 85%（約束已鎖定） │
│ 首次上線後返工比例 │ 60% 案例需重構 │ 15% 案例需小幅調整 │
│ 客戶信任度 │ 低（覺得 FDE 不聽需求） │ 高（覺得 FDE 問到重點） │
└────────────────────────┴─────────────────────────┴────────────────────────────┘
最重要的數字：$18,000/月 vs $3,200/月，差距來自一個 30 分鐘的 Scale 問題沒有問清楚。「高可用」被過度解讀為多區域主動-主動，而客戶實際的 SLA 是 99.9%（單區域 Cloud Run 即可滿足），多花了 $14,800/月，全年 $177,600。
八、面試一句話（Killer Phrase）
「Discovery to Constraints 的核心不是問功能需求，而是問能排除架構方案的邊界條件。我用 SCALE 框架——規模、合規、現有架構、延遲、經濟性——在 30 分鐘內確認 10 個關鍵問題，然後輸出約束矩陣，用矩陣的勾選結果驅動架構推薦，而不是靠直覺。舉例來說，客戶說「需要即時回應」，弱 FDE 直接選串流架構，強 FDE 先問 TTFT 上限——如果答案是 2 秒，標準非串流已經夠用，可以省下約 30% 的月基礎設施成本，大約 $1,500/月。最常見的顧問失誤是跳過 Compliance 問題，等到 PoC 做完才發現客戶的法務要求資料不能出境，這會讓整個架構打掉重練，損失 4–6 週工程時間。建立在精確約束上的架構推薦，才能讓客戶在第一次 PoC 就看到業務價值，而不是在第六週才發現方向錯了。」
系列導航
