夜雨聆风团队全面使用 AI 编程工具后的第一个月，数据通常很好看。
提交次数增加了，关闭的任务更多了，代码行数也明显上涨。以前要写两天的接口，一下午就能跑起来。周会上有人把这些数字放进报表，得出结论：研发效率提高了 40%。
再过一阵，另一组数据开始变难看。
PR 等待 Review 的时间变长，测试环境经常被某个大改动占住。线上小问题变多，但很难归因到一行代码。开发者感觉自己一直在交付，Reviewer 却觉得每天都在替别人读代码。
两个感受都是真的。AI 确实加快了编码，也把团队原有的瓶颈推到了后面。
代码供给变快，审查能力没有自动扩容
一个团队原来每天产出五个 PR，每个改动两三百行。现在 AI 能快速补齐接口、测试、数据结构和文档，PR 数量涨到八个，单个改动也更大。
Reviewer 还是那几个人。他们每天能认真理解的业务上下文和代码量没有翻倍。
结果不是简单地“Review 慢一点”，而是形成队列。等待中的 PR 会过期：目标分支继续变化，需求细节被忘掉，多个改动互相冲突。作者等了两天才收到意见，又要重新进入上下文。编码省下的一小时，可能在返工里花掉三小时。
大 PR 还有一个隐蔽问题。几百行改动时，Reviewer 会逐段推理；几千行改动时，人很容易退化成抽查：测试跑了，命名还行，看起来能用，那就合并。AI 生成的代码通常形式整齐，更容易制造“应该没问题”的感觉。
代码行数是最危险的效率指标
如果按新增代码量计算效率，复制一套实现比抽象公共逻辑更高效，删除废代码反而没有产出。这和软件维护的真实目标正好相反。
PR 数量也不可靠。把一个完整任务机械拆成十个提交，数字会变好，用户拿到功能的时间没有变化。
更接近交付结果的指标，可以从这些地方选：
从任务进入开发到生产可用的周期；
PR 等待首次 Review 和完成合并的时间
合并后需要返工、回滚或紧急修复的比例；
测试阶段发现的问题与上线后发现的问题
开发者花在理解、审查和修复 AI 代码上的时间。
不需要一次采集所有指标。先选一项速度指标和一项质量指标，例如交付周期与变更失败率。否则团队很容易用十张图解释一个没人敢负责的结论。
做一次四周对比，别靠使用感受
要判断 AI 是否提高团队效率，可以先记录四周基线，再运行四周实验。任务按类型分组，别拿新增页面和核心账务改造直接比较。
PR 模板里增加一个简单字段：AI 参与了哪些部分，生成比例不必精确，但要区分样板代码、核心逻辑、测试和重构。这样做不是为了考核个人，而是为了发现 AI 在什么任务上真正省时间。
每周抽样检查几类数据：相似任务的开发时间有没有缩短，Review 等待是否增加，PR 被打回几次，上线后有没有新增缺陷。还可以访谈 Reviewer：时间花在理解业务、核对生成逻辑，还是修复风格问题。
实验中经常会出现一种结果：简单任务明显变快，复杂任务的编码时间下降了，但评审和返工抵消了收益。这仍然是有价值的结论。它说明 AI 应该优先用于边界清晰的工作，复杂改造需要更强的上下文和验收规则。
限制 PR 大小，比要求“认真 Review”有效
“大家以后认真一点”不是流程。
更可执行的做法，是给改动设置预算。一个 PR 只解决一个可描述的问题；生成代码超过团队能在半小时内理解的规模，就继续拆分。机械生成文件、依赖锁文件可以单独提交，避免淹没核心逻辑。
作者提交前要做一次自己的验收，而不是把未经阅读的生成结果转给 Reviewer。至少确认：关键分支有测试，异常路径可解释，没有顺手改动无关模块，新增依赖确实必要，日志和监控能支持上线后的判断。
AI 参与的核心代码还要有明确所有者。谁提交，谁能解释；谁合并，谁接受上线风险。不能把责任留给“工具生成的”。
对大规模重构，可以先交一份结构性 PR，只移动文件或建立接口；后续 PR 再逐步替换实现。这样 Reviewer 能看清每一步，也容易回滚。让 AI 一次改完几十个文件虽然痛快，却把理解成本集中扔给了团队。
真正要提高的是有效交付
AI 很适合减少样板劳动、补测试、做小范围迁移，也能帮助开发者快速探索陌生代码。它的问题不在于会生成太多代码，而在于团队可能把“生成出来”误当成“已经完成”。
完成意味着需求被验证，改动有人理解，测试覆盖了关键风险，出了问题能观测和回滚。编码只是其中一段。
如果代码产出翻倍，交付周期却没有缩短，先别继续催大家多用 AI。去看 PR 在哪里排队，Reviewer 为什么不敢合并，哪些生成内容反复返工。瓶颈已经换地方了，管理方式也得跟着换。
最有用的效率报表，可能没有代码行数。它只回答两个问题：用户更早拿到可靠功能了吗？团队为这些功能留下的维护负担变轻了吗？
