瀑布模型：那个被骂了30年的"老古董"，为什么还没死？

2001年，时任微软CEO鲍尔默对着记者说："Linux是一种癌症。"同期，IT圈子里流传的另一句话更狠："瀑布模型是软件工程的幽灵，它活着，但所有人都知道它该死。"

那一年，敏捷宣言刚发布，XP和Scrum正在硅谷的初创公司里疯狂试验。所有人都觉得，线性顺序、阶段分明的瀑布模型，即将和绿皮火车一起被扔进历史垃圾堆。

23年后，瀑布模型还活着。不仅活着，它每年还在为全球数以万计的政府项目、金融系统、军工软件提供着方法论骨架。

一个被骂了30年的老古董，凭什么？

瀑布模型的前世今生

先说清楚瀑布模型是什么。简单讲，它把软件开发切成五块：需求→设计→编码→测试→维护。按顺序干，上一阶段不完工，下一阶段不动工。

这听起来蠢透了，对吧？需求分析完就锁死？改一行代码要走完整个流程才能动？

没错。但问题来了：什么叫"锁死"？

互联网项目里，需求变更是家常便饭。所以敏捷这套东西好用。但如果你做的是核电站控制系统、医械软件、自动驾驶算法呢？你敢在开发过程中"快速迭代"？你迭代一个刹车逻辑试试？

瀑布模型的真正问题是：它假设需求是可以一次性搞清楚且不变的。这个假设在2000年后的互联网时代确实过时了——但这个假设从来没在所有领域过时。

一个被忽视的反讽

Vibe Coding那篇文章里有一段话很值得玩味。它说AI时代的开发是"意图驱动"，开发者描述意图，AI生成代码，迭代快，成本低。

但它同时承认了一个问题：AI生成的代码长期维护困难，技术债务累积，直觉式编码可能导致架构混乱。

这不就是瀑布模型试图解决的那个问题吗？

瀑布模型的核心逻辑是什么？前期想清楚，后期少折腾。 设计文档写清楚，架构搭好，接口定义明白，之后编码阶段就是体力活。

AI coding现在在做什么？让编码变得极快，但把设计这个环节的重量级降到了最低——甚至有人宣称不需要设计了，AI生成出来跑跑看。

这在做什么？这在把软件开发的风险后置。

瀑布模型最大的骂名是"风险后置，晚期才发现问题"。但如果"晚期才发现问题"的原因是"我根本没做前期设计就开干了"，那骂瀑布模型就骂错对象了。

瀑布模型没有错，错的是用它的人

我在前面那篇讲Vibe Coding的文章里看到一组对比数据：

	Vibe Coding	传统编码
开发速度	快	慢
可维护性	难	易
架构控制	低	高

这个表反过来读，就是瀑布模型的优缺点列表。阶段清晰、文档规范、设计前置——这套东西解决的不是"开发快不快"，而是"长期维护贵不贵"。

所以瀑布模型真正适合的场景，是那些"前期想清楚比后期改改看更便宜"的领域。

什么样的项目符合这个特征？

• 需求涉及强监管合规性（金融、医疗、军工）
• 用户群体固定、需求不会随潮流快速迭代
• 后期修改成本极高，甚至根本无法回滚
• 项目生命周期10年以上，遗产系统需要被继承

这些场景有一个共同点：改不起。

你做一个直播APP，用户说"背景音乐能不能换一个"，你当天就能改。这是敏捷的主场。

你做一个心脏起搏器软件监管认证通过了，FDA告诉你"抱歉，我们发现了漏洞"，你重新走一遍审批流程需要18个月，成本超过2亿美元。这是瀑布模型的主场。

不是谁比谁高级，是谁在哪个场景下更划算。

为什么你的团队用瀑布模型会死

但等等，如果瀑布模型这么好，为什么那么多团队用瀑布模型就是灾难？

因为他们用错了用法。

一个20人的互联网创业团队，用瀑布模型做需求分析→设计→编码→测试→维护，每周五天，每天站会都用PPT汇报进度。结果是什么？两个月后第一个可演示版本才出来，投资人早就投了隔壁那家敏捷团队。

不是瀑布模型错了，是这个团队的场景本来就不适合瀑布模型。 他们其实需要一个更轻量的开发框架，比如MVP+快速迭代。

还有一个问题叫"文档崇拜"。瀑布模型强调阶段成果物——需求规格说明书、设计文档、测试报告。有些人把"写文档"当成了目的，把"让下游阶段有据可依"当成了附属品。

结果文档写了一百页，下一阶段的工程师根本不看。这不是瀑布模型的错，这是组织没有理解文档的真正价值：文档是用来对齐认知的，不是用来交差的。

AI时代，瀑布模型的幽灵更清晰了

回到开头那个问题：为什么瀑布模型还没死？

因为AI时代让它死而复生了一件事——软件系统的复杂度在指数级上升，而人类对复杂系统的理解能力没有同步提升。

核电厂的控制系统比2000年复杂一百倍。自动驾驶算法比2010年复杂一千倍。这些东西你不可能边做边改，不可能快速迭代，不可能"MVP驱动开发"。

反而是瀑布模型的前期重投入，在这些领域变成了救命的投资。

AI coding工具现在可以帮你快速生成代码，但它没有办法帮你搞清楚"为什么要这样设计"。当你做的是心脏起搏器，当你的代码bug会杀死病人，这个"为什么"就值几百万美元的调研和分析时间。

所以呢？

所以，面对任何开发方法论，你需要先问自己一个问题：我做的东西，改得起吗？

改得起——用敏捷，用Vibe Coding，用一切能让你快速试错的方法。错了就重构，成本可控。

改不起——老老实实用瀑布模型，或者它的变种（V模型、阶段门法），把前期的设计阶段做扎实，用规范的文档让团队对齐，用清晰的阶段划分让风险可控。

方法论没有高下之分，只有场景之别。

这不是一个技术判断，是一个商业判断。而太多技术团队在用技术偏好替代了商业判断，然后用敏捷或瀑布模型之一背锅。

下次当你听到有人骂瀑布模型是"老古董"的时候，问他一句：你做的是什么，改得起吗？

---

配图由豆包·可图生图生成