敏捷方法论在AI时代的重构：从协同实现到协同判断

摘要

本文承接对AI生产力悖论的分析，进一步探讨工程时代效率最高的方法论——敏捷开发——在AI时代面临的挑战与演化方向。文章首先呈现2026年初围绕"敏捷是否已死"的产业辩论，进而对敏捷宣言的四条核心价值观逐条进行AI时代的重读，分析具体仪式（每日站会、Sprint规划、代码评审、回顾会议）需要保留、改造或淘汰的边界，最后引入正在浮现的新方法论——规约驱动开发（Spec-Driven Development）——并讨论其与敏捷的承继关系。文章提出，敏捷在AI时代的真正使命不是被取代，而是被兑现。

关键词：敏捷宣言；规约驱动开发；意图工程；代码评审；协同判断

---

一、敏捷正在被AI"逼问"

2026年初，关于敏捷方法论存续的辩论已经进入白热化阶段。这场辩论的双方立场截然不同，但都触及了同一个根本问题：当AI能够在分钟级生成可运行代码时，建立在"周"或"两周"节奏上的敏捷仪式是否还有存在价值。

1.1 极端立场之一："敏捷已死"

Capgemini的Steve Jones在2026年初发表的一篇博客文章引发了广泛讨论¹。其核心论点是：为期数周的开发周期所设计的方法，无法适配Agent驱动的开发。具体的"罪状"包括：

• 两周Sprint在AI能于分钟级生成代码的时代显得十分古董；
• 敏捷宣言中"几周到几个月"的交付节奏在Agentic SDLC中已完全脱离现实；
• "工作的软件优于详尽的文档"这一原则在AI时代极其危险——AI非常擅长生成"看起来能跑"的软件，但会以前所未有的速度积累技术债²。

更尖锐的批评出现在The Agentic Engineering Manifesto中。该文指出，P3 Group的From Sprints to Swarms白皮书更进一步，将既有的敏捷框架称为"战略负担"，并直言每日站会"在AI编排器能够在微秒级别掌握每个任务精确状态的时代，已经成为一种荒谬的练习"³。

1.2 极端立场之二："敏捷无关紧要"

Tim O'Brien在2026年3月的文章给出了一种更冷静的批判：AI暴露了一个事实——这些仪式从来没有在做我们告诉自己它们在做的事⁴。敏捷从来都是一种"应该自然发生的沟通"的捷径。现在沟通方式变了，并且实际需要更多的沟通——发生在更少的人之间。

这一观察对理解AI时代的协作具有重要意义。它指出了一个被忽视的方向：AI时代不仅没有减少沟通，反而提高了沟通的密度，但承载沟通的团队规模正在缩小。

1.3 主流立场："敏捷不死，但必须进化"

Forrester在2025年发布的State of Agile Development报告提供了反向证据：95%的从业者肯定敏捷对其运营的关键相关性，其中61%已经部署敏捷实践超过五年⁵。这一数据表明，敏捷在产业实践层面并未崩塌，反而保持了高水平的认可度。

具有20余年从业经验的实践者在2026年初的行业反思文章给出了或许是最准确的诊断：不是AI杀死了敏捷，而是AI暴露了许多敏捷实施有多么脆弱⁴。具体表现为：

• 如果团队文档不足，AI会放大歧义；
• 如果架构不足，AI会放大不一致；
• 如果以演示证明就绪，AI会放大虚假的信心；
• 如果质量门槛松懈，AI会放大风险。

问题不在敏捷本身，而在于"随意的敏捷、口号化的敏捷、控制松懈的敏捷"。这些过去能够蒙混过关的弱点，在AI的高速生产能力下被全部曝光。

由此可以得出一个核心判断：AI不是敏捷的杀手，而是敏捷的显影剂。

二、敏捷宣言四条价值观的AI时代重读

敏捷宣言于2001年由17位软件实践者起草，提出了四条核心价值观⁶。在AI时代，这四条价值观的有效性需要被重新审视。

2.1 第一条："个体和互动 高于 流程和工具"

原意：以人为核心，避免被流程绑死。

AI时代的张力：当下的"个体"已经包含AI Agent。Jones明确指出：在Agentic SDLC中，工具具有绝对的重要性——使用Replit与使用Claude Code的差异是天壤之别，工具与流程是绝对基础性的¹。

