產品經理面試：API 版本生命週期支援是否應該收費？

題幹與適用場景

你的 B2B SaaS 有三個仍在使用的 API 版本。工程團隊希望只免費維護最新版本，銷售卻承諾大客戶長期相容。你需要決定哪些版本繼續服務、如何通知棄用、由誰承擔遷移工具，以及長期支援是否應該成為付費能力。

RFC 8594 定義表示資源可能在未來失效的 Sunset 回應標頭，RFC 9745 定義表示資源已棄用的 Deprecation 回應標頭。它們提供機器可讀的溝通訊號，卻不會替產品團隊決定支援期限、客戶分層或遷移責任。

這道題討論 API 生命週期產品治理與商業邊界，不等同於「如何實作 API 下線」或「如何制定 API 採用策略」。

面試官考察點

• 能否把相容性承諾連結到客戶價值、續約與工程成本。
• 能否定義版本、支援等級、棄用通知與遷移成功的可驗證契約。
• 能否區分所有客戶應得的安全修正與可收費的長期維護服務。
• 能否處理銷售例外、合約承諾、生態公平與自助遷移體驗。
• 能否用指標、試點與停止條件管理生命週期，而非無限承諾。

回答前需要釐清的問題

1. 舊版本的呼叫量、收入、客戶集中度與主要失敗場景是什麼？
2. 哪些變更屬於安全修正、錯誤修正、功能增強或破壞性變更？
3. 客戶合約是否已有支援年限、通知期、服務等級與賠償條款？
4. 客戶能否不改業務邏輯就切換版本，是否有 SDK、遷移報告與測試環境？
5. 銷售承諾是個別例外，還是已形成所有大客戶都會要求的市場預期？

30 秒回答框架

先按使用量、收入、風險與遷移難度分群，再把安全修正與棄用通知設為基礎承諾。最新版本與有限窗口的舊版本免費維護；超過窗口的長期支援可以收費，但必須包含明確的版本範圍、回應等級、遷移工具與退出日期。用相容性指標、遷移完成率與支援成本試點，驗證客戶是否願意為風險降低付費，再決定是否擴大。

分步驟深入解答

1. 先驗證問題是否值得商業化

建立版本地圖：每個版本的請求量、活躍客戶、收入、錯誤率、敏感資料風險、SDK 覆蓋與預計遷移工時。把客戶分成可自助遷移、需要協助遷移與合約約定長期相容三組。

訪談開發者、採購、安全與客戶成功團隊，確認客戶購買的是舊版本本身，還是遷移風險、停機風險與內部審批成本。若多數客戶只是缺少遷移文件，收費長期支援可能會懲罰可透過產品改進解決的問題。

2. 設計分層生命週期

可採用「目前版本、維護版本、棄用版本」三態。目前版本獲得新功能與一般修正；維護版本只接收安全與高影響錯誤修正；棄用版本繼續回傳清楚的遷移指引與機器可讀通知，並在承諾日期後停止服務。

每個版本公開發布日期、棄用日期、停止日期、支援範圍與替代版本。Deprecation 用來表達棄用狀態，Sunset 用來表達預計失效時間；文件、主控台、SDK 警告與客戶聯絡人應使用同一時間線。

3. 劃定免費與付費邊界

免費層應包含安全修正、公開遷移文件、變更記錄、穩定的棄用通知與合理遷移窗口。付費長期支援可以包含更長維護期、專屬回應、遷移評估、批次相容測試與自訂連接器，但不能把修正產品自身安全缺陷作為加價項目。

定價可以按版本數量、支援期限、呼叫量或服務等級分層。合約必須寫明涵蓋端點、修正類別、回應時間、客戶配合義務、例外審批與最終停止日期，避免銷售口頭承諾形成無限責任。

4. 設計遷移工具與證據

先提供差異報告、棄用端點清單、請求範例、SDK 版本建議、沙盒與回放測試。對可自動改寫的參數提供 codemod 或 lint 規則，對語意變化則提供人工檢查清單與灰度流量。

用遷移成功率、失敗原因、回滾次數、測試覆蓋與從通知到切換的天數判斷工具是否有效。不要把「客戶點擊了遷移指南」當成遷移完成，完成必須以新版本真實請求與關鍵業務結果為準。

