当谈论软件工程时

当谈论软件工程时，大家的第一反应会是什么呢？是觉得鄙夷？在 AI 盛行的年代，我利用 AI 就能"开发出软件"，哪里还需要软件工程？亦或是认为软件工程是一门逐渐被淘汰的课程。我也经常看到有人用 AI 生成了一个小脚本，挂一个 HTML 前端，就把它称作"软件"……

我对此是有切身体会的。系统学完 Python 基础语法后，我第一次接触了利用 AI 进行编程。我的第一个项目是一款基于 pygame 的枪战小游戏——虽然只是非常简单的一个小玩意，却给当时的我带来了极大的震撼和强烈的即时满足感。后来的一年里，我进组、带团队做大创，接触过越来越多的领域，也逐渐发现：AI 并不能完成我的所有需求。

恰好于 2026 年 9 月 22 日，我上完了第一节软件工程课，借此机会短文长论一番。

首先，AI 在端到端的任务完成上确实无懈可击。面对一个需求，它总能找到工作量最小的路径去实现。但这种"最小路径"恰恰是问题的根源：它没有全局架构意识，每一次迭代都是局部最优，局部最优的叠加，就是全局架构的灾难。至少在代码可读性上，AI 的表现堪称糟糕——我自己就有过连续迭代两次以上且不 review，之后就完全看不懂它在干什么，只好推翻自己重写的经历。

代码能跑和你能掌控，是两回事。从这个意义上说，软件工程就是当下约束 AI 写代码的"缰绳"。

其次，当 AI 让"构建 demo"的能力变得人人可得时，真正的分水岭就出现在了 demo 之后。非计算机专业的爱好者兴致勃勃地让 AI 构建出自己想要的功能，可一旦想把项目部署上线、交付给真实用户，就会撞上重重阻力：环境配置、依赖管理、数据库设计、版本控制、日志与监控、安全漏洞……这些恰恰都是 AI 最难替人兜底的部分——因为它们不是"写一段代码"能解决的，而是需要对系统全貌的理解和工程化的方法论。

最后，软件工程的核心从来不是"教你怎么写代码"，而是教你怎么把代码变成可靠、可维护、可扩展的软件。需求分析、架构设计、测试驱动、持续集成、团队协作——这些能力 AI 暂时只能辅助，无法替代。恰恰相反，AI 生成的代码越多，对这些能力的需求就越迫切：审查 AI 的代码需要读懂它的水平，组织 AI 的产出需要架构层面的视野，维护 AI 留下的系统更需要工程规范作为锚点。

AI 降低的是"写出代码"的门槛，而不是"做好软件"的门槛。当人人都能在五分钟内生成一个 demo 时，能把它打磨成产品的人反而更稀缺了。因此我认为，软件工程并不是过气的明星，反而会在 AI 时代愈发重要——过去，他是软件行业的基石，未来则会成为区分"会对话的人"与"会造软件的人"的那道护城河。