AI 解决开发速度的问题,软件工程解决复杂性失控的问题

今天一整天都在思考一个问题。

AI让做出一款软件，变得前所未有地容易。

我可以在没有完整工程规划的情况下，直接告诉 Agent我的宏大构想，然后开始写。

它真的能写出来，问题往往出现在后面。

当软件越来越复杂，版本不断迭代，一个原本只需要修改几行代码的小问题，可能开始牵动几十个文件，甚至改变底层架构。

改一次，能跑。再改一次，也能跑。

直到我花一个礼拜的时间，迭代了50个版本的时候，代码已经变成一个层层叠加的黑箱。

Agent已经开始丢三落四了，我更看不明白哪里出了问题。

这时候，我才发现，真正昂贵的已经不是开发的问题了，而是维护。

第一件事，就是稍微看看关于软件工程相关的内容，作为专门独立的一级学科，当然是有存在的道理的。

所以我越来越确定一件事。

AI 时代，软件工程没有变得不重要，反而变得更重要了。

因为 Agent 极大提高了写代码的速度，也同时提高了制造复杂性的速度。

真正需要控制的，是架构怎么划分、版本怎么管理、修改如何记录、决策如何归档、测试如何验证、问题如何回溯。这是个工程管理的问题。

我现在采用的方法，是让两个 Agent 分工。

一个负责主导开发。另一个负责审查、验证和维护架构视角。

同时把Git、版本、架构文档、修改记录、工程规范全部纳入统一工作流。

目的只有一个。

让每一次修改，都知道自己改了什么。

让每一个问题，都能够被定位。

让每一个版本，都能够被追回。

一款真正准备长期运行的软件，不能只是今天能跑。它必须能够被理解、被维护、被修复、被升级。

尤其是本地化的工具软件。

性能、稳定性、响应速度，本身就是产品体验的最重要的一部分。

代码结构越混乱，技术债越多，最终都会以卡顿、崩溃、兼容性问题的形式，全部暴露在用户面前。

而对于工具产品来说，产品的体验几乎就是生命线。

而我的核心诉求只有一个，打造出极致的产品，在我认知和能力范畴之内做到“极致优雅”。

要像对待一款作品一样，对待这款软件。

至于结果就交给命运，如果这款产品最终没能达到我预期中的效果，我也不会觉得自己浪费生命做了一款垃圾。

或许这些辗转坎坷，都是在未未来另一个我完全无法设想的产品在铺路。

至于未来，谁知道呢？