產品經理面試：B2B SaaS 是否應該公開 API 變更日誌？

題幹與適用場景

客戶說你們的 API 變更總是透過私訊通知，難以追蹤和評估影響。你需要判斷是否建立公開 API changelog，並定義受眾、變更分類、敏感資訊邊界、通知渠道、指標與路線圖。

GitHub Releases 將版本、說明與可下載資產作為可追蹤的發布物件；RFC 9745 則定義機器可讀的 Deprecation 回應標頭。它們說明發布記錄與執行時訊號可以互補，但不會自動解決租戶權限、破壞性變更揭露或客戶行動優先級。

這道題考察開發者產品的溝通與治理，不等同於 API 版本下線實作、一般文件中心建設或上一題的長期支援定價。

面試官考察點

• 能否驗證開發者真正需要可追蹤性、影響評估還是更快的支援回應。
• 能否設計穩定、可篩選、可訂閱且不洩露敏感資訊的變更記錄。
• 能否區分新增、修正、行為變化、安全修正與破壞性變更。
• 能否把 changelog 與文件、SDK、Deprecation 訊號和客服流程連起來。
• 能否用採用率、遷移結果與支援成本決定是否擴大投入。

回答前需要釐清的問題

1. API 使用者是公開開發者、已認證租戶、合作夥伴還是內部團隊？
2. 目前通知覆蓋率、遺漏率、支援工時與因變更造成的事故是多少？
3. 哪些內容可以公開，哪些只對受影響租戶或合約客戶可見？
4. 客戶希望訂閱 RSS、電子郵件、Webhook、主控台提醒還是版本差異 API？
5. 誰負責撰寫、技術審閱、法務審閱與變更發布後的追蹤？

30 秒回答框架

先用開發者訪談、支援工單與變更事故驗證可追蹤性是否是問題，再推出公開的版本化 changelog。每筆記錄包含影響範圍、動作、遷移連結、發布日期與破壞性等級；敏感修正只透過受控渠道通知。讓記錄與文件、SDK 及 Deprecation 標頭同步，先試點高呼叫量 API，觀察閱讀到遷移的轉化、通知覆蓋與支援工時。

分步驟深入解答

1. 定義使用者問題與價值

把「想要 changelog」拆成四種需求：發現新能力、判斷破壞性影響、證明合規變更、追蹤已處理的遷移任務。訪談開發者、技術負責人、支援與安全團隊，收集他們如何從電子郵件、工單和文件拼出時間線。

按呼叫量、收入、整合關鍵程度與變更風險分群。若客戶只需要收到關鍵棄用通知，完整公開時間線未必是第一優先級；若客戶需要稽核證據，還要提供版本封存與匯出。

2. 設計變更分類與最小欄位

至少區分新增、修正、行為變化、棄用、安全修正與破壞性變更。每筆記錄包含發布日期、版本、受影響端點或 SDK、影響說明、動作、遷移截止時間、文件連結與負責人。

不要公開漏洞利用細節、租戶名稱、未發布客戶承諾或內部事故調查。安全修正可先用模糊描述與受控通知，待風險窗口過去再補充公開說明。欄位結構固定，避免只寫行銷文案。

3. 選擇公開與受控渠道

公開 changelog 適合通用新增與版本時間線；登入後主控台適合顯示租戶實際受影響端點；電子郵件、Webhook 或 RSS 適合持續訂閱。高風險安全事件與合約例外需要受控通知，並保留觸達記錄。

每個渠道指向同一筆規範記錄，避免電子郵件、文件與主控台出現不同日期。支援按版本、產品區域、變更等級篩選，並提供機器可讀格式供客戶內部系統消費。

4. 連接執行時與開發工具

對已棄用端點回傳 RFC 9745 Deprecation 訊號，並在適用時提供替代端點與遷移文件。SDK 發布說明、型別定義與範例程式碼應引用相同變更 ID。

