微软873名工程师的研究数据，推翻了我们用了十年的审查逻辑。
Bacchelli和Bird在2013年ICSE会议上发表的研究，可能是软件工程领域被引用最多、却被实践最少的一篇论文。他们追踪了微软内部多个团队的代码审查流程，统计了数千条审查意见，然后得出了一个让管理层不舒服的结论：所有人嘴上都说审查是为了"发现缺陷"，但缺陷在实际审查产出中只占少数。
真实的审查意见分布是这样的：代码改进建议——重构这段、换个更简单的写法、命名再清晰一点；知识传递——解释现有代码为什么写成这样，把只有某个同事知道的上下文挖出来；团队认知同步——让审查者了解系统另一部分的设计，把一个技术决策扩散到整个组织。缺陷当然存在，但只是评论里的少数派。
这个发现直接指向四个需要改变的实践。
第一，停止用"发现缺陷数"考核审查者。这个指标优化的方向是错的。一个审查者留下十条有用的重构建议、零条bug记录，他做的是高价值工作。而数缺陷的KPI会把人推向简单的挑刺——风格、命名——让人回避那些更难但更有复利效应的结构反馈。
第二，选审查者看上下文理解，不看"抓bug能力"。同一项研究发现，审查效果主要取决于对变更的理解深度：它的历史、依赖关系、团队之前的决策。这意味着把审查轮给最熟悉相关子系统的人，比派给最资深的全栈工程师更有效。
第三，把审查当成入职工具。既然知识传递是主要产出，那审查就是你最便宜的培训机制。让每个初级提交的PR配一个资深审查者，不是为了抓他漏掉的bug，而是为了在对话里传递团队的心智模型。
第四，AI审查工具要优化对的事情。现在大多数基于大模型的PR审查工具，都在调优"标记潜在问题"这个能力。这是人类审查里杠杆最低的象限。高杠杆象限是建议更好的写法、浮现上下文。能跳出缺陷标记、进入上下文感知重构建议和架构评论的工具，才是真正能放大团队能力的。
更深层的道理是：代码审查的价值在团队层，不在代码层。代码是媒介，团队的共享理解才是产品。
你们团队的审查流程实际在优化什么？这是你想要的吗？
热门跟贴