AI Engineer 與 Product Builder 兩條 track，各有深度系列和每日練習。
每日一篇 AI Engineer 面試練習，依星期輪替七個主題——ML 基礎、深度學習、系統設計、LLM 工程、Coding、論文閱讀、行為面試——從網路抓最新面試題與資源。
71 篇每日一篇 Product Builder 面試練習，依星期輪替七個主題——產品直覺、指標分析、策略執行、AI 產品設計、成長實驗、技術 PM、行為面試——從網路抓最新案例與面試題。
71 篇從 ML 基礎、系統設計、LLM 應用架構到行為面試，拆成十個主題逐篇準備。每篇聚焦一個面試環節，整理核心概念、常見題型與實戰策略。
17 篇從產品直覺、指標設計、策略思維到 AI 產品設計，拆成十個主題準備 Product Builder 面試。每篇聚焦一個面試環節，整理框架、案例與答題策略。
10 篇今天的核心是把 self-attention 從公式講到工程判斷：Q/K/V 怎麼從輸入投影出來、為什麼要除以 √d_k（避免 softmax 梯度消失）、多頭注意力怎麼讓模型同時學不同種類的關係、causal mask 跟 padding mask 各解決什麼問題。再往上走到 BERT（MLM，雙向，適合理解類下游任務）跟 GPT（next-token prediction，單向，適合生成）的預訓練目標差異如何決定各自的下游用法。練習題取自 Amazon Software Engineer（Machine Learning）技術篩選輪的真實問法——完整推導 scaled dot-product self-attention 並比較 BERT 跟 GPT——陷阱是只會背 Attention(Q,K,V) = softmax(QK^T/√d_k)V 這個公式，答不出每一步為什麼存在。
今天的練習題是外送 App 完成訂單單週掉 12%，但真正的重點不是背出 AARRR 這五個字母，是練習怎麼把一個籠統的『訂單掉了』定位到漏斗的哪一段——是新使用者打開 App 的那一步（Acquisition/Activation），還是老使用者回購的那一步（Retention），因為兩種掉法要查的方向完全不同。第二個框架是 OEC（Overall Evaluation Criterion，整體評估準則）：A/B 測試不能只看單一主要指標有沒有漲，因為主要指標可能用犧牲使用者體驗換來的短期暴增，所以要同時盯著一組護欄指標，確認漲幅不是拿長期信任去換的。案例是 Ron Kohavi 與 Stefan Thomke 在 Harvard Business Review 公開的第一手敘述：Bing 一個把廣告標題和第二行文字合併顯示的改版想法，在待辦清單裡放了半年才排進測試，一上線監控系統就跳出『好得不像真的』警報——營收漲幅遠超預期，團隊第一反應不是慶祝，是先排查是不是記錄重複計算的 bug，排查後確認沒有 bug，再檢查護欄指標（使用者體驗相關數字）有沒有被犧牲，確認沒有之後才正式上線，年化貢獻超過一億美元，是 Bing 史上單一改版帶來最大的營收成長。
今天的核心是 bias-variance tradeoff 在「規模變大」這個條件下會怎麼變化：資料量變大會在同樣模型複雜度下自然壓低 variance，所以規模夠大時常常可以負擔得起更複雜的模型而不過擬合；L1／L2 正則化的差別是幾何上的（diamond 有角 vs circle 沒有角），bagging 降 variance、boosting 降 bias 則是用演算法設計直接對應誤差分解裡的兩項；優化器選 SGD 還是 Adam，也是另一種规模下的 trade-off（Adam 收斂快但記憶體多三倍、可能收斂到較平的 minima 而略為犧牲泛化）。練習題取自 Apple Machine Learning Engineer 面試的真實問法——解釋 bias-variance tradeoff，以及規模變大時你會怎麼想——這類題目的陷阱是只會背公式，答不出「規模」這個條件到底改變了什麼。
CIRCLES 負責把題目拆成七步結構，Sean Ellis 的『很失望』分群法負責決定該聽誰的話——這兩個框架合起來才是今天的重點：分群不是面試裡隨口列幾個人設，是決定後面所有分析該往哪個方向走的第一個選擇。練習題是真實 PM 模擬面試題庫收錄的『設計一個幫助長者獨立使用大眾運輸系統的產品』，拆解示範怎麼把長者這個籠統標籤，先切成『認知清楚但行動不便』與『認知退化但行動自如』兩種完全不同的失敗模式，再各自配不同的解法與安全防線。案例是 Rahul Vohra 在 First Round Review 公開的 Superhuman 原始敘述：早期只有 22% 使用者說『如果不能用了會很失望』，遠低於 Sean Ellis 認定的 40% 產品市場契合門檻，Vohra 沒有急著改產品，而是先把回答『很失望』的那群人單獨抓出來分析他們共同的使用情境，光是這個分群動作、什麼都還沒改，分數就跳到 32%，接下來四個季度用同一套『調查→分群→分析→迭代』流程跑完，分數依序推進到 47%、56%、58%。
今天的論文是 Continual Learning Exam（arXiv:2610.33956，2026-10-25 發布），用 120 個五關任務鏈、89 種職業角色，測 agent 能不能把前面任務學到的東西用在後面的任務上。結果是最強系統也只闖過 47.7% 的關卡、完整通關五關的任務只有 23.3%，而且加回饋重做一次,中位數只進步 5.3 個百分點。練習題模擬面試官丟一組『單次任務分數很高、但長任務鏈表現很差』的評測結果，要你診斷是模型真的學不會，還是評測設計本身把『記得住』跟『用得上』混在一起算。
今天的骨架是兩層：先用「五條獨立線」把一句話的技術需求拆成五個不能互相替代的面向——存取權限、吞吐量上限、預算額度、輸出品質、可預期的失敗行為——避免把「加個警示」講成「做了硬性管控」；再用「原子預留 → 對帳釋放」處理併發請求搶同一筆資源時的競態：天真作法是兩個請求各自讀一次餘額、各自核准,結果超支;正確作法是用一次性的原子扣減擋下第二個請求，等第一個請求實際結算後再核銷差額、釋放剩餘額度。練習題是 PracHub 改編自 OpenAI「Product Manager, API Infrastructure」職缺描述的企業 API 預算控管案例：剩餘授信 $12，兩個請求各要保留 $8，天真系統會核准兩次變成授權 $16 比 $12 還多；拆解示範先把「警示」和「硬擋」定義成兩個不同產品、再用原子預留處理併發,最後用小範圍試跑＋對帳準確率衡量成功。案例是 Stripe 2017 年公開的 idempotency key 機制：同一個 idempotency key 在 24 小時內重複送出，Stripe 回傳第一次請求的結果而不是再扣一次錢，這套「先鎖定、重試認得出來」的邏輯跟今天練習題要解決的競態問題是同一個底層原理，現行官方文件在 2026 年仍明文保留「併發執行時的衝突不儲存冪等結果」這條規則。
今天的練習題取自 270 篇真實面試回報整理出的 Mistral AI 面試題：『給一個 toy language model 的 logits，用 NumPy 實作 greedy、top-k、top-p 三種 decoding』。核心不是背 softmax 公式，是講得出三個關鍵決定——exp 前要先減最大值避免 overflow、top-k 跟 top-p 篩選後都要重新正規化機率，以及 top-p 的候選集合大小是隨分布動態變的，不是固定數字。
今天的骨架是兩個框架：先用 Growth Loop 找出產品裡已經半成形的迴圈——不是憑空發明一個分享機制，是找『使用者已經在做，只差一步就能帶來新使用者』的行為，裝上輸入、行動、輸出三個指標；再用 Nir Eyal 的 Hook Model（Trigger、Action、Variable Reward、Investment）判斷一個功能能不能讓使用者自己回來，而不是每次都靠推播硬拉回來。練習題是 PracHub 收錄的 Slack 真實面試題：怎麼幫 Slack 開出更多 product-led growth 的擴散路徑——拆解示範先問『成長指的是新 workspace、既有團隊更活躍，還是免費轉付費』鎖定範圍，再從 Slack 已經在跑的跨公司 channel 共享這個半成形迴圈下手，而不是硬加一個邀請按鈕，同時要準備好回答 IT 團隊對治理失控的質疑。案例是 Calendly 投資人暨董事 Blake Bartlett 接受 Sacra 專訪時的說法：Calendly 的病毒迴圈不是設計出來的，是因為『排程』這個任務本身就是兩個人同時遇到同一個問題——這個判斷標準（工作流程本身有沒有牽涉到非使用者）就是今天拿來排序 Slack pathway 優先順序的同一套邏輯。
今天的核心是權限控管跟引用驗證不能交給 prompt 去「請模型注意」，要做成 deterministic 的檢索層跟事後檢查：ACL 過濾發生在文件進入 context 之前,不是進了 context 之後靠 LLM 自律;引用則要在生成後驗證來源 ID 確實在允許的檢索集合裡。練習題取自 OpenAI 的真實面試(同一題也在 Google、Lyft 被回報):「設計一個搜尋內部文件的 agent,必須遵守權限、引用來源、且該拒答時會拒答」,關鍵不是背出 RAG 架構,是能示範一套「把安全邊界放進程式碼、把語意判斷留給模型」的分工邏輯。
AI 產品設計題考的不是背得出 human-in-the-loop 這個詞,是能不能先問清楚一個具體問題——這個功能錯了的代價多高、這個動作能不能收回——再決定要不要讓 AI 自己動手,還是先停在草稿等人看過。核心框架是風險分級任務分配:把每個決策按『犯錯成本』與『可不可逆』分成三格,高成本且不可逆的要先經人核准才執行,中成本但可逆的用事後抽查,低成本的才放給 AI 自己處理再回報例外。第二個框架是信任校準:目標不是讓使用者無條件相信 AI,也不是讓他每一步都要盯著,是讓他清楚『這個情況該信,那個情況該查』——常見錯誤是以為加一個信心分數就解決了,但研究顯示信心分數本身很難幫使用者做出更好的判斷。練習題是 ZoomInfo PM 面試真題:『你會怎麼設計一個幫銷售開發代表(SDR)寫 outreach 訊息的 AI 功能?』拆解示範先問『這是全自動發送還是草稿輔助』來鎖定範圍,再用風險分級框架推出『發送這個動作不可逆、寫錯會得罪潛在客戶』,所以應該先做草稿輔助,不是一步到位做全自動發送。案例是 Anthropic 自己公布的資料:Claude Code 使用者對權限提示的批准率高達 93%,但這個數字背後藏著『批准疲勞』——人看久了會停止認真檢查,這正是信任校準失敗的真實案例,不是信任校準成功的案例。
今天的核心是 feature store 的兩層架構——offline store 當訓練用的真相來源，強調 point-in-time correctness；online store 用低延遲資料庫服務線上推論——以及連接兩者的 materialization 怎麼決定 freshness 的上限。練習題取自 Spector AI 的真實 MLE 面試：「從零設計一個 feature store，新鮮度跟基礎設施成本怎麼取捨」，關鍵不是背出 offline／online 兩個名詞，是能示範一套「先看特徵變動速度，再決定走批次、串流還是 request-time 計算」的分級邏輯。
戰略題考的不是能不能背出 SWOT 或 Porter's Five Forces,是能不能在六步裡做出一個站得住腳、而且敢講出反方意見的具體決定——先釐清題目在問多長的時間範圍,再回去查公司真正靠什麼賺錢(不是看它的使命宣言),接著定位這次威脅或機會從哪裡冒出來,訂出能真正刪掉幾個選項的『指導原則』,從一堆選項篩到剩兩三個,最後選一個、講出它最強的反方論點、再說明為什麼還是這樣選。練習題是 Google 面試裡真實出現過的題目:『你是 Zoom 的 CPO,正面對 Google Meet 的強力競爭,你會怎麼做?』拆解示範用五個透鏡——市場定位、品牌忠誠度、通路、組織能力、產品技術——逐一掃過 Zoom 對 Google Meet 的相對優劣勢,而不是看到題目就急著丟功能點子。案例是 Google 自己正面被 ChatGPT 衝擊時的真實選擇:沒有另外做一個獨立的聊天機器人去跟 ChatGPT 硬碰硬,而是把 AI Mode 直接塞進搜尋框裡——因為使用者本來就每天在用 Google 搜尋,這是 Google 真正擁有的通路優勢,比起從零構建使用習慣容易得多。
今天的核心是 LoRA 的數學假設——凍結原始權重 W,只訓練兩個小矩陣 B、A 的乘積 ΔW=BA,rank r 遠小於原矩陣維度,B 初始化為零讓訓練起點等於原模型——以及 QLoRA 多做的事:把凍結的 base 量化成 4-bit NF4,adapter 本身仍用 bf16 訓練,兩者解決的是不同層次的資源問題。練習題取自 Sarvam AI 的真實 MLE 面試——解釋 LoRA/QLoRA 怎麼運作,以及什麼時候選 PEFT 而不是全參數微調——關鍵不是背出縮寫,是能示範一套「先看任務需要多少新知識,再看硬體預算,最後才決定 rank 跟是否量化」的決策順序。
Metrics 面試最常考的不是背指標名詞，是拿到一個掉下來的數字時，能不能用一套可重複的程序把它拆開查，而不是憑直覺亂猜原因。今天的核心框架是北極星指標的指標樹拆解——把一個太抽象、單一團隊兩週衝刺內摸不到的北極星指標，拆成廣度、深度、頻率、速度四個可以直接被某個小隊影響的輸入指標，範例取自一個 AI 寫作平台把『每週成功產出的 AI 草稿數』拆成四個槓桿的做法。練習題是 PM 面試圈廣泛引用的 diagnostics 真題：『Instagram Stories 單日掉了 7%，DAU 也掉 5%，你會怎麼查？』,拆解示範先把指標定義釐清、再用地理／平台／用戶群分段定位問題範圍、接著把時間軸和內部改版或外部事件對齊、同時排除埋點或計算邏輯本身出錯的可能，最後才下結論並給出後續監控建議，而不是看到數字掉就急著講故事。案例是 Spotify 在早期擴張階段的真實選擇——如果當時選了『總註冊數』當北極星指標，成長團隊會把力氣全部花在把人拉進門，但 Spotify 選了『活躍使用者的聆聽時長』，讓這個數字同時餵養 Discover Weekly 等演算法推薦、也直接決定免費層的廣告庫存量與付費轉換的自然驅動力，示範了『虛榮指標』和『能擷取真實價值的指標』之間的差別怎麼在真實公司的決策裡發生。
Agent 面試常被問到八題：Agent 迴圈、Structured Output、Function Calling、大量工具、記憶、設計考量、MCP 與 A2A、Prompt Caching。本篇用「概念 → 機制 → 面試怎麼答」串成一條線，並對照一手來源更正 2026-07 MCP 規格改版的時間點。
面試常被問到的四題系統設計（企業 RAG、推論服務、客服 Agent、線上 A/B 與資料飛輪）、三題 Python（動態批次、取樣、退避重試加 token bucket）與 STAR 行為骨架，每題附可講出口的回答與核對清單，程式碼都實際執行通過。
LLM 工程面試常見七個主題：LoRA／QLoRA 與微調 vs RAG、RLHF／DPO／GRPO 對齊、PagedAttention 讓 vLLM 吞吐量提高 2 到 4 倍的推論優化、取樣解碼、LLM 評估、OWASP LLM Top 10（2026 版）與幻覺。每節都拆成概念、機制、回答方式。
面試追問通常落在機制：為什麼要除以 √d_k、AdamW 和 Adam＋L2 差在哪、AUC 很高為什麼還不能上線。本文逐題講概念、機制與答法，最後附 3 題可執行的 numpy 手寫題。
Prompt 管單次措辭、Context 管模型此刻看到什麼、Harness 管包住非確定性模型的整套系統；Bsharat 的 26 條原則、Breunig 的四種 context 失敗、OpenAI 約一百萬行零手寫的 harness 實驗，各對應一層。評估則是 harness 裡最常被省略的一塊，要在 CI 設閘門擋下沉默回歸。
RAG 面試題用「三階段流程 → 各階段的失敗點 → 九種變體各補哪個洞 → 6 類 RAG 解不了的問題」四步回答：Self-RAG、CRAG、Adaptive-RAG 補判斷，Graph RAG、KG-RAG 補索引，CAG 乾脆不檢索，Agentic RAG 與 Reasoning RAG 把決策交給模型。
先讀公司官方說明：Meta 已要求候選人在面試中使用內建 AI，Anthropic 預設禁用。題庫挑有附來源、今年還在更新的，例如 alexeygrigorev field guide、ombharatiya 與 alirezadir。12 個熱門 repo 只有 2 個替題目附上可點的來源，有些答案放在付費牆後面。
行為面試不是靠臨場發揮，而是靠事前準備好的故事庫。AI Engineer 的行為面試有獨特的考點：AI 倫理（bias、fairness、privacy）、技術決策的影響力敘事（為什麼選這個模型/架構）、跨團隊推動 ML 專案的經驗。準備策略：建立 8-10 個 STAR 故事，每個故事練到能在 2 分鐘內講完。
AI Engineer 的 coding 面試和 SWE 不完全一樣——除了 LeetCode medium，還會出 ML-flavored 的題（實作 tokenizer、寫 batch inference pipeline、處理稀疏矩陣）。準備策略：LeetCode medium 練到 70% 通過率就夠，剩下的時間花在 numpy/pandas 操作、資料處理 pipeline、以及 ML 相關的程式題。
深度學習面試重點不是推導反向傳播，而是能不能解釋架構背後的設計直覺。高頻考點：CNN 的 locality 與 translation invariance、RNN 到 Transformer 的演進為什麼必要、self-attention 的計算邏輯與複雜度、BatchNorm vs LayerNorm 的適用場景、常見的 training tricks（learning rate schedule、gradient clipping、mixed precision）。
LLM Application Design 是 2025-2026 面試最熱的新題型。核心考點：RAG pipeline 的 chunking/retrieval/reranking 設計、agent 架構的 tool-use 與 planning loop、context window 管理策略、guardrails 與 safety 設計、以及 LLM 應用的評估方法。面試官特別看重你有沒有踩過坑。
ML 基礎面試不考你背公式，考你能不能用直覺解釋概念、在追問下不崩潰。高頻考點：bias-variance tradeoff 的實際意義、L1/L2 regularization 的選擇邏輯、cross-entropy 為什麼比 MSE 適合分類、SGD 與 Adam 的取捨、precision/recall 在不同場景的重要性差異。
ML System Design 面試的核心不是選模型，而是怎麼把一個商業目標變成一個可上線、可監控、可迭代的 ML 系統。面試官想看你能不能：把業務目標翻成 ML 目標、設計 data pipeline 和 feature store、選擇合理的 serving 策略、規劃 monitoring 和 A/B testing。
MLOps 面試考的是你有沒有把模型推上生產的經驗。高頻考點：ML pipeline 的 CI/CD（跟軟體 CI/CD 有什麼不同）、model registry 與版本管理、A/B testing 的設計與陷阱、inference 的 scaling 策略（水平擴展、模型壓縮、caching），以及生產環境的 monitoring 與 alerting 設計。
LLM 面試的分水嶺是你有沒有實際用過這些東西。高頻考點：BPE tokenization 的邏輯與多語言問題、預訓練目標（CLM vs MLM）、fine-tuning 的三種層次（full/LoRA/prompt tuning）、RLHF 的流程與 failure mode、prompting 的工程實踐、LLM 評估的困難與現有方法。
AI Engineer 面試不只考 ML——大廠看系統設計與 coding，新創看端到端交付，AI-native 公司看 LLM 工程深度。準備策略：先釐清目標公司類型，再按六大維度（ML 基礎、系統設計、LLM 應用、Coding、Paper Reading、行為面試）分配時間。
Paper Reading 面試不是考你有沒有讀過那篇 paper，而是考你能不能快速理解一個新方法並找出它的限制。AI-native 公司（Anthropic、OpenAI）特別愛考。準備策略：練習 30 分鐘讀完一篇 paper 並能口述 contribution + limitation，建立自己的必讀論文清單，每篇練習用三句話總結。
AI Product Design 是 2025-2026 面試最熱的新題型。核心考點：什麼時候該用 AI（不是所有問題都需要 AI）、human-in-the-loop 的設計模式（什麼時候讓人介入）、信任建立（怎麼讓用戶相信 AI 的輸出）、AI 產品的獨特挑戰（hallucination、latency、cost），以及 AI 產品的評估指標。
Product Builder 的行為面試和 SWE 不一樣——不只考團隊合作，特別考你怎麼在沒有直接權力的情況下推動事情。核心能力：影響力敘事（怎麼說服工程師做你想做的功能）、衝突處理（跟設計師/工程師/stakeholder 意見不同時怎麼辦）、vision 表達（怎麼用 30 秒讓人理解你的產品方向），以及失敗故事（怎麼從失敗中學習而不是推卸責任）。
Execution 面試考的是你能不能把想法變成可交付的東西。核心能力：roadmap 規劃（怎麼在有限資源下排序）、優先序辯護（為什麼先做 A 不做 B）、跨團隊協作（怎麼推動工程和設計）、stakeholder management（怎麼處理衝突），以及用數據追蹤進度的能力。
Growth 面試考的不是你會不會做 growth hack，而是你有沒有系統性的成長思維。核心能力：growth loop 設計（acquisition → activation → retention → referral 的飛輪）、實驗設計（假設 → 指標 → 實驗 → 分析的完整流程）、retention 策略（找到 aha moment、設計 habit loop）、以及用數據判斷什麼值得繼續投資。
Metrics 面試考的是你能不能用數字做決策，而不是你懂多少統計。核心能力：北極星指標的選擇邏輯（為什麼選這個不選那個）、指標樹拆解（找到可操作的 lever）、漏斗分析（哪一步流失最值得修）、A/B testing 的設計與陷阱、以及面對反直覺數據時的判斷力。
Product Builder 不是傳統 PM——你要能從 0 到 1 建產品，不只寫 PRD。面試考的是產品直覺、指標思維、技術理解力與執行力的交集。準備策略：先搞清楚目標公司要的是 PM 還是 Builder，再按九大維度分配時間。
Product Design 面試不是考你畫 wireframe，而是考你怎麼從問題走到方案。核心能力：MVP 範圍判斷（什麼該做什麼不做）、trade-off 分析（速度 vs 完整度、通用 vs 客製）、設計決策的溝通能力（為什麼選 A 不選 B），以及快速迭代的思維。
Product Sense 面試考的不是你能想出多少功能，而是你能不能從一個模糊的需求裡找到真正值得解的問題。核心能力：用戶分群思維、問題重構（把『加個功能』翻成『解決什麼問題』）、feature prioritization 的結構化論述、以及在面試官追問下堅持或修正判斷的能力。
Strategy 面試不是考你背框架，而是考你能不能在資訊不完整時做判斷。核心能力：市場規模估算（TAM/SAM/SOM 的實際用法）、競爭護城河分析（網路效應、轉換成本、品牌）、進入新市場的 go/no-go 決策，以及用排除法而不是加法來做策略取捨。
Technical PM 面試不要求你寫 production code，但你要能讀懂 trade-off。核心能力：API 設計的基本思維（RESTful、版本控制、錯誤處理）、系統架構的 high-level 理解（微服務、資料庫選型、快取策略）、與工程師協作的溝通模式（RFC 流程、技術 spec review），以及在技術限制下做產品決策的能力。