杀死代码评审表演，保留评审本身
内容提要
作者修正半年前“杀死代码评审”的观点：逐行评审已过时，但替代方案不应只是AI查diff。评审的核心是建立团队对系统的共同理解，而非找bug；AI能查错却缺乏判断力与问责。新方案分五层：让AI先辩论、记录意图与验收标准、建立“AI劣质模式登记表”、保留团队讨论决策环节，并明确谁拥有不变量。
延伸解读
评审的真正价值：构建团队共识
文章指出，代码评审的核心并非找bug，而是建立团队对系统的共同理解。研究显示，44%的开发者将找缺陷视为评审首要目的，但实际只有14%的评论涉及缺陷。评审是知识传递和心智模型构建的场合。AI虽能查错，却无法替代这种共识构建。若只关注缺陷，会忽视评审对团队协作和系统理解的长期价值。
AI评审的局限与风险
AI评审不会疲倦、能逐行检查，但它缺乏判断力、问责能力，且不了解决策背景。它无法告诉你“不要构建这个功能”，也无法被追责。将AI用于逐行diff审查，而人类仅做形式化批准，会形成“评审表演”。更严重的是，自动化评审可能删除团队讨论系统设计的唯一固定场合，导致共享理解流失。
五层新方案：从辩论到不变量
作者提出五层替代方案：让AI在PR创建前辩论并记录分歧；记录意图与验收标准；建立“AI劣质模式登记表”并转化为不变量；保留团队讨论决策环节；明确谁拥有不变量。其中，登记表是最易启动的一层，可从最近1000条评审评论中提取前20个模式作为不变量。这些层次旨在将AI用于其擅长之处，同时保护人类判断。
责任转移与团队新角色
责任已从作者转移到评审者，再转移到编写不变量的团队。这意味着所有权不再意味着逐行审查代码，而是拥有治理代码的不变量并维护其背后的心智模型。文章警告，若不明确谁拥有不变量以及所有权的含义，事故会替你定义。团队需要主动讨论评审的新目的，并调整工具与文化以协同演进。
Q&A
作者为什么说半年前提出的“杀死代码评审”观点是错的？
作者仍然认为逐行评审已过时，但承认自己提出的替代方案错了。原方案只关注用AI查diff，却忽略了评审的核心是建立团队对系统的共同理解，而非仅仅找bug。
代码评审的真正核心目的是什么？
代码评审的核心是建立团队对系统的共同理解，促进知识在团队中流动。找bug只是次要任务，研究表明只有14%的评审评论涉及缺陷。
AI代码评审有哪些局限性？
AI评审不会疲倦、能读每一行，但它没有参与决策过程，训练数据与所审代码同类，无法判断是否该构建该功能，也无法被问责。它看的是错误的工件（diff），且不了解决策背景。
作者提出的新五层方案包括哪些内容？
新方案分五层：1. 让AI在PR创建前先辩论，记录分歧；2. 记录意图与验收标准；3. 建立“AI劣质模式登记表”，将重复评论转化为不变量；4. 保留团队讨论决策环节；5. 明确谁拥有不变量。
为什么说“自动化评审会删除共享理解”？
代码评审是工程师唯一定期讨论系统的时刻。自动化评审虽然对抓bug影响小，但会消除这种对话，而知识共享正是代码评审的产物。如果不小心自动化，就会删除团队共享理解。
在新的评审模式下，责任和所有权发生了怎样的变化？
责任从作者（写代码）转移到评审者（读并批准），现在转移到编写不变量的团队。所有权意味着拥有治理代码的不变量并维护其背后的心智模型，逐行评审不再属于其中。
