瀑布模型：那个被骂了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亿美元。这是瀑布模型的主场。