88.3% 的组织已在每日或每周使用 AI 编码辅助，但智能体生成的代码在 75 分位要等 17.6 小时才被评审——瓶颈正从「写代码」移向敏捷流程的后半段。本文按五个环节拆开讲数据与做法。
本文要点
- AI 编码已普及：88.3% 的组织每周在用。
- 评审成新瓶颈：智能体 PR 等待 17.6 小时。
- 规划环节阻力最大：69% 开发者不让 AI 碰规划。
- PR 越写越大：智能体中位 89 行 vs 人工 26 行。
- 分工重划：人守高责任决策，AI 做准备与初稿。
AI 编码工具能替代敏捷开发的哪些环节？
AI 编码目前能稳定承接的是「准备与初稿」类工作——评估 backlog、检查验收标准、生成代码和测试初稿；而涉及承诺与上线的高责任环节，仍应由人主导。
这个边界在 2025 年的 Stack Overflow 开发者调研（49,000+ 份响应）里看得非常清楚：84% 的开发者在用或计划用 AI 工具，但对高责任任务抵触明显——76% 不打算让 AI 接管部署与监控，69% 不打算让它参与项目规划；同时只有 29% 信任 AI 产出，比上一年降了 11 个百分点。换句话说，AI 已经进了开发流程，但团队本能地把决策权留在人手里。
实践中更可持续的定位是「人类主导、AI 建议」：2020 版 Scrum Guide 本身允许在每日站会邀请他人提供咨询，agent 的咨询席位是规则允许的，只是别给它投票权。
Sprint 规划环节，AI 具体做什么、不做什么？
AI 在 Sprint 规划里的成熟用法集中在三件事：检查 issue 是否缺验收标准、基于历史数据预测承诺风险、草拟 sprint 目标供人修订——决策权仍在团队手里。
- 规划前的质量门：Fraunhofer IESE 提出的两阶段模式，在细化会议和规划会议之前用模型逐条检查 issue 是否缺失验收标准，把含糊需求拦在进入 sprint 之前。
- 承诺风险预测：Scaled Agile 的实践是用历史交付数据预测某个 sprint 承诺是否会在周中失败，让团队在会上就调整范围。
- 目标与就绪度草稿：Atlassian Rovo 会生成 sprint 目标并检查工作项就绪度；Linear 把 agent 当一等用户接进工单流；GitHub 的 coding agent 则可以直接认领 issue 干活。
不做什么也明确：不要让 AI 替团队做范围取舍和承诺。调研里 69% 的开发者对「AI 做规划」说不，这不只是心理阻力——规划错了，修正成本全流程最高。
代码评审为什么成了新瓶颈？
LinearB 对 810 万个 PR 的 2026 年度分析显示：智能体生成的 PR 在 75 分位要等 17.6 小时才进入评审，而非 AI 辅助代码只需 3.4 小时；前者 30 天合并率仅 32.7%，远低于后者的 84.4%。
| 指标（2026，810 万 PR 样本） | 非辅助 PR | AI 辅助 PR | 智能体 PR |
|---|---|---|---|
| 改动行数（中位 / 75 分位） | 26 / 157 行 | 96 / 408 行 | 89 / 293 行 |
| 等待评审时长（75 分位） | 3.4 小时 | — | 17.6 小时 |
| 评审实际用时（75 分位） | 4.2 小时 | 3.2 小时 | — |
| 30 天内合并率 | 84.4% | — | 32.7% |
口径：数据来自 LinearB 覆盖 4,800 个团队、163,820 名贡献者、42 个国家的 2026 年度分析；报告自述所有相关性为观察结果，不构成因果结论。
两个细节值得研发负责人注意。其一，AI 辅助让 PR 变大（中位 96 行，人工只有 26 行），但评审实际用时反而更短（75 分位 3.2 小时对 4.2 小时）——最大的改动恰恰得到最少的评审时间，这是质量的隐性风险。
其二，智能体 PR 的积压不是评审变慢，而是评审容量没变、供给翻倍：88.3% 的组织都在让 AI 写代码，下游产能却还是原来那几个评审人。
CI 流水线怎么接住 AI 生成的代码？
必须让 AI 生成的代码过与人工代码完全相同的门槛：自动化测试、静态扫描、人工批准三关缺一不可，再辅以更小的提交粒度。
三件可立即落地的事：
- 拆小提交：智能体 PR 的 75 分位仍有 293 行，接近人工 PR 的两倍。给 agent 立下「单次改动不超过一个函数或一个模块」的约束，评审时长会随行数下降。
- 机器把守第一道门：测试、lint、安全扫描在人工介入前跑完，把人工评审留给「这段逻辑对不对」，而不是「这代码能不能编译」。
- 保留最终控制权：agent 可以自主提交，但合并按钮必须握在人手里——这是各实践指南共识里的底线。
流水线本身的瓶颈定位与改造手法，我们在此前的工程复盘中展开过：AI 编码场景下 CI 流水线的具体优化做法。
交付节奏实证：100 个案例里的一手数据
截至今日优码云已发布的 100 个交付案例里，99 个写明了项目周期：典型首版周期集中在 4 到 14 周，核心团队规模集中在 3 至 5 人，其中 97 个是 Web 端项目。
行业分布上，零售商业 16 个、智能制造 15 个、医疗健康 12 个、仓储物流 10 个、餐饮连锁 9 个；从时间看，97 个案例完成于 2026 年。这组数据是我们自己 AIcoding 工作流下的交付节奏样本——它不能外推成「行业普遍如此」，但能说明一件事：以周为节拍的小步交付（这正是敏捷的节奏）在 AI 辅助下可以由 3 至 5 人的核心团队稳定支撑，「8 周首版上线生产环境」在这批案例里是常见档位，而不是特例。
研发负责人该从哪里开始改流程？
先改两处：把 AI 生成的 PR 计入评审容量预算，并在回顾会上开始测量 AI 的真实交付影响——2026 年仍有 44.7% 的组织没有正式测量。
测量缺口的代价是决策失真：同份报告显示，76.1% 的领导者仍在用「采用信号」（多少人装了工具）而非交付数据来汇报生产力提升。建议从下个 sprint 的回顾会开始固定三个指标：PR 合并周期、返工率、评审等待时长，用 sprint 之间的变化判断 AI 是否真的在帮忙。
组织层面的推进节奏与常见卡点，可参考企业 AIcoding 落地的三阶段推进与四类卡点诊断；需要一份可直接执行的排期，见企业 AI Coding 落地 90 天路线图。
常见问题
AI 编码工具会让敏捷团队裁员吗？
现有数据不支持「替代」结论：84% 的开发者在用 AI，但只有 29% 信任其产出，部署、监控、规划等高责任环节仍由人主导。更现实的图景是团队用同样的人数承接更多迭代，而不是减少人数。
智能体 PR 和 AI 辅助 PR 有什么区别？
AI 辅助 PR 仍是人写代码、AI 做补全与重构；智能体 PR 由 AI 认领 issue 自主产出，中位 89 行、等待评审约为人工代码的 5 倍，需要更严格的 CI 门槛与更小的提交约束。
小团队有必要为 AI 编码调整敏捷流程吗？
最小改动就三件：评审前加自动化检查、sprint 承诺给 AI 产出留折算余量、回顾会加一项 AI 影响测量，总投入不到半天，不需要引入新框架。
怎么衡量 AI 编码对交付的真实影响？
看交付指标而不是采用率：固定跟踪 PR 合并周期、返工率、评审等待时长三个数字，比「多少人装了 AI 工具」更能说明问题——76.1% 的领导者还在用后者汇报。
参考
- LinearB — AI in Software Development（2026 年度分析，810 万 PR）：https://linearb.io/library/ai-in-software-development
- Augment Code — AI Sprint Planning with Agents（2026-07）：https://www.augmentcode.com/guides/ai-sprint-planning-with-agents
- Stack Overflow 2025 Developer Survey — AI 章节：https://survey.stackoverflow.co/2025/ai
- Stack Overflow Blog — Mind the gap: Closing the AI trust gap（2026-02）：https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap