AI革命：软件开发成本骤降90%？

AI 时代，软件开发成本真的下降了 90% 吗？Martin Alderson 在本文中分享了自己的观察：AI Agent 正在大幅压缩开发中的人力成本，让原本需要数周甚至数月完成的项目，在几小时或一周内就能交付。AI 不仅加速新项目开发，还能轻松理解和维护老旧代码库，这种变化释放了巨大的潜在软件需求。

这篇文章深入探讨了成本下降背后的原因、AI 工具对开发模式的重塑，以及为何 2026 年可能成为行业大转折的一年。

作为一名有 20 年软件开发经验的程序员，我见证了许多浪潮，包括 SaaS 的兴起、移动应用的崛起、区块链的狂热，以及那些声称要让程序员失业的低代码工具。然而，随着代理式编码（Agentic Coding）的出现，软件开发的经济模型正在发生剧变，这股力量将彻底重塑整个行业。

之前，我讨论了为什么现有的评测标准可能忽略了某些关键跃迁，而这段时间的思考和经历，让我更加确信我们正走向一场“十年一遇”的行业大转折。

软件交付成本

在我刚开始做开发时，开源的兴起标志着自定义软件开发成本的第一波大幅下降。我还清晰地记得当年使用 SQL Server 或 Oracle 的授权费用高昂，因此我从一开始就选择开源 MySQL，它让我能够构建定制化的网络应用，而无需承担高昂的数据库授权费。

之后我们经历了云计算（尽管其是否真的省钱仍有争议），但假设它在初期确实减少了部分资本支出。近年来，我认为我们处于“复杂性时代”。软件工程变得——在我看来往往是不必要地——复杂了。大家纷纷转向对人力要求极高的模式，如 TDD、微服务、复杂的 React 前端以及 Kubernetes。我甚至觉得过去几年软件开发的成本几乎没有下降。

然而在我看来，AI Agent 会大幅降低软件开发中的人力成本。

那 90% 的成本节省到底来自哪里？

2025 年初，我对各种 AI 编码工具持怀疑态度——现在依然如此。许多平台看起来就是换了皮的低代码工具，或者带有自动补全功能的 VS Code 衍生版本。以公司里一个典型的内部系统项目为例。假设数据模型已经有了雏形，你需要构建一个 Web 应用来管理某个“widget”类的业务对象。

按照过去的流程，你需要一个小团队来搭建 CI/CD、整理数据访问模式、开发核心服务。然后是大量 CRUD 页面，再加上一些仪表盘或可视化。最后（理想情况下）还得写一套自动化的单元测试、集成测试、端到端测试，确保质量过关。这个过程通常需要大约一个月的时间。

然而使用代理式编码的 CLI 工具，这些流程里几乎所有步骤都能在几小时内完成。我曾让 Claude Code 花几小时写完一个复杂内部系统的完整单测 + 集成测试套件（300 多条）。这种规模的测试，对我自己或我认识、尊重的开发者来说，都得花上好几天写。

AI Agent 已经非常擅长把业务逻辑规范转成结构清晰、可用性很高的 API 和服务。

过去一个月的项目现在一个星期就能搞定。思考时间差不多，但实现时间直接减少。而且团队越小，沟通开销越低，甚至反向验证了“布鲁克斯定律”的镜像效应：沟通成本不再是人越多效率越低，而是人越少效率爆炸提升。一两个开发者就能做到过去一个团队才能完成的工作量。

潜在需求的释放

乍看之下，这对软件行业似乎是个坏消息，但从经济学角度并非如此。

杰文斯悖论（Jevons Paradox）告诉我们，当某种东西的生产成本下降时，我们并不会只是“花更少的钱做同样的量”，而是会做更多。电灯就是典型例子：蜡烛和煤气灯销量掉了，但整个社会的人造光源总量却大幅增加。

这一点应用到软件开发上，就是供需关系问题：社会对软件有着巨大的“潜在需求”。几乎每家公司都有几百甚至几千份 Excel 表格在记录关键业务流程，而这些东西本该做成 SaaS。如果一家外包公司报价 5 万美元来把其中一个做成应用，那只有最核心的项目能立项。但如果成本降到 5000 美元（找个不错的开发者配合 AI 工具即可），需求会大爆发。

唯一的护城河：领域知识

那么开发者会被淘汰吗？现实并非如此简单。

目前人类仍然非常重要，因为你需要“看着 AI 干活”：审核它的输出、提出建议、避免它走偏。如果完全放任 AI 写代码，项目很快会乱成一团。但只要有人类的参与，AI 就能帮你在短时间内构建质量非常高的软件。

掌握这些工具的开发者在解决业务问题时变得异常高效。而他们的领域知识与行业理解将成为最大的杠杆：知道什么架构合适、用什么框架、哪些库稳定好用。再叠加对业务本身的理解，“传说中的 10 倍工程师”正在变成现实。

未来我们可能不再需要“一个业务专家 + 一整个开发小队”，而是只需要两三个人紧密配合即可。这种组合让迭代速度快得惊人，软件变得几乎是一次性的：如果方向不对，直接丢掉重来，从经验中学习就行。

不要措手不及

AI Agent 和模型仍在快速进化，而我觉得现有的基准测试并没有真正反映这一点。例如 Opus 4.5 能在 10–20 分钟的长会话中保持较好理解，不会偏离主题。我们才刚刚开始看到数千亿美元资本投入到 GB200 GPU 上的成果，而我相信更新一代的模型很快就会让这些看起来过时。

然而，我遇到过太多抵触这种变化的软件工程师。我听到的反对理由总是雷同：LLM 会犯太多错误、它理解不了某个框架、或者根本没节省时间。这些说法正迅速变得不成立。

工程师们需要积极拥抱这场变革。这不会一夜之间完成——大企业总体上仍然落后，被繁琐的供应商审批和管理结构困住，这让它们对小型竞争者极度脆弱。

但如果你在一家小公司或团队工作，并且有机会使用这些工具，就应该抓住它。你的工作会发生变化——不过软件开发一直都在变化。只是这一次变化可能比任何人预料的还要快。