題幹與適用場景
公司準備在 12 個月後關閉 v1 API，推出 v2。v1 有 3,000 個客戶，約 40% 的請求仍依賴舊欄位，其中 200 個客戶是高收入企業。請規劃遷移方案，兼顧新能力、相容性、開發者體驗、收入風險和最終下線。
這道題考察產品經理如何把一次技術遷移變成有邊界的客戶產品：先確認誰受影響、為什麼要遷移和哪些行為不可破壞，再設計相容層、工具、溝通、分批推進和退出條件。GitHub 的 API 版本文件把破壞性變更、Deprecation/Sunset 標頭、支援窗口和遷移測試都作為版本治理的一部分，可作為現實約束。
面試官考察點
第一項是能否把客戶分群和風險排序說清楚，而不是只宣布一個日期。高收入、強法遵、低活躍和自助客戶的遷移阻力不同。
第二項是能否區分相容、遷移和下線。保留舊版本、提供適配層或批量轉換只能降低風險，不能取代客戶確認和最終退出標準。
第三項是能否用可觀測資料推進決策。請求量下降不等於遷移完成，要同時看活躍應用、錯誤率、欄位使用、成功遷移和客戶支援負擔。
回答前需要釐清的問題
- v2 的核心價值是什麼？ 是安全、效能、法遵、成本，還是新資源模型？
- 哪些 v1 行為是破壞性變化？ 欄位刪除、型別變化、認證變化和錯誤語意都要列出。
- 客戶是否知道自己使用了哪些欄位？ 能否提供按 token、應用或組織的呼叫明細？
- 12 個月是硬截止還是目標日期？ 哪些證據可以觸發延期或分階段關閉？
- 能否執行雙版本或適配層？ 成本、延遲和資料一致性邊界是什麼？
- 下線後的支援承諾是什麼？ 410、錯誤文件、客戶申訴和安全例外如何處理？
30 秒回答框架
「我先建立 v1 使用基線和客戶分層，逐項列出 v2 的破壞性變化與遷移收益。然後發布相容指南、差異清單、驗證工具和按應用維度的用量看板，先邀請高價值客戶和內部整合做試點。遷移期間同時發送文件、控制台、電子郵件和直接客戶溝通，並用 Deprecation/Sunset 標頭和階段性錯誤演練提高可見性。每個階段有採用率、錯誤率、活躍應用遷移率和支援工單閾值；達到退出條件後才關閉 v1，保留安全例外和回復窗口。」
分步驟深入解答
第一步：定義遷移目標和不可破壞的行為
把目標拆成客戶價值和平台約束：例如 v2 提供更細粒度權限，v1 的核心讀寫語意必須在過渡期保持穩定。建立破壞性變更清單，包含刪除或重新命名欄位、增加必填參數、型別變化、列舉變化和認證要求變化。不要把「介面回傳 200」當成相容證明。
第二步：建立使用基線和風險分層
按組織、應用、token、版本、端點、欄位、請求量、收入、法遵和技術負責人分層。給每個應用計算近 90 天活躍度、受影響欄位比例、遷移複雜度和客戶價值。高收入但低請求量的客戶仍需要專人確認；沒有明確 owner 的應用要提前進入風險佇列。
第三步：設計遷移路徑和相容邊界
優先提供 additive 遷移：新增可選欄位、並行回傳或 v1 到 v2 的適配層。對無法相容的欄位給出等價映射、範例請求和明確的語意變化。適配層要有期限、成本和觀測，不應永久隱藏客戶沒有完成遷移的事實。
第四步：把工具和文件做成產品
提供差異清單、按應用的呼叫報告、靜態檢查或 SDK 遷移提示、沙箱驗證、範例程式碼和回復說明。文件要把每個破壞性變化連接到替代寫法和測試步驟。遷移工具輸出應可重複，避免客戶只能閱讀長篇公告後手工猜測。
inventory -> classify risk -> test v2 -> dual-run -> migrate -> verify -> retire v1第五步：安排分階段發布和溝通
先讓內部和設計夥伴雙跑，再開放自助遷移，最後處理高價值或複雜客戶。每階段同時使用變更日誌、開發者文件、控制台橫幅、電子郵件和客戶經理溝通。把日期、影響、動作、支援入口和例外條件寫成同一份遷移契約，避免不同渠道傳遞不同承諾。
第六步：用訊號而非單一採用率做門禁
每週看 v1 請求量、活躍 v1 應用數、受影響欄位呼叫數、v2 成功率、遷移後回復率、棄用標頭覆蓋率、支援工單和高價值客戶確認率。遷移完成必須同時滿足「應用已切換、關鍵場景通過、錯誤率沒有異常、客戶 owner 已確認」。
第七步：定義下線、延期和例外規則
下線前先在測試環境模擬 410 或等價錯誤，確認客戶能看到動作指引。延期需要明確證據，例如安全修復未完成、關鍵法遵客戶仍在遷移或 v2 存在已確認回歸。安全風險可以觸發提前關閉，但必須說明影響、替代路徑和支援範圍。例外要有到期日，不能變成永久旁路。
第八步：複盤遷移並沉澱版本治理
下線後檢查錯誤峰值、客戶留存、支援成本、基礎設施節省和未預期使用方式。保留 v1/v2 的差異、溝通記錄、決定日誌和事故時間線。把版本支援週期、破壞性變更評審、棄用標頭、遷移測試和客戶通知納入下一次發布範本，降低未來遷移的突發性。
設計取捨與邊界
取捨一：相容層還是快速切換
相容層能降低短期風險，但會增加維護、延遲和語意歧義。只有當遷移價值明確、相容邊界可觀測且有退出日期時才保留；否則應提供清晰的 v2 遷移窗口而非無限延長 v1。
取捨二：統一截止日期還是客戶分批
統一日期便於營運，分批可以控制風險並給複雜客戶更多時間。建議保留一個公開總截止日期，同時按客戶風險設定里程碑和提前檢查點，避免高收入客戶在最後一週集中暴露。
取捨三：請求量下降還是應用真正遷移
請求量可能因業務下滑、快取或停用而下降。應用遷移應以活躍應用、關鍵端點成功呼叫、欄位替代完成和 owner 確認共同判斷，不能只看總流量。
失敗演練與演進計畫
演練一：遺漏的破壞性欄位
隨機抽取真實請求回放到 v2，比較狀態碼、錯誤物件、分頁、時區和金額語意。把差異按嚴重性分類，任何未解釋的關鍵欄位差異阻止擴大流量。
演練二：高價值客戶在截止日前未遷移
提前 90 天產生客戶清單，驗證客戶經理、技術支援和產品負責人都有明確 owner。為未回應客戶提供一次技術診斷和限期例外，而不是在最後一天直接關閉。
演練三：下線後錯誤峰值
在小流量或沙箱中回傳 410 與遷移連結，確認 SDK、監控和客戶文件能引導修復。設定自動回復或恢復舊路由的短窗口，並記錄觸發條件。
常見誤區與追問
誤區一：只發一封棄用電子郵件
通知不能取代使用清單、程式碼範例、測試環境和支援入口。遷移需要在客戶實際工作流中可執行。
誤區二：把版本號當成全部相容性
同一版本內也可能有欄位、錯誤和認證變化。必須維護逐項差異清單與契約測試。
誤區三：永久保留舊版本
沒有退出日期的相容層會分裂文件、拖累基礎設施並擴大安全面。每個例外都要有期限和負責人。
誤區四：只按總請求量排序客戶
低流量應用可能是關鍵帳務或法遵流程。分層應結合業務價值、受影響範圍和技術複雜度。
誤區五：忽略未版本化呼叫
依賴預設版本的客戶可能在下線後看到行為變化。應主動識別未帶版本標頭的請求，並在過渡期發出提示。
誤區六：沒有驗證回復和延期
只演練成功遷移無法證明風險可控。要提前驗證錯誤引導、例外核准、回復窗口和延期條件。