当代码越来越便宜

TL;DR

代码变得便宜了：AI 编程工具（Claude、Cursor、GitHub Copilot）显著提高了开发者的生产效率，延续了降低进入门槛、减少开发开销的趋势——类似于之前的编程语言/框架转变（C→Java→Python）。
编写代码一直都是最简单的部分：真正的瓶颈已从”如何编写代码”转移到”如何清晰地定义需求”和”如何验证解决方案”。更快的代码生成加剧了对需求收集和测试的压力，可能导致更多不够完善的交付物。
对开发者的双刃影响：廉价的代码使得方便的一次性工具和更容易的重构成为可能，但也带来了低质量 AI 生成代码充斥代码库的挑战。然而，开发者现在处于一个前所未有的环境中，快速原型设计和实验变得更加可行。
AI 短期内不会替代复杂软件产品，但赋能利基解决方案：AI 编程使得为特定个人或小群体需求开发定制工具变得更加可行，而不必搜索现有产品。由于量身定制的小工具用户有限，更适合发挥 AI 的优势，而不是替代复杂的广泛使用的应用。

2025 年一年，AI 编程取得了飞速的进展，能够熟练（且正确）使用 AI 工具的开发者，工作效率会显著提高。而科技媒体对于这些技术的进步更是不吝赞美，仿佛一个“人人都可以开发软件产品“的时代又到来了。不过且不论这些媒体噱头的真伪，在大量的 AI 帮助下，代码确实变得更便宜，顺着这个思路，我想聊聊自己的看法。

1. 编写代码的体验再一次变天了

作为一个软件工程师，从 Github Copilot 到 Cursor 再到 Claude Code，AI 编程工具的每一次显著提升，都带来了更顺畅的开发体验。甚至还衍生出了一些新的开发范式，比如 Spec-driven development (SDD)。虽然媒体宣传得震天响，但这种变更给我的感受更类似于从 C 换到 Java，从 Java 换到 Python。使用 Java 开发，不需要我再主动注意内存分配、数组越界、手写许多基础的数据结构，虽然写出的代码性能一般，但面向对象和 JVM 管理带来的开发便捷性是令人印象深刻的。而后换成 Python，语法更接近自然语言，开发环境更简单，包管理器更成熟，内置了更方便的数据结构以及更方便的进程线程管理。

类比到前面两个，这种变化的趋势是一致的，更高的开发效率、更低的开发门槛、更少的细节掌控。我很难想象一个 Python 开发者会关注自己程序多占用那么几MB 大小的内存。而现在有了 Claude Code 这样的几乎完全自主的 AI 开发工具后，这种趋势仍然在延续。通过自然语言与 AI 工具交流即可完成代码开发，并且 AI 的代码生成速度远远高于工程师在 IDE 上手动编写代码的速度。但与之对应的，在快速开发的过程当中，更多的细节也被忽略了，只要它们不出问题，简单的 Code Review 取代了详细阅读和理解系统的模块以及设计范式。

2. 可是代码一直都是最简单的部分

我想大多数的软件行业从业者或者是软件工程专业的毕业生（如果有好好听软件工程这门课的话），对“代码一直都是最简单的部分“这个观点应该都能有所耳闻，我个人也是非常认同这一点的，毕竟在整个软件开发的生命周期里，实际编写代码的时间并不（应该）是整个项目的主要时间，而现在，这个时间被进一步压缩了。这里我不想再详细说一些老生常谈的内容，比如要有良好的系统架构、工程范式或者强调全面的测试、明确的需求带来的好处，而更多的是想聊聊整个开发过程在现有 AI Coding 的状态下产生的变化。

当应用软件开发的主力语言从 C 切换到 Java 时，“工程师的时间比系统运行时间更有价值“这个观点也普遍被接受了，毕竟计算设备的内存和 CPU 频率的单价在下降，比起极致的性能优化，快速交付可使用的大型软件显然是更主要的挑战。而今，这个整个现象的升级版本我想也逐渐显露出来了，有了 AI Coding，能够开发并完成交付的门槛进一步降低，甚至一些浅层的性能问题也都不再是问题了，开发者不需要了解究竟是哪里让系统看上去慢了不少，而只要能提出合理的需求，不是情况 AI 都能直接解决。

现在，交付软件的压力从“CPU、内存不足“、“代码不会写“转移到了“如何提出合理的需求“以及“如何验证这些需求被满足“。当然，我并不是说在现在这个环境下，需求和验证的问题变得更复杂，实际上它们变得更容易了，但只是相比较中间那个被剧烈压缩的 Coding 环节，还没有那么容易，因此成了显眼包。

