软件工程50年：我们改的是代码，还是只是换了身衣服

软件工程的方法论改了50年，但有个问题没人敢问——这些改变是真的学会了什么，还是只是换了个流行款式？

2023年，全球企业在敏捷转型上花了约300亿美元。同期，Standish Group的报告显示，项目成功率跟20年前相比，曲线几乎重合。钱花了，仪式做了，站会开了，但东西该延期还是延期，该烂尾还是烂尾。

疼痛驱动的进化史

软件工程的方法论从来不是设计出来的，是疼出来的。

瀑布模型（Waterfall）在1960年代诞生时， Winston Royce 的原始论文其实警告过它的风险——但管理层喜欢"需求→设计→编码→测试"的线性美感，像喜欢甘特图一样。结果项目平均超期200%，需求变更成本呈指数级爆炸。疼了二十年，才有人认真听 Royce 的警告。

敏捷（Agile）在2001年出现，不是因为 Kent Beck 们突然开悟，是因为 Rational Unified Process（统一软件开发过程）把中型团队也逼进了文档地狱。17个人在雪鸟滑雪场签了份宣言，核心就一句话： working software over comprehensive documentation（可工作的软件胜过详尽的文档）。

但敏捷能扩散，不只是因为好用。2008年金融危机后，企业需要"更快交付"的故事向董事会交代；Scrum 认证体系（Scrum Alliance 2001年成立）创造了数十亿美元的培训市场；Jira 等工具把敏捷流程固化成可购买的软件模块。方法论的传播路径，和疗效只有松散的相关性。

survived 下来的实践——迭代交付、持续集成（Continuous Integration）、反馈循环——确实在足够多的场景里减少了疼痛。但这比"证明有效"弱，比"纯属巧合"强，处于一种尴尬的中间地带。

每代人都得重新踩坑

更深的问题从来没解决：流程是应该被测试的假设，而不是被服从的真理。

这个教训每代人都得重新学一遍，而且学得很难。1990年代的 CMM（能力成熟度模型）被当成宗教推行，直到有人发现五级认证的公司照样产出垃圾代码。2010年代的 Spotify 模型（Spotify Model）被全球复制，但 Spotify 自己早就弃用了——它从来就不是给外部公司设计的。

方法论被继承时总是以教义形式出现。新入行的工程师拿到的是"我们要做双周迭代"的指令，而不是"我们在验证双周是否适合当前项目"的问题。组织把流程当成身份标识——"我们是敏捷的"——而不是可证伪的实验。

这种混淆的代价是真实的。2022年，一家金融科技公司强制推行 SAFe（规模化敏捷框架），18个月后工程师离职率上升40%，交付周期反而延长。复盘时发现，问题不是敏捷错了，是把敏捷当成正确答案强制执行错了。

AI正在拆掉成本围墙

现在变量变了。AI 正在溶解支撑当前实践的成本结构。

写代码的成本在下降。GitHub Copilot 的用户编码速度提升55%，这改变的是"写代码很贵，必须仔细规划"的底层假设。测试的成本在下降。AI 生成的测试用例覆盖率达到人工的80%，但成本是1/20。代码审查（Code Review）在自动化，Facebook 的 SapFix 已经能自动修复部分漏洞。

这些变化不是渐进优化，是前提条件的瓦解。当构建和测试变得便宜，"前期详细设计"的合理性就动摇了；当审查可以自动化，"必须人工把关每一行"的仪式就值得重新审视。

但有些东西 AI 碰不到：弄清楚该做什么、为谁而做。这是产品经理的地盘，是用户研究的地盘，是组织政治的地盘。这些问题的成本没有下降，反而可能因为技术选项的爆炸而上升——当做什么都变得可能，选择做什么变得更难。

组织会分化为两类：把流程当假设的，和把流程当信仰的。前者会快速实验、废弃、重组；后者会先困惑，再防御，最后被迫改变。

软件工程史上有过多次这种分化。1980年代的结构化编程 vs goto 的捍卫者；2000年代的敏捷 vs 瀑布的坚守者。每次"被迫改变"都伴随着大量浪费——项目取消、团队重组、职业生涯中断。

这次的不同在于速度。AI 压缩了反馈循环，也压缩了纠错的时间窗口。

50年来，软件工程确实学到了一些东西：迭代比长周期安全，反馈比假设可靠，自动化比人工重复劳动稳定。但这些知识总是以过时的形式被传递，每个新团队都要重新发现它们的边界条件。

AI 不会终结这个循环，但会加速它。问题是这一代人要为纠错支付多少学费——以及有多少人能意识到，他们手里的方法论不是地图，只是上次探险时画的草图。

你的团队现在在用什么流程？是去年选的，还是十年前选的，还是"反正大家都这么做"？