重构方向：从"个体与互动"演化为"人-Agent协同 + 公开的Prompt过程"。研究者提出的"vibe teaming"概念主张：人和Agent的无缝协作，让敏捷性从一种方法变成一个智能的、自适应的系统⁷。Prompt过程的半透明化使团队能够"目睹"成员的思考路径，而非等结果出现后再追溯解释。

2.2 第二条："工作的软件 高于 详尽的文档"

原意：避免生产无人阅读的文档，优先产出可运行的软件。

AI时代的反转：这一条受到的冲击最大。Jones指出，在Agentic SDLC中，文档至关重要——文档是与Agent"协商"想要什么的更好方式，也提供了独立的代码评审依据¹。在99.999%的项目中，开发者实际上并不评审"工作的软件"，因为最终一切都变成机器代码，开发者评审的是"源代码"。在Agentic SDLC中，"源"应当更多地是文档，而非技术代码本身。

这一反转催生了一种新方法论：规约驱动开发（Spec-Driven Development，简称SDD）⁸。其核心思想是颠倒传统架构——让规约变得可执行且权威。Piskala在其于arXiv发表的论文中提出：在AI能比人类打字更快生成代码的世界里，代码不再是稀缺资源，清晰度才是⁹。

重构方向：从"工作的软件 vs 详尽的文档"演化为"可执行的规约（spec）作为单一真相源"。Spec同时承担三种角色——文档、给AI的输入、验证标准。

2.3 第三条："客户协作 高于 合同谈判"

原意：与客户的实质协作优于纠结合同条款。

AI时代的演化：这一条相对稳固，但增加了新维度——与AI Agent的"协作边界"。Jones举出的实例颇具典型性：在更新动物识别软件时，即使他已创建了YOLO的MCP版本，Claude与Gemini仍然倾向于编写自己的版本（通常采用更老的YOLO实现）。如果开发者"只是协作"和"只是vibe"，那么实际上是"只是在创造大量技术债"¹。

重构方向：客户协作的本意不变，新增"Agent边界协作"——明确告诉AI什么不要做，往往比告诉它做什么更重要。

2.4 第四条："响应变化 高于 遵循计划"

原意：拥抱变化，避免死守计划。

AI时代的悖论：响应变化的技术能力变强了（AI可以快速重做），但"计划"本身的价值反而上升了。原因在于AI执行得过快，若缺乏清晰意图就会偏离目标过远。

重构方向：从"响应变化"演化为"意图稳定 + 实现灵活"。Brookings的研究提出的方向是：人类团队定义目的（purpose），驾驭复杂性，监督进化的机器协作系统。未来不是迭代的，而是自主的；不是建立在backlog上，而是建立在意图（intent）上⁷。

三、敏捷仪式在AI时代的边界重划

敏捷宣言的四条价值观下衍生出12条原则，并进一步具体化为若干仪式。这些仪式在AI时代各自面临不同的命运。

3.1 每日站会（Daily Standup）

Miriam Posner的批评一针见血：每日站会被宣传为轻量级的低调签到，对一些工作者而言却成了监视的实践。当工作被分解成小块时，工作者感到有义务列举每项任务¹⁰。

在AI时代，"昨天写了什么代码"已经失去意义——AI写了百倍的代码量，重要的不是数量，而是判断与方向。

Vodafone、Atlassian与Accenture的联合PoC实验给出了改造方向：将专门的AI Agent嵌入Scrum团队，承担backlog、Sprint规划、回顾、质量等环节的支持工作¹¹。一个典型站会场景是：AI Agent异步加入，浮出阻塞点，总结趋势，在团队成员喝下第一杯咖啡之前就完成。

核心转变：站会从"进度同步"变为"意图同步"——讨论对象不再是"我做了什么"，而是"我准备让AI做什么、为什么、风险在哪里"。

3.2 Sprint规划（Sprint Planning）

AWS于2026年的指南中提出了一个重要观点：Sprint Planning必须进化为Intent Design²。在这一模型中，架构变为"脚手架"——定义角色、护栏与回退机制，而非脚本化每个决策路径。

核心转变：从"分解任务"转向"设计意图边界"。规划的产物不再是任务列表，而是Agent可以执行的Spec。

3.3 Sprint长度

这是受冲击最大的环节。两周Sprint在AI能于分钟级生成代码的时代显得十分古董。然而完全取消时间盒也存在问题，因为人类的认知与对齐仍然需要节奏。

新趋势是双层节奏：

• 微循环（小时级）：人与AI共同迭代具体功能；
• 宏循环（周/月级）：人类团队对齐意图、评估方向、清理技术债。

