題幹與適用場景
這道題考察你能否把一次重要技術取捨變成可搜尋、可評審、可演進的團隊記憶。回答需要涵蓋何時值得寫 ADR、如何記錄被否決的選項、如何讓記錄服務程式碼評審與後續排障，以及如何處理被新決定取代的舊記錄。
適用對象包括後端、平台、SRE、技術負責人與需要跨團隊協作的工程師。假設團隊已有程式碼儲存庫和評審流程，但沒有統一的決策記錄規範；方案可能涉及可靠性、安全性、介面、相依性或不可逆的成本取捨。
面試官考察點
第一，能否辨識「架構上重要」的決定，而不是把每個實作細節都寫成文件。第二，能否用中性背景、限制、選項和後果解釋為何做出選擇。第三，能否把 ADR 放進提案、評審、接受與取代的生命週期。第四，能否讓記錄在程式碼評審、入職與故障排查中真正被使用。
回答前需要釐清的問題
- 這次決定影響系統結構、關鍵品質屬性、公開介面還是一般實作細節？
- 當前有哪些硬性限制，例如延遲、可用性、合規、團隊技能、遷移窗口與成本？
- 方案已經上線，還是仍處於 Proposed 狀態？誰有接受或拒絕權限？
- 團隊把 ADR 放在程式碼儲存庫、文件庫還是兩者同步？如何搜尋並通知受影響團隊？
- 未來哪些訊號會觸發重新評估，例如流量、故障率、成本或法規變化？
30 秒回答框架
「我先確認這是否會影響系統結構、關鍵品質屬性或難以逆轉的介面；如果是，就建立一份短小的 ADR。記錄問題背景、限制、候選方案、否決原因、最終決定、取捨、風險和狀態，並讓受影響團隊在 Proposed 階段評審。接受後把記錄視為不可變歷史，需求變化時新增一份 Superseding ADR，連結舊記錄並更新索引。最後把 ADR 放到團隊能存取的版本庫，在設計評審、程式碼評審、入職和排障時引用。」
分步驟深入解答
第一步：判斷是否達到記錄門檻
當決定影響系統結構、關鍵品質屬性、公開介面、重要相依性或難以逆轉的成本時寫 ADR。一般變數命名、一次性重構細節和已有明確標準涵蓋的選擇不必單獨建檔。門檻的目標是保留真正會影響未來判斷的上下文，避免文件噪音讓重要決定失去可見性。
第二步：用中性背景描述問題
先寫問題、使用者或業務影響、功能與非功能需求、期限和不可違反的限制。不要把偏好的方案寫進背景，也不要用「某團隊堅持」取代事實。背景應讓沒有參加討論的新成員理解為什麼現在必須做決定。
第三步：列出選項和取捨
列出實際考慮過的方案，包括被否決的選項及原因。用可比較的維度說明延遲、可用性、故障半徑、安全性、遷移成本、維運負擔和團隊能力；無法量化時明確寫出假設和信心等級。候選方案不需要寫成完整設計指南，細節可以連到獨立的評估文件。
第四步：寫出明確的決定與後果
決定句應能單獨閱讀，例如「我們採用區域化佇列，並接受跨區切換需要人工核准」。接著寫預期收益、代價、風險、需要補充的控制和受影響元件。只寫「選擇方案 A」無法支援未來評審，因為讀者看不到當時的理由和承擔的代價。
第五步：設定狀態、擁有者和評審
常見狀態包括 Proposed、Accepted、Rejected、Deprecated 和 Superseded。指定記錄擁有者，邀請受影響團隊在 Proposed 階段閱讀並留言；接受時補充日期、利害關係人和版本。評審目標是確認事實、限制、選項和後果完整，而不是追求所有人永遠同意。
第六步：把 ADR 放進工程工作流
將 ADR 與程式碼儲存庫或團隊文件庫一起版本化，建立可搜尋索引。設計評審和程式碼評審遇到違反已接受決定的修改時，應連結對應 ADR 並要求明確的變更記錄。新人入職、交接和線上排障也應能從 ADR 了解「為什麼這樣做」，減少重複爭論。
第七步：需求變化時新增記錄
接受或拒絕後的 ADR 保持不可變。若新證據、規模、成本或法規改變了結論，建立一份新的 ADR，記錄變化背景、舊決定的限制和新取捨；新記錄接受後，將舊記錄標為 Superseded 並互相連結。如此既保留歷史，又讓讀者能快速找到目前有效的決定。
高品質示範回答
「我會先確認這是不是影響系統結構、關鍵品質屬性、介面或難以逆轉成本的決定；如果只是局部實作細節，就不增加 ADR。達到門檻後，我在 Proposed 記錄問題背景、使用者和非功能需求、限制、候選方案、否決原因、最終選擇、取捨、風險和信心等級。
我會邀請受影響團隊在評審時間內先閱讀，再討論未解決的問題；記錄狀態、擁有者、日期和利害關係人。接受後把 ADR 放在可搜尋的版本庫中，在設計評審、程式碼評審、入職和排障時引用。記錄保持短小、事實化，不取代完整設計文件。
如果需求或證據改變，我不會改寫已接受記錄。我會建立新的 ADR，說明舊決定為何不再適用、有哪些新選項和後果；新記錄接受後把舊記錄標記為 Superseded 並建立連結。如此團隊看到的是目前決定，同時仍能追溯每次取捨。」
常見錯誤
- 把 ADR 寫成完整設計文件 → 讀者找不到決定本身 → 保留背景、選項、決定和後果，細節另鏈。
- 只記錄最終方案 → 未來重複爭論 → 寫出被否決選項和當時限制。
- 用個人偏好取代限制 → 記錄無法複核 → 使用中性、可觀察的事實與假設。
- 接受後直接修改原文 → 歷史被覆蓋 → 新增記錄並標記舊記錄為 Superseded。
- 沒有狀態和擁有者 → 團隊不知道是否生效 → 設定生命週期、負責人和接受日期。
- ADR 存在但沒人引用 → 文件成本沒有收益 → 接入設計評審、程式碼評審、入職和排障。
追問及應對
追問 1：團隊意見不一致時能接受 ADR 嗎？
可以。記錄未解決的異議、風險和接受權限；評審的目標是讓決定和代價可見，而不是製造虛假的一致。若需要補資料，可以保持 Proposed 並安排驗證任務。
追問 2：什麼時候應該回溯補寫 ADR？
當現有系統有重要但沒人能解釋的結構、介面或品質屬性取捨時，可以根據提交記錄、事故資料和維護者訪談補寫，並明確標註這是對既有決定的回溯記錄，避免把推測寫成當時事實。
追問 3：ADR 應該放在儲存庫還是 wiki？
優先放在受影響程式碼附近的版本庫，便於和實作一起評審；如果業務和安全團隊需要更廣存取，可以同步索引或摘要，但要保留單一權威來源，避免兩處內容漂移。
追問 4：如何證明 ADR 有價值？
觀察新成員理解關鍵決策所需時間、重複爭論次數、程式碼評審中違反已接受決定的發現率，以及事故排查時能否快速找到背景。指標用於發現盲點，不應把文件數量當作目標。