這篇的用法：
每個情境，先蓋住「模範答案」，自己練習說 2-3 分鐘，
再對照模範答案看哪裡說得不夠深。
不要只用眼睛「讀」，要用嘴巴「說」——面試是口頭表達，不是閱讀測驗。
如何使用這個情境庫
每個情境的結構：
客戶場景 → 你收到的原始問題
隱藏的限制條件 → 面試官設計的陷阱，你要靠「問問題」發現它
追問鏈 → 面試官會按這個順序追問（難度遞增）
模範答案架構 → 拿到 3-4 分的回答應該包含什麼
最常見失分點 → 哪些地方最多人在這個情境答錯
情境一：金融科技客服 Agent（RAG + 合規限制）
客戶場景
客戶：一家有 200 萬用戶的數位銀行
背景：客服團隊有 50 人，每天處理 30,000 個 ticket
60% 是重複性的 FAQ（帳戶查詢、匯款規則、費率說明）
客戶希望用 AI 自動處理 FAQ，讓人工客服專注複雜問題
面試官說：「請設計這個 AI 客服系統。」
隱藏的限制條件（要靠問問題才能發現）
如果你問到「有沒有合規要求？」→ 面試官說：
「是的，這家銀行受金融監管，所有客戶資料不能離開台灣。」
如果你問到「不同客服問題的差異？」→ 面試官說：
「有一類問題是個人帳戶查詢（需要驗證身分），
另一類是一般 FAQ（不需要身分驗證），兩類要分開處理。」
追問鏈（難度遞增）
Q1：「你的 RBAC 設計是在哪個環節做過濾？為什麼？」
Q2：「客戶資料不能出台灣，你的 Vertex AI 呼叫怎麼設計？」
Q3：「AI 回答了一個帳戶問題，但答案是錯的。客戶打電話來投訴。
你的系統有什麼設計可以讓這個問題可以追溯？」
Q4：「這個系統的月成本大概是多少？客戶的 CFO 要看一個數字。」
Q5（顧問題）：「客戶的法遵長說，所有 AI 的回答都必須有人工審核才能發出。
你怎麼處理這個需求？」
模範答案架構
釐清需求（問兩個問題）：
「在開始設計前，我想確認兩件事：
第一，這個系統有合規要求嗎？資料能放在 GCP 嗎，還是有地理限制？
第二，個人帳戶查詢和 FAQ 查詢，處理邏輯有沒有不同？」
→ 拿到：台灣 region 限制 + 兩類問題的分流需求
架構設計：
「我的架構分三層：
第一層：API Gateway + 身分驗證
用 Google Cloud Identity 驗證用戶身分，
區分「已驗證用戶的帳戶查詢」和「匿名 FAQ 查詢」兩條路徑。
第二層：Router
帳戶查詢 → CRM Tool（只讀，帶用戶 token）
FAQ 查詢 → RAG Pipeline（查知識庫）
兩者的 LLM 回答都會帶 citation（引用了哪個文件或哪個帳戶欄位）
第三層：Compliance Layer
所有 Vertex AI 呼叫限定 asia-east1（台灣節點）
用 VPC Service Controls 確保資料不出 Region
每個 AI 呼叫記錄到 Cloud Audit Logs」
追問回答：
Q1（RBAC）：
「RBAC 在查詢向量 DB 時就過濾，不是查完再過濾。
Post-filter 可能讓 Top-K 全被過濾掉，LLM 拿到的 context 品質不穩定。
Pre-filter 讓向量搜尋只在用戶有權限的文件空間裡進行。」
Q3（可追溯）：
「我的設計是：每個 AI 回答都帶一個 response_id，
response_id 對應到 Cloud Logging 的一筆記錄，
記錄了：哪個 query、查了哪些文件、LLM 的完整 prompt 和 response。
如果客戶投訴，工程師可以用 response_id 還原完整的推理過程。」
Q5（法遵長要人工審核）：
「這個需求讓系統的設計發生根本性的改變——
它把『即時回答』變成了『非同步審核後回答』。
我的回應是：先問法遵長，審核的頻率和範圍是什麼？
是 100% 審核還是抽查 5%？
如果是抽查，可以設計一個 Shadow Mode——
AI 即時回答用戶，但所有回答存到 Review Queue，
法遵團隊異步審核，有問題時 flag 並觸發系統改善。
如果真的需要 100% 人工審核才發出，
我會和客戶討論這是否符合用戶體驗的預期——
因為這意味著回應時間從秒級變成小時級。」
最常見失分點
❌ 沒有問「資料合規要求」→ 設計出來的架構不能上線
❌ RBAC 做 post-filter，被追問後說不清楚為什麼不對
❌ 顧問題只說「這樣做技術上可行」，沒有說「我會和客戶討論 UX 代價」
情境二：保險公司理賠審核 Multi-Agent（ADK + 並行執行）
客戶場景
客戶：台灣前三大保險公司
背景：人工理賠審核需要查三個系統（核保資料庫、醫療記錄、詐欺偵測），
每個 case 平均需要 3 小時，目標是降到 15 分鐘
客戶已在 GCP 上有所有三個系統的 API
面試官說：「請設計這個 AI 理賠審核系統，並告訴我你的 ADK 架構。」
隱藏的限制條件
如果你問「高風險或不確定的 case 怎麼處理？」→ 面試官說：
「理賠金額超過 500 萬的 case，最終決定必須有人工審核。」
如果你問「三個系統的延遲分別是多少？」→ 面試官說：
「核保 DB 200ms，醫療記錄 800ms，詐欺偵測 1.5 秒。」
追問鏈
Q1：「你為什麼選 ADK 而不是 LangGraph？這個場景有什麼特性支持你的選擇？」
Q2：「三個系統的延遲是 200ms、800ms、1.5 秒。你的並行設計，
整個 pipeline 的 P95 延遲大概是多少？」
Q3：「ADK 的 Session State，這個 case 的中間結果要存在哪個 scope？為什麼？」
Q4：「詐欺偵測系統突然掛掉了。你的 Agent 怎麼處理？」
Q5（顧問題）：「系統上線一個月後，客戶發現 AI 的誤判率（把詐欺 case 放行）
是 3%，比人工的 1% 高。你怎麼回應客戶？」
模範答案架構
ADK 架構選擇：
「我選 ADK 因為三個原因：
第一，客戶在 GCP，ADK 原生整合 Vertex AI，部署到 Agent Engine 省掉 Infra 配置。
第二，這個工作流的結構清楚——並行查三個系統 + 決策——
ADK 的 ParallelAgent + LlmAgent 直接對應，不需要從頭設計控制流程。
第三，Client 沒有 AI 工程師，ADK 的 boilerplate 少，維護成本低。
如果這個流程需要和非 Gemini 模型混用，我才會考慮 LangGraph。」
ADK 架構設計：
「最外層是一個 SequentialAgent，兩個步驟：
Step 1：ParallelAgent，三個 LlmAgent 同時執行：
policy_agent → 查核保 DB → 寫入 session:policy_result
medical_agent → 查醫療記錄 → 寫入 session:medical_result
fraud_agent → 跑詐欺偵測 → 寫入 session:fraud_score
Step 2：decision_agent（LlmAgent），
讀取三份 session state，用 Gemini Pro 做最終決策。
如果理賠金額超過 500 萬 → 呼叫 require_human_approval Tool，
暫停 Agent，等審核人員在 5 分鐘內確認。
超時未確認 → 降級到人工處理隊列，記錄 case。」
延遲回答（Q2）：
「並行執行的瓶頸是最慢的那個——詐欺偵測 1.5 秒。
加上 decision_agent 的 LLM 呼叫約 1-2 秒，
總 pipeline 約 3-3.5 秒，目標的 15 分鐘輕鬆達成。
如果詐欺偵測 timeout（例如超過 3 秒）有一個 fallback：
先輸出『詐欺評分待確認』的中間結果，
異步補跑詐欺偵測後更新審核結論。」
顧問題回應（Q5）：
「3% 誤判率和 1% 的人工差距，我的第一個問題是：
這 3% 的誤判，是哪種類型的 case 出錯的最多？
是詐欺評分模型的問題，還是 decision_agent 的 Prompt 問題？
我不會承諾立刻降到 1%——這需要更多資料分析。
我的建議是：在接下來 2 週，把所有誤判的 case 拿出來，
看 fraud_score 的分佈——是 AI 打了低分但還是放行，
還是詐欺偵測系統本身準確率就只有這樣？
如果是前者，調整 decision_agent 的判斷閾值可以快速改善。
如果是後者，是詐欺偵測系統的問題，不是 AI 的問題——
那這個 3% 不是 AI 造成的，是原系統的既有問題。
這個區分對客戶的後續決策很重要。」
最常見失分點
❌ 選了 ADK 但說不出為什麼不選 LangGraph
❌ 沒有做並行設計，用 Sequential 跑三個系統（延遲 200+800+1500=2500ms）
❌ Session State scope 沒有想清楚，把敏感醫療資料存到 user: scope
❌ 顧問題只回答「我來優化模型」，沒有先分析誤判的根因
情境三：醫療機構臨床文件助理（VPC 隔離 + Self-Reflection）
客戶場景
客戶：一家擁有 5,000 位醫師的大型醫療集團
背景：醫師每天要看 30-50 份病歷，想要 AI 幫助摘要和提取關鍵資訊
病歷含有大量 PII（姓名、身份證、診斷）
客戶的 IT 政策：「所有病歷資料不能上雲。」
面試官說：「請設計這個系統。你的資料安全設計是什麼？」
隱藏的限制條件
如果你進一步問「『不能上雲』指的是什麼？」→ 面試官說：
「IT 的解釋是：原始病歷資料不能傳送到 Google 的伺服器。
但他們已經在用 Google Workspace，而且願意評估 GCP。」
追問鏈
Q1：「病歷摘要偶爾會有錯誤——提取了不存在的診斷。
你怎麼在架構上減少這個問題？」
Q2：「你說資料要留在醫院的 VPC，但 Vertex AI 的 Gemini API 呼叫怎麼設計？」
Q3：「一份病歷 20,000 字，超過了你的 context window。你怎麼處理？」
Q4：「PII 的處理，你在架構的哪個位置做 Tokenization？為什麼？」
Q5（顧問題）：「醫師說 AI 摘要有時候漏掉了很重要的用藥紀錄。
這對病患安全有影響。你怎麼回應這個風險？」
模範答案架構
釐清「不能上雲」的定義（關鍵第一步）：
「IT 說資料不能上雲，我想先確認這個限制的範圍。
是原始病歷資料，還是也包括匿名化後的資料？
是不能傳送到 Google 的任何服務，還是在 GCP 的特定 Region 是可以接受的？」
→ 拿到：原始資料不出去，但 GCP 的 VPC 內部是可以的
架構設計：
「我的設計有兩層隔離：
第一層：PII Tokenization（在院內完成）
病歷進入 AI Pipeline 之前，院內的 Cloud DLP 服務
把所有 PII（姓名→P001、身份證→ID001、診斷→D001）替換成匿名 token。
原始 PII 和 token 的對應表存在院內的加密 DB，不出院外。
第二層：VPC Service Controls + Private Service Connect
Tokenized 病歷傳送到 GCP 的 asia-east1 Region，
透過 Private Service Connect 呼叫 Vertex AI Gemini API，
整個路徑不經過公共網路。
VPC-SC Perimeter 確保資料不能從 VPC 外部存取。
AI 回答生成後，再把 token 替換回原始 PII，
結果只顯示在院內的顯示層，不存儲在 GCP 上。」
Self-Reflection（Q1）：
「提取不存在的診斷是典型的幻覺問題。
我設計 Generator-Evaluator 架構：
Generator Agent 先生成摘要，
Evaluator Agent（不同的 System Prompt，扮演嚴格的醫療審查者）
比對摘要和原始病歷，找出不一致或無法驗證的描述，
回饋給 Generator 修正。
最多迭代 2 次，2 次後仍有 flag 的項目標記為『需要醫師確認』。」
顧問題回應（Q5）：
「漏掉用藥紀錄是高風險的問題，我不會輕描淡寫。
我的第一個回應是：立刻加一個『用藥紀錄』的 mandatory check——
在每份摘要生成後，強制執行一個驗證步驟：
對照原始病歷，確認所有藥物名稱都出現在摘要裡。
這不依賴 LLM 判斷，是規則式的比對，不會有幻覺。
同時，我會建議客戶在這段時間採用『AI 輔助』而不是『AI 決策』——
AI 生成摘要，醫師在確認前 review，而不是直接信任。
這個問題的根本解決需要更多 case 分析和 Eval Pipeline，
不是今天能立刻修好的。
但規則式用藥比對可以今天就上線，把最高風險的問題先擋住。」
最常見失分點
❌ 沒有問清楚「不能上雲」的具體含義，直接說「只能用 On-premise 部署」
❌ PII 處理放在 GCP 端（應該在院內完成 Tokenization 再出去）
❌ 顧問題只說「我來修 bug」，沒有提「先用規則式比對擋住最高風險」
❌ 20,000 字病歷沒有提 Map-Reduce 或 Parent-Child chunking
情境四：零售業即時推薦 Agent（Scale + Cost + GKE）
客戶場景
客戶：東南亞最大的電商平台之一
背景：每日活躍用戶 2,000 萬，每秒峰值 50,000 queries
目前的推薦系統是規則式的，轉換率低
希望用 LLM 生成個性化推薦理由，提升轉換率
工程團隊強，有自己的 ML 工程師
面試官說：「設計這個 AI 推薦系統，以及你怎麼讓它在這個規模下運行。」
隱藏的限制條件
如果你問到 Latency 要求 → 面試官說：
「推薦需要在 200ms 內完成，用戶才不會感覺到延遲。」
如果你問到 Budget → 面試官說：
「工程主管說 LLM 的成本不能超過現在推薦系統的 3 倍。」
追問鏈
Q1：「200ms 的限制，你怎麼實現？直接呼叫 Gemini API 的 P95 大概是 1-2 秒。」
Q2：「LLM 成本不能超過 3 倍，你怎麼控制？50,000 QPS 的規模，token 成本怎麼算？」
Q3：「你的系統要部署在哪裡？Cloud Run 行嗎？」
Q4：「推薦品質如何評估？Offline 指標和 Online 指標你用哪個？」
Q5（顧問題）：「上線兩週後，轉換率上升了 2%，但 LLM 成本超出預算 40%。
你怎麼辦？」
模範答案架構
架構設計：
「這個規模的 LLM 推薦系統，不能每個 query 都即時呼叫 LLM——
200ms 的延遲要求 + 50,000 QPS = 不可能同步呼叫 Gemini API。
我的設計是預計算（Pre-computation）架構：
離線階段（每小時執行一次）：
對 Top-10,000 個熱門商品 × 主要用戶 Persona（100 個）
預先生成推薦理由文字 → 存入 Redis Cache
即時階段（用戶 query 時）：
先從現有推薦系統拿到候選商品列表（快，毫秒級）
對每個商品查 Redis Cache 取推薦理由（1-5ms）
組合成個性化推薦頁面 → 200ms 以內完成
對沒有預計算理由的長尾商品：
顯示通用推薦理由（規則式），不呼叫 LLM
這部分商品的曝光量不高，對整體指標影響小」
成本控制（Q2）：
「預計算架構讓呼叫量從 50,000 QPS 降到 10,000 商品 × 100 Persona = 100 萬次/天。
和 50,000 QPS × 86,400 秒 = 43 億次/天 相比，
成本降了 4,000 倍以上。」
部署（Q3）：
「Cloud Run 不適合這個規模：
50,000 QPS 在 Cloud Run 的冷啟動和實例管理上會有問題，
而且 Redis Cache 的高頻讀寫需要低延遲網路連接。
我選 GKE——Deployment + HPA（Horizontal Pod Autoscaler），
根據 QPS 自動擴縮容，Redis 部署在同一個 VPC 的 Cloud Memorystore。」
顧問題（Q5）：
「成本超 40% 是因為預計算的範圍設太廣，
或者 LLM 呼叫的 token 數比預估高。
第一步：看成本分佈——哪 20% 的商品造成了 80% 的成本？
通常是長尾商品被過度預計算了。
解法：只對 Top-1,000 熱門商品做 Gemini Pro 預計算，
其他商品改用 Gemini Flash（成本低 5 倍），
或者用規則式文字模板。
目標：把成本壓回 2 倍以內，同時保留 Top 商品的 AI 推薦品質。」
最常見失分點
❌ 設計了即時 LLM 呼叫但沒有考慮 200ms 限制
❌ 成本計算沒有量化（「用 Flash 應該比較便宜」不夠）
❌ 選了 Cloud Run 但說不出為什麼不適合高 QPS 長連接
❌ 顧問題只說「優化 Prompt 降低 token」，沒有分析成本來源
情境五：政府機關法規查詢系統（On-premise 限制 + Vertex AI Search vs DIY RAG）
客戶場景
客戶：某部會的數位轉型辦公室
背景：公務員每天需要查詢數千份法規文件，目前用關鍵字搜尋
希望升級為自然語言問答
IT 規定：「所有系統必須部署在政府的私有雲（On-premise），不能使用公有雲。」
面試官說：「你怎麼設計這個系統？在這個限制下，你的 Vertex AI 和 GCP 還能用嗎？」
隱藏的限制條件
如果你進一步問 IT 限制的細節 → 面試官說：
「其實他們有一個政府私有雲，基礎設施是和 Google Cloud 合作建的
（類似 Google Distributed Cloud），
可以使用 Vertex AI 的部分功能，但資料不能到公共 GCP。」
追問鏈
Q1：「你會選 Vertex AI Search 還是自建 RAG？為什麼？」
Q2：「法規文件有版本問題——同一個法規可能有 2020 版和 2023 版。
你的 RAG 系統怎麼設計來處理版本問題？」
Q3：「公務員問了一個問題，但這個問題的答案跨越三個不同的法規文件，
而且三個文件的說法有輕微矛盾。你的系統怎麼處理？」
Q4：「如何評估這個系統對公務員工作效率的實際影響？」
Q5（顧問題）：「系統上線後，有公務員說某個法規問答的答案和他記憶中的不一樣，
但其實是他記錯了。他向長官投訴說 AI 不可信。
你怎麼處理這個溝通問題？」
模範答案架構
「On-premise」的邊界釐清（第一件事）：
「在開始設計前，我需要先確認這個 On-premise 限制的具體邊界。
是完全不能用 Google 的任何服務，
還是他們有 Google Distributed Cloud 這類的私有部署方案？
這個答案完全決定了我能用哪些工具。」
架構選擇（基於 GDC 可用）：
「在 Google Distributed Cloud 環境下，我選自建 RAG 而不是 Vertex AI Search。
原因是這個場景對 Retrieval 的精準度要求極高——
法規查詢的錯誤代價很高，需要能深度控制 Retrieval 邏輯。
Vertex AI Search 的搜尋邏輯是 black box，
如果準確率不達標，我沒有辦法 debug。」
版本問題（Q2）：
「每份文件的 metadata 包含 version_date 和 status（現行/廢止）。
向量 DB 的查詢加上 metadata filter：
where status == 'current' 或 where version_date == '2023'
同時建立一個版本對照表——當查詢到舊版法規時，
系統自動提示『此法規已於 2023 年修正，以下為最新版本』。」
矛盾文件（Q3）：
「三個文件說法不同時，不應該讓 LLM 自行決定哪個正確。
我設計一個矛盾偵測機制：
Generator 生成回答後，Evaluator Agent 檢查答案和三份文件的一致性，
如果發現矛盾，強制輸出格式變成：
『三份相關法規在這個問題上存在不一致之處。
文件 A 說 X，文件 B 說 Y，文件 C 說 Z。
建議諮詢法律顧問確認適用的法規版本。』
不做決策，把判斷責任還給人。」
顧問題（Q5）：
「這個投訴的核心不是技術問題，是信任問題。
我的處理方式有兩步：
短期：讓系統自動附上 Citation——
每個回答後面列出「依據法規：XX 法第 Y 條」，
讓公務員可以自己點開原始文件確認。
這樣之後再有人說答案不對，
他能看到 AI 的答案有法律依據，他可以決定要不要相信。
長期：請客戶的法規專家評估前 50 個最常見問題的回答品質，
建立一個官方認可的 QA 資料集。
這個資料集既是 Fine-tuning 的素材，也是對外溝通的公信力依據：
『這個系統的回答已經由 X 部法規專家審核 50 個標準問題，
準確率 Y%。』」
最常見失分點
❌ 聽到「On-premise」就直接放棄 GCP，沒有問是否有 GDC 選項
❌ 版本問題沒有設計 metadata filter
❌ 矛盾文件讓 LLM 自行決定哪個正確（高風險設計）
❌ 顧問題只說「加強技術」，沒有認識到這是信任問題，需要溝通策略
情境六：教育 SaaS 平台 AI 導師（Multi-turn + Memory + 成本）
客戶場景
客戶：一家有 50 萬學生用戶的線上教育平台
背景：學生在學習過程中可以問問題，目前是真人導師回答（反應慢、成本高）
希望用 AI 導師處理 80% 的問題，讓真人專注複雜問題
學生可能和 AI 導師有幾十輪對話，討論同一個學習主題
面試官說：「設計這個 AI 導師系統，特別說明你的 Memory 設計。」
隱藏的限制條件
如果你問到「學生的資料是否敏感？」→ 面試官說：
「有大量未成年學生，資料保護要求嚴格，不能存儲任何可識別個人的學習記錄到第三方。」
如果你問到成本 → 面試官說：
「每個學生每月平均 200 輪對話，月費只有 150 台幣，LLM 成本要控制在月費的 15% 以內。」
追問鏈
Q1：「一個學生和 AI 導師聊了 50 輪，context 怎麼管理？」
Q2：「你設計的 Memory 系統，如何確保不同學生的資料完全隔離？」
Q3：「學生問了一個超出課程範圍的問題（例如問政治或宗教）。
你的系統怎麼處理？」
Q4：「月費 150 台幣，LLM 成本要在 15% 以內，也就是約 22 台幣。
你的 Token 預算怎麼設計？」
Q5（顧問題）：「一位家長投訴說 AI 導師給了他孩子一個數學公式的錯誤答案，
孩子考試因此失誤。你怎麼回應？」
模範答案架構
成本計算先行（這題成本是核心設計 constraint）：
「22 台幣 / 200 輪對話 = 每輪對話 0.11 台幣 ≈ $0.003 USD。
用 Gemini Flash：Input $0.075/1M，Output $0.30/1M。
每輪對話假設 1,000 input tokens + 300 output tokens：
成本 = 0.075/1000 + 0.09/1000 = $0.000165 per 輪
200 輪 = $0.033 ≈ 約 1 台幣，遠低於 22 台幣的上限。
這讓我知道：Gemini Flash 足夠，不需要 Pro。」
Memory 設計：
「三層記憶：
In-Context（最近 5 輪）：
完整的問答記錄，保持對話連貫性
Summary Buffer（5-20 輪）：
超過 5 輪的歷史，用 Gemini Flash 壓縮成學習摘要
例如：『學生目前學習到微積分的連鎖律，
對合成函數的概念理解有困難，
已解釋過 3 次，需要更多練習題』
Long-term Learning Profile（跨 session）：
每位學生的學習進度、薄弱點、已完成的章節
存在 Firestore，按 student_id 隔離
不存任何可識別個人身分的資訊（名字、學校），只存學習狀態」
資料隔離（Q2）：
「每個 session 的資料 key 是 session_id（UUID），不是 student_id。
學習 profile 存在 Firestore，key 是 anonymized_id（學生 ID 的 hash，不可逆）。
即使 Firestore 被存取，拿到的是 hash，無法對應到真實學生。
Session State 用 session: scope，session 結束後自動清除。」
顧問題（Q5）：
「家長投訴這件事要認真對待。我的回應分三個層次：
立刻：承認問題，不辯解——
『您反映的問題非常重要，我們正在調查，
會在 24 小時內給您一個具體的回應。』
48 小時內：找出具體的 case——
用 response_id 找到那次對話的完整記錄，
確認是 LLM 的幻覺，還是 Prompt 設計問題，還是資料問題。
給家長一個有事實依據的解釋，不是含糊的道歉。
根本改善：對數學計算類問題加 code_execution Tool——
數學答案不依賴 LLM 的語言生成，
改為 LLM 生成解題思路 + Python 執行數值計算，
計算結果是確定的，不會有幻覺。
這個改進可以防止同類問題再發生。」
最常見失分點
❌ 沒有先算成本，設計了 Gemini Pro 的架構但成本超出 10 倍
❌ Memory 設計裡存了 student_id 和姓名，沒有考慮未成年資料保護
❌ 超出範圍問題（政治/宗教）的處理沒有設計，被面試官追問後臨時想
❌ 顧問題只道歉沒有提根本解（code_execution 讓數學計算不依賴 LLM）
練習指南
建議的練習方式：
週 1（建立基礎）：
情境一（金融合規）+ 情境五（政府 On-premise）
→ 練習「釐清需求」和「合規限制下的架構設計」
週 2（深化技術）：
情境二（ADK Multi-Agent）+ 情境三（VPC + Self-Reflection）
→ 練習 ADK 架構說明 + 安全設計
週 3（顧問技能）：
情境四（Scale + Cost）+ 情境六（Memory + 成本計算）
→ 練習成本估算 + 顧問情境回應
每個情境的練習流程：
1. 自己先說 3 分鐘（不看答案），錄音
2. 對照模範答案，找出你沒說到的點
3. 用「追問鏈」和朋友或同事做 Mock 對話
4. 特別練習「顧問題」——這是最多人失分的地方
判斷自己是否準備好的標準：
□ 能說出每個情境的 2 個「隱藏限制條件」問題
□ 每個架構設計都有至少一句「我的假設是 X，如果 X 不成立...」
□ 每個顧問題都有「技術 + 業務語言 + 下一步行動」三個層次
□ 說任何 GCP 工具，都能說出「適合這個工具的場景」和「不適合的場景」
六個情境覆蓋了 FDE RKK 最常見的考題類型。
但真正的面試題永遠比這裡的更複雜、更模糊——
練習這些情境，練的不是「背答案」，而是「在模糊中快速找到關鍵 constraint 的能力」。
