AI软件工程范式革命的思考

一句话概括

王鹏程从控制论和工程史视角出发，论证软件工程过去五十年从未真正”工程化”——它一直停留在手工艺阶段，而大模型的出现第一次让”投入能源，另一头流出可工作的软件”成为可能，文章系统推演了AI-Native软件工程的正确路径、组织形态和核心难点。

实践内容

核心论点：软件工程是五十年来最不彻底的工程

经典工程的成功路径：
  蒸汽机 → 离心调速器（机械负反馈）
  化工 → 恒温器、压力调节器
  电力 → 电网调度系统
  自动化 → PLC、流水线控制器

共同点：消耗能源把人脑参与的低阶认知回路固化成物理装置

软件工程的卡壳：
  软件开发做的是抽象、分解、推理、创造——都是高阶认知
  没法像调速器那样固化成物理回路
  必须靠大量高密度的人力
  人脑：会误解、会遗漏、不一致

历代方法论的本质

结构化编程、面向对象、敏捷、Scrum、DevOps
  → 都是优化堆人力的方式
  → 没改变"必须靠人力堆"这个事实
  → 承认"人是不可替代的不确定性来源"，然后让它更可管理

但留下了一整套自动化验证基础设施：
  编译器、类型系统、单元测试、CI/CD、灰度发布
  契约编程、形式化方法、静态分析、覆盖率、监控、链路追踪
  → 这是新范式的地基

大模型补上了缺口

大模型的工程史定位：
  第一次让"非人类实体"能够处理软件开发中的高阶认知任务
  不是替代编译器（那是低阶），是替代需求分析、架构设计、代码编写

但带来了新麻烦：
  1. 输出不确定：同样 prompt，不同次输出不同
  2. 验证困难：AI 写的代码，人不一定能快速理解
  3. 上下文窗口限制：无法一次处理整个大型项目
  4. 幻觉问题：可能生成看似正确但实际错误的代码

当下业界的弯路

错误路径：
  1. 把 AI 当"更快的编译器"——只用来补全代码片段
  2. 把 AI 当"全能程序员"——期望它独立完成整个项目
  3. 把传统流程强加给 AI——让 AI 走人的工作流

正确路径：
  让 AI 做它擅长的（生成、推理、模式匹配）
  让人做人擅长的（判断、决策、创造性思维）
  建立新的协作范式，而不是简单替代

AI-Native 软件工程的特征

1. 认知主体转移：从"人脑为主"到"人机协同"
2. 验证体系升级：AI 生成 → 自动化验证 → 人类确认
3. 知识管理变革：从文档驱动到知识库+RAG 驱动
4. 组织形态变化：从"人管人"到"人管 AI + AI 管流程"
5. 工具链重构：IDE → Agent Harness → 评测体系

落地路线图

阶段一：AI 辅助（当前主流）
  - Copilot / Claude Code 补全代码
  - 人做决策，AI 做执行
  - 验证方式不变

阶段二：AI 驱动（正在发生）
  - Agent 自主完成子任务
  - 人定义需求和约束，AI 规划和执行
  - 需要新的验证体系

阶段三：AI-Native（未来）
  - AI 成为第一公民
  - 人退到设计、审核、创新的位置
  - 软件工程真正"工程化"

摘录

软件工程过去五十年其实没真正”工程化”过。它一直停留在手工艺阶段，被各种方法论包装成工程，但骨子里还是靠人脑堆。这一点直到大模型出现才开始有可能改变。

经典工程的”成功”，秘密不在某项技术，而在这套”能源换低阶智能”的范式本身。蒸汽机的离心调速器、化工厂的恒温器和压力调节器、电网的调度装置、流水线上的 PLC——本质上都是同一件事：让原本要靠人盯着、调整、判断的事情，由一台烧煤或者通电的设备自己完成。

软件危机的本质就是这件事——不是哪个技术不行，而是这个工程门类的认知主体始终是人脑，而人脑在这套生产关系里没法被替换。

这五十年沉淀下来一整套东西——编译器、类型系统、单元测试、CI/CD、灰度发布、契约编程、形式化方法、静态分析、覆盖率、监控、链路追踪。这套东西虽然没让软件工程”工程化”成功，但它们留下了一个非常关键的资产：一整套自动化验证基础设施。

大模型这件事的工程史定位：第一次让”非人类实体”能够处理软件开发中的高阶认知任务。不是替代编译器（那是低阶），是替代需求分析、架构设计、代码编写。