并且，类似 Coding 效率提升 N 倍代表软件交付效率也能提升 N 倍这样的观点一旦被接纳，对于雕琢需求和完善验证是一种压力测试。首先，好的点子其实并不多见，快速验证的流程虽然加速了想法实现，但相应的也缩短了一些想法存活的周期，而不完善测试和验证环节则会进一步损害想法落地的效果。因此，对于这种研发节奏变动而导致的更多“半成品“的出现，我认为这不是一件很好的事情。

3. 开发者的工作环境变得既糟糕又美好

代码变得廉价，对开发者来说，既是好事也是坏事，在 Claude Code 等等 AI Coding 工具越来越“智能“了之后，也有不少开发者吐槽自己不得不被 AI 生成的垃圾代码淹没，或者是要在 Github 上应对 AI 工具提交的劣质 PR，甚至不好的 AI Coding 工具使用习惯可能会飞速让一个井井有条的代码工程变得臃肿甚至难以维护。

但从另一个角度来说，开发者也处在了一个前所未有的好环境里，在这里代码很便宜，大量的“日抛代码“为开发工作带来了更多的便利，比如，当系统数据出现异常时，可以随手创建一个可视化的小工具，只为检查一些基础问题。做一些维护工作时，也可以随意创建一些用完即抛的脚本，不用思考是否有必要制作一个未来能够复用的工具，反正下次重写也就是分分钟的事情。此外，模块重构、迁移项目到新的编程语言、静态 BUG 检查都变得更加容易，并且以往一些开发者不喜欢做的那种编写文字材料（Commit Message、注释、ChangeLog、ReadMe）工作，如今也都能不费功夫地完成得又好又漂亮。

4. AI Coding 替代软件产品仍需时间，但利好面向小群体的小产品

之前看到过一些夸张的说法，讲在 AI Coding 的加持下，软件产品将会被逐步替代。嗯，说实话这挺疯狂的，并且单从现在的 AI 能力来看还远远达不到，无论是用 AI 本身的能力解决问题还是靠 AI Coding 自动生成软件来解决问题。对于这一点，我也想聊聊自己的看法。

首先，AI Coding 是否能代替掉软件产品，这取决与一个平衡点：让 AI 开发一个满足自己需要的软件的成本与购买并学习使用一个软件解决自习需求成本之间的关系。显然，在当下这个节点上，比起让 AI 开发一个 Photoshop 来说，还是购买并学习使用 Photoshop 更划算。

不过，Coding VS 购买 + 学习，这个平衡关系是始终存在的，而AI Coding 的出现，让天平向 Coding 方向更倾斜了一点。复杂的软件经过精细的设计、大量历史用户需求的积累和创新，想要直接替换显然不容易。但是面向个人或者小范围群体的一些特定需求的小软件，在有了 AI Coding 的加持下，则可能更适合直接上手做一个，而不是在应用市场或者搜索引擎里寻找资源然后逐个尝试。

这些小型的软件产品，主要以满足个人的一些需求出发，因此可以做的更定制化，并且由于受众及其有限，它不需要处理复杂并且带有矛盾的长尾需求，也不需要面对大量难以预料的用户行为，同时用户对 BUG 的容忍程度也更高，反馈更及时，这些特性进一步降低了整个软件开发的难度，也更适合 AI 在其中与使用者充分沟通、反复试错。所以，或许 AI Coding 还不是一个“一句话就能给我我想要的东西“的万能机，但适当地用开发一个小工具来替代寻找一个恰当产品，在当下也是一个不错的选择。

最后我想说说自己对未来的一点看法。不少声音会对软件工程师未来职业发展表示担忧，我想这其实也不是什么需要多虑的事情，我想作为一个合格的开发者，持续学习的能力和一个相信未来会更好的开放心态是必备的素质，软件开发从来都不缺变革型的技术迭代，而每一次都能发掘出更多的需求、落地更好的灵感，然后努力实现来改善人类的生活。

现在，开发工作变得前所未有的简单，当脑内产生一个好想法，把它落地的难度也前所未有的低，甚至缩短了个人开发者与专业团队之间的差距，个人也可以用有限的时间构建出非常复杂的软件了，只要你有一个合格的软件架构设计，就几乎拥有了一个 7*24 工作的职业开发团队。与其说对软件开发的未来担忧，我觉得这是一个前所未有的好机会来吸引更多的人构建更多、更好的产品来造福人类。