AI Coding 上线后，我们团队失效了的 6 条研发管理规则

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

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

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

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

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

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

旧规则

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

为什么失效了

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

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

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

我们的遭遇

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

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

修复决策

我们做了三个改动：

① 拆分任务类型：把 sprint 任务分成"生成型"（AI 可大幅加速，如标准增删改查、样板代码、单元测试生成）和"协调型"（需求分析、系统设计、跨 team 对齐、bug 排查）。两类任务分别估时，不混在一起。

② 协调型任务保持旧基线：不因为 AI 整体提效就压缩协调型任务的估时，那样只会把压力转移到下游。

③ Sprint 容量里留 20% buffer 给 Review 和 Debug：AI 生成代码需要更多 review 和 debug 投入，这笔时间要显式预留，不能假设它会自动消化。

erlang 复制代码

Sprint 容量规划 v2（AI 时代）

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

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

旧规则

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

为什么失效了

AI 工具让单次 PR 的代码量大幅增加。我们的实测数字：**AI 介入前，团队 PR 平均 diff 约 180 行；AI 介入后，涨到约 520 行。**同样的 review 时间 budget，只能覆盖原来 1/3 的理解深度。

"一人 approve"规则没有变，但它内在假设的 PR 规模已经变了。

更隐蔽的问题是：AI 生成的代码"看起来对"------结构规整、命名合理、注释完整，但逻辑陷阱藏得更深（例如：边界条件、并发假设、错误处理路径）。这让 reviewer 产生认知捷径：代码看起来没问题 → approve。

我们的遭遇

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

事后复盘：reviewer 没有发现这个 bug 不是因为能力不够，是因为 540 行代码里，他真正仔细读的只有前 80 行------后面是"扫了一眼"。这是reviewer 疲劳，不是失职。

修复决策

我们引入了分级 review 机制，不再用"1 个 approve"一刀切：

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

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

L1：代码结构和意图清晰，逻辑路径已验证
L2：主路径已验证，边界情况只做了抽样检查
L3：快速浏览，信任作者，适用于非关键路径

这不是为了追责，是为了让团队知道"这个 PR 的 review 深度是多少"，遇到 bug 时能更快定位。

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

旧规则

季度绩效 KPI 里，代码产出是核心度量之一：代码行数/PRs merged/功能点交付。这些指标可量化、可对比，绩效评定时减少主观性。

为什么失效了

AI 工具让这三个指标全部虚高：

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

这就造成了一种反选择：AI 重度用户的 KPI 自动高于不用或少用 AI 的工程师，即便后者做了更难、更有价值的事情。

我们的遭遇

Q3 考核季，两种结果撞在一起：

工程师 A：AI 工具重度用户，一个季度 PRs merged 数量是团队均值的 2.3 倍，代码行数最高，KPI 排名第一。但他负责的是 CRUD 功能，没有技术难度。

工程师 B：负责团队最核心的消息队列重构，这个项目需求分析就花了两周（大量跨 team 对齐），实现阶段代码量不大但每行都是关键路径，上线零故障。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 规模和复杂度，结合 peer feedback 打分。

为什么失效了

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

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

我们的遭遇

去年底，一位工程师走晋升答辩 P5→P6，展示了 12 个 AI 辅助完成的功能，每个都有清晰的设计文档（也是 AI 生成的，但格式规范）。答辩委员会印象不错，通过了。

三个月后，这位工程师负责的一个功能上线出现了内存泄漏。排查时，他无法独立分析 heap dump，也无法解释为什么选了当前的数据结构------他的回答是"AI 建议这样做的，我觉得 OK 就用了"。

这不是这位工程师的错。这是我们的晋升答辩没有测试到真正需要测试的东西。

修复决策

晋升答辩加入两个新环节，portfolio 展示变成必要条件而非充分条件：

① 现场技术挑战（30 分钟） ：答辩前临时给一个来自生产环境的真实 bug（脱敏处理），要求候选人在答辩委员会面前进行 debug 思路展示。评委不评价答案对错，评价思维过程：是否知道从哪里开始、怎么缩小范围、遇到不确定时怎么处理。

这个环节很难用 AI 作弊------当面展示的是推理过程，不是结果。

② Portfolio 必须附"我做了什么"说明：每个功能条目要求候选人标注：

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

不是为了区分"用 AI"和"不用 AI"，是为了暴露候选人对自己工作的理解深度。

第五条失效规则：招聘 JD 的"框架熟练度"筛选

旧规则

JD 要求：N 年经验、熟悉 X 框架、了解常用设计模式，面试包含手写算法题（Leetcode 风格）和框架 API 问答。这套方法是行业默认标准，用了很多年。

为什么失效了

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

框架 API 记忆：用 AI 补全和文档搜索的效率远高于靠记忆，这不再稀缺
Leetcode 简单题：AI 30 秒给出解法和复杂度分析，这不再是能力筛选器
代码实现速度：AI 辅助让实现速度不再可靠区分候选人

