「AI杀死敏捷」吵了半年，我翻遍全网信源发现：死掉的是「站会敏捷」

这半年，敏捷圈一直在吵同一个问题：AI 是不是把敏捷杀死了？

一边，是一篇名为《AI 已杀死敏捷宣言》的文章在 LinkedIn 上流传，宣称 AI 能直接交付需求之后，站会、冲刺、回顾这套仪式全成了冗余。知乎另一边，一线带团队的人感受更直接：本以为 AI 能减负，结果迎来的是升级版压榨——领导觉得既然 AI 能写代码、改 bug、跑流程，那迭代就要更快、工期就要更短、业务需求就应该当天上线。知乎

吵了半年，双方都有话说。我把知乎、36氪、小红书、今日头条上从业者、敏捷教练和《敏捷宣言》作者本人的观点都翻了一遍，结论先放在这里：正在死掉的是「站会敏捷」，而敏捷本来要解决的问题，AI 反而把它的价值放大了。

一、先看背景：这场架为什么偏偏现在吵起来

因为 AI 编程赛道最近实在太热闹了。6 月，SpaceX 一分现金没花收购 Cursor，把这家 ARR 高达 40 亿美元的 AI 编程工具第一名收入囊中。36氪紧接着，马斯克旗下又推出 AI 代码托管平台，微软市值随之蒸发千亿。36氪

资本的判断不会骗人：曾经的「AI 编程老祖」Devin，估值也在这轮混战中反超了 Cursor。36氪当 AI 几分钟就能吐出过去要写一天的代码，一个绕不开的问题浮出水面——围绕「编码很慢」这个前提设计出来的一整套敏捷仪式，还有存在的必要吗？

二、《敏捷宣言》作者本人怎么看

今年 4 月，《敏捷宣言》17 位署名作者中的两位——Kent Beck 和 Martin Fowler——在一场硅谷闭门活动上并肩坐下，正面回应了「敏捷已死吗」这个提问。

两位老人的态度一句话就能概括：敏捷没死，但把敏捷做成生意的那套玩法，确实死了。回看过去二十年的敏捷转型，他们毫不客气：当年的「敏捷转型」，在无数企业中最终都演变成了一场「形式主义的灾难」，催生了庞大的「敏捷工业复合体」。知乎

Beck 还有个更扎心的观察：AI 正在让软件开发「重新孤岛化」。过去我们把程序员从封闭办公室里解放出来，让他们围坐在一起结对、争论；现在却有人以「我手下有 6 个 Agent，我是小团队的管理者」自居。他的回应一点不留情面：不，你不是。你只是在同时使用 6 个工具。知乎他甚至觉得 AI 有点「太快了」——如果 AI 要 3 分钟才返回结果，团队还能趁机讨论变量命名的哲学和下一步的架构方向；可它 15 秒就返回了，我们就失去了交流的时间。

三、真正发生的变化：瓶颈搬家了

抛开站队，一线从业者的共识其实比吵架双方想象的高得多。一位前 Scrum Master 的复盘说得最直白：写一个 CRUD 接口，以前要半天，现在 AI 辅助十分钟搞定，瓶颈从「写代码」转移到了「想清楚要什么」和「验证对不对」。知乎他举的例子很具体：一个「用户登录」功能，用 Claude Code 从 spec 到代码到测试，连 OAuth 带 JWT 带密码策略，四十分钟就能搞定。实现只要小时级的活儿，再花两个小时开估算会讨论它值几个点，确实有点本末倒置。所以他的结论很干脆：迭代周期应该跟着交付节奏走，而不是跟着日历走。

这套逻辑已经渗入传统企业的真实研发流水线。在 TCL 与腾讯云 CodeBuddy 的合作里，AI 编程助手能够读懂企业代码库，贯穿从需求拆解、代码编写、测试修复到部署上线的全链路，并守住大型制造企业最在意的安全底线。36氪当编码、测试、修复都被 AI 接管了一大半，「按编码工时排期」这个旧假设，自然就站不住了。

AI 编程圈有个流传很广的类比，讲的也是同一件事：传统计划模式像高射炮，炮弹发射后只能祈祷风速和目标轨迹与之前计算的丝毫不差；而敏捷像巡航导弹，能够根据目标的最新移动坐标，实时调整飞行弹道。知乎

Github 上拥有 37k Stars 的 BMAD METHOD 框架的进化，几乎就是这句话的注脚。其早期版本接到一个 Epic 需求时，会批量拆解并一次性生成十几个用户故事顺次执行——第二个故事一旦跑偏，后面所有故事都建立在错误假设上。而最新版本的设计思路变了：开发完一个 Story 后，必须停下来提取当前代码仓库的最新拓扑和状态，然后再去生成并执行下一个。知乎所谓响应变化，说白了就是下一步的决策，必须建立在上一步真实交付的东西之上。

