想象一个很常见的工程现场：AI Agent 改完十几个文件，测试全绿，PR 摘要写得很顺。Reviewer 打开页面，扫几眼 summary，再翻几段 diff，最后点了 Approve。
这正是 Cursor 最新开发者习惯报告里最值得警惕的变化：AI 生成代码的速度，正在超过人工审查的速度。
报告显示，AI 改动中“不经过单独人工 diff acceptance step”的比例，从 2026 年 1 月 1 日的 7%，升到 5 月 7 日的 38.5%，5 月 16 日仍有 36.3%。
严格说，标题里的说法是传播化表达。Cursor 的统计口径更窄：缺少单独人工 diff 接受步骤的 AI 改动，进入了提交链路。但即便按这个更谨慎的口径，趋势也已经很明确：传统 code review 正在被 AI 产能挤压。技术团队真正要警惕的，不是某一次 AI 改动是否恰好正确，而是这种“默认接受”的比例正在快速上升。
审查压力来自变更规模
Cursor 的其他数据解释了为什么人会开始“不看”。
每位开发者每周新增代码行数，从 2025 年 1 月 1 日的 3.6K，上升到 2026 年 5 月 16 日的 8.6K。PR 的 P75 行数，从 125.86 行涨到 345.02 行。超过 1,000 行的合并请求占比，也从 8% 升到 13.8%。
AI 没有只是让工程师写得更快。它还让一次变更变得更大、更散、更跨模块。
过去 code review 默认有一个前提：人写代码，人的产出速度天然有限，所以一个 PR 通常还能被另一个人理解。Agent 打破了这个限制。它可以一次改完多个模块、补测试、写摘要，然后把一个“看起来完整”的变更包交给 reviewer。
测试是绿的，摘要是顺的，diff 很长。最容易发生的动作，就是扫几眼，点通过。
传统审查机制的失配
问题不只是 AI 会不会写错。人写代码也会错。
真正的变化是，旧的 review 流程默认“代码写完后再审 diff”。但 AI 生成的变更，往往应该在 diff 之前就被审查：它打算改什么、边界在哪里、测试覆盖什么、哪些模块不能碰。
最小可行的做法，是把 AI 改动分成四档。
| 风险等级 | 典型场景 | 审查要求 |
|---|---|---|
| 低风险 | 样式、文案、局部重构 | 自动检查加快速确认 |
| 中风险 | 业务逻辑、数据模型、跨模块接口 | 先审 plan，再审测试 |
| 高风险 | 认证、支付、并发、数据删除、依赖 | 多人审查，独立边界测试 |
| 禁止自动合入 | 安全敏感、加密、生产配置、合规 | 完整人工评审和专项审查 |
落地也不复杂：PR 模板加三问——风险等级是什么、Agent 的 plan 是否被人工确认、测试是否覆盖失败路径；仓库里用 risk:low、risk:medium、risk:high 标签驱动 CODEOWNERS、必需 CI 和 branch protection。
低风险可以快。中风险必须有人看 plan。高风险必须多人审查。安全、支付、生产配置这类改动，无论测试多绿，都不能自动合入。
这套规则的关键，是把“相信 reviewer 会认真看”，改成仓库层面的硬约束。否则 AI PR 越写越顺，reviewer 越容易把通过测试误认为已经完成审查。
门禁必须前移
Cursor 报告还显示，被接受的 AI 代码在一小时后仍存留的比例，从 76.6% 升到 80.6%。这说明开发者对 AI 输出的信任正在上升。
信任上升不是坏事。危险在于，开发者对 AI 输出的信任已经上升，仓库里的审查制度还停在旧速度。
以后团队不能只问“这个 PR 有没有人 approve”。更重要的问题应该是：这是几级风险？Agent 的计划有没有被确认？测试是不是独立设计的？有没有触碰权限、支付、数据删除、生产配置？
AI 写代码的拐点，不是它开始犯错。真正的拐点，是它写得太快、太完整、太像已经被审过，于是人开始不看了。
