AI 提效之后，研发管理必须重写的6 项规则与决策矩阵

cmzznet

232人浏览 · 2026-06-14 12:50:22

cmzznet · 2026-06-14 12:50:22 发布

AI 提效之后，研发管理必须重写的 6 项规则与决策矩阵

导读：当 AI Coding 工具渗透率从 0 到 80%，研发团队的管理框架也需要同步更新。本文从工时估算、CR 准入、绩效 KPI、晋升标准、招聘筛选、HC 规划六个维度，结合团队真实案例，逐条分析失效原因和修复策略。

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

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

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

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

一、工时估算规则失效：历史基线不再可用

旧规则

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

失效原因分析

AI 工具让"写新代码"速度提升了 3-5 倍，但 sprint 里其他环节耗时几乎没变：

环节	AI 提效程度	说明
写新代码	高（3-5x）	AI 生成样板代码、标准功能
需求澄清	无	AI 生成代码反而暴露更多边界情况
Code Review	负（更慢）	PR 体量增加，同等时间理解深度下降
QA 测试	无	工作量按功能点算，功能点增加了
上线协调	无	多 team 依赖的协调成本与代码量无关

当写代码只占 sprint 周期的 30%，就算速度提升 5 倍，整体只提速 27%——但工程师的估时本能还在把这 30% 换算成总时间，导致 sprint 容量系统性高估。

团队案例

连续两个 Sprint，前端进度超前，开发侧"提前完成"，但 QA 积压翻倍，测试同学连续加班。最终结果：开发快了约 40%，实际交付慢了约 20%——瓶颈从开发挪到了 QA。

修复决策

Sprint 容量规划 v2（AI 时代）

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

关键原则：协调型任务（需求分析、系统设计、跨 team 对齐）保持旧基线，不因 AI 整体提效而压缩。

二、Code Review 准入规则失效："一人 approve"成形式

旧规则

每 PR 至少 1 个 reviewer approve 后才能 merge，reviewer 自决 review 深度。

失效原因分析

AI 介入后 PR 体量大幅增加。团队实测数据：

AI 介入前：PR 平均 diff 约 180 行
AI 介入后：PR 平均 diff 约 520 行

同样的 review 时间，只能覆盖原来 1/3 的理解深度。AI 生成代码"看起来对"（结构规整、命名合理、注释完整），但逻辑陷阱藏得更深（边界条件、并发假设、错误处理路径），更容易触发 reviewer 的认知捷径。

团队案例

某功能 PR diff 540 行，reviewer 花 15 分钟 approve。上线两天后发现并发 bug：AI 生成的数据库操作没有处理 race condition，低流量不触发，高峰期暴露。

事后复盘：reviewer 真正仔细读的只有前 80 行，后面是"扫了一眼"——这是 reviewer 疲劳，不是失职。

修复决策：分级 Review 机制

PR 类型	判断标准	Review 要求
轻量改动	diff ≤ 100 行，无逻辑变更	1 reviewer，快速过
标准 PR	diff 100-300 行，AI 生成占比 < 40%	1 reviewer，正常深度
AI 密集 PR	diff > 300 行，或 AI 生成占比 > 60%	2 reviewer + 必填 checklist
核心路径 PR	涉及 DB schema、认证、支付、核心 API	2 reviewer + EM 同步

引入**“理解度签名”**：reviewer approve 时在评论标注 L1/L2/L3 理解层级，遇到 bug 时能快速定位 review 盲区。

三、绩效 KPI 规则失效：代码量/PRs 指标虚高

旧规则

季度 KPI 核心度量：代码行数、PRs merged、功能点交付。可量化、可对比、主观性低。

失效原因分析

AI 工具让这三个指标全部虚高，失去区分度：

代码行数：AI 生成几乎不消耗工程师精力，每行含金量在下降
PRs merged：AI 生成 + 快速改动 = PR 数量膨胀，但不代表真实产出
功能点交付：加速了功能实现，但真正稀缺的（系统设计、需求拆解、技术决策、跨 team 对齐）没被捕捉

结果：AI 重度用户 KPI 自动高于不用 AI 的高质量工程师，即便后者做了更难更有价值的事。

团队案例

Q3 考核季：工程师 A（AI 重度用户）PRs merged 是团队均值 2.3 倍，KPI 排名第一，但负责的是无技术难度的 CRUD 功能。工程师 B 主导消息队列核心重构，需求分析就花了两周，实现阶段代码量不大但每行都是关键路径，上线零故障，KPI 排名中下。

绩效季结束后，工程师 B 找我聊了，只说了一句：“我不太明白这个 KPI 在衡量什么。”

修复决策：KPI 三维重构

降低量化指标权重：代码量相关 KPI 权重从 30% 降至 10%
引入质量成本反向指标：上线 3 天内 hot-fix PR 数、被 reviewer 驳回 3+ 次的 PR 数、归因到个人的线上 bug 数
显式捕捉难以量化产出：主导的跨 team 对齐次数、系统设计文档、oncall 轮次和 SLA
加入 AI 协作能力加分项：AI 生成代码质量显著高于团队平均（由 reviewer 标注）的工程师得加分——奖励"用好 AI"，不奖励"用多 AI"

四、晋升标准规则失效：portfolio 膨胀难以验证深度

旧规则

晋升答辩：展示独立完成的功能清单、主导的架构设计、参与的技术决策；答辩委员会按 portfolio 规模和复杂度打分。

失效原因分析

AI 让 portfolio 膨胀——候选人可以辅助完成比以前多 3 倍的功能，答辩材料非常丰满。但答辩委员会无法有效区分"AI 辅助完成但候选人完全理解"和"AI 做了，候选人只是提交了"。

