今天的骨架是兩層：先用「五條獨立線」把一句話的技術需求拆成五個不能互相替代的面向——存取權限、吞吐量上限、預算額度、輸出品質、可預期的失敗行為——避免把「加個警示」講成「做了硬性管控」；再用「原子預留 → 對帳釋放」處理併發請求搶同一筆資源時的競態：天真作法是兩個請求各自讀一次餘額、各自核准,結果超支;正確作法是用一次性的原子扣減擋下第二個請求，等第一個請求實際結算後再核銷差額、釋放剩餘額度。練習題是 PracHub 改編自 OpenAI「Product Manager, API Infrastructure」職缺描述的企業 API 預算控管案例：剩餘授信 $12，兩個請求各要保留 $8，天真系統會核准兩次變成授權 $16 比 $12 還多；拆解示範先把「警示」和「硬擋」定義成兩個不同產品、再用原子預留處理併發,最後用小範圍試跑＋對帳準確率衡量成功。案例是 Stripe 2017 年公開的 idempotency key 機制：同一個 idempotency key 在 24 小時內重複送出，Stripe 回傳第一次請求的結果而不是再扣一次錢，這套「先鎖定、重試認得出來」的邏輯跟今天練習題要解決的競態問題是同一個底層原理，現行官方文件在 2026 年仍明文保留「併發執行時的衝突不儲存冪等結果」這條規則。
Technical PM 面試裡的系統設計題，考的不是畫得出框和箭頭，而是會不會先把範圍問清楚、再把使用者旅程拆成需求、點名『準確、速度、隱私』這類系統屬性，最後自己主動講出取捨——這是 Aced 2026 年技術 PM 指南整理的五步順序，跟上禮拜練過的 RFC／決策矩陣是同一種紀律的兩種用法。今天的練習題是『設計一個系統，讓 Gemini 回答使用者的一個查詢』，拆解重點在於要不要先做 RAG 檢索、檢索加的延遲值不值得換來的事實正確性。案例是 Discord 把訊息資料庫從 Cassandra 遷到 ScyllaDB 的真實故事：177 個節點砍到 72 個，p99 延遲從 40 毫秒級壓到 15 毫秒，而驅動這個決定的不是『新技術比較潮』，是維運痛苦累積到門檻之後，工程主管怎麼量化痛苦、估算遷移成本、最後拍板換掉撐了五年的系統。
Technical PM 面試裡最難的不是畫出架構圖，而是在工程團隊意見分歧時，怎麼把決策過程變成一份大家都能回頭查的文件。今天練一道來自 Exponent/Aced 真實面試題庫的系統設計題：『設計一個偵測 Amazon 評論濫用的系統』，用 RFC → 決策矩陣 → ADR 的框架拆解——先寫 RFC 讓每個選項的取捨攤在陽光下，再用一張決策矩陣把抽象的『怎麼選』變成具體的評分標準，最後用 ADR 把『為什麼選這個』留下紀錄，而不是只留下『選了這個』的結論。案例是流傳已久但從未被正式證實出處的 2002 年 Bezos API Mandate——傳說 Amazon 內部強制所有團隊只能透過服務介面溝通、禁止任何後門，這個決定意外變成 AWS 的起點。
Technical PM 面試考 API 設計，真正要看的不是你會不會畫架構圖，而是你怎麼在『不能打斷任何一個現有整合』的前提下，還能讓系統往前走。今天練一道改編自 Stripe 真實歷史的題目：『你要把一個布林欄位換成列舉欄位，但已經有數千個第三方整合依賴舊格式，你會怎麼規劃這次變更？』答案框架是 Use Case → Contract → Compatibility → Operability → DX：先搞清楚誰在呼叫、呼叫的契約是什麼，再決定相容策略、維運成本與開發者體驗怎麼兼顧。案例是 Stripe 自 2011 年公司成立起維護所有 API 版本的相容性，不用 v1/v2/v3 大版號，改用以日期命名的 rolling version，把每次破壞性變更封裝進獨立的 version change module，六年內做了近百次破壞性升級，對現有整合幾乎無感。
Technical PM 面試考的不是你會不會畫架構圖，而是你能不能把一個破壞性 API 變更，拆解成客戶分群、相容層設計、分階段淘汰時程這幾個具體決策，並且敢真的設一個會執行的下線日期。今天的框架是 Use Case → Contract → Compatibility → Operability → DX 五層 API 設計框架，搭配 ADR（背景→決策→後果→回頭觸發點）把決策寫下來。練習題是「如何規劃一個破壞性授權變更的 API 淘汰計畫」，拆解思路是先釐清變更性質、用呼叫量數據把客戶分群、評估相容層的可行性、分四階段淘汰（警告→溝通→軟性截止→下線），最後用流量遷移率當領先指標。案例是 Stripe 從 2011 年至今用日期命名版本與版本轉換模組，讓每個帳號在第一次呼叫時自動釘選版本，之後所有破壞性變更都由內部轉換模組吸收，開發者可以永遠留在自己被釘選的版本上；2024 年 9 月起進一步把節奏公開為每月小版本、每年兩次大版本。
Technical PM 面試最容易穿幫的地方,是被問「這個 API 要怎麼升級」時,只會說「多寫一版文件」,答不出工程團隊維護雙版 schema 的實際成本,也答不出怎麼幫還沒升級的客戶爭取時間卻不拖垮整個團隊的路線圖。今天練一道情境題:B2B API 平台的核心 resource 要把單一數字欄位改成巢狀物件以支援多幣別,工程 lead 想直接在下一版強制升級。答案框架是 RFC 流程(Problem → Options → Decision → Cost)把技術決策攤開來討論,搭配 ADR 把「為什麼選這個方案、放棄了什麼」寫成有時效性的紀錄。案例是 Stripe 的日期命名 API 版本系統——每月發相容版本、每半年才發一次可能有 breaking change 的具名大版本(如 2026-08-26.dahlia),讓 2012 年寫的整合程式碼到今天都還能跑,靠的不是「不做 breaking change」,而是把 breaking change 的成本主動吸收在自己身上,而不是丟給客戶。
Technical PM 面試最容易被看穿的地方,是把版本策略講成一句「我們會做 v1、v2」,卻答不出誰該承擔升級成本、多久允許一次 breaking change。今天練一道情境題:企業合約要求 API 六個月內穩定不能無預警改格式,工程團隊目前沒有版本管理。答案框架是版本策略選項比較(路徑版本、header 版本、日期滾動版本)搭配 Cost-Reversibility 權衡矩陣,把每個選項的工程成本與客戶風險攤開來比。案例是 Stripe 用日期命名的滾動版本策略——每月版本只允許相容變更、每半年一次大版本才准破壞相容性,且每個帳號可以釘住自己的版本,讓 API 十幾年沒有真的「壞」過任何一個整合。
Technical PM 題最常見的失分點,是把技術判斷講成「工程說了算」或「我全部自己決定」,講不出怎麼把決策過程開放給團隊、又不失去方向。今天用 RFC 流程收斂多方意見、用 Architecture Decision Record 留下決策的來龍去脈,再練一道「合作夥伴系統逾時後自動重試,造成重複下單」的 API 設計題——怎麼設計讓重試變安全,又怎麼知道修好了。案例是 Stripe 的 Idempotency-Key header:同一個問題,他們在支付 API 上已經解了十年,至今仍是這類題目最常被拿出來對照的答案。
Technical PM 面試不是要你會設計系統，是要你能跟工程師用同一套語言討論取捨。今天用 RFC 流程（Draft-Review-Decision-Implementation）練『怎麼收斂技術討論的範圍』，用 Architecture Decision Record（Context-Decision-Consequences-Alternatives）練『怎麼把一個技術取捨寫清楚、留下可追溯的紀錄』，練一道 Exponent 收錄的 Stripe 技術輪真實題：設計一個 Ledger Service。
Technical PM 面試考的不是你會不會寫程式，是你能不能把一個技術決策（要不要接受 breaking change）講成一個工程師會認同的產品判斷。今天用「釐清→草擬→拆解取捨→回扣產品」四步法搭配輕量版 ADR，練一道 API 版本控管的真實題，並對照 Stripe 用 idempotency key 把「網路重試會不會重複扣款」這個不確定性收斂成一紙契約的做法。
Technical PM 面試考的不是你會不會畫架構圖，是你會不會在畫圖之前先講清楚限制條件。今天練 Clarify → Estimate → Sketch → Trade-off → Mitigation 五步結構，題目是 Google 真實面試題「設計企業版 Google Keep」，案例是 Uber 一則 latency vs consistency 的真實工程協商故事。
Technical PM 面試不要求你寫 production code，但你要能讀懂 trade-off。核心能力：API 設計的基本思維（RESTful、版本控制、錯誤處理）、系統架構的 high-level 理解（微服務、資料庫選型、快取策略）、與工程師協作的溝通模式（RFC 流程、技術 spec review），以及在技術限制下做產品決策的能力。