软件越来越容易做,为什么反而越来越难维护?

如果只看代码,今天的软件未必比过去更难维护。

甚至恰恰相反。AI 可以解释陌生代码、补测试、寻找调用关系、修改依赖,也可以替开发者完成大量过去很耗时间的排查工作。2026 年发表在《Empirical Software Engineering》的一项受控研究也没有发现,使用 AI 辅助开发出来的代码会让后来接手的开发者明显更难修改。

所以,如果把"维护越来越难"简单解释成"AI 写的代码质量差",这个结论并不成立。

真正发生变化的地方,是软件的经济账。

软件的"出生价格"在下降,出生以后的账却没消失

一套软件其实有三种成本。第一种是把它做出来的成本,第二种是它存在期间持续产生的成本,第三种是有一天不再需要它时,把它安全地关掉的成本。

过去最显眼的是第一种。写一个内部管理工具可能需要几周,做一套业务系统可能需要几个月,因此很多需求在开始以前就会被开发成本筛掉。这个工具真的值得做吗?一年只用十几次的功能有没有必要单独开发?有没有现成产品可以代替?

AI 正在快速降低这道门槛。

OpenAI 今年公开过一个很极端的内部实验:一个真实投入使用的软件产品没有人工手写代码,应用逻辑、测试、CI、文档、可观测性和内部工具全部由 Codex 生成,最后形成大约百万行代码。OpenAI 估计,整个项目花费的开发时间大约是传统人工编写的十分之一。

这个数字不能拿来推算普通企业的项目周期。OpenAI 给 Agent 建立了专门的工具、测试、日志、文档和反馈环境,官方自己也明确提醒,这种自主程度不能在缺少类似工程投入的情况下直接复制。

但它说明了一件很重要的事:软件的"出生价格"正在快速下降。

问题在于,软件出生以后并不会因为当初只花了两个小时生成,就只产生两个小时的成本。

一个最开始给自己用的小工具,后来可能被整个部门依赖;临时保存的数据可能慢慢变成正式业务数据;脚本可能开始定时运行;另一个系统又开始调用它的结果。接下来操作系统会升级,依赖会更新,第三方接口会改变,员工会调岗和离职,业务规则也会继续变化。

这些都是维护。

修 Bug 只是维护里最容易被看到的一部分。让软件适应新的环境、继续支持变化的业务、升级已经过时的依赖、处理安全问题、调整权限,以及最终把不再使用的软件安全退役,都属于它活着以后要付的账。

于是这里出现了一个很有意思的不对称:

AI 极大地降低了创建软件的成本,但一套软件一旦真正进入业务,它后面的持有成本和退出成本并没有按照同样的速度消失。

软件数量增长,负担不一定只是线性增长

如果用一个不严谨但很好理解的模型来看,一家企业的软件负担大概可以理解为:

总负担 ≈ 软件数量 × 每套软件的持续成本 + 软件之间的关系成本

前半部分已经够麻烦了,后半部分更容易被低估。

公司里有十套完全互不相关的小工具,和十套互相调用接口、共享账号、复制数据的软件,不是同一种复杂度。每多一条依赖,就多一个未来可能断掉的地方;每复制一份数据,就多一个"到底哪份才是真的"的问题;每增加一个服务账号、API Key 或 OAuth 权限,就多一份以后必须有人记得回收的访问能力。

因此,软件数量增加以后,维护负担并不一定只是跟着数量线性增长。真正难处理的是这些软件开始组成一张越来越大的关系网。

这也是 AI 时代一个容易被忽略的变化。

过去开发成本本身就是一种天然的节制。现在,一个部门觉得现有系统不好用,可以自己做一个工具;员工嫌某个操作麻烦,可以写一个自动化程序;一个 Agent 甚至可以在很短时间里把一个临时想法变成带数据库、账号系统和后台页面的完整应用。

每一个决定单独看都很合理。

几年以后,企业真正面对的可能不是"这些代码谁看得懂",而是另一个问题:我们到底还有多少软件?

哪一些还在使用?谁负责?连接了哪些数据?拥有什么权限?哪些系统正在依赖它?如果今天关闭,会不会让另外三个系统第二天一起出问题?

这其实不是 AI 发明的问题。SaaS、微服务、低代码和所谓的 Shadow IT 早就在制造类似现象。AI 做的事情更像是把最后一道生产门槛继续压低,让"做一个新的东西"比过去更容易。

讨论 AI 与维护时,要把三个层次分开

因此,讨论 AI 与维护时,需要把三个不同层次的问题分开。

第一个是开发时的体验。Stack Overflow 2025 年开发者调查中,66% 的受访者表示,他们最常遇到的 AI 困扰是答案"几乎正确,但又差一点",45% 认为调试 AI 生成的代码更加耗时。这说明 AI 可以减少一部分编写时间,但验证它并不是免费的。

第二个是代码本身是否更难维护。《Empirical Software Engineering》2026 年那项包含 151 名参与者的研究,在受控实验范围内没有发现 AI 辅助开发产生的代码,会让另一批开发者后续修改得明显更慢,代码质量也没有显著恶化。研究作者反而提醒了另一个风险:当生成代码的成本越来越接近零,大量新增代码本身可能造成代码库膨胀;即使每一个文件单独看都写得不错,整个系统仍然可能因为规模扩大而更难理解。

