代码审查的意义远不止于（可自动化的）缺陷检测
在 AI 生成代码和自动化审查工具兴起之际，工程师们正在重新审视代码审查究竟是为了什么。许多人认为，虽然机器人和 lint 工具可以捕捉语法问题、基础 bug 和样式违规，但它们无法处理更高层次的问题，比如架构、业务契合度、长期可维护性，以及团队内部的知识共享。也有人反驳说，人工审查无法跟上 AI 加速产出的规模，必须由更强的自动化测试、设计评审以及新的系统理解分发流程来补充甚至取代。
代码审查的目的和价值
- 被认为远不只是找 bug：还包括知识传递、共享对系统的理解、架构防线、验证测试和部署计划，甚至是法律/组织层面的“尽职调查”。
- 有人认为 PR 是最后一道关键关口，架构错误、误解和技术债仍然可以在这里被拦下。
- 也有人说，如果重大问题总是在 PR 阶段才被发现，那说明更早的阶段（设计、站会、结对、需求评审）出了问题。
样式上的吹毛求疵 vs 自动化
- 有人抱怨资深审查者往往只评论格式和标点。
- 强烈支持自动化的 lint/formatter，并通过一次性的样式指南决策来消除无休止的争论。
- 关于自下而上的共识与自上而下的样式强制之间的争论，目的是避免没完没了的讨论。
人类 vs AI 的代码审查
- 许多人指出，LLM 在局部问题上表现不错：语法、简单 bug、性能提示、测试和风格。
- 被普遍认为的弱点包括：
- 架构适配以及对现有模式的复用。
- 诸如可维护性、项目约定和仓库组织之类的“元”问题。
- 业务逻辑、验收标准，以及“我们真的想要这个功能吗？”
- 识别并减少过度设计，以及大块不可审查的 AI 生成内容。
- 有些人表示 AI 审查工具“现在已经足够好”，可以取代大部分人工审查；另一些人则认为流行工具表浅、噪声大且不可靠。
AI 对团队和流程的影响
- 有人担心大量使用 AI 会侵蚀开发者的深层理解，使成本/收益评估和安全变更更困难。
- 某组织描述了一场“危机”：没有人觉得改代码是安全的；他们重新引入了严格的人工代码审查、WIP 限制，以及必须由两个人类签字确认的要求。
- 令人沮丧的是，人工反馈常常只是被再喂回给代理，似乎是在训练工具而不是人。
代码审查的未来
- 有些人预测，对于非关键代码，人工审查将大体消失；人类的重点会转向设计评审和治理。
- 另一些人认为，依靠人工审查去在 AI 的速度下卡住 AI 生成的代码是不可能的；他们主张改用 AI 驱动的测试、元检查，甚至是完整子系统的重建。
- 反对观点则认为：当前 AI 的输出往往杂乱、重复，并且会腐蚀架构；跳过人工审查被视为鲁莽地累积技术债。