把 changelog 條目與 API 規範、測試、文件與發布流水線關聯。若端點行為由設定或地區決定，記錄適用條件，避免開發者只看到一個泛化標題。

5. 建立撰寫與審核流程

工程提交結構化變更草稿，產品確認使用者影響與動作，技術寫作者統一語言，安全與法務檢查揭露邊界。發布前檢查版本、端點、日期、連結與遷移步驟。

設定更正機制：發現錯誤時保留原記錄、標註修訂時間與影響範圍，不靜默覆蓋歷史。對重大變更指定負責人，負責追蹤客戶遷移與後續問題。

6. 指標與實驗

追蹤訪問、訂閱、受影響客戶觸達、文件點擊、遷移開始、遷移完成、錯誤率與支援工時。將記錄閱讀與真實新版本請求、成功業務結果關聯，避免把頁面瀏覽量當成價值。

先為一個高呼叫量 API 開啟訂閱與租戶影響視圖，比較事故率、支援工時與遷移週期。若閱讀率低但工單減少，仍可能有價值；若通知增加焦慮卻沒有行動，應優化分類與行動連結。

7. 路線圖與停止條件

第一階段建立結構化範本、公開頁與受控通知，涵蓋新增與棄用。第二階段增加版本篩選、RSS/Webhook、租戶影響分析與 SDK 變更關聯。第三階段提供歷史匯出、變更 API 與自動遷移任務。

當條目無法及時審核、誤報導致信任下降、受影響客戶沒有遷移動作或維護成本超過支援節省時暫停擴展。沒有可靠資料的變更不要自動發布，寧可保持人工審核。

高品質示範回答

我會先驗證客戶缺的是時間線、影響評估還是關鍵通知，再推出版本化公開 changelog。條目區分新增、修正、行為變化、棄用、安全修正與破壞性變更，包含影響端點、動作、日期、遷移連結與負責人；敏感安全內容走登入後的受控渠道。

執行時的 Deprecation 訊號、文件、SDK 與 changelog 使用同一變更 ID。先在高呼叫量 API 試點，觀察通知覆蓋、遷移完成、真實新版本請求、事故率與支援工時，再決定增加訂閱、影響分析與自動遷移能力。

常見錯誤

• 只把 changelog 當行銷新聞，沒有影響範圍與下一步動作。
• 所有客戶看到相同內容，洩露租戶、漏洞或合約資訊。
• 只發電子郵件，不在執行時、文件與 SDK 提供一致訊號。
• 把瀏覽量當成遷移成功，不驗證真實新版本請求。
• 允許工程直接發布，缺少產品、技術寫作、安全與法務審核。
• 靜默修改歷史記錄，導致客戶無法重建當時的影響判斷。
• 沒有停止條件，持續增加篩選、訂閱與自動化功能。

追問及應對

為什麼要公開，而不是只發電子郵件？

公開記錄提供可搜尋、可回溯的時間線；電子郵件與主控台負責把行動提醒送達受影響客戶。兩者共享規範記錄，避免重複維護。

安全修正也要公開嗎？

先按風險與揭露時間窗決定。高風險細節透過受控渠道通知，公開記錄只提供必要影響與修正狀態，避免幫助攻擊者重現。

如何證明 changelog 減少了問題？

比較通知覆蓋、遷移完成、事故率、支援工時與新版本成功請求，而非只看訪問量。用高呼叫量 API 做前後對照試點。

誰擁有最終發布權？

工程提供事實，產品確認影響與動作，技術寫作者保證可讀性，安全與法務審閱揭露邊界。重大變更指定單一負責人跟進結果。

客戶想要機器可讀格式怎麼辦？

提供穩定的 JSON 或 RSS 結構，包含變更 ID、版本、等級、受影響範圍、日期與遷移連結；保持欄位相容並記錄修訂。

什麼時候停止投入？

當維護成本超過支援節省、誤報損害信任、客戶沒有遷移行動或審核無法及時完成時暫停擴展，先修正資料與流程。