分歧怎么处理
评审意见不一致时的处置顺序很清楚：先确认双方在讨论同一个问题（目标、约束、事实前提是否一致），再讨论方案；用数据与规范条款说话；两轮之内没有收敛就转当面或语音沟通；最后由作者综合意见决策，并把理由写回改动或设计文档里。
基本信息
| 第一步 | 澄清事实与目标：前提不一致时先对齐前提 |
|---|---|
| 依据优先 | 性能数据、兼容性要求、规范条款优先于个人偏好 |
| 收敛信号 | 双方能复述对方观点，并认可其中合理的部分 |
| 裁决记录 | 作者综合决策后把理由写入 PR 或设计文档 |
处置步骤
- 先确认是否在争论同一个问题：目标、约束、事实前提是否一致。
- 用数据与规则说话：性能数据、兼容性要求、既有规范条款。
- 两轮未收敛就转当面或语音沟通，半小时胜过三天评论。
- 把结论写回改动里留记录，说明为什么这样定，避免同类争议重复出现。
- 僵持不下时请负责人或架构师裁决，并明确谁来记录结论。
- 情绪开始升温时先暂停：换异步或当面沟通，比继续在评论区推进更有效。
分歧类型与处理
| 分歧类型 | 处理方式 |
|---|---|
| 事实分歧 | 补数据、日志或文档，用证据定论 |
| 方案取舍 | 列出选项与代价，请作者决策并记录理由 |
| 目标不一致 | 回到需求与约束确认，必要时请产品方澄清 |
| 风格偏好 | 交给格式化工具与团队规范，不进入辩论 |
评审目标是代码库健康，不是「谁赢」；僵持时可请负责人或架构师裁决。
作者保留最终决策权，但需要为决策负责：把取舍理由写清楚，下一次遇到同类问题的讨论会快很多。
把已达成一致的部分先固化：分歧点往往只有一两处，其余意见可以先落地，避免整条改动被一起拖住。