5. 處理銷售例外與公平性

建立例外登記：客戶、承諾人、合約條款、版本範圍、到期日、成本與替代方案都可稽核。短期例外應有價格與退出日期，不能只靠工程團隊私下維護分支。

對所有客戶公開相同的基礎時間線；付費客戶獲得額外服務能力與更長窗口，但不應獲得隱瞞棄用或繞過安全修正的特權。若歷史合約衝突，先讓法務與銷售確認義務，再由產品發布統一公告。

6. 評估成本、風險與指標

成本包括建構矩陣、測試環境、值班、文件、SDK 與舊相依套件的安全修正。風險包括舊版本漏洞、遷移失敗導致停機、客戶被鎖定的感受與生態碎片化。

核心指標包括舊版本呼叫占比、棄用通知觸達率、遷移完成率、遷移失敗率、支援工時、長期支援毛利、重大安全修正時效與續約影響。按客戶分層觀察，避免大客戶少量呼叫掩蓋大量小客戶的遷移負擔。

7. 路線圖與停止條件

第一階段清理版本地圖、合約承諾與通知機制，選兩個客戶試點遷移工具。第二階段上線主控台提醒、差異報告、沙盒與付費長期支援合約。第三階段根據呼叫下降、遷移成功與毛利決定是否停止舊版本或增加自動化。

停止條件包括安全修正無法按期完成、例外數量持續增加、遷移失敗造成高風險事故、客戶不願付費且呼叫價值下降，或維護成本超過保留收入。達到條件時凍結新客戶接入舊版本，提前公告並執行最終停止計畫。

高品質示範回答

我會先畫出版本使用、收入、合約與遷移難度，再把安全修正與棄用通知設為所有客戶的基礎承諾。目前版本提供新功能，維護版本只修安全與高影響錯誤，棄用版本在公開窗口內繼續服務，並透過 Deprecation 與 Sunset 標頭、主控台與文件發出一致通知。

長期支援可以收費，但收費內容應是更長窗口、專屬回應、遷移評估與相容測試，不能把產品安全缺陷收費化。先用差異報告、沙盒與回放測試幫助兩個客戶遷移，觀察呼叫下降、完成率、失敗率、支援工時與續約影響，再決定擴大付費支援或按停止條件關閉舊版本。

常見錯誤

• 只按工程方便立即關閉舊版本，沒有查看收入、合約與遷移風險。
• 把安全修正放進高價方案，破壞基本信任與安全責任邊界。
• 只發布部落格通知，沒有機器可讀的棄用時間、主控台提醒與客戶觸達記錄。
• 承諾「長期相容」卻沒有端點範圍、回應等級與最終停止日期。
• 把遷移文件瀏覽量當成遷移成功，不驗證真實新版本請求。
• 為單一大客戶維護私有分支，導致版本矩陣不可稽核。
• 沒有凍結新客戶接入舊版本與最終停止的退出條件。

追問及應對

為什麼不全部免費維護？

有限窗口的基礎維護降低生態風險；無限期限會持續增加測試與安全成本。付費長期支援把額外期限與服務責任明確化，同時保留公平的基礎安全承諾。

客戶說合約承諾了永久相容怎麼辦？

先保存合約證據並讓法務、銷售確認義務。產品上登記例外範圍與到期日，提供遷移方案；在義務未釐清前不單方面停止服務。

RFC 標頭能解決棄用溝通嗎？

不能。Deprecation 與 Sunset 提供機器可讀訊號，但還需要文件、主控台、SDK、客戶聯絡人與支援流程共同執行時間線。

如何防止付費支援變成鎖定客戶？

公開版本規則、匯出遷移工具與停止日期；付費價值放在回應、評估與測試服務上，讓客戶能在沒有供應商協助時完成基本遷移。

什麼時候值得提供 codemod？

當參數變化可靜態識別、客戶數量大且失敗模式穩定時值得提供。語意變化或資料遷移仍需沙盒、回放與人工校驗，不能承諾全自動安全轉換。

哪個指標決定停止舊版本？

綜合呼叫占比、關鍵客戶覆蓋、遷移完成率、失敗風險、支援成本與合約義務。單一呼叫量門檻無法反映少數高風險客戶的影響。