🎯 什麼情境該想到我
當技術討論或 code review 變成人身衝突、大家開始護短，或者提意見怕傷感情的時候。
出處：《高效程式設計師的 45 個習慣》習慣 3「對事不對人」。分工：這張是即用版；原書的完整內容（魔鬼的誘惑、三種回應的對照、四個技巧、平衡的藝術）→ 態度決定一切：對事不對人。
⚙️ 怎麼用
良策
「对事不对人。让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。」（旁註：消極扼殺創新）
三種回應的對照（原書的例子）
同事提出一個新方案：
- 「那样很蠢！」——否定個人能力。
- 「那样很蠢，你忘记考虑它要线程安全。」——指出缺點，但仍然在否定；而且如果對方回「它本來就跑在自己的執行緒上」，你會很難堪。
- 「谢谢。但是我想知道，如果两个用户同时登录会发生什么情况？」——只有這種有效：提出具體的顧慮，而不是下結論。
讓討論保持對事的四個技巧（原書）
- 設定最終期限：例如午餐前做出決定。沒有最好的答案，只有更合適的。
- 逆向思維：先看方案的優點，再努力從反面去認識它。
- 設立仲裁人：主持人確保每個人都有發言機會，防止明星員工主導；仲裁人不發表自己的意見。
- 支持已經做出的決定：客戶不在乎是誰的主意，結果才重要。
平衡的藝術（節錄）
- 盡力貢獻想法，沒被採納也不需要生氣。
- 「資料庫廠商可能會倒閉」這種說法不夠，要評估發生的可能性。
- 只有更好，沒有最好——不存在「最佳實踐」，只有特定條件下更好的實踐。
- 不帶情緒不等於盲目接受：用合適的詞和理由說明你為什麼不同意。
在 code review 裡的樣子
| ✗ 對人 | ✓ 對事 |
|---|---|
| 「你又忘了處理錯誤。」 | 「這個函式在 ctx 被取消時會回傳什麼？」 |
| 「這寫法太菜了。」 | 「這裡用 map 會不會比較快？這個 slice 可能有幾千個元素。」 |
| 「誰寫的這段？」（在事故中） | 「這段程式碼在什麼情況下會拿到空值？」 |
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- 對事不對人不等於不在乎人的感受：用尊重的語氣談事，兩者兼顧。
- 需要心理安全作為前提：在會懲罰錯誤的團隊裡，再怎麼強調對事不對人，大家還是不敢開口（見 工具-心理安全感）。
- 明顯的問題要直接說：安全漏洞、會造成事故的 bug，提問式的說法可能太隱晦。
🔗 相關工具
- 態度決定一切 —— 原書第 2 章的完整展開
- 工具-心理安全感 —— 前提條件
- 工具-無指責事後檢討 —— 同一原則在事故場景的制度化版本
- 用提問代替命令 —— 卡內基的版本