敏捷开发已死？当 AI 抹平人类带宽极限

多年以来，软件行业始终把敏捷开发（Agile）奉为圭臬。许多团队把各类看板、每日站会和双周冲刺当成软件交付的唯一真理。

但这套机制正在失灵。这就好比有人给了你一辆顶级超跑，脚下的路却依然是为马车设计的。车速极快，旧道路却寸步难行。

Photo by GABRIEL CARVALHO on Unsplash

执行者的本质变了

以 Agent 为核心的开发范式，彻底改变了“谁来干活”这件事。

现在，开发者可以在后台挂一个 Agent 搭建核心功能模块，同时自己去排查性能瓶颈，再顺手唤醒另一个 Agent 执行依赖版本升级。然而，大多数团队的研发排期，依然默认“一个程序员同一时间只领一个任务卡片”。

敏捷的核心价值观没有错——拥抱变化、交付可用软件、保持紧密反馈环，这些在今天比以往任何时候都重要。真正崩溃的是仪式感和交付节奏。

每日站会、故事点（Story Points）、Sprint 计划，所有这些机制都锚定在过去唯一的物理单元上：一个人类，一个任务，一个两周冲刺。这个前提现在不复存在了。

决定新范式的三个事实

如果抛开过去，重新为现代开发流程画一张蓝图，有三个底层逻辑必须重写：

1. 代码本身正在极速贬值。
这并不是贬低开发者的劳动，而是在重新定义“产出”。代码行数的价值趋近于零，真正的价值在于“方案是否精准满足了需求”。在团队内部，Pull Request 的性质已经变了：如果代码根本不是人手敲出来的，逐行挑剔语法没有任何意义。代码审查正在演变为纯粹的架构探讨，目标不是追求极致的代码审美，而是在控制风险的同时最大化吞吐量。

2. 任务并行成为默认常态。
单线程接单、按顺序推进的排期机制已经像上个世纪的产物。我们拥有了随时并发调遣多个智能体的能力，只是整个团队的组织结构还没学会如何承接这种杠杆。

3. 需求梳理成了唯一的产能瓶颈。
如果团队里有一个能 7x24 小时不间断写代码的员工，你却仍然按照“朝九晚五”的节奏每天给他分派几个零碎工单，这是极大的浪费。Agent 的执行速度，已经远远超过了人类定义需求的速度。团队的稀缺资源不再是“敲键盘的工时”，而是边界清晰、逻辑严密的业务规格（Spec）。

Photo by Tasha Kostyuk on Unsplash

认知切换没有消失，只是换了位置

在宣扬 AI 生产力的浪潮中，有一点很少有人提及：同时挂着三个 Agent 并不等于解放大脑。

上下文切换的损耗没有消失，它只是从“写代码”转移到了“审代码”。

过去，程序员会被写代码中途的被打断所消耗；现在，你需要在一小时内跳入三个不同的代码流分支，为每一个分支的产出做架构判断。这种高密度的决策负荷极度消耗心力。如果新流程不把这种审查压力计算在内，团队很快就会在打着“提效”旗号的狂欢中彻底耗尽心力。

“后敏捷时代”的工作流雏形

尽管还没有标准答案，但一套适配 AI 算力的研发模式正在成型：

• 按 Agent 吞吐量规划，而不是人头工时：以人肉工时为基准的 Sprint 排期已经失去预测意义，排期需要计算的是系统的并行跑动上限。
• 把需求梳理变成工程师的核心基本功：既然明确的需求成了最大瓶颈，那么撰写精确的 Spec 和验收标准，就是程序员杠杆率最高的操作。
• 让代码评审退回系统设计层：放弃逐行纠错，聚焦系统一致性、边界风险以及架构契合度。
• 把例行维护委托给常驻 Agent：日常巡检、依赖更新、线上报错日志的初筛和补丁生成，完全可以交给后台常驻任务。直到需要合并代码时，人类才介入确认。

藏在效率背后的心理困局

很多顶尖工程师之所以热爱这门职业，是因为从无到有、死磕底层逻辑直到代码完美运行所带来的心流与成就感。

当 AI 接管了绝大多数具体实现，交付功能的节奏前所未有地快，很多人内心却浮现出一种荒谬的失落感：东西做出来了，但我好像没资格把功劳算在自己头上。

这或许是软件工程接下来要面对的最深层挑战。新机制不仅要回答如何榨干 AI 的效率，更要回答：如何让驾驭工具的工程师，依然坚信自己是一个无可替代的造物者？