这一结构在功能上类似于CPU的L1与L2缓存——不同问题在不同时间尺度上被处理。

3.4 代码评审（Code Review）

这是一个具有反讽意味的环节——它本是敏捷的"质量保障"，如今却成为AI生产力的最大瓶颈。前文已述：PR审核时间上升91%，AI生成的PR平均扩大154%¹²。

改造方向有二：

1. 从Code Review转向Spec Review：人审查规约与测试用例，AI执行代码生成与初步审查；
2. 自动化质量控制优先于软件测试：AI可以持续生成与更新测试用例，使QA随代码同步演进¹¹。

3.5 回顾会议（Retrospective）

在所有敏捷仪式中，回顾会议是为数不多价值反而上升的环节。原因在于人与AI协作产生了若干全新维度的问题——提示有效性、AI出错模式、判断失误——这些都需要复盘。

具体而言，站会与回顾可以揭示提示有效率、代码拒绝率、幻觉事件、团队情绪等趋势。这些信息虽可由Agent自动化采集，但仍需由人类审核以制定行动项¹¹。

四、新方法论的兴起：规约驱动开发

如果说敏捷是工程时代效率最高的方法论，那么规约驱动开发（Spec-Driven Development）可能是AI时代的接班人——但其性质不是替代敏捷，而是将敏捷的迭代精神嫁接到一个新的基础上⁸。

4.1 核心理念

Piskala（2026）指出，SDD的核心转变在于：从"意图prompt"转向"任务prompt"⁹。意图prompt说"给我建一个X"；任务prompt说"按这些文档定义实现X，遵循这些约束，产生我可以机械验证的输出"。在后一种模式下，Agent的自由度大大缩小，输出质量与spec质量成正比上升。

4.2 工作流

SDD的标准工作流包含四个阶段¹³：

1. Specify（规约）：团队共同撰写规约——这构成了新的"沟通"环节；
2. Plan（规划）：资深工程师定义架构约束；
3. Implement（生成）：AI依据spec生成实现；
4. Validate（验证）：自动化对照spec进行验证。

这一工作流的关键特征在于：沟通被前置了，但只发生在抽象层（spec），不发生在实现层。这恰好回应了AI生产力悖论的核心痛点——人类沟通在"该慢的地方慢下来"（意图对齐），AI在"该快的地方快起来"（实现）。

4.3 与敏捷的承继关系

SDD并非瀑布模型的复兴，而是反馈循环的收紧。其端到端流程仍保留了敏捷的迭代精神：团队首先以清晰、可测试的术语指定行为，然后规划架构与约束，给AI和人类提供同样需要的结构性上下文。Piskala提出了三个层级的规约严谨度：spec-first、spec-anchored与spec-as-source，以应对不同场景的需求⁸。

可以将SDD理解为敏捷的二阶进化：保留迭代、保留反馈、保留响应变化，但把"迭代的最小单元"从"代码"提升到了"规约"。

五、对AI生产力悖论的方法论回应

回到本文承接的核心矛盾——AI生产力过快导致沟通成本极高——敏捷方法论的进化版本能够给出以下五条具体回应。

5.1 将沟通从"实现层"提升到"意图层"

旧敏捷的沟通对象是"如何实现"——在AI时代，等讨论结束时AI已经完成。新敏捷的沟通对象是"该做什么、不该做什么、边界在哪里"（即Spec）——然后让AI去实现。

这是最根本的转变：沟通的对象变了。讨论意图属于小信息量、高价值的对话；讨论实现属于大信息量、低价值的对话——后者已被AI替代。

5.2 用"工件"替代"会议"完成异步对齐

让AI生成提案spec或原型，团队以异步方式评审。避免用同步会议追赶AI的速度——这场比赛人类必败。同步沟通的稀缺资源应用于真正需要面对面讨论的事项，而非进度同步。

5.3 设计双层节奏

• 微循环（小时级，人+AI）：spec内的快速实现迭代；
• 宏循环（周级，人+人）：spec之间的对齐、清债、复盘。

不同的认知任务匹配不同的节奏，避免单一节奏对所有协作场景的强制覆盖。

5.4 将"评审能力"作为团队核心能力培养

AI产能越高，人类的判断价值越高。Kent Beck作为敏捷宣言的原作者之一，在2025年的访谈中明确表示：敏捷在AI时代更多是关于愿景、复杂度管理与人类监督，而不是代码语法²。

评审能力——尤其是对spec、对架构、对长期方向的评审能力——将成为AI时代工程组织的关键能力。

