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

从瀑布模型到敏捷开发，从单体架构到微服务，软件工程方法论平均每5-7年就换一次主流叙事。但一个尴尬的问题很少被正面回答：这些变化里，有多少是真正的"学习"，有多少只是管理层的集体换口味？

原文作者抛出了一个区分标准——学习是因为撞了墙才改，换口味是因为旧东西不够新鲜。按这个标准审视，软件工程的发展史更像是一本"疼痛日记"：不是谁设计了更好的方法，而是旧方法在特定场景下反复炸雷，逼得人不得不动。

方法论是怎么活下来的：不是赢在了起跑线，是死在了别处

迭代交付、持续集成、快速反馈——这些今天被视为常识的实践，它们的传播路径其实很潦草。咨询公司需要卖新课，CTO需要刷存在感，工具厂商需要推新套件，三股力量合力把某些做法捧上了神坛。

「方法论也通过咨询经济学、管理时尚和工具约束传播，这使得无法干净地将任何方法论的兴衰归因于纯粹的经验价值。」作者写道。

但存活下来的确实有一些共性：它们能在不同团队、不同项目里反复减少同一种疼痛。这种"跨场景止痛"能力比严格证明弱，比巧合强。有点像感冒药——没人完全清楚为什么对多数人有效，但确实比喝热水强。

真正的问题是更深层的那个教训一直没传下去：任何流程都是一个待检验的假设，而不是一个待遵守的真理。每一代新人都把前辈的方法论当教义继承，然后亲自撞一遍墙，才重新发现"原来这玩意儿是特定条件下的权宜之计"。

AI正在拆掉什么：成本结构，不是问题本身

作者对AI影响的判断很克制，但指向明确。构建成本下降、测试速度提升、代码审查自动化——这些环节的效率革命已经在发生。GitHub Copilot让写代码变便宜，AI测试工具让回归验证从小时级降到分钟级。

但有一件事AI碰不到：搞清楚该做什么、为谁而做。这是产品经理的老本行，也是软件工程里最贵、最慢、最不能外包的部分。你可以用AI一天生成100个功能原型，但选错方向的话，100个全是沉没成本。

这里的分化会很残酷。把流程当"可证伪假设"的团队，会快速实验、快速放弃、快速迭代。把流程当"最佳实践圣经"的团队，会先困惑（为什么AI写的代码还要走这么多审批？），再防御（制定"AI代码使用规范"），最后被迫（竞争对手已经跑完三个实验周期了）。

「理解其流程为猜想的组织将适应；不理解的将先困惑，再防御，最终被迫。」

历史的循环：我们终将纠正，但代价是多少

软件工程有个隐藏的自愈机制——它最终会纠正错误，只是纠正的方式很费人。瀑布模型盛行了二十年，直到足够多的项目延期超支到无法忍受；敏捷被滥用成"每周冲刺但从不交付"，直到有人开始谈"可持续节奏"。

每次纠正都伴随着大量浪费：被废弃的工具链、被推翻的组织架构、被裁撤的"转型专家"。作者的问题很直接：这一次AI驱动的重构，我们要付多少学费？

一个细节值得玩味。作者把软件工程的学习比作"不完全的失败学习"——我们确实从爆炸中学到了东西，但学到的东西被包装得太像真理，导致下一代必须重新发明怀疑。

现在轮到AI时代的新人了。他们会把"AI辅助开发"当成新教条，还是能从开头就保持警惕？历史没给过乐观的理由，但也没阻断过个体选择。

你的团队现在把AI工具当成"效率放大器"还是"思考替代品"？这个分类本身，可能就是下一个五年差距的起点。