评审沟通的语气
评审沟通的核心是对事不对人：先问清意图，再给出依据，最后提供替代方案。把「你这样写不对」换成「这里如果输入为空会怎样？」更容易达成共识，也让讨论聚焦在代码本身而不是作者身上。
基本信息
| 基本原则 | 先理解再判断、评论指向代码而非作者、给出可执行建议 |
|---|---|
| 高频场景 | 设计分歧、历史包袱、紧急修复 |
| 升级方式 | 分歧较大时改为同步沟通，再把结论写回评审记录 |
| 措辞尺度 | 公开仓库的评论会长期留存，先确认适合公开场合 |
| 判断依据 | 给出可验证理由，例如边界条件、性能影响、维护成本 |
典型使用场景
- 指出明显缺陷时避免让对方感到被否定
- 设计分歧需要先对齐目标再谈实现方式
- 紧急修复的评审需要更聚焦风险与回滚方案
- 改动历史包袱代码时先说明背景与约束
- 给新人的提交提供更多解释性的反馈
表述对照
表述对照
差：这写法太差了
好：这个实现每次请求都会做全表扫描，数据量上来会有性能问题，
能否改成按主键查询？我整理了一个参考写法，见下面的建议块。
# 提问式反馈同样有效：
# 「这里的超时值定成 30 秒，是基于什么考虑？」措辞对照
| 容易引起对抗的写法 | 更有效的写法 |
|---|---|
| 这样写不对 | 这里在输入为空时会怎样 |
| 为什么不这样做 | 换成另一种方式能否覆盖这个场景 |
| 这是常识 | 我在文档里看到另一种做法，你更倾向哪个 |
| 重写吧 | 建议把这段拆出来便于单独测试，你看是否合适 |
先问意图再下判断：看似奇怪的写法背后常有历史原因或线上约束，贸然否定会漏掉关键信息。
在公开仓库评论前确认语气适合公开场合，情绪化措辞会长期留存在历史记录里，后来者只看到结论看不到上下文。