5.5 接受团队规模缩小的趋势

O'Brien的判断"更多沟通，更少的人之间"指向了一个不舒服但真实的方向：AI时代的最优团队规模在缩小⁴。因为沟通成本（n²）依然存在，而每个人的产能上升了10倍。3至5人的spec-driven团队，可能比15至20人的传统敏捷团队产出更高。

这一趋势对组织结构、招聘策略与管理岗位的存续都将产生深远影响，但其底层逻辑是稳健的：当个体产能极大提升后，组织若不相应地降低协调开销，则边际收益必然递减。

六、根本判断

回望本文的核心问题，可以得出如下根本判断：

不是敏捷不行了，是"敏捷的实施惯性"不行了。

敏捷宣言四条原则的精神（适应性、协作、反馈、人本）依然有效，但围绕它建立的具体仪式（两周Sprint、每日站会、Story Point、Velocity）大多是工业时代的妥协产物，并非敏捷理念的本质。AI做的事情，是把敏捷理念中原本应该但从未实现的东西逼到了台前：

• "工作的软件优于详尽的文档"——AI让"可执行的spec"成为可能；
• "响应变化"——AI让"在意图层响应"成为可能；
• "客户协作"——AI让"非工程师直接参与原型"成为可能。

因此，敏捷在AI时代的真正使命不是被取代，而是被兑现。

七、结语

敏捷方法论诞生于2001年，其背后是对瀑布模型僵化性的反思。25年后，AI时代正在以同样的力度逼问敏捷自身的僵化性。所幸，敏捷宣言的原作者们曾经表达过一种谦逊的态度——他们写下的不是真理，而是一组在当时条件下的最佳判断。这种谦逊为敏捷在AI时代的进化留下了空间。

那些将敏捷视为一组仪式的团队，将在AI时代被迫放弃这些仪式或被这些仪式拖累；那些将敏捷视为一组价值观的团队，则有机会借助AI的能力，第一次真正兑现25年前那批人写在宣言里的理想。这场兑现的工作，可能是这一代工程师最有意思的工作之一。

---

参考文献

Footnotes

1. Jones, S. (2026). AI Killed the Agile Manifesto: We Need a New Philosophy in Software Development. Medium. https://blog.metamirror.io/ai-killed-the-agile-manifesto-805ad9a639db ↩ ↩² ↩³ ↩⁴

2. InfoQ. (2026). Does AI Make the Agile Manifesto Obsolete? https://www.infoq.com/news/2026/02/ai-agile-manifesto-debate/ ↩ ↩² ↩³

3. Gelas, A. (2026). The Agentic Engineering Manifesto. https://arnaudgelas.github.io/agentic-engineering-manifesto/ ↩

4. Rethink Your Understanding. (2026). Agile Isn't Dead and AI Isn't Killing It Either. Medium. https://medium.com/@rethinkyourunderstanding/agile-is-not-dead-fa8531ec3e91 ↩ ↩² ↩³

5. Forrester. (2025). The State of Agile Development. https://www.forrester.com/blogs/category/agile/ ↩

6. Beck, K., et al. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/ ↩

7. Brookings Institution. (2025). The Future of Agile Isn't Faster, It's Collective. https://www.brookings.edu/articles/the-future-of-agile-isnt-faster-its-collective/ ↩ ↩²

8. Piskala, D. B. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants. arXiv:2602.00180. https://arxiv.org/abs/2602.00180 ↩ ↩² ↩³

9. Piskala, D. B. (2026). Spec-Driven Development: When Intent Becomes the Source Code. Data Science Collective, Medium. https://medium.com/data-science-collective/spec-driven-development-when-intent-becomes-the-source-code-3af39f86b9d3 ↩ ↩²

10. Posner, M. (2024). Agile and the Long Crisis of Software. Logic Magazine. https://logicmag.io/clouds/agile-and-the-long-crisis-of-software/ ↩

11. Ideas2IT. (2026). How AI Is Transforming Agile Software Delivery: AI in SDLC. https://www.ideas2it.com/blogs/agentic-ai-agile-software-delivery ↩ ↩² ↩³

12. Faros AI. (2025). The AI Productivity Paradox Report. https://www.faros.ai/ai-productivity-paradox ↩

13. ScienceStack. (2026). Spec-Driven Development: From Code to Contract in the Age of AI Coding Assistants (arXiv:2602.00180v1). https://www.sciencestack.ai/paper/2602.00180 ↩