一、先看闭环长什么样环节目标Author小步提交、自测、把意图写进描述Reviewer找风险、问假设、补知识空白CI自动化能抓的不要浪费人工Merge达成「可维护的同意」而不是「没人反对」【一句话】 Review 的产品不是评论数是合并后的系统质量与团队共识。二、评审应该把注意力花在哪里优先看正确性与边界条件并发、幂等、安全、数据兼容可读性与模块边界三个月后谁维护测试是否证明关键路径可观测性失败时好不好查可以放手交给工具/指南纯格式化争议用统一 formatter无影响的命名洁癖循环「我个人更喜欢另一种写法」但并无风险差异【结论】 人脑看风险与设计机器看风格与回归。别反着来。三、评论怎么写才不伤人弱评论更强的写法这写得不行这里在并发下可能重复扣减建议…给出场景改成我这样两个方案A 简单 / B 更稳我倾向 B因为…同上具体指出文件与假设避免堆「1」实用句式「我的理解是…若理解错了请纠正」「风险在于…是否可加测试锁住」「非阻塞建议…」与「合并前必须…」分开标记【避坑】 对人下结论对代码提证据。人格攻击是团队债务不是技术严格。四、作者侧也要会「被评审」PR 描述写清动机、方案、风险、测试方式尽量小 PR巨型变更无人能认真看对评论默认善意解读先回应问题再解释委屈不同意就给数据/反例而不是情绪对撞五、团队最小清单【清单】关键路径必须至少一人 ReviewCI 红禁止合并评论区分「必须改 / 建议 / 提问」2448 小时内有首轮反馈按团队约定反复出现的问题沉淀进规范或自动检查写在最后代码评审是工程团队的免疫系统 太松会感染太紧会过敏。【一句话带走】 好的 Review 让缺陷更便宜也让知识在团队里流动。你们团队 Review 更大的问题是「没人看」还是「看得太怼」欢迎留言。