而团队真正需要但旧面试没有测试的能力：

把模糊需求拆解成可实现任务的能力（需求理解、向上沟通）
评估和验证 AI 生成代码的能力（批判性思维）
在多种方案间做 trade-off 的能力（工程判断力）
跨 team 对齐的能力（协作）

我们的遭遇

三个月前招了一位候选人，简历亮眼，算法面试两轮都很流畅，框架问答也准确。实习第一周，mentor 反馈了一个问题：这位候选人在所有任务里都能交付结果，但当 mentor 问"为什么这样做"，他无法回答------不是故意隐瞒，是他自己也不清楚，因为"AI 建议这样，我就用了"。

他没有建立"理解然后实现"的工作模式，而是"AI 生成然后提交"的模式。这在 CRUD 任务上是可以的，但在需要工程判断的场景里会出问题。

我们的面试没有测出这个差异。

修复决策

面试结构大改：

① 去掉手写算法题：不是因为算法不重要，是因为它不再能区分候选人。

② 换成"AI 代码审查"题：给一段 200 行的 AI 生成代码（来自真实场景，脱敏），要求候选人在 20 分钟内：

指出 3 个可能的问题（性能、边界、安全、可维护性，任选）
对其中最严重的问题提出修改方案

这道题测的是批判性阅读和工程判断，而不是代码生成速度。

③ 系统设计改为"决策追问"：给出设计问题后，每当候选人做出一个技术选择，追问"为什么不用另一种方案？""这个 trade-off 你是怎么考虑的？"这部分很难靠 AI 辅助------要当场解释自己的推理过程。

第六条失效规则：HC 规划的"人效倍数"公式

旧规则

HC（Headcount）需求 = 功能交付量 / 预期人效。AI 让人效提升，那 HC 需求下降，这是合理的线性推导。很多团队都在这样规划。

为什么失效了

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

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

QA 的工作量随功能点增加而增加，AI 没有替代人工测试（尤其是探索性测试）
SRE/DevOps 的复杂度随系统规模增加，AI 出 bug 率也影响了 oncall 频率
EM 的协调成本随团队规模和跨 team 依赖增加，这部分 AI 没有帮上
PM 的需求澄清工作量随 AI 生成功能加快而增加（更快的开发意味着更频繁的需求讨论）

当 HC 规划按"AI 让工程师人效翻倍，HC 减半"的公式来做，砍的往往是 QA 和 SRE 编制------因为这两个岗位看起来是"辅助"，而不是"产出代码"的核心工程师。

我们的遭遇

年初规划时，VP 决定按"AI 提效系数 1.8x"压缩 HC，在工程师编制不变的情况下，QA 编制减少了 2 个名额，理由是"AI 生成代码质量更高，测试工作量会下降"。

结果：当季功能交付量确实上升了，但上线 bug 数上升了约 35%，因为 QA 资源被稀释，覆盖度下降。SRE oncall 频率增加，一位 SRE 连续三个周末都有 P1 告警。

"省下的" 2 个 QA 的成本，实际上被 SRE 加班、hot-fix 开发成本和用户投诉处理成本翻倍了------但这些成本分散在不同部门，看起来跟 HC 规划没关系。

修复决策

我们把 HC 规划里的岗位分成两类，分开推算：

① AI 可加速岗位（feature engineering）：这类岗位人效确实被 AI 提升，HC 规划可以按提效系数适度压缩，但不要超过 40%------AI 工具渗透率、工程师适应程度都会影响实际提效。

② AI 无法替代岗位（QA、SRE、EM、PM）：这类岗位的工作量随功能交付量增加而增加，AI 提效系数不适用。更合理的规划基准是"功能交付量增加多少，这些岗位需求增加多少"。

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

汇总：6 条规则修复矩阵

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

结尾

这 6 条规则，每一条在没有 AI 的时候都是合理的、经过验证的。它们失效不是因为设计错了，是因为底层假设变了。

AI Coding 工具改变的不是"工程师的能力"，而是"什么是可量化的产出"这个问题的答案。旧的管理框架是在代码产出稀缺、人工时间宝贵的世界里设计的。现在，代码产出不再稀缺，稀缺的是判断力、系统思维、和对不确定性的容忍能力------而这些东西，旧 KPI、旧面试、旧晋升标准都没有捕捉到。

6 条规则不需要同时改。我们的实际顺序是：绩效 KPI 和晋升标准优先 （影响最深、最难沟通），然后是 CR 准入 （工程侧最快落地），最后是 HC 规划（需要向上汇报，节奏最慢）。

每改一条，都需要跟团队解释清楚：这不是在说 AI 用错了，而是在说管理工具需要跟工具一起进化。

如果你的团队也在被其中某条规则困扰，欢迎在评论区聊聊你们的处理方式。