软件工程50年没做成的事，被大模型做成了

如果你翻一遍工程史，会发现一件非常尴尬的事：机械、化工、电力、通讯——所有叫得上号的工程门类，都完成了同一件事：用一台烧煤或通电的设备，把原本要靠人盯着、判断、调整的事给替代了。蒸汽机上的离心调速器、化工厂的恒温器、电网的调度器、流水线上的PLC——本质上都是"能源换低阶智能"。

唯独软件没有。软件工程喊了五十年"工程化"，骨子里还是手工艺——代码得一行一行靠人脑写，编译器只是翻译，从不"理解"需求。

这个局面，直到大模型出现才开始松动。

为什么软件工程一直没"工程化"成功

先看经典工程是怎么赢的。蒸汽机之所以能替代人力，不是因为它力气大，是因为它把"调速"这个认知动作固化成了物理装置。离心调速器不需要人盯着转速表，机械结构自己就能感知变化、自动调节进气量。这就是控制论的雏形——让机器自己完成感知、判断、执行的闭环。

化工、电力、自动化都是沿着同一条路走下来的。工厂里最大的不确定性来源是人脑，工程化的本质就是把这个人脑从主回路里抽走，让一台机器来管。

软件为什么做不到？因为软件需要的是高阶认知——抽象、分解、推理、创造。这些东西没法像调速器那样固化。代码是人一行一行想出来的，每一行都依赖人脑的认知活动。你可以用编译器、类型系统、单元测试来辅助，但它们只是在验证结果的正确性，不是在替代认知本身。

更扎心的是，过去五十年所有软件方法论——结构化编程、面向对象、敏捷、Scrum、DevOps——本质上都在做同一件事：优化"堆人力"的方式，但没改变"必须靠人力堆"这个事实。敏捷是承认需求会变，Scrum是承认一个人管不了，DevOps是承认交付链太长。它们全部是在处理人脑带来的不确定性，而不是消除人脑这个不确定性的源头。

大模型补上了那个终极缺口

如果把大模型放到工程史的坐标系里看，它的位置就非常清楚了。

经典工程做了"能源→低阶智能"，大模型做的是"能源→高阶智能"。输入算力，输出的是能理解需求、生成代码、做逻辑推理的认知产物。这不是简单的"AI写代码"，这是人类历史上第一次有了"认知引擎"这个东西。"引擎"不是修辞——它在工程史中的位置，和蒸汽机是平级的。

蒸汽机让"做功"这件事第一次能源化，大模型让"认知"这件事第一次能源化。

这才是AI软件工程范式革命真正让人激动的地方。不是因为它能写多少行代码、省几个程序员，而是它把"认知"从人脑这个不可靠的容器里解放出来了。软件工程第一次有条件去走经典工程已经走过的那条路——把人类认知从主回路里撤出来，让机器接管执行层。

但问题才刚开始

认知引擎带来了新麻烦，而且是全新的类型。

经典工程面对的不确定性是物理世界的不确定性——温度波动、负载变化、材料疲劳。这些不确定性有物理规律可循，可以建模、可以预测、可以设计冗余。

认知引擎带来的是认知层面的不确定性。大模型会幻觉、会误解需求、会生成看起来正确但有逻辑漏洞的代码。这些不确定性的来源不在物理世界，在模型内部——它是一个非确定性系统，同样的输入可能产生不同的输出。你没法像设计蒸汽机那样设计一个认知引擎的容错机制。

更麻烦的是：在经典工程里，"不对"是一个工程问题——传感器坏了、管路堵了，修理就是了。但在认知引擎里，"不对"可能是一个语义问题——模型生成的代码跑通了，但它实现的需求跟你想要的不是同一个东西。这种错误更难捕获，后果也更难预测。

范式真正的含义：从"写"到"定义"

这轮变革的核心不是"AI写代码替代程序员"。核心是角色的重新分配。

以前的软件开发循环是：人理解需求→人写代码→人测试→人部署。现在是：人定义目标和约束→AI生成代码→人验证结果。

人从"写代码的人"变成了"定义目标的人"和"把关结果的人"。这对人的要求不是变低了，是变了。过去一个好程序员的标准是"能把逻辑写清楚"，未来的标准是"能把需求定义清楚，并且能判断AI生成的东西对不对"。

这个变化对软件工程的冲击比对编程的冲击更大。过去五十年积累的工程实践——代码审查、单元测试、CI/CD、监控——全部是基于"人在写代码"这个前提设计的。当AI生成大部分代码时，这些实践的适用性需要重新评估。你该怎么review AI写的代码？测试用例谁来写？是AI自己写还是人写？这些问题没有现成答案。

最难的不是生成，是验证

如果说LLM解决了"生成"的问题，那"验证"就是下一块要啃的骨头。

代码能跑不等于代码对。AI生成的代码正确率在持续提升，但正确率99%和正确率100%之间的差距，比你以为的大得多。一个需求里需要处理的边界条件可能有几十个，AI对了98个、漏了2个——这2个就是生产环境埋的雷。

传统软件工程里，验证靠的是测试、review、静态分析、形式化方法。这些东西在AI生成的代码面前够不够用？我的判断是：不够。因为传统验证手段假设代码是"有意为之"的——人会犯错但可以解释、可以追溯。AI生成的代码出问题时，追溯链条是断的——没有设计意图，有的是概率分布。

这才是范式革命真正难的地方。生成能力的瓶颈在快速打开，验证能力的瓶颈还没有像样的突破。而一个工程体系能不能真正运转起来，恰恰取决于验证侧能不能跟得上生成侧的进步速度。

这件事的终点不在技术

说到这，讲一句不太中听的话：软件工程能不能完成这次范式转变，技术只占一半。

另一半在组织。过去五十年让软件成为手工艺的东西，不只是缺少认知引擎。还有组织结构、管理方式、考核体系、工作习惯——所有这些都在把人往"写代码的人"这个角色上推。当角色变成"定义目标的人"和"把关结果的人"时，这些东西全部要跟着变。

这才是最难的那道坎。技术迭代可以按季度来，组织变革是以年为单位的。蒸汽机从发明到全面替代手工业花了上百年。认知引擎不会需要那么久，但它也不会只因为技术就自动完成范式切换。

软件工程真正的"工程化"时刻，不是在某个模型跑分超过人类的那天。是在人们不再问"AI写的代码能不能用"的那天——就像没人再问"离心调速器靠不靠谱"一样。

到了那一天，软件工程才算走出了五十年的手工艺时代。