从"人写代码"到"人指挥AI"：敏捷在智能时代的重构
2024年，GitHub 官方研究显示，开发者会接受约 30% 的 Copilot 建议。到 2024-2025 年前后，Cursor、Windsurf、Devin 等 AI 编程工具密集出圈，“Vibe Coding”也从社交媒体上的玩笑，逐渐变成了真实发生的开发方式。越来越多的程序员发现，他们日常工作中最频繁的动作不再是敲击键盘写代码，而是写出一段精准的提示词（Prompt），然后看着AI在几秒内生成过去需要数小时才能产出的代码初稿。 一个看似合理的推论随之而来：如果代码都能由AI自动生成，那么围绕“人写代码”而形成的那套敏捷实践——每日站会、故事点估算、结对编程、代码评审——是不是也该进博物馆了？ 这里先做一个必要的澄清：本文讨论的“传统敏捷实践”，主要指 Scrum、XP 及其在团队中的常见落地方式，而不是把敏捷价值观本身等同于某几个固定动作。敏捷是原则，站会和故事点只是某种实现。 毕竟，敏捷宣言诞生于 2001 年。那时候最主流的编程语言还是 Java 和 C++，最时髦的框架是 Struts，而“人工智能”在大多数开发者眼中还是科幻小说的概念。二十多年后，当AI开始深度参与编码工作，敏捷似乎成了为上一个时代量身定做的古董。 但事实恰恰相反。 AI没有改变敏捷的本质，它只是以极其戏剧性的方式证明了一件事：在大多数复杂软件工作中，真正稀缺的从来不是把语法敲出来，而是理解问题、判断方向、验证假设、管理复杂度。 而这些，恰恰是敏捷方法论一直在处理的核心问题。 当代码初稿的生成成本显著下降，敏捷不仅没有过时，反而获得了前所未有的重要性。只是，它的表现形式必须彻底重构。 要理解敏捷如何进化，我们首先需要诚实地面对一个问题：在AI深度介入开发流程的今天，哪些传统敏捷实践确实正在失真，甚至开始失效？ 传统的每日站会有三个标准问题：昨天我完成了什么？今天计划做什么？我遇到了什么阻塞？ 这套话术建立在一种隐含假设之上：每个人的产出是可量化的、线性的、人力驱动的。一个程序员昨天写完了用户登录模块的前端验证，今天开始做后端接口对接——这种叙事在站会上是清晰且有意义的。 但在AI时代，同样的站会可能变成这样：“昨天我用三个 Prompt 让AI生成了五千行代码，包括用户系统、权限管理和数据迁移脚本。今天我会继续生成管理后台的 CRUD 界面。目前没有阻塞。” 听起来效率惊人，但实际上什么也没说。五千行代码是否运行正确？是否满足了真实需求？是否引入了隐蔽的 bug？是否和系统其他部分兼容？这些问题在传统的站会框架里根本没有位置。 当“产出”的度量单位从“人天”变成“生成批次”，站会的核心议题就必须从“进度同步”转向“意图对齐”和“风险同步”。 敏捷估算——无论是故事点还是理想人天——通常都有一个根本前提：人类写代码的速度虽然有波动，但整体上是相对稳定、可预测的。一个资深工程师完成某个用户故事大约需要两天，团队可以基于这个经验数据来规划 Sprint。 AI打破了这个前提。 一个复杂的 API 集成，可能一个 Prompt 就产出了 80% 的初稿；而一个看似简单的表单验证，可能因为边界条件复杂、历史包袱过多，需要反复调试一整天。AI的产出曲线是高度非线性的。继续只用故事点去衡量 AI 辅助开发的工作量，就像在蒸汽机时代还坚持用“马匹数量”来衡量运输能力。 更深层的问题是：当实现初稿变得便宜，估算的对象本身就变了。 我们不应该再只估“多久能做完”，还应该估“有多大把握一次做对”“哪里最可能返工”“什么地方值得先做验证而不是先做实现”。 代码评审（Code Review）仍然是工程质量的重要防线。但当大段代码是由AI生成的，评审的重点就变了。 语法？AI通常比人更稳定。风格？AI可以迅速对齐项目的 ESLint、Prettier 或类型约束。实现逻辑？如果 Prompt 和上下文足够清楚，AI给出的实现往往比人类更“像标准答案”。 真正需要 Review 的，恰恰是传统 Review 中最容易被忽略的部分：这段代码是否准确翻译了业务意图？是否遵守了系统约束？是否在关键边界条件下依旧成立？ 当一段几百行的AI生成代码出现在 PR 里，Reviewer 面临的 cognitive load（认知负荷）往往更高——因为 Reviewer 没有参与前面的推理过程，不知道AI为什么这样写，也不知道哪些部分是关键约束，哪些部分只是表面看起来整齐。AI生成的代码往往“看起来都对”，直到在真实环境里出错。 所以问题不是“代码评审没用了”，而是：代码级 Review 不应再是唯一质量防线，更不应被平均地施加在所有改动上。 对支付、权限、数据库迁移、基础设施这类高风险变更，代码级审查依然不可替代；但对大量中低风险生成代码，团队必须把更多精力转向行为验证和结果验证。 传统结对编程是两个人坐在一台电脑前，一个写、一个看，实时纠错、实时讨论。这种模式在AI时代看起来有些奢侈——毕竟，你旁边现在就坐着一个不知疲倦、通晓多种语言和框架的“结对伙伴”。 但结对编程的核心精神——实时校验、第二双眼睛、防止 tunnel vision——在AI时代不仅没有过时，反而更重要了。 只是结对的对象变了。现在的结对模式更像是：一个人负责与AI对话和驱动生成，另一个人负责质疑、追问和验证。或者，在单人场景中，开发者必须建立“自我结对”机制——每完成一个AI生成任务，就强制自己停下来回答：这段代码我真的理解了吗？它做了什么假设？什么情况下会失败？ 在讨论需要改变什么之前，我们必须先确认：在这一切变化中，什么是不变的？ 敏捷方法论诞生的初衷，是为了应对软件开发中的根本不确定性：用户不知道自己要什么，直到他们看到自己不想要的东西；技术方案在实现之前永远只是概率更高的假设；市场环境和业务需求会在开发过程中不断变化。 AI能解决的是“如何更快地实现”，但它解决不了“应该实现什么”。事实上，当代码初稿的生成成本显著下降，“做错事”的代价反而更高了——因为你可以在一周内生成十个错误的功能，然后花半年时间去清理它们带来的技术债、流程噪音和用户困惑。 因此，探索性、迭代性、反馈驱动的开发逻辑，不仅没有过时，反而比任何时候都更重要。 敏捷宣言的第一条价值观是“个体和互动高于流程和工具”。这条价值观在AI时代获得了新的诠释。 AI降低了编码门槛，却显著提高了“意图表达”的要求。过去，你可以对一个后端工程师说“帮我加一个用户筛选功能”，对方基于领域知识和上下文理解，通常能做出大致合理的实现。但现在，如果你给AI同样模糊的指令，它很可能会生成一个表面完整、实则偏题的方案——因为它没有你脑子里那套隐性的业务背景。 于是，“把需求说清楚”成了AI时代最稀缺的能力。 Prompt Engineering 确实重要，但它只是表层。更深的一层，是团队是否能把问题背景、约束条件、已有经验和失败案例显性化，并让AI和人都能读懂。 有一种乐观观点认为，AI可以自动重构、自动优化，因此技术债会大幅减少。这是一种危险的幻觉。 AI生成代码的速度和数量，意味着团队可以在极短时间内累积海量改动。如果这些代码缺乏清晰的设计约束、缺乏人的理解、缺乏稳定的验证体系，那么它形成的就不只是传统意义上的技术债，而是“AI债”——一种规模更大、隐蔽性更强、偿还成本更高的债务。 Vibe Coding 的最大风险，不是它会生成错误代码，而是它会以极快的速度生成暂时看不出错误、但长期难以维护的系统。当代码量快速增长，而人的理解、测试和治理能力跟不上时，技术债就会成倍膨胀。 重构、整洁代码、可维护性、可演进性，在AI时代不仅不能丢，还必须被更严格地执行。 确认了变与不变之后，我们来讨论最实际的问题：敏捷团队应该怎么做？ 传统团队经常在需求还没完全想清楚时就开工，因为编码本身很贵，大家总想“先做一点再说”。但在AI时代，生成太容易了，没准备好就开始生成，往往只会更快地走错方向。 因此，团队需要重新重视 Definition of Ready。它不是瀑布式的大文档前置，而是给每个工作项设置一个最低限度的“可生成状态”。 一个适合AI开发的 Ready，至少应包含： 从这个意义上说，Definition of Ready 可以被理解为：把传统敏捷里零散的需求澄清、验收条件、依赖识别，前置成一份可供人和AI共同消费的起跑线。 传统敏捷迭代的是功能，功能是代码的载体。但在AI时代，代码本身变得更可替换——同一个意图，用不同的 Prompt、不同的上下文、不同的模型，可能生成完全不同的实现。因此，团队真正应该迭代的核心对象，需要从“功能/代码”上移到“意图”。 新实践：意图文档（Intent Document） 意图文档可以理解为一种更轻量、但更聚焦的需求说明：它把传统需求文档中的“问题定义、约束说明、验收标准”抽出来，变成一份既供人理解，也供AI消费的核心上下文。 它至少应该包含： AI根据意图文档生成实现方案，团队在每个 Sprint 中迭代的，不只是代码，更是对问题本身的理解。 新实践：Prompt 作为新的用户故事 传统用户故事的格式是：“作为一个[角色]，我想要[功能]，以便[价值]。”在AI时代，团队还应维护一份对应的“Prompt 故事”。它可以理解为面向 AI 的用户故事补充层，格式更像： “给定[上下文]，执行[操作]，输出必须满足[验证条件]，并遵守[约束]。” Prompt 应该像代码一样被版本化管理、被团队评审、被测试验证。但这里真正的核心资产，未必只是 Prompt 库，而是更大的上下文资产库：意图文档、Prompt 模板、测试样例、架构约束、设计决策记录、失败案例回放。 很多团队以为AI落地的关键是 Prompt Engineering：谁更会写提示词，谁就更强。这个理解太浅了。 AI输出质量的上限，往往不是由某一段漂亮的 Prompt 决定的，而是由团队提供的上下文质量决定的。Prompt 只是最后一句话，真正影响结果的是它前面那一整套信息组织方式。 这就是为什么 Context Engineering 会成为AI时代的新基础设施。 它本质上做的是三件事： 如果说传统敏捷强调“共享理解”，那么 Context Engineering 就是把“共享理解”从口头协作推进到可机器读取、可工程复用的层面。它不是新瓶装旧酒，而是把需求澄清、领域建模、文档治理、知识管理重新焊接成了一套生产能力。 既然传统站会的三个问题正在失效，我们应该问什么？ “每日对齐会”可以理解为对传统站会的一次认知同步化改造。它不再主要追问谁做了多少，而是追问团队当前是否还在对的问题上，用对的约束，做对的验证。 建议的新框架是： 昨天的AI输出是否符合预期？ 今天的意图是否需要调整？ 哪些生成结果需要人工重点验证？ 站会的核心，不再是“同步进度”，而是“同步认知”。 面对大批量AI生成代码，逐行 Review 不应再是唯一质量防线。团队需要建立新的质量结构。 新实践：三级验证制 三级验证制可以理解为：把传统的代码审查、验收测试和上线反馈，重组成一个更适合 AI 开发节奏的复合质量机制。 第一级：AI自验 第二级：意图验证 第三级：价值验证 同时要补一条现实原则：高风险改动仍然必须进行代码级 Review。 支付、权限、数据库迁移、关键基础设施、复杂并发逻辑，不能只看结果不看实现。 当AI深度参与开发后，传统工作量估算并不会彻底消失，但它明显不够用了。团队不能只估“耗时”，还要估“把握”。 建议引入“信心度矩阵”。它可以理解为一种风险导向的迭代规划工具，从至少三个维度去评估每个工作项： 低信心度的工作项，不应该简单地分配更多时间，而应该分配更多探索——用 Spike、原型验证、小范围试错、快速回放去降低不确定性，而不是一头扎进大规模实现。 传统 Sprint 的结束标志是一批可发布功能。在AI时代，功能实现初稿更容易得到，方向正确却变得更昂贵。因此，每个 Sprint 的交付物应被重新定义。 它不只是： 还包括： 一个 Sprint 结束后，团队回顾的重点不应该只是“我们按时交付了吗”，而应该是“我们的认知升级了吗”“我们的系统变得更可复用了吗”。 AI生成代码的测试策略必须升级。 “AI契约测试”并不是一个彻底陌生的东西，它更像是对传统验收测试、接口契约测试、回归测试的一次重新组合：目的只有一个——在实现可能频繁变化的前提下，守住行为稳定性。 可以重点建设三类测试： 如果说 Context Engineering 解决的是“喂什么给AI”，那么 Harness Engineering 解决的就是“如何让AI稳定地在一套受控环境里工作”。 很多团队的问题不是 Prompt 不够聪明，而是没有支架。每次生成都是一次性的、偶然的、不可复现的。今天好用，明天换个上下文就失灵。 Harness Engineering 的核心，就是把 Prompt、上下文、执行环境、测试脚手架、评估脚本、样例数据、回放机制连接起来，形成一套可重复、可验证、可迭代的工作流。 它通常包括： 如果把 Prompt Engineering 看成技巧，Context Engineering 看成知识组织，那么 Harness Engineering 就是把这一切工程化、制度化、流水线化。它本质上是 AI 时代的“工装”和“夹具”。 AI让改动更频繁、更碎片化，也更容易在短时间内堆出大量“表面能跑”的提交。因此，团队需要的不是更松的交付，而是更强的交付系统。 AI时代的 CI/CD，不应该只负责“代码能不能合并”，还应该承担“行为有没有变坏、风险能不能被看见、出事后能不能退回来”的职责。 至少要把下面几件事纳入默认工程能力： 在AI时代，真正危险的不是“生成错了”，而是“生成错了却没人第一时间看出来”。可观测交付的意义，就是把“看不见的错误”变成“可被快速发现和快速回退的错误”。 AI进入开发之后，团队最容易陷入一种错觉：大家都觉得自己更快了，但没人说得清到底快在哪、又慢在哪。 这就是为什么指标体系必须补上。它不是为了给团队制造新的考核焦虑，而是为了防止“局部效率提升”掩盖“系统效率退化”。 一个更适合AI时代敏捷团队的指标体系，可以重点观察： 真正值得庆祝的，不是 Prompt 数越来越多，也不是生成字节数越来越大，而是：验证变快了、返工变少了、接管变容易了、学习被沉淀下来了。 传统敏捷的小步快跑是：小功能 → 小代码 → 小发布 → 小反馈。 AI时代的小步快跑应该变成：小假设 → 小验证 → 小意图 → 小生成 → 小审查 → 小发布 → 小学习。 关键变化在于：“跑”的不是代码量，而是验证速度。 你应该在一天内验证十个假设并放弃其中九个，而不是花一周时间把其中一个假设做成华丽但错误的代码。 AI时代，一个开发者加上AI工具，产出能力确实可能超过传统的小团队。但这也带来了一个危险：没有了团队的制衡机制，个人更容易沉迷于“AI看起来已经做完了”的幻觉。 答案不是放弃单人开发，而是建立更严格的个人敏捷纪律： 随着AI深入开发流程，团队角色也在进化。这里我刻意保留一些“有名字”的说法，因为它们确实抓住了变化的方向。 这些名字之所以值得保留，不是因为它们听起来新，而是因为它们提醒我们：AI时代的团队分工，正在从“谁写代码”转向“谁定义问题、谁构造上下文、谁验证结果、谁维护长期结构”。 用AI快速堆砌功能，不等于敏捷。没有反馈循环、没有验证机制、没有方向修正的快，只是高速撞墙。 真正的敏捷速度，是“尝试—学习—调整”的循环速度，不是代码产出的速度。 当一个团队长期依赖AI生成代码，团队成员可能会逐渐失去对底层技术、系统边界和故障模式的理解。这违反了敏捷里的“可持续开发”精神——团队应该能以长期可维持的节奏持续交付价值。 如果AI停工一天团队就瘫痪了，那这个团队不是敏捷的，而是脆弱的。 AI说“完成了”，很多时候只是“生成了”。在AI时代，团队必须重新定义“完成”（Definition of Done）。 至少应该满足： 缺少以上任何一条，都不应该被视为“完成”。 回顾敏捷宣言的四条价值观： 在AI时代，这四条价值观不仅没有褪色，反而每一条都获得了新的迫切性： AI没有改变敏捷的本质，它只是以更尖锐的方式提醒我们：软件开发的核心矛盾从来都不是“人 vs 代码”，而是“确定 vs 不确定”。 当代码初稿的生成成本显著下降，真正稀缺的不是算力，不是 API 额度，而是人类的判断力、方向感，以及把混乱重新组织成秩序的能力。敏捷在AI时代的终极使命，就是帮助人类在无限的可能性中，快速找到正确的路，并确保我们在到达终点时，依然理解自己到底建造了什么。 Vibe Coding 很快。但敏捷的意义，是让我们有节奏地快——而不是慌乱地快。 注： 这篇文章本身，也是一次人与 AI 结对写作的实践。当AI可以一天生成一万行代码，限制我们交付的，不再只是手速，而是脑子有多清楚。
引言：一个看似矛盾的现象
一、AI时代下，传统敏捷实践正在失效的场景
1.1 站会变得尴尬
1.2 以编码耗时为核心的估算正在失真
1.3 PR Review 的困境
1.4 结对编程的进化
二、什么没有改变？敏捷的底层逻辑依然成立
2.1 不确定性的本质没变
2.2 沟通成本依然是最大瓶颈
2.3 技术债依然存在，只是换了形式
三、敏捷在AI时代的重构——新实践建议
3.1 从“开始生成”到“Definition of Ready”
3.2 从“迭代代码”到“迭代意图”
3.3 从“写 Prompt”到“Context Engineering”
3.4 从“每日站会”到“每日对齐会”
3.5 从“代码 Review”到“结果验证”
3.6 从“故事点估算”到“信心度估算”
3.7 从“Sprint交付功能”到“Sprint交付学习”
3.8 从“自动化测试”到“AI契约测试”
3.9 从“一次性提示”到“Harness Engineering”
3.10 从“持续集成”到“可观测交付”
3.11 从“感觉变快”到“指标化管理”
四、Vibe Coding × 敏捷 = 新的开发范式
4.1 什么是适合AI的“小步快跑”
4.2 单人敏捷（Solo Agile）
4.3 团队层面的新角色
五、警惕！AI时代敏捷的陷阱
5.1 “快”不等于“敏捷”
5.2 过度依赖AI导致的能力空心化
5.3 虚假的“完成”
结语：敏捷的终极形态——人机协同的节奏感
“AI让‘做’变得便宜，让‘想’变得昂贵。敏捷的价值，恰恰在于保护‘想’的时间，并把‘想清楚’变成团队的日常能力。”
