AI改的代码 根本不审就直接放生产环境了
想象一个很常见的工程现场：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 改动是否恰好正确，而是这种“默认接受”的比例正在快速上升。
每位开发者每周新增代码行数，从 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 改动分成四档。
落地也不复杂：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”。更重要的问题应该是：这是几级风险？
就跟小作坊随便找人画图是一样的，随意画，没有审核，侥幸能用就用，不行再说，损失大约可以跑路
页:
[1]