第三个问题比前两个都大:企业能不能管理不断增长的软件资产。

这已经不是代码质量指标能够回答的了。

DORA 在今年的研究里观察到,AI 确实减少了初始代码生成需要的时间,但节省下来的部分时间会重新进入审核和验证阶段。更高的 AI 使用程度同时和更高的交付吞吐量、更高的交付不稳定性相关。DORA 因此把 AI 描述成一个放大器,比简单说"AI 提高生产力"或者"AI 降低质量"都更准确。

原本有明确架构、测试、发布流程和责任边界的团队,AI 会让它更快。原本连哪些系统是谁负责都说不清楚的组织,AI 也会很高效地帮它继续增加新的系统。

OpenAI 自己的 Codex 实验后来就遇到了这类问题。Agent 会模仿代码库中已经存在的模式,其中当然包括不理想的模式。随着代码快速增长,一些问题会被不断复制。OpenAI 团队早期甚至固定用每周五,也就是大约 20% 的工作时间,清理他们称为"AI slop"的东西。

后来他们发现这种人工大扫除根本扩展不下去。

解决方式不是要求工程师重新逐行检查百万行代码,而是把维护本身也重新设计:架构边界变成机器能够验证的规则,设计决策和执行计划进入代码库,文档有自动检查,后台 Codex 任务持续扫描偏离规范的实现、更新质量评分并提交重构。

软件生产自动化以后,治理也必须自动化

这里有一个比"AI 能不能写软件"更值得研究的变化。

当软件生产开始自动化以后,软件治理也必须逐渐自动化。

过去不少团队依赖一种很脆弱的东西维持系统:某几个老员工"知道这里不能动"。这种知识在人写代码的时代已经危险,在 Agent 可以一天产生大量修改以后更不够用。为什么这样设计、哪些模块不能互相依赖、数据的真正来源是什么、什么状态才允许上线,这些信息需要从人的记忆里搬出来,变成机器和后来的人都能读取的规则。

这也是为什么一些大型软件组织开始使用 Software Catalog。Backstage 这类工具解决的并不是"怎么写代码",而是非常朴素的问题:公司到底有哪些服务、网站、库、数据管道和模型,它们分别属于谁,现在处于实验、生产还是准备淘汰的阶段,又依赖哪些东西。

Backstage 的文档里甚至直接提到一个词:orphan software,没人真正负责的软件。

这类软件可能仍然每天正常运行,所以很容易被忽略。真正可怕的不是它今天坏了,而是它仍然读取正式数据、持有生产权限、被别的系统依赖,却已经没有任何团队愿意对它负责。

AI Agent 还让这里多了一层安全问题。

一个临时工具如果只能读取一份本地 CSV,风险通常有限;但当它拿到了数据库账号、云平台密钥、企业 API 权限甚至部署权限,它已经拥有了真正的攻击面。NIST 的安全软件开发框架一直要求跟踪安全需求、设计决策、软件组件来源和相关风险。到了 Agent 可以自己创建、修改和部署软件以后,这些事情只会更重要,而不是因为代码生成自动化就自动消失。

所以,一个 AI 做出来的小工具到底需不需要"正规化",不应该看它用了多少行代码,而应该看它已经变得多重要。

如果只是个人两周后就会删除的数据处理脚本,没有必要为了所谓最佳实践给它建一整套企业级平台。工程化本身也有成本,把每一个临时工具都当核心业务系统治理,只会制造另一种浪费。

但当一个东西开始被多人依赖、处理正式数据、长期运行、连接其他系统或者获得生产权限以后,它就应该逐渐承担与自己重要性匹配的责任。

至少应该有人能够回答几个问题:谁最终负责它?数据从哪里来、流到哪里去?依赖什么?拥有哪些生产权限?出了问题从哪里看?最后什么情况下可以把它关闭?

真正成熟的软件管理,甚至应该开始关注一些过去很少有人统计的数字。

例如生产系统里还有多少没有明确负责人的服务;过去半年几乎没人使用却仍然运行的系统有多少;多少已经宣布废弃的组件仍然持有生产权限;每个季度新增加的软件和真正退役的软件分别有多少。

如果一个组织每个月能用 AI 新做二十个工具,却一年都关不掉一个,那么它的开发效率看起来可能非常漂亮,软件资产负担却一直在积累。

我们更认可的 AI 开发方式

这也是我们更认可的 AI 开发方式。

AI 已经完成的原型,没有必要为了进入"正式开发"就全部重写。能保留的东西应该保留,能继续让 Agent 完成的工作也没有理由重新堆人工。真正需要补上的,是随着软件重要性提高而出现的那些东西:明确的边界、测试、日志、安全、所有权和最后的退出方式。

专业工程不应该把一个两小时的小工具强行变成两个月的项目。

但专业工程同样不能只负责让更多软件出生。

AI 正在快速降低软件的创建成本,而软件真正进入企业以后,持有它和最终放弃它的成本仍然存在。未来软件工程里越来越重要的一项能力,可能不是还能把代码生成得多快,而是能够判断哪些东西值得长期存在,哪些东西应该被正式管理,以及什么时候应该干净地让它结束。

如果这一点没有跟上,那么"软件越来越容易做"最后带来的,可能不是更少的维护,而是一家公司拥有越来越多谁也不敢关掉的软件。

了解软件开发与外包服务

了解技术咨询服务