话说回来，

Q3 sprint planning 那天PO 发了一条信息："上个季度 AI 工具提效明显。这个季度我们把需求量加 %，应该问题不大吧？"

那一刻我意识到一件事——AI 没让我们变慢，但管理框架是按旧世界设计的。

我们用了  个月把 AI Coding 工具铺到团队 % 的工程师，Copilot 类工具渗透率从  到全员。代码产出确实快了，但某一天开始，连续几个 Sprint 都"按时完成"，QA 却积压翻倍；绩效季一到，两个最被团队依赖的工程师反而 KPI 排名垫底；招了一个算法面试满分的候选人，实习一周后发现他无法解释自己提交的任何一个实现决策。

这些问题不是 AI 带来的。是我们没有同步更新管理规则，让旧假设悄悄失效了。

我梳理了团队在过去半年里踩过的坑，找到了 6 条程序性失效的研发管理规则。每一条都有具体场景、具体后果、还有我们现在用的修复决策。其实，

第一条失效规则：工时估算的"历史基线"

旧规则

Story Point 和人天估算基于历史速度：每个 SP 大概等于 N 小时每周 sprint 容量基于团队历史 velocity 推算。这套方法稳定跑了三年，

为什么失效了

AI 工具让"写新代码"的速度提高了 - 倍，但 sprint 里其他事情的耗时几乎没变：

• 需求澄清AI 生成的代码往往暴露更多边界情况，反而需要更多澄清轮次
• Code Review代码量增加了review 时间没增加。但质量债在悄悄积累
• 测试QA 的工作量按功能点算，AI 让功能点变多了但 QA 编制没变
• 上线协调多 team 依赖的协调成本跟代码生产速度无关

当"写代码"只占整个 sprint 周期的 %，就算这 % 提速 * 倍，整体提速仍然只有 %——但工程师仍然按照旧基线把这 % 换算成总时间，导致 sprint 容量程序性高估。

使用者痛点

开发快却交付慢、QA 加班、PO 越加激进需求。按理说，

我们的遭遇

连续两个 Sprint。前端进度超前，开发侧"提前完成"，但 QA 阶段的积压翻倍，测试同学连续加班。最终一算的观点是，开发快了约 %。但实际交付慢了约 %——瓶颈从开发挪到了 QA，整体反而更慢。

更糟糕的是"提前完成"的假象让 PO 更激进地加需求量，形成正反馈。

修复决策

我们做了三个改动：

① 拆分任务类型

把 sprint 任务分成"生成型"和"协调型"。两类任务分别估时不混在一起。

② 协调型任务保持旧基线

不因为 AI 整体提效就压缩协调型任务的估时那样只会把压力转移到下游。

③ Sprint 容量里留 % buffer 给 Review 和 Debug

AI 生成代码需要更多 review 和 debug 投入。这笔时间要显式预留，不能假设它会自动消化。

Sprint 容量规划 v2
总可用时间
├── 生成型任务 % → 按 AI 速度估时可激进
├── 协调型任务 % → 按旧速度估时不压缩
└── Review & Debug buffer % → 显式预留，不规划需求

第二条失效规则：Code Review 的"一人 approve 即可"准入

每个 PR 至少有 N 个 reviewer approve 后才能 merge。Reviewer 自己决定 review 深度——简单改动快速过复杂逻辑多花时间。这套规则在 PR 平均 - 行的年代运转得很好。

AI 工具让单次 PR 的代码量大幅增加。我们的实测数字：A I介入前 PR 平均 diff≈ 行；AI介入后涨到≈ 行，

"一人 approve"规则没有变，但它内在假设的 PR 规模已经变了。AI 生成的代码看起来结构规整、命名合理、注释完整，却隐藏更深层次的逻辑陷阱。导致 reviewer 容易产生认知捷径：代码看起来没问题 → approve。

P R 大幅膨胀导致 reviewer 疲劳，仅审阅少数关键行；上线后出现难以捕捉的隐蔽 bug。

A 某功能 PR diff 行，reviewer 花了 分钟 approve。上线两天后发现并发 bug：AI 生成的数据库操作未处理 race condition，高峰期才暴露。

A事后复盘的观点是，reviewer 没有发现这个 bug 并非能力不足。而是因为在  行代码里他真正仔细读的只有前 行——后面是“扫了一眼”。这是reviewer 疲劳,而非失职。其实，

A引入分级 review 机制。不再用“一人 approve”一刀切：

PR 类型与 Review 要求矩阵
轻量改动	快速通过
	配置/样式/注释类
普通改动	正常深度
	AI 密集 PR
主要方法 → 必须 ≥2 reviewers + EM 同步审查

"理解度签名": reviewer approve 时需在评论里标注理解层级：

• L1 – 代码结构和意图清晰，逻辑方法已验证；
• L2 – 主方法已验证，仅抽样检查边界情况；
• L3 – 快速浏览，仅信任作者。

第三条失效规则：绩效 KPI 的"代码量/PRs"度量

A季度绩效 KPI 中，将代码产出作为主要度量之一：代码行数 / PRs merged / 功能点交付。这些指标可量化、可对比，从而降低评定主观性。

• #1 代码行数：A I 工具让每行代码几乎不消耗工程师精力，每行含金量下降；
• #2 PRs merged：A I+快速改动导致 PR 数膨胀，却不代表真实产出；
• #3 功能点交付：A I 加速实现，却未捕获程序设计、需求拆解、技术决策等稀缺产出。

A造成一种反选择：A I 重度使用者 KPI 自动高于少用或不用 A I 的工程师，即便后者承担更难、更有价值工作。

使用者痛点⚠️

• A K P I 与实际价值脱钩，引发公平感缺失；
• A 团队内部出现“谁用 A I 就能拿高分”的误导风气；
• B 主要项目贡献者因 KPI 不佳产生挫败感。

🔧 工程师 A:

- AI 重度使用

- 本季度 PRs merged 为团队均值X倍
行数最高
KPI 排在前面。不过，

💡 工程师 B:

- 主导消息队列重构

- 实际实现 code 行数不多。但每行都是关键方法

- 上线零故障
KPI 排名中下.




两位同事面对相同绩效程序，却因衡值差异产生截然不同感受。B 在考核结束后主动找我：“我不太明白这个 KPI 在衡量什么。”

---

...

---