也许我们不应该审查所有这些代码
内容提要
AI生成代码量激增，传统代码审查难以应对。作者认为不应依赖事后审查，而应通过结对编程、团队设计、自动化测试等缩短反馈循环，提前沟通设计、知识共享和架构对齐。仅对高风险变更保留人工审查，避免审查成为瓶颈，强调工程师理解系统而非差异。
延伸解读
反馈循环前置
作者认为，代码审查之所以成为瓶颈，是因为反馈发生得太晚。与其在代码完成后进行审查，不如通过结对编程、团队设计会议等方式，在设计阶段就进行沟通和知识共享。这样不仅能提前发现设计问题，还能让团队成员更早地理解系统，减少对事后审查的依赖。
审查的适用场景
并非所有代码都需要人工审查。作者建议仅对高风险变更保留人工审查，例如涉及安全边界、影响范围大或团队不熟悉的代码。对于格式化、静态检查等确定性任务，应通过自动化工具处理。这样可以将有限的人力集中在真正需要人类判断的地方，避免审查成为瓶颈。
理解系统而非差异
作者担心，过度依赖代码审查会让工程师只关注代码差异，而忽视对系统整体架构和设计意图的理解。随着AI生成代码量的增加，这种风险加剧。作者强调，团队需要通过协作设计、共同运维等方式，确保工程师理解系统的工作原理，而不是仅仅审查代码变更。
Q&A
为什么作者认为不应该审查所有AI生成的代码？
作者认为AI生成的代码量远超人类审查能力，传统的事后代码审查无法应对。更重要的是，代码审查被用来解决错误的问题，如知识共享、团队协作等，这些应该通过更早的反馈循环来实现，而不是等到代码完成后再审查。
作者建议用什么方法替代传统的代码审查？
作者建议采用结对编程、团队设计会议、自动化测试、静态分析、适应度函数和持续验证等实践，将反馈提前到决策点，而不是依赖事后审查。这些方法能更好地实现知识传递、集体所有权和架构对齐。
在什么情况下作者认为仍然需要人工代码审查？
作者认为对于高风险变更，如根本性架构变化、涉及敏感安全边界、影响范围巨大、关键系统的不熟悉部分，或团队缺乏信心的变更，仍需要经验丰富的人工审查。
作者如何回应Brian Houck关于认知和意图债务的担忧？
作者承认认知和意图债务是真实问题，但认为强制性的拉取请求不是有效的防御。相反，应通过协作设计、结对、良好边界、可执行架构和共享运维责任来维持人类对系统的理解，让工程师理解系统而非差异。
作者认为代码审查被过度赋予了哪些职责？
作者认为代码审查被赋予了质量门禁、安全检查、架构审查、指导机制、知识共享系统和所有权模型等过多职责。这些职责本应通过更早的协作实践来实现，而不是集中在审查环节。
作者为什么认为等待代码审查才开始重要对话是错误的？
作者认为重要的对话（如设计决策、知识传递）应该在实现之前或过程中进行，而不是等到代码完成后。等待审查意味着反馈延迟，且无法在决策点及时调整，导致返工和瓶颈。