四、变与不变：一张清单

还在跑 Scrum 的朋友，这里有一份从多个独立信源交叉出来的清单：

清单背后的逻辑，一句话说得清：当 AI 能瞬间生成代码和测试用例时，「可工作的软件」不再是稀缺品，团队的核心矛盾从「做不出来」转向「不知道做什么对」。知乎

直接后果是「快」不再稀缺，「对」才稀缺。以前做一个新产品，可能要半年调研、设计、开发，上线了才知道行不行；现在有了 AI，原型可能一周就能做出来，但方向对不对、用户买不买账，依然是未知数。知乎

所以清单里所有变化的共同点只有一个：把人的时间从「盯执行」挪到「做判断」。流程上要明确划分「AI 全自动区」和「人类必须介入区」，把提示词验证纳入完成的定义；Scrum Master 要从流程警察转型为「业务翻译官」，站会的焦点从追踪进度转向对齐认知与排除 AI 带来的盲区。知乎

五、这事和你有什么关系？三类人，三种看法

如果你是一线开发，或刚开始带 AI 团队：你最该防的不是站会浪费时间，而是团队失去定义「做什么」的能力。如果你不主动用交互去定义清晰的边界，AI 就会用它预训练模型里最平庸的假设，去填补你的留白。知乎AI 帮你省下来的时间，应该投到讨论需求和验证价值上；否则你只会更快地交付错误的东西。

如果你是敏捷教练或 Scrum Master，担心被替代：会被替代的，是「盯进度、画燃尽图」那部分。有资深实践者的判断是：真正的敏捷不是漫无目的的行动，而是有条不紊的适应。知乎AI 越是接管执行，「让变更可见、可控、可优先」这件事就越需要人来做——这恰恰是教练们的老本行。

如果你是管理者，正准备为「AI 敏捷转型」买单：先问清楚你买的是效率，还是控制幻觉。在小红书那篇《敏捷为何在中国无法真正落地》的评论区，高赞留言说得露骨：领导普遍认为敏捷等于快，敏捷以后就可以左脚踩右脚原地飞升。小红书如果你的敏捷本来就只剩汇报式站会和压缩工期，那 AI 只会让它变本加厉——领导看见 AI 能提速，直接砍掉所有缓冲时间。知乎

六、三个坑，和两个值得盯的信号

第一个坑：技能生锈。有大厂程序员自曝，用了半年 AI 编程，自己连 Laravel API 都不会写了。36氪当手感练习全被 AI 接管，失去的不只是写代码的能力，还有判断「AI 写得对不对」的底气。解法很朴素：偶尔放下 AI，亲手写几行代码。

第二个坑：把蛇油当解药。如果向你兜售「AI 敏捷转型」的咨询方只讲成功案例，讲不清人机边界怎么划、AI 产出怎么验证，那大概率是又一个「敏捷工业复合体」。Beck 和 Fowler 今年 4 月就提醒过：无数根本不懂技术的咨询公司，正在兜售着各种「AI 转型」的灵丹妙药，AI 正在成为新的「蛇油（Snake Oil）」。知乎

第三个坑：把伪敏捷当敏捷。很多团队不是被 AI 打败的，是被自己演的那套敏捷打败的——IBM 调研显示，76% 的中国组织声称采用多种敏捷方法，但 Standish Group 的报告指出，仅 23% 的「敏捷转型」真正达成了预期目标。知乎换句话说，不少团队的问题根本不是「敏捷不适应 AI」，而是从来没做过敏捷，做的只是「敏捷的壳」。知乎

两个值得持续关注的信号：一是 BMAD 这类 AI 工程框架的演化方向，它们正在把「响应变化」写进机器流程；二是 InfoQ 在 2026 年趋势报告里给出的判断：AI 重写工程师角色，但一切仍然关乎人。今日头条这里的「人」，指的是判断、责任和对齐目标的能力——这些恰恰是敏捷里 AI 替代不了的部分。

七、写在最后

死掉的不是敏捷，是「站会敏捷」：那些只为汇报进度而开的站会、只为切割排期而设的冲刺、只为把工时换算成点数而存在的估算。而敏捷本来要解决的问题——在不确定的事里找到值得做的事——在 AI 时代不但没有消失，反而被放大了。知乎

对真正在做敏捷的人来说，这反而是个好时代：编码不再是瓶颈，你终于有理由把开会的时间从「盯执行」挪到「对齐认知」。如果你的敏捷只剩一套仪式，那 AI 不是凶手，是验尸官——它只是让早就存在的问题提前暴露。

别在错的方向上跑太久。