前言：旧敏捷为何在 AI 时代失效？
我们正在经历一个非常典型的"效率悖论"：
- 个体/局部提速是真实的：在 McKinsey 的实验研究里，开发者在代码文档、代码生成、重构等任务上，完成时间可缩短到接近一半，甚至"最多可快到 2 倍"。
- 但组织/系统层面常看不到同量级改善：Atlassian 2025 DevEx 调研显示，68% 的开发者每周因 AI 节省超过 10 小时，但同时 50% 的开发者仍每周因组织低效"损失 10+ 小时"，90% 的人损失 6+ 小时；结果就是"省下来的时间，被流程摩擦又吃回去"。
- 少数公司确实跑出了系统级增益：McKinsey 对"近 300 家上市公司"的调研显示，AI 落地的头部公司在团队生产力、上市速度、客户体验等指标上实现 16%--30% 改善，软件质量改善 31%--45%，并且强调：靠"上工具"不够，必须重构流程、角色与度量。
一句话：AI 把"写代码"这段路拓宽了，但旧敏捷把"入口、闸口、收费站"都留在了原地。
于是你会看到：原型更快了、PR 更多了、测试更堵了、回归更频繁了、跨端对齐更痛了、线上事故也更"突然"。
下面我们将拆解"旧敏捷在 AI 时代为什么会失效"的 6 个系统问题。
问题一：核心假设与 AI 开发逻辑完全脱节
旧敏捷（Scrum/看板的经典实践）成立的前提，很多隐含假设来自"代码稀缺时代"。AI 把这些假设直接改写了。
旧敏捷核心假设 vs AI 时代开发特性（对照表）
| 旧敏捷核心假设 | AI 时代的开发特性 | 直接后果（系统层面） |
|---|---|---|
| 人是主要瓶颈：写代码最贵最慢 | 代码不再稀缺：AI 能快速生成/改写/重构；实验显示部分任务可提速到接近 2 倍 | 流程还在"管人写代码"，但瓶颈转移到 规范、评审、测试、集成、发布、观测 |
| 需求可切片并相对稳定，适配 Sprint 节奏 | 需求/方案/Prompt/数据每天都在演化（尤其是 AI 功能、策略、运营强驱动场景） | 固定节奏容易造成：输入不清 → 返工上升 → 队列排长 |
| 人工审查兜底质量 | AI 生成速度远超人工审核吞吐；如果闸口不升级，审查就是新瓶颈 | 产能表面上涨，Lead Time 反而变长 |
关键洞察：旧敏捷强调"快速迭代"，但它默认"迭代的主要成本在编码"。AI 时代，编码成本下降，系统成本反而集中在"把不确定性变成确定性"：规格化、验证、观测、回滚。
问题二：度量指标陷入"伪效率"陷阱
AI 时代最容易出现的错觉是：看上去更忙、更高产，但价值交付没变快，甚至变慢。
1. Story Point / 吞吐量为什么更容易失真？
- Story Point、Sprint 完成率、commit/PR 数等，天然偏向"产出规模"，但 AI 会让"产出规模"更廉价。
- 你会得到一种危险信号："我们交付更多了" ≠ "用户更快拿到价值了"。
2. 更合理的度量方向：从"产出"转向"价值流"
McKinsey 2025 强调，高表现组织更关注结果指标（质量、速度）而不是只看"采用率/使用量"。对应到工程侧，你可以把指标体系改成三层：
- 价值流指标 (Outcome)：Idea → Prod 的端到端周期、关键路径功能上线时间、关键体验指标改善
- 质量与风险 (Quality/Risk)：变更失败率、线上回滚率、P0/P1 事故、MTTR
- 队列与摩擦 (Flow)：PR 排队时长、评审等待、测试等待、发布等待、跨团队依赖等待
一个非常实用的判断 ：
如果 AI 让编码更快，但 PR 等待、测试等待没下降，你的"整体交付速度"不会变快。Atlassian 的"省 10 小时又丢 10 小时"就是这个系统现象的量化侧写。
问题三：流程设计造成系统级效率堵塞
旧敏捷的流程很多是为"人写代码"优化的：故事拆分、站会同步、迭代评审。AI 时代真正堵的地方，通常在三个环节。
1. 输入端（需求/规格）模糊，AI 生成"看似可用、实际偏航"
AI 很擅长补全，但不擅长凭空猜"你到底要什么"。如果输入还是"模糊 user story + 口头对齐"，AI 输出会更像"自动脑补"，短期看起来省事，长期返工更重。
改造建议 (Spec-first) ：
把"用户故事"升级成 AI 可消费的结构化规格，例如：
- 业务目标（北极星指标/约束）
- 交互状态机（状态、事件、转移）
- 数据契约（字段、枚举、边界、错误码）
- 端侧约束（性能、离线、隐私、埋点口径）
- 验收样例（Given/When/Then + 反例）
2. 闸口端 (Review/Testing) 吞吐没升级，AI 把队列撑爆
McKinsey 2023 的实验表明：生成、重构、文档都能明显提速，这会让 PR 数更大、更频繁。但如果你的质量体系仍然主要依赖人工：
- 人工 Review 成为"单点瓶颈"
- 手工回归成为"系统瓶颈"
改造建议 (Shift-left + 自动化闸门)：
- 强制"可机器验证"的契约：lint、format、静态扫描、依赖治理
- 测试左移：单测/契约测试/快照测试覆盖 UI 与关键链路
- 为 AI 代码引入"更强的自动审查"：例如规则化的代码规范、复杂度阈值、模块边界检查
3. 分配端（人怎么用 AI）没有新机制：有人过载，有人空闲
Atlassian 指出开发者真正的摩擦往往不在写代码，而在找信息、切上下文、跨团队协作。如果管理机制仍围绕"谁写哪块代码"，你很难做出最优分配：
- AI 适合并行试错、生成草案。
- 人适合做架构取舍、风险兜底、线上负责。
旧分配方式，会把人拖回"当 AI 校对员"的低价值区。
问题四：分工模式不匹配人机协同需求
在 McKinsey 2025 的描述里，头部组织正在形成"AI-native 的 PDLC 角色变化"：工程师更强调结构化规格沟通、系统权衡，PM 也更深入原型与质量环节。
旧敏捷经典分工正在发生的变化
- Dev：从"编码主力"→ 更像"系统设计 + 约束表达 + 验证负责人"
- QA：从"手工回归"→ 更像"测试工程化 + 自动化闸门 + 质量度量"
- PO/PM：从"需求传递者"→ 更像"价值定义 + 原型验证 + 质量共同体"
AI 时代更缺的三类新能力
（不一定是新岗位，但必须有人负责）
- 规范设计 (Spec Engineer / Spec Owner)
- 把需求翻译成"可验证、可生成、可追踪"的规格与验收。
- AI 审核与风控 (AI Reviewer / AI Safety Gate)
- 专门盯：合规边界、数据泄漏风险、依赖许可、可观测性缺失、逻辑漏洞。
- 提示与模板资产化 (Prompt Librarian / Workflow Owner)
- 把"好用的一次性 Prompt"沉淀为团队资产，形成可复用的模板与流水线。
你会发现：这三类能力，本质上都是在补"旧敏捷没覆盖的系统环节"。
问题五：技术债防控机制全面失效
AI 生成代码的典型风险，不是"写不出来"，而是写得太快、太多、太像能跑。McKinsey 2023 也明确提醒：复杂任务上收益会下降，且需要人提供组织上下文与监督来保障质量。
AI 放大技术债的三种常见形态
- 复杂度堆叠：为了"先跑起来"，AI 容易堆条件分支、配置开关、隐式依赖。
- 一致性丢失：不同人不同 Prompt 生成的风格与架构不一致，最后变成"拼接怪"。
- 长期成本外溢：短期交付爽，长期迁移/重构/排障成本飙升。
防控建议：把"规范"从文档变成"闸门"
- 架构约束机器化：模块边界、依赖方向、API 稳定性规则。
- Golden Path：把最佳实践写进脚手架/模板/CI，而不是写在 Confluence。
- 可观测性强制：关键链路必须有日志、指标、追踪与回滚开关（否则不准合并）。
问题六：优化目标偏离价值核心
旧敏捷最危险的偏移是"过程合规"凌驾于"价值交付"：
- Sprint 跑满、点数做高、燃尽图好看。
- 但用户价值、质量稳定性、端到端周期并没有同步改善。
McKinsey 2025 对高表现组织的一个核心强调是：衡量要看结果（质量/速度/体验），而非只看 AI 使用与产出规模。Atlassian 也提醒：如果你只把 AI 用在编码环节，而忽略组织摩擦，整体收益会被抵消。
总结：旧敏捷问题的本质与破局方向
核心结论
- 旧敏捷的"灵魂"（快速反馈、拥抱变化）依然有效。
- 但旧敏捷的"身体"（流程/指标/分工/闸门）在 AI 时代已经不匹配。
- 本质是：把为"人写代码"设计的操作系统，硬跑在"人机协同、代码不稀缺"的硬件上。
三大核心错配
- 假设错配：从"人控开发"到"人机协同"。
- 流程错配：从"线性迭代"到"动态价值流 + 队列治理"。
- 角色错配：从"人力分工"到"人机互补 + 责任制"。
破局起点：30/60/90 天行动清单
目标：把"AI 的局部提速"变成"系统级交付加速"，避免"省 10 小时又丢 10 小时"。
-
0--30 天：先把瓶颈找出来（别急着堆工具）
- 拉一张 价值流地图：Idea → Spec → Dev → Review → Test → Release → Observe。
- 统计 3 个队列时长：PR 等待、测试等待、发布等待。
- 选 1 条关键链路做"端到端度量"上线（Lead Time / 变更失败率 / MTTR）。
-
31--60 天：把"输入与闸门"升级成机器可执行
- Spec-first：把 Top3 高频需求做成结构化规格模板。
- 把规范变成 CI 闸门：lint、依赖治理、契约测试、快照测试。
- 建立"AI 生成代码的最小合并标准"：必须可测、可观测、可回滚。
-
61--90 天：重构分工与责任，把 AI 变成"产线能力"
- 明确 3 个责任人：Spec Owner / Quality Gate Owner / Prompt & Template Owner。
- 把"好 Prompt"沉淀成团队资产：模板库 + 示例输入输出 + 适用边界。
- 对齐结果指标：质量与速度优先（不要只看采用率/代码占比）。