功能数量不再是能力的可靠代理指标。

团队案例

工程师走 P5→P6 晋升，展示 12 个 AI 辅助完成的功能，每个有格式规范的设计文档，答辩委员会通过。三个月后，该工程师负责的功能上线出现内存泄漏，排查时无法独立分析 heap dump，也无法解释为何选了当前数据结构，回答是"AI 建议这样做的"。

晋升答辩没有测试到真正需要测试的东西。

修复决策：答辩增加两个新环节

① 现场技术挑战（30 分钟）：答辩前临时给来自生产环境的真实 bug（脱敏），要求候选人当面展示 debug 思路。评委评价思维过程，不评价答案对错。此环节很难靠 AI 作弊。

② Portfolio 附"我做了什么"说明：每个功能条目标注：

需求理解和拆解是否主要由自己完成（Y/N）
技术方案是否主要由自己设计（Y/N，用 AI 的话说明如何验证）
上线后遇到的最难问题是什么，怎么解决的

目的是暴露候选人对自己工作的理解深度，不是惩罚 AI 使用。

五、招聘筛选规则失效：框架熟练度和算法题失效

旧规则

JD 要求：N 年经验、熟悉 X 框架、了解常用设计模式；面试包含 Leetcode 风格算法题和框架 API 问答。

失效原因分析

AI 工具改变了什么是稀缺技能：

能力	AI 前稀缺度	AI 后稀缺度	变化原因
框架 API 记忆	高	低	AI 补全效率 > 记忆效率
Leetcode 算法	高	低	AI 30 秒给出解法 + 复杂度分析
代码实现速度	高	低	AI 辅助，实现速度不再区分候选人
需求拆解能力	中	极高	AI 无法替代
AI 代码审查能力	无	极高	新稀缺技能
工程 trade-off 判断	高	更高	AI 无法替代决策过程

团队案例

招了算法面试两轮流畅、框架问答准确的候选人，实习第一周发现：所有任务都能交付结果，但当 mentor 问"为什么这样做"，无法回答——“AI 建议这样，我就用了”。工作模式是"AI 生成然后提交"，而非"理解然后实现"。

修复决策：面试结构大改

去掉手写算法题：不再能区分候选人，去掉
换成"AI 代码审查"题：给 200 行 AI 生成代码（真实场景脱敏），20 分钟内指出 3 个问题并提出最严重问题的修改方案——测批判性阅读和工程判断
系统设计改为"决策追问"：每当候选人做出技术选择，追问"为什么不用另一种方案"——测当场推理能力，很难靠 AI 辅助

六、HC 规划规则失效："人效倍数"公式不能线性套用

旧规则

HC 需求 = 功能交付量 / 预期人效。AI 提效 2x → HC 需求减半。看起来是合理的线性推导。

失效原因分析

这个公式有一个被忽视的假设：所有岗位的人效都被 AI 等比提升了。

实际情况：AI 主要提升了"写代码"环节的人效，而研发团队里写代码只是总工作量的一部分：

岗位	AI 对工作量的影响	说明
Feature Engineering	减少（AI 加速编码）	同等功能量所需人力减少
QA / Test	增加（功能点增加）	AI 没有替代探索性测试
SRE / DevOps	增加（AI bug 率影响 oncall）	更多代码 = 更多 oncall
EM	不变	协调成本与代码量无关
PM	增加（开发更快，需求讨论更频繁）	需求澄清轮次增加

按"AI 提效系数"统一缩减，砍的往往是 QA 和 SRE——因为它们"看起来是辅助"。

团队案例

年初按"AI 提效系数 1.8x"削减 2 个 QA 名额，理由是"AI 代码质量更高"。结果：当季功能交付量上升，但上线 bug 数上升约 35%，SRE 一位同学连续三个周末有 P1 告警。省下的 2 个 QA 成本，被 SRE 加班、hot-fix 开发和用户投诉处理翻倍消耗——但这些成本分散在不同部门，看起来跟 HC 规划没关系。

修复决策：按岗位类型分开规划

岗位类型	AI 提效影响	HC 规划策略
Feature Engineering	高（3-5x 写代码速度提升）	可适度收紧，但留 buffer，不超过 40%
QA / Test	低（AI 增加了测试需求）	随功能量扩编，不压缩
SRE / DevOps	中低（AI bug 率影响 oncall）	保持或微增
EM / PM	低（协调成本不变）	按团队规模，不变

核心原则：AI 可加速岗位和 AI 无法替代岗位分开规划，不统一套提效系数。

汇总：6 条规则修复矩阵

规则	旧假设	失效原因	修复决策	优先级
工时估算	历史 velocity 可直接套用	AI 只加速写代码，不加速协调和 QA	拆分任务类型，留 20% buffer	高
CR 准入	1 人 approve 即可	PR 规模 3x，review 深度被稀释	分级 review + 理解度签名	高
绩效 KPI	代码量/PRs merged 可代理产出	AI 让这些指标虚高	降低量化权重，引入质量成本反向指标	最高
晋升标准	Portfolio 规模代理工程能力	AI 让 portfolio 膨胀，深度无法区分	加入现场技术挑战 + 自述说明	最高
招聘筛选	框架熟练度和算法题区分候选人	AI 让这些能力不再稀缺	换成 AI 代码审查题 + 决策追问	中
HC 规划	AI 提效可线性缩减 HC	只有写代码岗位被 AI 加速，QA/SRE/EM 不是	按岗位类型分开规划	高