敏捷已死？真正过时的是"两周冲刺"：智能体驱动开发时代，产品和研发该怎么协作
这篇文章基于《Agile is Dead: Welcome to the Era of Agent-Driven Development》的中文翻译稿重新整理。原文的观点很锋利：AI 智能体把软件交付速度拉到了秒级，而很多团队还在用两周一次的 Sprint 管理它。
我的理解是：敏捷并不是一夜之间失效了，真正失效的是"用人类协作节奏去管理机器执行速度"。
先说结论
如果一句话概括这件事：
智能体驱动开发不是"AI 帮我写代码"，而是"人类设定目标，智能体持续执行，系统用质量闸门决定是否进入下一轮"。
过去我们习惯把软件开发拆成一个个任务：写需求、排 Sprint、开站会、写代码、评审、测试、上线。这个流程在纯人类团队里很合理，因为人需要理解、沟通、排期、休息，也需要靠仪式降低协作成本。
但当智能体可以在几十秒内完成"生成方案、写代码、跑测试、修复问题"的闭环时，原来的流程就会出现一个尴尬问题：
代码生产速度已经变成秒级，管理节奏却还停留在天级、周级。
这不是工具升级那么简单，而是软件生产方式的底层节奏变了。
一个熟悉的场景
想象一个周二早上的站会。
你打开 Zoom，解释"认证模块还卡在代码评审里，预计周五能合并"。项目经理点点头，把 Jira 工单从"待处理"拖到"进行中"，顺手看了一眼燃尽图。
与此同时，你 IDE 里的智能体可能已经生成了 50 个认证模块的实现版本，还顺手跑完了测试。
这就是原文里最刺痛人的那句话：我们遇到的是速度问题。
敏捷是为人类设计的。它非常擅长解决"几十个人如何一起做复杂软件"的问题。可到了智能体时代，问题变成了另一个：
当执行者不再疲惫、不需要站会、可以持续试错时，我们还要不要用两周一个冲刺来管理它？
速度错配：从 4 天到 45 秒
先看一张图。
这张图最值得看的不是"45 秒"这个数字本身，而是它背后的错配。
在传统敏捷里，一个需求要经历构思、编码、评审、测试，最后进入发布节奏。每个环节都依赖人的注意力，所以流程自然会被拆成天、周、Sprint。
但在智能体驱动开发里，很多环节可以被压缩成一次连续动作：
- 大模型生成多种实现策略；
- 构建智能体写出代码；
- 测试智能体生成并运行测试；
- 评审智能体根据目标和约束做自我检查；
- 质量闸门判断是否进入下一步。
当这些动作可以连续发生，真正慢下来的往往不是代码，而是人类还在等下一次会议、下一次排期、下一次评审窗口。
这也是为什么"敏捷已死"这个标题有传播力。它不是说敏捷的价值完全消失，而是在提醒我们：敏捷当年解决的是人的协作摩擦，现在我们面对的是人机协作的节奏差。
ADD 到底是什么？
原文把这种新范式叫做 Agent-Driven Development，简称 ADD，中文可以理解为"智能体驱动开发"。
它和"用 Copilot 写代码"不是一回事。
用 Copilot 写代码，本质上还是人在主导每一个步骤。人写需求，人决定下一行代码，人跑测试，人修复问题，AI 只是更聪明的补全工具。
而 ADD 的核心是：
智能体拥有一个目标的完整执行闭环，人类从任务分配者变成目标设定者、约束设计者和质量兜底者。
也就是说，产品经理和研发不再只是把需求拆成工单，而是要把目标、约束、验收标准、风险边界说清楚。
传统敏捷里，我们会写：
实现 login 接口。
在 ADD 里，更好的表达会变成：
将登录链路平均耗时降低 20%，支持 OAuth 登录，不得降低现有安全策略，所有新增路径必须通过单元测试和可访问性检查。
前者是任务，后者是目标加约束。
智能体真正需要的不是"你下一步做什么"，而是"什么结果算对，什么边界不能碰"。
新工作流：用闭环取代冲刺
如果说 Sprint 是人类团队的节奏单位，那么闭环就是智能体团队的节奏单位。
这个闭环可以拆成四步。
第一步：人类设定目标
产品经理、产品工程师或技术负责人先定义目标状态。
比如：
- 实现深色模式切换；
- 首屏加载时间降低 30%；
- 新增企业微信登录；
- 把某个高频报错的发生率降低到 1% 以下。
但只写目标还不够，还要写约束。
例如：
- 必须通过 WCAG 无障碍访问检查；
- 不能改变现有 API 返回结构；
- 新增逻辑必须覆盖单元测试；
- 只允许改动指定模块；
- 出现性能回退必须停止合并。
在智能体时代，产品经理最重要的能力不只是"会写需求"，而是会定义一个可验证的目标空间。
第二步：编排器拆解任务
编排器智能体相当于一个"AI 项目经理 + 技术负责人"。
它拿到目标之后，会拆解需要做的事情：查代码、定位影响范围、制定实现策略、分配给构建智能体、测试智能体、评审智能体。
这里的重点是：它不需要等下一次站会。
如果目标清楚、权限足够、质量闸门完整，系统可以立刻开始执行。
第三步：智能体自主执行
构建智能体写代码。
测试智能体生成测试。
评审智能体检查代码是否符合目标、风格和约束。
如果失败，就返回前一步继续修复；如果通过，就进入质量闸门。
这一步听起来很像"AI 自动写代码"，但真正关键的是持续反馈。一个只会生成代码的智能体没有那么可怕，也没有那么有用。真正有价值的是能在测试、日志、指标和约束里不断修正自己的系统。
第四步：质量闸门决定能不能继续
质量闸门是 ADD 里最不能省的东西。
它决定一次智能体改动能否进入预发布、生产环境，或者只能回到闭环里继续修。
质量闸门可以包括：
- 单元测试是否通过；
- 回归测试是否通过；
- 关键业务指标是否异常；
- 性能是否下降；
- 安全扫描是否有风险；
- 代码影响范围是否超出预期；
- 是否需要人工确认。
所以，ADD 并不是"让 AI 随便上线"。恰恰相反，它要求团队把"什么叫安全、什么叫成功、什么叫异常"定义得更清楚。
三个敏捷仪式，会被什么替代？
如果不再每天站会、不再每两周冲刺、不再开一堆复盘会，那团队靠什么管理进展？
我认为会有三个替代。
1. 用实时仪表盘替代站会
站会的本质是同步状态。
但智能体系统里，状态不应该靠人嘴说，而应该靠系统记录。
你不需要问"你昨天做了什么"，而是看：
- 智能体尝试了几种方案；
- 哪些测试失败了；
- 失败原因集中在哪类模块；
- 平均一次闭环要多久；
- 多少改动卡在质量闸门；
- 人工介入发生在哪些节点。
新的管理指标可能不再是"这个 Sprint 完成了多少 Story Point"，而是：
每小时有多少目标闭环被安全完成。
2. 用目标提示词替代待办事项梳理
传统待办事项梳理，重点是把需求拆成足够小、足够明确的任务。
ADD 时代，重点会变成把目标、上下文和约束写得足够好。
一个糟糕的指令是：
修复这个 Bug。
一个更好的指令是：
分析 logs/error.json 中的堆栈跟踪，定位导致支付回调失败的最小影响范围。请提出 3 种修复方案，选择复杂度最低且不改变现有 API 的方案实现，并确保相关单元测试全部通过。
这不是"提示词玄学"，而是产品和研发共同定义执行边界。
过去我们把精力花在"拆任务"上，以后会更多花在"写清目标"和"设计验收条件"上。
3. 用闭环调优替代冲刺复盘
敏捷复盘常问：
这次 Sprint 为什么这么慢？
ADD 的复盘更像系统调优：
- 为什么构建智能体连续失败 5 次？
- 测试智能体是不是漏掉了关键场景？
- 质量闸门是不是太松，放过了不该放过的改动？
- 约束是不是写得太模糊，导致智能体乱改？
- 哪些任务仍然必须人工确认？
也就是说，我们不再只优化团队沟通，而是在优化一个持续运行的人机系统。
开发者不会消失，但角色会变
这个话题很容易被讲成"AI 要取代程序员"。但我觉得这种说法太粗糙。
更准确的变化是：开发者从"每一行代码的直接生产者"，逐渐变成"系统边界和质量机制的设计者"。
过去开发者说：
我实现了 login 按钮。
以后更可能变成：
我设计了登录链路的安全闸门，确保智能体生成的所有改动都不会破坏认证策略。
开发者会更像系统架构师、质量工程师、影响范围工程师。
他们要设计：
- 智能体能访问什么代码；
- 智能体不能触碰什么区域；
- 什么指标能代表成功；
- 哪些测试必须自动生成；
- 哪些异常必须触发人工介入；
- 如何让每次智能体修改都有日志、证据和回滚路径。
代码能力仍然重要，但它不再只是"写得快"。更重要的是知道怎么让一个自动化系统写得对、测得准、改得稳。
产品经理的变化更大
从产品经理视角看，ADD 带来的变化可能更明显。
过去很多需求文档其实是"任务说明书"：
- 做一个按钮；
- 加一个字段；
- 改一个页面；
- 新增一个接口。
但智能体不缺执行力。它缺的是上下文、判断标准和边界。
所以，产品经理要从"派发任务"转向"定义结果"。
未来更有价值的产品表达会包括：
- 用户目标是什么；
- 成功指标是什么；
- 哪些体验不能被破坏；
- 哪些业务规则必须保留；
- 哪些异常情况必须兜底；
- 哪些地方必须让人确认；
- 这次改动影响哪些角色、流程和指标。
简单说，产品经理要少写"把按钮放到哪里"，多写"这个功能为什么存在，以及怎样才算真的解决问题"。
但别急着把 Scrum 指南扔了
我不建议把"敏捷已死"理解成"所有敏捷实践都没用了"。
在很多场景里，敏捷仍然有价值：
- 团队目标还不清楚；
- 需求探索仍然依赖大量用户反馈；
- 系统复杂度高，需要多人协同判断；
- 合规、安全、组织流程要求强人工审批；
- 团队还没有可靠的测试和观测体系。
这些情况下，敏捷的迭代、复盘、同步仍然有意义。
真正需要警惕的是另一件事：
当智能体已经能完成连续闭环时，团队还把所有改动强行塞进两周 Sprint，只是因为过去一直这么做。
流程不应该成为速度的天花板。
团队可以怎么开始？
如果你现在是产品经理、研发负责人或创业团队成员，不需要一上来就搭一个复杂的多智能体系统。可以从一个小闭环开始。
建议按这个顺序试：
-
选择低风险模块
比如后台配置、内部工具、测试补全、文案调整、样式修复，不要一开始就碰支付、权限、账务。
-
把需求改写成目标和约束
不要只写"改页面"，要写清楚成功标准、不能改什么、必须验证什么。
-
建一个最小质量闸门
至少包括测试、代码检查、影响范围检查和人工确认点。
-
记录每次智能体尝试
看它失败在哪里，哪些提示词有效，哪些约束不够清楚。
-
逐步扩大闭环范围
先让智能体做建议，再让它改代码，再让它跑测试，最后才考虑自动进入发布链路。
ADD 不是一步到位的组织变革，它更像是一条升级路径：先让局部闭环跑起来，再让团队围绕闭环重新设计协作方式。
最后
敏捷曾经非常重要。它把早期软件开发里的混乱，变成了可沟通、可迭代、可管理的过程。
但智能体时代的问题变了。
当代码生成可以变快，真正稀缺的东西就变成了目标、上下文、验证、约束和判断。
所以，我不觉得未来的关键是"把 Sprint 做得更短"。如果一个闭环可以 45 秒完成，那再把两周 Sprint 压缩成一周，意义也有限。
真正值得做的是：
把团队从任务管理，升级到目标编排；从会议同步，升级到系统观测；从人肉把关，升级到质量闸门。
这才是智能体驱动开发真正有意思的地方。
原文信息：
- 原文标题：Agile is Dead: Welcome to the Era of Agent-Driven Development
- 原文链接：https://medium.com/write-a-catalyst/agile-is-dead-welcome-to-the-era-of-agent-driven-development-bd70c32970da
- 本文基于用户提供的中文翻译稿进行博客化改写、结构重组和配图重绘。