- 适合：逻辑错误、数据风险、安全漏洞、接口破坏、关键测试缺失
- 不适合：命名偏好、格式、可读性小建议 → 用评论或 Nit
- 发出时给出明确清单：哪些必须改、哪些可讨论
- 作者修复后主动复核并解除阻塞状态
把意见分层（阻塞 / 非阻塞）能显著减少来回次数。
| 意见分层 | 阻塞项逐条列出，可选项标注 nit 或建议 |
|---|---|
| 解除条件 | 作者修复后逐条回复，评审者复核并解除阻塞 |
什么时候用请求修改（Request changes）
请求修改适用于必须修复后才能合入的问题：正确性缺陷、安全风险、兼容性破坏、测试缺失；小建议与风格问题用普通评论即可。
易错点
- 用 Request changes 表达'我不太喜欢这个方案'：方案级分歧应另行讨论
- 多人重复提相同意见：先读已有评论再补充，避免作者重复劳动
数据来源与参考
- Google Engineering Practices · The Standard of Code Review
- GitHub Docs · Request changes 语义