写代码更快了，但团队真的更快了吗？
最近一年，AI coding 工具最大的变化不是「能不能写代码」，而是「能把提交速度推到多快」。一个熟练使用 Cursor、Claude Code 或 Copilot 的开发者，一下午产出的代码量，往往能顶过去几天。
表面上看，这当然是生产力跃迁。但在实际协作里，我越来越强烈地感受到另一件事：代码生成速度提升之后，团队积累得最快的资产未必是功能，而是 代码审查债务（Code Review Debt）。
所谓代码审查债务，不是说 PR 没人看，而是说 提交增长速度已经超过了团队稳定理解、验证、追责这些改动的能力。代码能写出来，不等于团队能真正消化它。
为什么 AI 时代更容易产生审查债务
过去一个工程师写一段复杂逻辑，速度本身就是天然闸门。你写得慢一点，往往也意味着你在实现过程中会不断自检。现在这个闸门被弱化了。AI 把样板代码、边界分支、测试骨架、接口拼装全部加速，PR 可以很快从 200 行膨胀到 2000 行。
问题在于，审查者的认知带宽并没有同步扩容。Review 仍然要靠人理解业务、判断边界、识别风险、联想上下游影响。AI 解决了「生成」问题，却没有顺手解决「信任」问题。
- 改动体积更大 —— AI 很擅长“一口气补全”，于是一个本来该拆成 3 个 PR 的需求，经常被合并成一个巨型提交
- 局部看着都对 —— 生成代码往往语法完整、命名体面、结构像样，最危险的问题反而藏在业务前提、兼容性假设和异常路径里
- 责任边界变模糊 —— 当作者自己也只是“指导 AI 产出”，他对每一行代码的确信程度，可能比传统手写时代更低
团队已经欠下审查债务的几个信号
这类债务最麻烦的地方，是它早期不像性能瓶颈那样容易被监控到。系统照样能跑，迭代也照样在继续，但团队对代码的真实掌控感正在下降。
- PR 合并越来越快，但回归问题也越来越多 —— 这通常说明团队在追求吞吐量，而不是在建立理解
- Review 评论越来越偏表面 —— 大家只改命名、排版、文案，而很少讨论业务假设、状态流转或失败路径
- 作者自己也说不清关键设计 —— 一旦 reviewer 追问“为什么这样做”，回答开始退回到“AI 是这么补的”或“这样跑通了”
- 代码能改，但没人敢动 —— 新功能可以堆上去，可一遇到重构、抽象、替换实现，团队普遍心虚
如果这些现象开始频繁出现，团队欠下的不是文档债，也不只是测试债，而是更根本的理解债。
真正有用的应对方式，不是禁用 AI
我并不认为答案是“回到手写时代”。AI coding 已经是现实生产力，不可能也没必要倒退。关键在于，团队要把流程从“默认相信生成速度”切换成“主动保护审查质量”。
- 强制缩小 PR 粒度 —— 与其限制是否用 AI，不如限制一次提交能跨多少模块、引入多少行为变化
- 要求作者写出“风险说明” —— 不是总结功能，而是明确这次改动最可能出问题的地方、没有覆盖到的边界、reviewer 应重点看的区域
- 把 AI 用在审查准备上 —— 让它先产出变更摘要、调用链分析、测试建议，帮助 reviewer 更快进入上下文，而不是只帮作者扩写代码
- 保留人工问责点 —— 每个关键 PR 必须有能解释设计取舍的人，不能把责任外包给工具
说白了，AI 可以放大产能，但不能替团队完成“对代码负责”这件事。这个责任必须被重新设计到流程里。
最后：别让吞吐量伪装成工程能力
今天很多团队都在追求“更快交付”，这没有问题。但如果衡量指标只剩下提交数、PR 数量、需求完成速度，AI 会很轻易地把这些表面指标全部拉高，同时悄悄透支真正稀缺的东西：理解力、可维护性和团队信任。
从长期看，工程团队的护城河不是“谁能生成更多代码”，而是“谁能在更高生成速度下，仍然保持系统可控”。这也是我越来越在意代码审查债务的原因。
写得更快当然很好，但如果没有对应的审查纪律，速度最后只会变成一种更昂贵的混乱。