產品經理面試題：SaaS 是否應該提供欄位級 API 棄用清單？

題目與適用場景

你的 SaaS 有大量 B2B API 客戶。團隊希望採用 2026 年 6 月發布的 IETF Internet-Draft《A Deprecation Manifest for Field-Level Lifecycle Signalling in HTTP APIs》，透過 application/deprecations+json 告知單一請求或回應欄位的棄用、日落時間與替代項。請判斷是否應把它做成產品能力，並說明範圍、客戶價值、相容策略、發布順序與成功指標。該草案仍是 work in progress，不是最終 RFC。

面試官考察點

• 能否把協定能力轉成客戶問題、遷移工作流與商業價值。
• 能否區分資源級回應標頭（RFC 9745、RFC 8594）與欄位級清單的邊界。
• 能否在標準未定稿時控制承諾、相容性與治理風險。
• 能否用可觀測指標驗證採用率、遷移完成度與誤報率。

回答前需要澄清的問題

1. 客戶主要使用 SDK、OpenAPI 產生器，還是直接解析 JSON？
2. 目前是否已有棄用公告、版本策略與聯絡人通知機制？
3. 欄位棄用是否集中在回應欄位，也包括請求欄位、巢狀陣列與多型結構？
4. 目標是協助人工遷移，還是讓 CI/CD 與 SDK 自動阻斷風險？
5. 哪些客戶、地區或合規場景要求保留舊欄位多久？

30 秒回答框架

先確認問題：客戶難以及時發現欄位級變更，資源級 Deprecation/Sunset 標頭無法表達每個成員的生命週期。我的結論是做「可選的欄位級生命週期訊號」試點，不把草案包裝成穩定標準。第一階段只涵蓋回應欄位，提供清單、文件連結與替代欄位；同時保留 OpenAPI、公告與資源級回應標頭。用試點客戶的發現率、遷移完成時間、誤報率與回滾率決定是否擴大範圍。

分步驟深入解答

1. 定義客戶痛點與邊界

欄位被棄用通常仍會在一段時間內回傳。客戶需要知道「哪個欄位、何時棄用、何時移除、替代什麼」，而不是只看到整個資源有一個生命週期訊號。清單解決發現與編排問題，不改變欄位目前行為，也不能取代版本政策、契約測試或人工溝通。

2. 解釋協定與現有能力的關係

資源級標頭仍是預設通道。欄位級清單可透過 Link 發現：

Link: </.well-known/deprecations>; rel="deprecation"; type="application/deprecations+json"

範例清單：

{
  "deprecations": [
    {
      "target": "response",
      "selector": "$.customer.legacy_name",
      "selectorType": "jsonpath",
      "deprecation": "2026-09-01",
      "sunset": "2027-03-01",
      "replacement": "$.customer.display_name",
      "info": "https://docs.example.com/migrations/customer-name"
    }
  ]
}

在產品設計上應把格式、發現方式與業務治理分開：草案變化時，客戶仍能透過文件與 OpenAPI 取得穩定說明。

3. 選擇最小可行產品

先支援回應中的 JSON 欄位、單一 API 版本與明確日期。暫不承諾所有 JSONPath 方言、請求體變體、GraphQL、二進位協定或自動改寫客戶端。清單唯讀、可快取，並提供原始文件連結與人工確認入口。

4. 設計發布與遷移流程

變更登記後，平台產生清單並校驗日期順序；文件、SDK changelog 與客戶通知同步發布。先對內部 API 與設計合作客戶灰度，再擴大到自助客戶。遇到誤報或日期變更，必須保留版本記錄與回滾開關。

5. 設定治理、風險與指標

治理規則包括欄位擁有者、最短通知期、替代項必須可用、日落前的例外審批。核心指標包括：清單發現率、受影響呼叫識別率、從通知到遷移完成的中位天數、仍呼叫已棄用欄位的請求占比、誤報率、客戶支援工單量與回滾次數。若客戶沒有解析清單，產品應投資 SDK、CLI 或 CI 檢查，而不是繼續堆格式。

6. 做出階段性決策

若試點顯著縮短遷移時間且誤報可控，擴大到請求欄位與巢狀結構；若收益主要來自文件而非機器解析，則把清單保持為進階能力，優先完善 OpenAPI、通知與版本政策。任何對外承諾都應標註草案依據與相容保證。

高品質示範回答

我會做，但先把它定位為「欄位級生命週期訊號」試點，而不是宣傳一個已經定稿的標準。客戶現在能收到資源級 Deprecation 與 Sunset，卻難以知道回應中的具體成員；欄位級清單可以把發現、替代項與日期交給自動化工具。

第一階段只支援一個 JSON 回應模型與明確的棄用、日落日期，保留 OpenAPI、文件與資源級標頭作為相容通道。平台在變更登記時校驗欄位擁有者、替代項與最短通知期，先讓內部及設計合作客戶接入，記錄發現率、遷移中位時間、已棄用欄位呼叫占比、誤報率與回滾次數。清單格式來自 2026 年 6 月的 IETF 草案，因此我會在文件中明確它仍可能變化，並保留關閉或降級開關。

若試點證明客戶能更早發現變更且支援成本下降，再擴大到請求欄位與更複雜結構；若客戶主要依賴文件而不解析清單，就把資源投入轉向 SDK、CI 檢查與通知編排。產品成功標準是減少意外破壞與遷移時間，而不是增加一個協定名詞。

常見錯誤

• 把 Internet-Draft 說成已批准的 RFC，或承諾所有客戶端立即支援。
• 只討論 JSON 格式，不說明欄位擁有者、日期政策、通知與回滾。
• 認為回應標頭可以自動定位任意巢狀欄位。
• 只給「做/不做」結論，沒有試點、指標與停止條件。
• 忽略請求欄位、陣列索引、多型結構造成的選擇器歧義。

追問及應對

如果客戶不解析清單怎麼辦？

把清單作為機器可讀補充，繼續提供 OpenAPI、遷移文件、SDK changelog、Webhook 或電子郵件通知；用發現率驗證真實使用，而不是強迫客戶採用。

如何處理草案發生變化？

隔離 manifest 產生器與客戶 API，記錄格式版本，允許關閉清單或回退到文件與資源級標頭，並在相容性說明中標註草案狀態。

什麼時候支援請求欄位？

當回應欄位試點證明選擇器、日期與遷移流程穩定，而且請求欄位有清晰的驗證與回滾語義後再支援；否則會把誤報直接變成寫入失敗。

你會怎樣證明產品價值？

比較試點組與對照組的遷移完成時間、已棄用欄位呼叫占比、支援工單與回滾率，同時檢查清單解析覆蓋率與誤報率，避免把文件瀏覽量當成遷移成功。