代码审查
代码审查（Code Review）是软件开发过程中由开发者对他人所编写代码进行系统性检查的实践活动。其目的在于发现缺陷、优化代码结构、确保符合编码规范，并促进团队知识共享。代码审查通常发生在代码合并前，可通过人工或借助工具辅助完成，是保障软件质量的重要质量控制手段。
核心事实
时间轴 (近 90 天)
应对 agent 放大过度设计传播的常用做法是在 agent 上下文中显式加入约束（如'只实现当前测试用例覆盖的需求，不要添加未使用的参数或配置项'），并在审查环节把'是否服务于当前需求'作为独立的检查问题。
代码审查环节完全没有跟上代码生成的节奏：review时间增加了49%，需要返工修改的PR比例几乎翻倍，review中的评论数量多了约三分之一。
代码审查是一个比代码生成更靠近“质量守门”环节的场景，ReviewBench的出现说明业界开始认真对待AI在该环节的能力评估。
代码审查中涉及架构层面的取舍和团队约定等隐含知识很难被完整编码进基准测试中。
当任务有清晰的规格和可验证的结果时，较弱的模型只要照着指令走，就能交出接近顶级模型的结果。
针对 AI 生成代码的审查需要审查者假设代码可能在看起来正确的情况下做了错误的事，并围绕意图而非实现进行验证
代码审查的核心正从语法、代码风格、命名规范等表层问题转向业务逻辑、失败场景、安全性、性能和长期可维护性的判断
合并AI代码前应亲自运行测试与检查，而不是依赖助手声称的测试已通过
审查AI代码时应先看代码差异（diff）形成自己的判断，再看AI写的总结，以避免被总结叙述框住思路
合并请求（Pull Request / PR）是现代软件协作的核心机制，开发者在独立分支完成开发后向主代码库发起合并申请并经代码审查后合入主干
还有 17 条时间轴事件
全部知识事实 (20)
AI代码审查并非要完全取代人类，而是形成高效互补，AI负责机械性检查，人类负责架构决策和业务逻辑判断
90%已验证当一次代码审查超过 400 行代码时，审查者的缺陷发现率会急剧下降
80%已验证如果审查AI生成代码的成本高于自己动手，那么这个智能体的实际价值就大打折扣
65%已验证正式代码审查流程可追溯到1970年代Michael Fagan在IBM提出
65%已验证有工程师指出AI生成的代码在安全性审查、性能优化方面存在问题
65%已验证AI 代码分析是辅助判断工具，无法完全替代人工审查
65%已验证在AI大规模参与代码生产的时代，传统人工Code Review流程可能需要被AI辅助自动化审查、更严格的自动化测试覆盖等新范式取代
65%待验证一些团队已开始在审查流程中明确标注哪些代码是AI生成的，以便审查者调整审查策略
60%待验证人工代码审查平均只能发现约60%的缺陷
60%待验证应对 agent 放大过度设计传播的常用做法是在 agent 上下文中显式加入约束（如'只实现当前测试用例覆盖的需求，不要添加未使用的参数或配置项'），并在审查环节把'是否服务于当前需求'作为独立的检查问题。
50%待验证代码审查环节完全没有跟上代码生成的节奏：review时间增加了49%，需要返工修改的PR比例几乎翻倍，review中的评论数量多了约三分之一。
50%待验证代码审查中涉及架构层面的取舍和团队约定等隐含知识很难被完整编码进基准测试中。
50%待验证代码审查是一个比代码生成更靠近“质量守门”环节的场景，ReviewBench的出现说明业界开始认真对待AI在该环节的能力评估。
50%待验证当任务有清晰的规格和可验证的结果时，较弱的模型只要照着指令走，就能交出接近顶级模型的结果。
50%待验证针对 AI 生成代码的审查需要审查者假设代码可能在看起来正确的情况下做了错误的事，并围绕意图而非实现进行验证
50%待验证代码审查的核心正从语法、代码风格、命名规范等表层问题转向业务逻辑、失败场景、安全性、性能和长期可维护性的判断
50%待验证合并AI代码前应亲自运行测试与检查，而不是依赖助手声称的测试已通过
50%待验证审查AI代码时应先看代码差异（diff）形成自己的判断，再看AI写的总结，以避免被总结叙述框住思路
50%待验证面对五到十倍的审查量，审查者的时间与注意力无法同比例扩张，导致代码审查这道质量防线崩塌
50%待验证合并请求（Pull Request / PR）是现代软件协作的核心机制，开发者在独立分支完成开发后向主代码库发起合并申请并经代码审查后合入主干
50%