当 AI 让代码不再稀缺：未来软件工程的范式转移

副标题：从通用软件与代码复用，走向技术分层、场景特化与知识驱动的软件生产

一、引言：如果编写软件的成本趋近于零，会发生什么？

以一个思想实验开篇：

假设人类从一开始就拥有 AI，能够以极低成本生成、修改和重构数百万行代码，我们还会建立今天的软件工程体系吗？

为什么需要如此多的大型通用框架？
为什么大量业务软件依赖复杂的配置系统？
为什么软件需要牺牲特定场景的性能和简洁性来追求通用性？
为什么程序员的大量时间花在理解和适配既有代码上？

提出文章的核心观点：

现代软件工程的许多设计原则，并不是唯一合理的技术选择，而是在人类编码与维护成本高昂这一历史条件下形成的经济最优解。

AI 正在改变这一前提。

二、传统软件工程的经济基础：代码昂贵，因此必须复用

2.1 软件复用的历史必然性

人类开发者的时间、精力和知识有限。

为了摊薄开发成本，软件工程逐步形成了以复用为中心的体系：

通用库、框架和中间件
面向对象与设计模式
抽象层、插件和扩展机制
配置驱动的软件产品
大型开源项目与依赖生态

2.2 通用性并不是免费的

追求通用性往往意味着付出额外成本：

为不需要的场景保留大量功能
抽象层增加认知和调试复杂度
通用接口阻碍特定场景的极致优化
配置、依赖与兼容性形成长期维护负担

2.3 一个反直觉的判断

过去我们认为优秀的软件应该具有良好的通用性，部分原因只是因为重复开发太昂贵。

当重复生成实现的成本下降，通用性就不再必然是最优选择。

三、AI 改变的不只是编程效率，而是软件的生产经济学

3.1 从人工编程到 AI 生成

传统软件生产链：

需求 → 架构设计 → 人工编码 → 测试 → 交付 → 维护

AI 原生软件生产链：

意图与需求 → 形式化规格与约束 → AI 生成 → 自动验证 → 部署 → 持续再生成

3.2 从复用代码到复用知识

过去最有价值的资产是已经实现的代码。

未来更重要的资产可能是：

领域知识（Domain Knowledge）
规格说明（Specification）
约束条件（Constraints）
接口与行为契约（Contracts）
测试与验证体系（Test Oracle）
自动生成与优化机制

代码从长期维护的核心资产，逐渐转变为由知识和约束生成的具体产物。

3.3 从通用实现到场景特化

传统方式：构建一个系统，支持一万个不同场景。

新方式：维护一套领域知识和生成能力，为一万个场景分别生成适合的实现。

探讨这种转变所带来的性能、复杂度、定制化能力和生命周期成本变化。

3.4 必须区分代码生成成本与软件总成本

AI 降低的首先是实现成本，而不一定是验证、部署、审计和维护成本。

因此，场景特化并不是无条件优于通用复用。

四、关键边界：基础设施不会消失，技术分工仍然存在

这是整篇文章最重要的限定与深化。

4.1 不是所有通用软件都因业务复用而存在

必须区分两种不同性质的通用性：

第一种：面向业务差异的通用性

例如：

试图适配所有企业业务流程的管理系统
为各种页面交互设计的庞大应用框架
为多种业务形态设计的复杂插件和配置体系

这类通用性的主要价值，是降低不同业务重复开发的成本。

当 AI 能低成本生成专用实现时，其中一部分通用性可能不再经济。

第二种：面向技术分工的通用性

例如：

GCC、LLVM 等编译器基础设施
PostgreSQL 等成熟数据库系统
操作系统内核
网络协议栈
文件系统
密码学库
标准化协议和接口

它们不仅是在复用代码，更是在封装高度专业化的技术能力。

4.2 基础设施的核心价值是专业分工

以 GCC 为例。

业务程序并不需要重新解决指令选择、寄存器分配、代码优化和目标平台适配等问题。

编译器把这些专业问题封装在相对稳定的接口后面。

数据库也是如此。

应用不需要每次重新实现事务、并发控制、持久化、崩溃恢复和查询优化。

这些基础设施存在的根本价值，不只是节省编码工作量，更是将复杂且相对稳定的技术问题交给专业化的软件层解决。

4.3 软件未来仍然是分层的，但分层原则将发生变化

过去的软件分层，同时受到技术复杂性和代码复用需求的驱动。

未来的软件分层，应更多由以下因素决定：

是否具有独立、稳定的技术职责
是否拥有明确的接口和行为契约
是否需要长期积累的专业知识
是否具有高昂的验证和可靠性成本
是否需要跨系统、跨组织协作
是否能够通过规模化投入持续改进

4.4 通用基础设施与场景特化并不矛盾

未来可能形成一种新的结构：

稳定的技术基础设施 + 可组合的能力接口 + AI 生成的场景特化软件

底层保留经过充分验证的专业技术能力。

上层根据业务需求动态生成，而不再依赖不断膨胀的通用业务框架。

