《软件工程经济学》②

软件工程真的一直在进步吗？

上篇聊了一个观察：AI Coding 让写代码变便宜了，但软件开发并没有因此变轻松。省下来的时间，被重新分配到了需求讨论、上下文补充和结果验证上。

有一个问题随之而来：如果不同成本之间的比例在变，那过去二十年形成的一些行业共识，会不会也需要重新审视？

这篇先把 AI 放一边，聊一件更底层的事。

行业里有一个很流行的叙事。

瀑布 → RUP → 敏捷 → DevOps → AI Coding 。

每一步都像是对前一步的超越。瀑布太重，所以有了敏捷。敏捷不够工程化，所以有了 DevOps 。现在 AI 来了，整个开发方式又要变。

听起来像一条不断向前的直线。

但如果你把时间线拉到四十年，把所有主流方法论放在一起看，会发现一件很难用"直线进步"解释的事。

很多已经退出历史舞台的方法，正在重新进入讨论。

一个具体的例子。

上世纪九十年代，CASE 工具承诺从模型直接生成代码。后来这个方向逐渐沉寂。

今天，Agent 又重新开始回答同一个问题：：

机器能不能根据一个足够准确的描述完成软件开发？

用例是另一个例子。

十年前它几乎退出了主流讨论，敏捷用 User Story 取而代之。但这两年，当 Agent 需要独立完成带着分支和例外的复杂任务时，不少团队发现，曾经被抛弃的用例结构，恰好提供了 Agent 执行时最需要的那类信息。

领域模型也是。DDD 的核心思想在敏捷时代被认为太重，但这两年在企业级 AI 项目里重新被大量引用。

如果软件工程真的是一条不断进步的直线，这些"旧方法"的回归很难解释。

一个更好的解释，也许不是直线，而是钟摆。

四十年来的方法论一直在这两极之间来回摆——

一极相信：只要把系统描述得足够精确，实现就不会出问题。

另一极相信：现实变化太快，不如先做出来再调整。

七十年代到九十年代，钟摆在"精确描述"那一侧。结构化分析、面向对象设计、UML 、RUP 、CASE 工具、MDA ，方法不同，底层信念一致：模型清楚，实现可靠。

然后互联网来了。钟摆摆向了"先做出来"那一侧。敏捷、精益创业、DevOps ，方法不同，底层信念也一致：别试图提前描述清楚，快速试错成本更低。

但钟摆不是简单地来回。

每一次摆动，其实都在回答同一个问题：软件开发里，什么东西最贵？

当实现成本极高时，值得在前期多投入来减少后期修改——所以形式化工程占优。

当发布和回滚的成本极低时，前期分析的边际收益下降——所以轻量化工程占优。

方法论本身没有绝对的好坏。

同一种方法，在不同的成本结构下，会有完全不同的经济性。

理解这一点，能帮我们看清楚一些过去被混在一起的事情。

比如 RUP 和敏捷的关系。

行业流行的说法是"敏捷战胜了 RUP"。但仔细看，它们面对的根本不是同一个问题。

RUP 的前提是需求相对稳定，发布周期长，修改代价高。在这种环境下，前期多花时间分析需求，总成本更低。

敏捷面对的现实是需求未知，发布成本低。前期分析的回报太低，不如直接上线去试。

更准确地说，真正的区分不在于"需求变不变"——银行和税务系统的需求也一直在变。

真正的区别，不在于需求会不会变化，而在于需求能不能在开发之前，通过分析不断逼近真实。

社交产品、推荐系统这类产品，很多核心需求只能通过上线、观察和迭代不断发现。

但银行清算规则可以。税务申报逻辑可以。风控审批流程可以。它们很多时候是可以被分析、被建模的。

只是分析和维护这件事本身的成本，一度太高了。

当分析成本高于试错成本，行业自然选择更轻的方法。这不是理念上的胜负，是经济学。

至少从过去几十年的历史来看，一个反复出现的现象是：真正推动方法论变化的，往往不是理念，而是成本。

那么今天呢？

上篇我们观察到，AI Coding 正在快速降低实现成本。那些过去因为"正确但太贵"而被放弃的实践，是否值得重新评价？

那些过去隐藏在实现成本之后的问题，是否正在重新成为真正的瓶颈？

我不确定全部答案。但有一个趋势已经清晰：

如果成本结构的变化让"正确但昂贵"的实践重新变得经济，那么今天重新进入视野的，可能就不只是某一种具体的方法。

如果这种判断成立，那么今天重新进入视野的，也许不是某一种具体的方法，而是整个需求工程。

下一篇，我想从一个几乎被遗忘了二十年的具体工件开始聊起。

最后留一个问题。

你的团队里，有没有哪种做法——曾经被认为"太重了""没必要""过时了"，最近又重新开始被提起？