代码评审（Code Review）本该是提升代码质量的手段，却常常变成消耗团队情绪的战场。问题往往不在技术本身，而在于意见的"重量"没有被区分：把个人偏好说得像阻塞项，把真正的缺陷轻描淡写成"随便看看"。
三类意见，三种分量
阻塞项（Blocker）：不修就不能合并。判断标准是可验证的客观问题，例如：逻辑错误、空指针风险、并发下的数据竞争、安全漏洞（如拼接 SQL、未校验的用户输入）、明显的性能退化、破坏既有接口契约。这类意见要写清楚为什么会出问题，最好给出复现场景或反例。
建议项（Suggestion）：可以合并，但改进会更好。例如：可以复用的已有工具函数、更清晰的命名、拆分过长的函数、补充边界测试。建议项要允许作者说"这次先不改"，并说明理由即可。
个人偏好（Nit / Preference）：纯粹风格口味，例如大括号位置、变量名长短、注释用中文还是英文。这类意见要么交给格式化工具和 lint 规则自动解决，要么明确标注为"非必须"，不要让它拖住合并。
一个实用的表达模板
每条评论前加一个标签，读者一眼就能判断优先级：
[阻塞]这里在userId为空时会抛异常，建议先判空或提前返回。[建议]项目里已有formatDate工具函数，可以复用，减少重复逻辑。[偏好]个人更习惯早返回，不改也完全没问题。
标签的价值在于把判断权交还给作者，而不是让作者从语气里猜你的态度。
让意见不被反感的几个习惯
- 对事不对人：说"这个分支在并发下可能读到脏数据"，而不是"你怎么又没考虑并发"。
- 给理由，不只给结论："这里建议加索引"不如"这个查询在数据量上万后会全表扫描"。
- 区分"必须"和"可以"：把真正影响正确性、安全性的问题标为阻塞，其余放行。
- 控制数量：一次评审只挑最重要的几条，避免几十条细枝末节淹没关键问题。
- 先肯定再提意见：指出做得好的部分，不是客套，而是让作者知道哪些模式值得保留。
- 能自动化就别手评：格式、导入顺序、命名规范交给 lint 和 CI，人只看机器判断不了的东西。
作为作者，也可以主动降低摩擦
提交前自己先过一遍 diff，把"我知道这里可以更好，但受限于 X"写进描述里；对每条评论明确回复"已改""暂不改，原因是……"。评审是双向的，作者越清楚，评审者越容易聚焦。
小结
代码评审的核心不是证明谁更懂，而是让代码更可靠、团队更省心。把意见分成阻塞项、建议项、个人偏好三层，配上明确的标签和理由，既能守住质量底线，也不会让同事觉得被挑刺。长期看，这比任何"沟通话术"都更有效。