文章指出当前代码审查的重要性提升，但许多工程师仍存在误区。核心错误是仅关注代码差异（diff），而忽略系统整体性。高质量审查应结合代码库全局知识，指出重复代码位置不当等问题，才能有效维护长期代码质量。

代码审查中工程师常犯的错误

过去两年间，代码审查的重要性显著提升。虽然借助大语言模型（LLM）生成代码变得容易，但审查代码的难度丝毫未减[1]。如今许多软件工程师花在审查AI工具输出上的时间，已经超过审查同事代码的时间。

常见错误与改进建议

1. 不要只审查代码差异（diff） 最大的误区是仅聚焦于代码差异进行审查[2]。最高价值的审查意见往往与差异无关，而是基于对整个系统的理解。例如："这个方法其实已经存在于某处，无需重复添加"——这类建议需要审查者熟悉代码库的其他部分。

2. 控制评论数量 笔者认为优质代码审查的评论不应超过5-6条。过多评论会淹没重要意见。面对20处命名规范问题，建议用一条概括性评论替代逐行指正。例外情况是新成员入职时，可通过密集风格评论帮助其适应团队规范。

3. 避免"我会怎么写"的审查视角 工程师常陷入这种模式：逐段对比"我的写法"与当前代码，导致大量主观意见。需牢记软件问题通常存在多种合理解决方案，审查不是强加个人偏好的场合。

4. 明确阻止合并的审查 审查状态（通过/评论/阻止）比评论内容更重要。若存在严重问题，应直接使用阻止审查，避免造成"能否合并"的模糊地带。批准意味着"即使忽略我的评论也可合并"。

5. 多数审查应为通过状态 在标准SaaS代码库中，高比例的阻止审查往往意味着过度把关。特别是当基础架构团队成为功能团队的瓶颈时，双方目标不一致可能导致不必要的阻碍。除非存在严重问题或特殊情况（如新人能力不足/近期事故），应倾向于批准变更。

核心原则总结

• 关注PR中未编写的代码，而非仅审查差异
• 提供少量深思熟虑的评论，而非大量即兴批注
• 用"是否有效"替代"是否符合我的风格"作为审查标准
• 明确使用阻止审查表达反对
• 若无重大问题，尽量批准变更

这些原则也适用于AI生成代码的审查，但对其可适当加强把关。需注意的是，代码审查可服务于多种目标（知识共享、设计讨论、规范统一等），不同团队应根据优先级采取相适方法。

[1] 当前AI审查工具虽有用，但仍无法媲美人类工程师的全局判断力。 [2] "diff"指现有代码与提议修改之间的差异对比。 [3] 当功能团队与基础团队目标冲突时，往往需要高层介入解决。

以下是评论内容的总结：

1. 对文章的整体评价

多数评论者认为这是一篇好文章，赞同其主要观点。 - "This is actually good article." (watwut) - "Great article, fully agree with all the points." (Learner100)

2. 关于代码审查的严格程度

存在两种不同观点： 严格审查派： - "If a PR requires a 100 comments, so be it." (suralind) - "A piece of code should match the general style of the code it is being integrated into." (OptionOfT)

灵活审查派： - "your job is not to gatekeep the code" (dakiol) - "Code review is not the time for you to impose your personal taste on a colleague." (siva7)

3. 审查工具与流程改进建议

• 建议使用自动化工具处理格式问题："Leave that to the robots. Set up linting and style checkers" (awithrow)
• 提出LLM辅助审查的设想："automated walk through of a pull request...with commentary along the way generated by the LLM" (dchuk)
• 推荐标准化评论格式："Is anyone else using conventional comments" (moltar)

4. 审查中的具体实践建议

• 应检查本地分支："check out the branch locally...Your IDE might have more checks enabled" (hexbin010)
• 关注文件位置："I have to check every single file path...might end up under Orders somehow" (donatj)
• 避免无关讨论："when the comments involve things that have nothing to do with the PR" (AndyNemmity)

5. 审查意见的效力问题

关于非阻塞性评论是否会被忽视的讨论： - "Do people actually ignore a comment explaining a problem...just because it wasn't a blocking review?" (makeitdouble) - "a comment is basically a blocking, except if it's explicitely flagged as optional" (makeitdouble)

6. 审查的思维方式

• 不赞成完全以个人偏好审查："don't use this to generate a lot of comments" (criemen)
• 反对过度优化长期纯度："reviewers over-optimizing for long-term purity instead of short-term progress" (ramanvarma)