題干與適用場景
面試官希望了解你如何處理技術分歧，而不是聽到「我會堅持自己的標準」。場景可以是一個 Pull Request：你認為新增的並行複雜度、隱私風險或測試缺口會降低程式碼健康；作者認為這是小問題，要求先合併、以後再清理。請說明事實、討論過程、決定和結果。
Google Engineering Practices 建議先檢查作者是否真的有更好的脈絡，再根據程式碼健康解釋理由；若複雜度會隨時間遺留，通常應在目前變更中處理，緊急情況才例外。高品質回答要把原則落到一次可驗證的協作事件，而不是把作者描述成「難溝通」。
面試官考察點
- 是否先複核自己的判斷，能承認作者掌握了更完整的脈絡。
- 是否用風險、使用者影響、測試證據和維護成本解釋意見，而不是訴諸職位或個人風格。
- 是否區分必須在目前變更修復的阻斷項、可記錄的後續任務和純粹偏好。
- 是否提出最小可行修改、邀請合適 reviewer，並設定清晰的決策和升級路徑。
- 是否量化結果：缺陷避免、回滾減少、審查耗時、團隊關係和後續流程改進。
回答前需要釐清的問題
- 爭議涉及正確性、安全、隱私、效能、可維護性還是個人編碼偏好？
- 你評論的是哪一層：實作、測試、介面契約、發布風險還是團隊規範？
- 作者是否提供新證據、歷史約束或截止時間？誰擁有最終技術決策權？
- 變更是否緊急，是否有灰度、回滾或 feature flag 可以降低風險？
- 你如何保護作者隱私，避免在公開討論中把分歧變成人身評價？
30 秒回答框架
「我先重現或核對事實，確認對方是否掌握我遺漏的脈絡。若問題影響正確性、隱私或明顯降低程式碼健康，我用具體程式碼路徑、測試結果和使用者風險說明為什麼需要在本次變更修復，並提出最小改動；若只是偏好，我標成非阻斷建議。雙方仍無法達成一致時邀請領域 reviewer 或技術負責人，記錄決定和後續任務。最後複盤交付、品質和關係結果。」
分步驟深入解答
第一步：把分歧從人身判斷改成可驗證命題
把「這段程式碼很危險」改成「兩個請求同時更新同一資源時，缺少版本檢查會覆蓋更新」。提供重現步驟、日誌、測試或基準；先確認評論針對程式碼和風險，不評價作者能力。若沒有證據，先提出問題而不是直接阻斷。
第二步：主動檢查自己是否遺漏脈絡
詢問介面契約、歷史相容、上線窗口、依賴團隊和失敗回滾。Google 的指導強調作者可能更接近實作並擁有更好的資訊；如果新證據證明你的建議不成立，應明確承認並撤回，不把堅持誤認為品質。
第三步：分級評論並給出最小修改
將評論分為阻斷、非阻斷建議和表揚。阻斷項對應可重現的正確性、安全、隱私或高機率回歸；風格偏好使用 Nit 或放入團隊規範。提出最小 patch、測試補充或 feature flag，避免把無關重構塞進同一個 Pull Request。
第四步：用程式碼健康目標解釋「為什麼」
說明目前修復如何減少未來維護成本、避免重複事故或改善使用者體驗。不要只貼規則連結；把規則映射到這次變更的路徑、影響面和驗收條件。如果作者反對「現在清理、以後再說」，評估是否會增加複雜度、忘記清理或讓後續變更更難審查。
第五步：建立決策與升級路徑
先在評論中總結雙方共識和未決問題；必要時安排短會或邀請擁有領域權限的 reviewer。技術負責人應根據證據、程式碼健康和交付約束決定，而不是讓職位高低代替推理。將無法立即解決的非阻斷問題建立有 owner 的任務和期限。
第六步：驗證結果並複盤流程
合併前驗證測試、靜態檢查、灰度指標和回滾路徑；合併後觀察缺陷、回滾、審查輪次和交付時間。若同類 pushback 反覆出現，改進設計評審、PR 範本或文件，而不是每次依靠個人說服力。對緊急變更縮短審查範圍，但仍記錄風險和補救計畫。
高品質示範回答
「在一次並行快取改造中，我評論缺少請求版本校驗。作者認為這是理論問題，建議先合併。我先用兩個並行更新的測試重現舊值覆蓋新值，並確認該介面會修改訂單狀態，所以它屬於目前變更的正確性阻斷項。我承認作者對歷史相容欄位更熟悉，調整方案為保留舊欄位、增加版本條件寫入，並補充衝突測試和指標。」
「我們邀請負責訂單儲存的 reviewer 複核，約定在灰度中觀察衝突率和回滾路徑。作者接受最小 patch 後合併，灰度沒有再出現覆蓋更新；我在評論中說明通過原因，並把更大範圍的快取重構另建任務。複盤後團隊把並行寫入測試加入 PR 範本，後續類似爭議減少。」
常見錯誤
- 以職級或「規範要求」壓過作者 → 對方無法理解風險 → 給出程式碼路徑、證據和驗收條件。
- 所有評論都設為阻斷 → 交付和信任受損 → 區分正確性風險、建議和個人偏好。
- 相信作者一定錯 → 忽略實作脈絡 → 先複核並在證據改變時撤回。
- 把「以後清理」當預設方案 → 複雜度容易永久留下 → 評估風險，立即修復或建立 owner 和期限。
- 在公開評論中評價人格 → 分歧升級為衝突 → 只討論程式碼、影響和下一步。
- 沒有結果指標 → 無法證明處理有效 → 記錄測試、灰度、缺陷、審查耗時和複盤改進。
追問及應對
追問一：如果你發現自己錯了，會怎麼做？
公開承認遺漏的事實，撤回阻斷意見並說明新證據。保留對作者有效的感謝，避免為了維護權威繼續爭論；必要時補充一條記錄，防止團隊重複踩坑。
追問二：作者說截止時間到了，必須先合併怎麼辦？
先判斷風險是否影響正確性、安全或合規。高風險問題保留阻斷，提出縮小範圍、feature flag、灰度和明確回滾；低風險建議可以非阻斷，但建立有 owner 和時間的後續任務。
追問三：雙方仍然無法達成一致怎麼辦？
寫下爭議命題、證據、可接受的風險和備選方案，邀請領域 reviewer 或技術負責人決定。會後在 PR 中記錄結論和理由，讓未來讀者無需重新爭論。
追問四：如何避免 Review 變成瓶頸？
提前做設計討論，拆分小 PR，使用自動化測試和靜態檢查，把純風格規則交給工具。審查者優先處理高風險設計，再處理局部建議，緊急路徑保留最小審查和補救記錄。