甚至基础设施自身也可以在保持稳定契约的前提下，由 AI 生成不同的内部优化实现。

五、未来的软件架构：从层层通用抽象到稳定内核与动态生成

5.1 传统架构的问题

大量软件的架构层次，并不完全对应真实的技术分工。

部分抽象层仅仅为了应对潜在需求、兼容未知业务或实现代码复用而存在。

5.2 新的软件架构原则

提出一个基本原则：

在需要技术分工的地方建立稳定抽象，在需要业务差异的地方使用动态生成。

进一步讨论：

什么应该成为长期稳定的基础设施？
什么应该保留为标准协议和接口？
什么应该由 AI 根据场景生成？
什么样的抽象应该被消除？
什么样的抽象反而会因为 AI 而更加重要？

5.3 软件的复杂性将重新分布

通用业务实现中的复杂性可能下降。

规格设计、系统边界、验证、可观测性和安全性的重要性则可能上升。

未来的软件可能不再以源代码规模衡量复杂性，而更多以行为规格、系统约束及其验证难度衡量复杂性。

六、开源生态的新形态：从共享成品代码到共享可执行知识

6.1 传统开源项目的核心资产

源代码、API、文档、社区和兼容性生态。

6.2 新形态：轻量脚手架与领域蓝图

未来一类重要的开源项目，可能不再提供完整的通用业务软件，而是提供：

领域模型与知识库
标准接口与规格
架构蓝图和轻量脚手架
参考实现
测试数据与验证套件
性能基准和评估标准
AI Agent 可使用的生成规则

开发者借助 AI，根据特定需求生成最终实现。

6.3 基础设施开源与业务软件开源将出现分化

基础设施开源继续积累经过长期验证的成熟实现、标准与生态。

业务应用领域则可能出现更多规格驱动、知识驱动和生成驱动的开源项目。

两者不是相互替代，而是形成新的协作关系。

6.4 新的开源价值衡量标准

一个项目的价值，不一定取决于代码量、功能数量或支持了多少种业务场景。

还可能取决于：

领域知识的完整程度
规格的准确性
验证体系的覆盖能力
生成实现的可靠性
对特定场景的适应能力

七、软件生命周期的重构：从维护代码到维护规格

7.1 从补丁式维护到重新生成

传统软件主要通过不断修改既有代码完成演进。

未来部分软件可以在需求变化时，根据新规格重新生成实现。

7.2 源代码可能成为中间产物

类似今天编译器输出机器码，未来的 AI 软件生产系统可以根据规格生成应用代码。

需要长期维护的，是生成依据和验证能力，而不一定是每一行实现。

7.3 软件版本管理的变化

从以代码提交和版本发布为中心，逐步扩展为：

规格版本
约束版本
验证套件版本
生成器版本
可追溯的构建产物

7.4 新的软件可靠性问题

讨论生成式软件面临的挑战：

同一规格是否能够得到可重复的行为？
如何保证重新生成不会引入回归问题？
如何进行安全审计和供应链管理？
如何保证长期数据兼容性？
如何控制 AI 生成错误的传播？

当代码生产不再稀缺，证明代码正确可能成为软件工程最稀缺的能力之一。

八、软件产业和开发者角色的重新分工

8.1 大型业务软件的价值可能被重新评估

传统 SaaS、ERP、CRM 和各类企业软件，部分竞争优势来自既有功能代码、产品完整性和定制化能力。

当企业能够低成本生成业务系统，这些优势可能受到挑战。

但数据积累、业务网络、合规能力、服务保障和生态协作仍可能构成重要壁垒。

8.2 基础设施和专业技术能力可能更加重要

随着业务实现更加容易生成，稳定基础设施、核心算法、协议标准、验证工具和专业技术知识可能成为更重要的公共底座。

8.3 开发者角色的转变

从以编写实现为主要任务，转向：

识别真实需求
定义系统边界
设计技术契约
建立规格与约束
组织自动化验证
判断技术分工是否合理
评估系统整体成本与风险

未来软件工程师的核心价值，将更依赖于理解问题和验证解决方案，而不仅是熟练编写某种语言。

九、结语：AI 不会消灭软件工程，而是让软件工程回归问题本身

回到开篇的思想实验：

如果代码不再稀缺，我们还需要今天这样的软件工程体系吗？

答案可能是：

我们仍然需要编译器、数据库、操作系统、标准协议和稳定的技术分层，因为它们代表真实存在的专业技术分工。

但我们未必还需要如此多仅仅为了节省人工编码成本而产生的通用业务框架、适配层和复杂配置体系。

未来软件工程的核心原则或许是：

稳定的技术能力应该被封装和复用；变化的业务需求应该被描述和生成；系统的正确性应该被独立验证。

软件工程不会走向没有抽象、没有复用的世界。

它将从以代码复用为核心的时代，走向以知识复用、专业技术分工和自动化生成共同驱动的时代。

最终被重新定义的，不是代码如何编写，而是什么东西真正值得被长期构建、维护和复用。