瀑布模型的问题被反复验证后，软件行业开始寻找更好的方法。
2001 年，17 位轻量级软件开发方法的倡导者在美国犹他州的雪鸟滑雪场聚会。他们讨论了两天，最终发表了《敏捷软件开发宣言》。这份宣言只有四句话，但改变了之后二十年软件开发的走向：
注意每句话里都有一个"高于"——不是说右边的那些不重要，而是左边的比右边的更重要。但在这个宣言发表之前，行业里的实际情况是：流程比人重要、文档比代码重要、合同比合作重要、计划比变化重要。敏捷宣言在做的，是一次"价值重排"。
敏捷的核心不是"不做文档"或"不遵循计划"，而是把反馈循环缩短到极致。瀑布模型中，你要等几个月甚至几年才能看到用户对产品的反馈。敏捷把它压缩到几周。Scrum 的"Sprint"（冲刺）通常设定为两周——每两周交付一个可运行的功能增量，然后根据反馈调整下一步计划。
这种"两周一次反馈"的节奏，在 Vibe Coding 出现之前，是最短的反馈循环。两周的时间，你做一个功能给用户试用，收集反馈，然后决定下一轮做什么。这比瀑布模型的"一年半"已经好了太多。
敏捷实践中有几个核心操作值得展开说一下。
每日站会（Daily Standup）—— 团队每天早上花 15 分钟，每个人回答三个问题：昨天做了什么、今天打算做什么、遇到了什么阻碍。这个会议的目的是"快速同步信息"，而不是"汇报工作"。你发现某个人被一个 bug 卡了两天，其他人可以说"这个我遇到过，解决方案是……"——信息障碍在 15 分钟内被扫清了。
Sprint 评审（Sprint Review）—— 每两周结束时，团队向利益相关者演示这两周完成的功能。利益相关者看到了真正能运行的软件，而不是几百页的需求文档。他们可以说"这个功能不错，但方向偏了一点"——反馈在半天的会议中完成。
回顾会议（Retrospective）—— 团队复盘这两周的合作：哪些做得好、哪些可以改进、下个 Sprint 要尝试什么改变。这个是敏捷中最被低估的环节——它不是"追责"，而是"持续改进"。
但敏捷也有一个被广泛讨论的问题："敏捷"这个词在实践中被严重稀释了。 很多公司说自己 "We are Agile"，但实际上只是在瀑布模型外面包了一层 Scrum 的外壳——每两周做一次"迷你瀑布"，需求仍然是在 Sprint 开始前就锁定的，团队仍然没有真正的自主权，客户仍然只在 Sprint 评审时才出现。这就变成了一种扭曲的流程，行业里有人叫它"敏捷剧场"（Agile Theater）——你有站会、有 Sprint、有回顾，但你的开发方式本质上和瀑布没什么区别。
敏捷解决了"需求→开发"之间的反馈循环，但"开发→上线"之间仍然存在一条鸿沟。在敏捷早期，开发团队和运维团队仍然是两个独立的部门。开发把代码"扔过墙"给运维，运维负责部署上线。开发不知道生产环境长什么样，运维不知道代码是怎么写的。出了问题，两边互相推诿。
DevOps（Development + Operations）就是要打破这堵墙。
DevOps 的核心实践是 CI/CD（持续集成/持续部署）：
CI/CD 的出现，把"从写完代码到上线"的时间从几个月压缩到了几个小时。这背后的理念和敏捷完全一致：缩短反馈循环。 如果在瀑布模型中反馈以年计，在敏捷中反馈以周计，在 DevOps 中反馈以小时计。
DevOps 还有一个重要的理念："你构建它，你运行它。"（"You build it, you run it."）——这句话来自亚马逊的 CTO 沃纳·沃格尔斯。意思是写代码的团队也要负责部署和运维自己的代码。你今天写了一个新功能上线了，今天晚上如果出了故障，你要自己爬起来修。这个规则强制开发者对自己的代码负责——不是"写完就扔了"，而是"写完了还要养着它"。
这种做法看起来增加了开发者的负担，但它的实际效果出奇地好：当你知道你自己要为生产环境的故障负责时，你写的代码质量自然就上去了。你会在写代码时多考虑边界条件，会主动加足够的日志，会在上线前做更充分的测试。
尽管敏捷和 DevOps 大大改善了软件开发的效率，但它们没有解决两个核心问题：
第一，它们没有消除"翻译损耗"。 敏捷缩短了沟通周期，但沟通的方式没变——你仍然需要把用户的需求翻译成用户故事，再翻译成技术任务，再翻译成代码。每次翻译都有信息损耗，而敏捷只是让这个损耗被发现得更早——你两星期后就能看到"翻译错了"的结果，而不是一年后。但你仍然很难在一开始就翻译对。
第二，它们没有改变"编码本身"的瓶颈。 不管你用多敏捷的流程，写代码仍然需要开发者一行一行地敲。你可以用 CI/CD 把上线的速度提到很快，但"写代码"这件事本身的速度并没有本质变化。一个人一天能写的代码量是有上限的——熟练的开发者每天大概能写 50~100 行高质量的生产代码。敏捷和 DevOps 没有解决这个物理瓶颈。
这就引出了 Vibe Coding 的角色。Vibe Coding 不是在和敏捷/DevOps 竞争——它是在它们的基础上，解决了它们没有解决的问题。
Vibe Coding 对敏捷/DevOps 最大的补充，可以从两个层面来理解。
在"想法验证"层面： 敏捷把你的反馈周期从几个月降到了两周。Vibe Coding 把它从两周降到了几分钟。你可以不再是"花两周做一个功能然后验证"，而是"花十分钟做一个原型然后验证"。这意味着你可以在开始正式开发之前，就用 AI 快速地探索更多方案。我们做一个功能可能有 5 种不同的实现思路，用敏捷你得硬选一个做两周——用 Vibe Coding 你可以让 AI 在半小时内把 5 种方案各做一个简陋原型，看完效果后选最好的那个。
在"编码瓶颈"层面： DevOps 解决了"从写完到上线"的速度问题，但没有解决"从想到写完"的速度问题。Vibe Coding 在解决这个问题——它让"从想法到代码"的时间从"敲键盘需要的时间"降到了"说话需要的时间"。你不是在写代码，你是在描述代码。
这两层的叠加效果是：Vibe Coding + DevOps = 从想法到上线只需要几分钟。 你想到了一个功能，对 AI 描述了它，AI 生成了代码，你审查后说"可以了"，CI/CD 自动把它部署上线。整个过程可能在一杯咖啡的时间内完成。这在瀑布时代需要 18 个月，在敏捷时代需要两周，在 Vibe Coding 时代只需要几十分钟。
问 AI：
"假设我已经在一个敏捷团队工作，我们每两周一个 Sprint。现在团队决定引入 AI 编程工具来辅助开发。你觉得我们的 Scrum 流程可以做哪些调整，来充分发挥 AI 的优势？比如 Sprint 的长度、用户故事的写法、评审的方式。"
这个问题的价值在于让你思考：你已经在用的一些"开发习惯"（比如 Sprint 的长度、站会的节奏、需求文档的格式）有多少是"因为这个流程要求这样做"，有多少是"因为当时没有 AI"？当你意识到后者的占比可能很高时，你就已经做好了"重新设计工作流程"的准备。