今日主題
Technical PM 面試裡，面試官很少真的在考「你會不會畫架構圖」。他們在考的是：當工程團隊內部對怎麼做有分歧，你怎麼把「每個人心裡都有一套方案」收斂成「一個有紀錄、能回頭查的決定」。這也是為什麼 2026 年的 Technical PM 面試越來越愛問「團隊意見不合時你怎麼做決定」這類問題，而不是單純的系統設計——因為多數 Technical PM 的日常不是從零設計系統，而是在工程師已經各有主張的情況下，主持出一個站得住腳的決策。
核心框架速記
RFC → 決策矩陣 → ADR：把「怎麼做技術決策」從一句空話拆成三個可以交付的文件。
| 階段 | 產出 | 解決什麼問題 |
|---|---|---|
| RFC（Request for Comments） | 每個方案倡議者各寫一份簡短提案，說明做法、取捨與遷移成本 | 讓分歧攤在紙上，而不是停留在會議室裡各說各話 |
| 決策矩陣 | 列出 3-5 個事先談好的評估標準（例如資料模型適配度、維運複雜度、團隊熟悉度、遷移風險、長期可擴展性），每個方案逐項打分 | 把「我覺得這個比較好」變成可以被檢驗、可以被挑戰的依據 |
| ADR（Architecture Decision Record） | 記錄決策的情境、選項、最終選擇與理由 | 讓六個月後新加入的工程師，不用重新吵一次已經吵過的架構辯論 |
這個框架的重點不是「寫很多文件」，而是把決策權從「誰在會議室裡聲音最大」轉移到「誰的論點在矩陣上站得住腳」——這正是 Technical PM 在工程協作裡最核心的槓桿點。
今日練習題
題目
「設計一個系統，偵測 Amazon 上的評論濫用行為（例如付費好評、刷評論、機器人帳號灌水）。」
（來源：Exponent／Aced 技術 PM 面試題庫，收錄為真實面試中出現過的系統設計題）
拆解思路
- 釐清問題：先問面試官「濫用」指的是哪一種——付費好評、競品惡意負評轟炸、還是機器人帳號大量灌水，這三者的偵測訊號完全不同，先鎖定範圍才不會把題目做成大雜燴。
- 定義使用者：拆成兩群——會被這套系統影響的「真實買家」（他們的正常評論絕對不能被錯殺），以及負責處理模糊案例的「信任與安全團隊」（他們是這套系統最終的操作者，不是旁觀者）。
- 結構化分析：用決策矩陣列出偵測訊號——帳號年齡與歷史、評論發布速度、文字重複度／模板化程度、是否為驗證購買、評論者與賣家的關聯圖譜。再把「誤判成本」當成最關鍵的評估標準：錯殺一則真實評論的代價遠高於漏放一則可疑評論，這決定了整套系統要往哪個方向偏。
- 提出方案：高信心的可疑案例自動下架，模糊案例路由給人工審核，而不是讓模型自己兩邊都要扛。這個分層本身就是一份迷你 RFC——把「全自動」跟「全人工」兩個極端方案的取捨攤開來比較，再選一個折衷點。
- 定義成功：追蹤精確率（precision）、召回率（recall），以及申訴後被撤銷的比例（appeal-overturn rate）——這個指標專門用來發現系統是不是誤殺太多真實評論。把這次決策連同這三個指標的門檻寫成一份 ADR，之後要調整敏感度時，不用重新辯論一次當初為什麼選這個權衡點。
範例回答（面試時可以這樣講）
先框定範圍：我不會直接跳進去設計一個抓所有濫用的系統，我會先問這題聚焦的是付費好評、惡意負評轟炸，還是機器人灌水，因為這三者的偵測訊號完全不一樣，先鎖定範圍才不會做出一個四不像的系統。
接著談怎麼拆解：我會把真實買家跟信任與安全團隊分開看，因為真實買家的正常評論絕對不能被錯殺，但信任與安全團隊才是這套系統每天在操作的人。我會用帳號年齡、評論發布速度、文字重複度、是否驗證購買、評論者跟賣家的關聯圖譜這幾個訊號打分，然後把『誤判成本』設成最關鍵的評估標準——錯殺一則真實評論的代價，遠高於漏放一則可疑評論，這個不對稱性決定了整套系統要往哪個方向偏。
最後講怎麼落地：我不會做成全自動或全人工的二選一，高信心案例自動下架，模糊案例路由給人工審核，兩邊互相補位。我會把這次的取捨——為什麼選這個敏感度門檻、為什麼不做成全自動——寫成一份決策紀錄，這樣半年後團隊要調整門檻時，不用重新吵一次已經吵過的架構辯論，只要看紀錄就知道當初為什麼這麼選。
自我核對清單
用這張表檢查你的回答有沒有漏掉關鍵點：
| 核對項目 | 有提到？ |
|---|---|
| 有先問清楚「濫用」指的是哪一種行為，鎖定範圍 | |
| 有區分真實買家與信任安全團隊兩種使用者 | |
| 有用決策矩陣列出具體的偵測訊號與評估標準 | |
| 有明確點出「誤判成本不對稱」這個決定方向的關鍵變數 | |
| 有定義可量測的成功指標（precision、recall、appeal-overturn rate） | |
| 加分項：有提到把決策寫成 ADR，避免未來重複辯論 |
今日案例
2002 年 Bezos API Mandate：一份從未被正式證實出處的傳說備忘錄，意外變成 AWS 的起點
這個案例流傳在矽谷工程圈已經二十年，但它的真實出處至今沒有被正式證實——最早的紀錄可以追溯到 API Evangelist 在 2012 年的一篇文章，而更廣為人知的版本來自 Steve Yegge 在 2011 年不小心公開的一篇內部貼文。按照這個流傳的版本，Jeff Bezos 在 2002 年對 Amazon 全公司下了一道強制令：所有團隊從此只能透過服務介面（service interface）對外暴露自己的資料與功能；團隊之間只能透過這些介面溝通；不允許任何其他形式的跨程序通訊——沒有直接連結、沒有直接讀取別的團隊的資料庫、沒有共享記憶體、沒有任何後門，唯一允許的溝通方式是透過網路上的服務介面呼叫；用什麼技術無所謂；但所有服務介面在設計之初就必須規劃成可以對外部開發者公開，沒有例外。不管這份備忘錄是不是真的以傳說中的形式存在，它描述的做法確實發生了：Amazon 內部因此被迫打破部門之間各自為政的資料孤島，每個團隊想要別的團隊的功能，都得透過一個定義清楚、有文件、有標準回應格式的介面去拿，而不是繞後門直接查資料庫。這套被強制養成的「介面優先」紀律，後來被公認是 Amazon 得以把內部基礎設施重新包裝、對外變成 AWS 的關鍵前提之一。
面試連結：這個案例最適合回答「怎麼用技術決策強制團隊協作」或「舉一個 API 優先設計創造出策略性護城河的例子」這類問題——重點不是「Amazon 很早就懂 API」，而是示範一個頂層的架構決策（禁止後門、強制走介面）怎麼在組織層級解決「團隊各自為政」的協作問題，而這正是今天框架裡 RFC → 決策矩陣 → ADR 想解決的同一個問題，只是這次的決策範圍是整個公司,而不是一個系統。
延伸閱讀
- 30+ Technical Product Manager Interview Questions (2026 Guide) — Aced — 完整收錄系統設計、AI/ML、技術基本功、工程協作四類題庫與範例答案，今天的練習題正是從這篇延伸。
- System Design Interview Blueprint: 2026 6-Step Framework — Tech Interview — 另一套系統設計拆解框架，適合跟今天的 RFC → 決策矩陣框架交叉練習。
- Meta System Design Interview — IGotAnOffer — 補上大型科技公司系統設計面試在高層架構與取捨溝通上的實際期待。
參考資料
- 30+ Technical Product Manager Interview Questions (2026 Guide) — Aced — 今日練習題「設計評論濫用偵測系統」出處。
- Technical Decision-Making Interview Questions — EM Tools — 今日核心框架 RFC → 決策矩陣 → ADR 與五項評估標準（資料模型適配度、維運複雜度、團隊熟悉度、遷移風險、長期可擴展性）出處。
- The Bezos API Mandate: Amazon's Manifesto For Externalization — Nordic APIs — 今日案例出處，含「這份備忘錄出處從未被正式證實」的說明。