不知道从什么时候开始，互联网上似乎每隔一段时间，就会有一个职业被 AI 宣判死刑。
程序员要失业了，设计师要失业了，教师、律师、会计也快没用了。似乎只要再等几年，人工智能就能包办所有工作，人类只需要坐在电脑前，输入几句话，剩下的事情自然有人替你完成。
尤其是软件开发领域，这样的声音几乎从来没有停过。
从最初的代码补全，到能够自主分析项目、修改代码、运行测试的 AI Agent，再到近来流行的 Vibe Coding，AI 的编程能力确实在以惊人的速度进步。
过去需要几天才能完成的工作，现在可能只需要几十分钟。一个没有编程经验的人，也可以通过自然语言生成一个看起来相当完整的网站。
于是有人开始问：既然 AI 都能写代码了，我们还需要程序员干什么？
这个问题乍一听很有道理。
但我想问一句：
你真的觉得，把代码写出来，就算把软件做好了吗？
一、AI 很会干活，但有时候真不知道你想要什么
作为一个经常使用 AI 参与软件开发的人，我对它的能力有很直观的感受。
很多时候，我确实会惊叹于 AI 的效率。一个复杂的功能，描述清楚需求之后，它能够迅速给出实现方案，编写代码，甚至主动运行测试、修复错误。
但另一些时候，它又会表现得相当奇怪。
举个很简单的例子。
我曾多次让 AI 优化一个面向普通学生的平台界面。我的要求其实并不复杂：界面简洁一些，符合正常用户的使用习惯，不要出现太多没必要的东西。
结果呢？
它确实修改了页面，也确实调整了布局，但整个界面看起来依旧像一个开发者调试后台。
一些本来应该放在技术文档里的内容，被堂而皇之地展示给普通用户。某个功能采用了什么技术架构、系统如何处理数据、内部使用了什么接口，恨不得全部写在页面上。
问题是，普通用户真的关心这些吗？
一个学生打开 AI 平台，只想找到功能、完成操作、得到结果。他没有义务去理解背后的技术实现。
而当我告诉 AI“这个界面还是不太对”的时候，它有时又会反过来问我：
你希望使用什么设计风格？导航栏放在哪里？卡片应该采用多大的圆角？页面应该如何布局？
这些问题当然可以讨论。
但如果每个细节都需要用户决定，我为什么不自己设计？
我们换一个场景。
假如你找到一位有经验的设计师，告诉他：“我想做一个面向大学生的 AI 平台，界面年轻化一点，简洁一些，功能不要太复杂。”
大多数情况下，他能够结合自己的经验、对目标用户的理解，以及现有产品的设计习惯，先给出一个大致符合预期的方案。
你不需要提前学习交互设计，也不需要掌握信息架构，更不用研究每个按钮应该放在哪里。
因为你花钱请他，恰恰就是希望他能帮你解决这些问题。
当然，人类设计师也会理解错需求，也需要与客户反复沟通。经验丰富的专业人员同样会提出问题。
但他们通常能够判断，哪些细节可以自行处理，哪些事情需要客户明确表态。
比如一个按钮应该采用什么圆角，设计师完全可以自己决定；但一个学生的私人聊天记录能否被学校管理员查看，就绝对不能擅自作主。
这种判断能力很重要。
人类在交流时，本来就会省略大量信息。我们习惯根据经验、常识和上下文理解对方的意思。
很多时候，提出需求的人自己也不知道究竟想要什么。他可能只知道“现在这个不好用”，至于哪里不好、应该怎么改，还需要专业人员进一步分析。
当前的 AI 在处理这些模糊需求时，依然会犯不少错误。它可能擅自填补一些不合理的假设，也可能不断向用户索要更详细的指令。
有人可能会说，这是因为你的 Prompt 写得不够好。
可问题来了。
难道每一个普通用户，都必须先学会需求分析、产品设计和软件工程，才能正常使用 AI 吗？
如果一个人想做个软件，结果还得先学习如何把模糊需求整理成完整的技术规范，那他究竟是在使用工具，还是在学习成为一个软件工程师？
二、会写代码，和会做软件，差得远了
图片：ThisIsEngineering / Pexels
我们不妨再举一个例子。
假如某个学校的老师找到你，说：“帮我们做一个教务管理系统。”
听上去很简单，对吧？
学生管理、教师管理、课程管理、成绩管理，再加上一个登录功能。
现在找一个能力不错的 AI 编程工具，把这句话输入进去，它很可能真的能生成一套系统。
页面有了，数据库有了，接口也有了。打开浏览器，功能似乎都能正常使用。
可你敢把它直接交给学校吗？
学校有多少学生？采用什么教学管理制度？不同学院的权限如何划分？课程容量如何限制？学生能否跨专业选课？补考和重修的成绩应该如何计算？
再往下想。
如果两名学生同时抢到了某门课程的最后一个名额，系统应该怎么处理？
如果教师录入成绩之后发现错误，是否允许直接修改？修改需要经过谁审批？操作记录保留多久？
如果学校已经有统一身份认证系统，我们是否还应该重新建立一套账号体系？
这些问题，很难靠一句“给我做一个教务管理系统”解决。
更麻烦的是，不同学校的答案可能完全不同。
一个在甲学校运行良好的系统，直接搬到乙学校，未必能满足实际业务。
真正的软件开发，需要面对的就是这些琐碎、复杂，甚至互相冲突的问题。
软件工程师需要和客户沟通，梳理业务流程，分析系统边界，考虑未来的扩展和维护，再把这些内容转化为可以执行、可以验证的工程规范。
编写代码只是其中一个环节。
我一直觉得，很多关于“AI 取代程序员”的讨论，最大的问题就在这里。
大家看到 AI 几分钟生成了几千行代码，看到它能做出漂亮的网页，就开始惊叹软件开发的门槛已经消失了。
但生成一套能运行的程序，与交付一套可靠的软件系统，中间还有很多工作。
系统能不能处理真实业务？数据会不会出错？权限有没有漏洞？以后需求变化了，架构还能不能支撑？
甚至连最开始的需求是否合理，都值得认真讨论。
如果客户真正的问题只需要一个简单的自动化工具就能解决，你却花费大量资源搭建了一整套复杂平台，那么代码写得再漂亮，也算不上一次成功的软件开发。
AI 确实让实现功能变得容易了。
可它并没有让现实世界的业务规则变得简单。
三、程序员真的会被取代吗？
图片：Nemuel Sereti / Pexels
先说清楚，我并不认为 AI 对就业市场的冲击是假的。
恰恰相反，这种冲击已经值得每一个软件工程专业的学生认真对待。
一些重复性高、需求明确的编码工作，确实越来越容易交给 AI 完成。
过去，一个企业可能需要几名开发人员才能完成的工作，未来可能由更少的人借助 AI 完成。
企业因此减少某些岗位的招聘需求，并不是什么难以想象的事情。
尤其是那些主要依靠熟悉框架、调用接口、编写简单业务代码来工作的开发者，未来的竞争压力恐怕不会小。
但如果据此认定，软件工程师这个职业也快消失了，我觉得还是有些草率。
我们可以换个角度思考。
假如一个程序员熟练掌握 Java、Python，能够使用各种框架快速开发功能，但是面对一个模糊的业务需求，他不知道如何分析；面对系统架构，他不知道如何选择；面对潜在的技术风险，他也没有能力判断。
那么，当 AI 能够以更低的成本完成编码时，这个人的竞争优势确实会受到很大影响。
可如果一名工程师能够理解客户的真实需求，能够设计合理的系统架构，能够根据项目规模、性能要求和开发成本作出技术决策，还能发现 AI 实现中的问题，情况就有所不同了。
他完全可以让 AI 编写大部分代码。
甚至可以让 AI 承担测试、部署、文档编写以及部分日常维护工作。
但他需要始终知道，整个项目正在朝什么方向发展。
当 AI 给出一个技术方案时，他能判断这个方案是否适合当前项目。
当需求发生变化时，他能分析变化会影响哪些模块。
当系统出现问题时，他能理解问题产生的原因，而不只是反复让 AI“再修一下”。
这也意味着，未来的软件工程师需要掌握的知识可能更加广泛。
需求工程、系统架构、产品设计、业务建模、技术决策、软件质量治理，这些能力的重要性将越来越突出。
当然，编程能力仍然是基础。
一个连数据库事务、并发控制、网络通信都理解不了的人，很难准确评估复杂系统的技术方案。
更不用说操作系统、数据库内核、编译器和安全基础设施等领域，本身就需要非常扎实的底层知识。
但如果大学四年下来，一个学生最大的收获只是学会了几门编程语言，熟悉几个开发框架，我认为这样的培养目标已经有些跟不上时代了。
未来的软件工程师，可以不亲自编写每一行代码，但必须有能力理解、评估并管理自己交付的软件。
四、如果 AI 从入门开始，就和我们一起学习呢？
讨论到这里，可能有人会提出一个问题。
如果未来大量初级编码工作都交给 AI，那些具备丰富经验的高级工程师又该从哪里来？
毕竟，今天的架构师和技术负责人，往往都是从基础开发工作一步步成长起来的。
但我觉得，这个问题多少有些受到传统培养路径的限制。
为什么未来的工程师，一定要按照过去的方式成长？
假如一个刚进入大学的软件工程专业学生，从学习第一门编程语言开始，就拥有一个长期陪伴他的 AI 学习伙伴，会怎么样？
他可以和 AI 一起写代码，一起理解程序运行的原理，一起调试错误，也可以一起讨论系统架构。
当他学习面向对象编程时，AI 可以结合真实项目，解释为什么需要抽象和封装。
当他学习数据库时，AI 可以陪他设计数据表、分析查询性能、研究索引和事务。
当他开始开发一个稍微复杂的软件时，AI 还可以和他讨论需求是否合理、架构是否存在问题，以及有没有更好的实现方案。
比如，学生准备开发一个在线选课系统。
他最初的想法可能非常简单：查询课程当前人数，如果没有满，就允许学生选课。
AI 可以向他提出一个问题：
“假如两个学生同时选中了最后一个名额，会发生什么？”
学生可能一开始答不上来。
没关系。
他们可以一起编写测试程序，模拟并发请求，观察数据库中的实际结果，再研究事务隔离和各种并发控制方案。
这类问题，在传统学习过程中，学生可能要到真正参与项目时才会接触。
但有了 AI，他可以更早地进行探索。
当然，这并不意味着 AI 一定能提供正确答案。它同样可能给出错误的解释、不合理的方案，甚至编写出存在隐患的示例代码。
所以学生还需要通过实验、文档和其他可靠资料进行验证。
我认为，这样的学习过程很有价值。
因为学生接触到的已经不只是语法和框架的使用方式，他开始尝试思考一个软件系统为什么要这样设计。
更重要的是，这种学习并不需要学生放弃亲自编程。
恰恰相反，他完全可以和 AI 一起完成实现工作。
遇到不懂的代码，就研究它为什么这样写；遇到复杂的方案，就尝试自己实现一遍；发现 AI 给出的建议存在问题，也可以直接反驳它。
AI 可以是导师，可以是开发伙伴，也可以是一个专门挑毛病的技术评审。
这些角色甚至可以随着学生能力的成长不断变化。
当然，我们也必须承认，AI 有可能让学生变得懒惰。
如果一个学生每次遇到问题，都直接要求 AI 给出最终答案，甚至连生成的代码都懒得看，那么无论他完成了多少项目，都很难形成真正的工程能力。
但这显然属于学习方式的问题。
难道因为有人会直接抄参考答案，我们就应该禁止学生使用参考资料吗？
真正值得研究的，是如何把 AI 融入教学过程，让它帮助学生理解知识、发现问题、积累经验。
我甚至认为，在合理的教学设计下，AI 有机会提高工程人才的培养效率。
学生能够更早接触复杂项目，更频繁地获得反馈，也能够在学习过程中尝试不同的技术方案。
我们没有必要让每一代学生都用完全相同的方式，重复前人积累工程经验的过程。
五、大学的软件工程教育，或许真的该改一改了
图片：Михаил Крамор / Pexels
作为一名软件工程专业的大学生，我对这个问题其实有很直接的感受。
在一些高校的软件工程课程中，我们依然会花费大量时间学习特定语言的语法、记忆框架的使用方法，然后按照要求完成一个管理系统。
图书管理系统、学生管理系统、课程管理系统……
这些项目当然有教学价值，尤其对于刚接触编程的学生来说，能够帮助他们建立基本的程序设计思维。
但问题在于，很多时候，课程的考核就停留在这里了。
能不能把功能写出来？程序能不能运行？界面有没有按照要求完成？
至于为什么要这样设计，实际业务中会遇到什么问题，系统未来如何扩展，出了安全漏洞该由谁负责，反而没有得到足够的重视。
更值得思考的是，今天不少学生已经在使用 AI 完成课程作业。
有些课程仍然试图通过限制 AI 使用、检查代码生成痕迹等方式维护传统考核模式。
我能够理解教师的顾虑。
如果学生连最基本的循环、函数和数据结构都没有掌握，就直接让 AI 帮忙完成所有作业，确实很难保证教学质量。
但如果一门软件工程课程已经进入系统设计和项目实践阶段，依然把“代码必须全部由本人手写”作为重要要求，就有必要重新考虑这种考核方式的实际意义。
毕竟，当 AI 已经成为实际开发中的常用工具时，我们为什么要刻意创造一个完全排除 AI 的开发环境？
软件工程专业的培养目标，应该更加重视学生能否解决实际工程问题。
我并不主张减少计算机基础课程。
相反，数据结构、算法、操作系统、计算机网络、数据库等课程依然需要认真学习。没有这些基础知识，学生很容易成为一个只会向 AI 发出指令、却无法判断结果是否正确的人。
但在此之上，需求工程、系统架构、产品设计、业务建模、技术决策和软件质量治理，完全值得获得更充分的教学资源。
课程内容可以调整，考核方式也可以改变。
举个例子。
一门软件工程课程的期末项目，教师可以只给学生一个模糊的业务需求：
“学校需要一个实验室预约管理平台。”
然后让学生自行开展需求调研。
实验室面向哪些人开放？不同类型的实验室是否有不同的预约规则？教师能否优先使用？预约冲突如何处理？学生爽约之后应该怎么办？
学生需要根据实际情况梳理这些问题，再完成系统设计。
开发过程中，可以使用 AI。
代码可以由 AI 辅助生成，测试脚本也可以由 AI 协助编写，部署和运维同样可以借助自动化工具。
但学生需要对项目负责。
到了验收环节，教师可以直接提问：
为什么采用这种数据库设计？
如果同时有几百名学生提交预约，系统会发生什么？
如果学校临时要求增加审批流程，现有架构需要如何调整？
甚至可以在答辩现场修改一条业务规则，让学生分析哪些模块需要变化。
这样的考核，可能更容易判断学生是否真正掌握了软件工程知识。
一个学生即使亲手写了几万行代码，如果完全无法解释自己的设计，我认为也很难说他已经具备了良好的工程能力。
反过来，一个学生借助 AI 完成了大量代码实现，却能够清楚解释每一个关键架构决策，能够独立分析系统缺陷，并且可以验证和维护整个项目，那么他的工程能力同样值得认可。
当然，这并不意味着所有编程考试都应该允许 AI 参与。
基础课程仍然需要检验学生独立理解和实现程序的能力，专业课程则可以逐步增加对综合工程能力的考核。
不同学习阶段，本来就应该有不同的评价标准。
进一步说，我认为 AI 甚至可以贯穿软件工程专业的整个培养过程。
大一学习编程基础时，AI 帮助学生理解语法和程序设计思想。
大二学习数据库、操作系统和计算机网络时，AI 可以参与实验、调试和问题分析。
到了大三，学生开始接触完整的软件工程项目，就可以与 AI 共同开展需求分析、架构设计和开发测试。
大四则应当有更多机会接触真实业务，参与具有实际用户和交付要求的项目。
在这个过程中，AI 始终是学生可以使用的工具和学习伙伴。随着课程深入，学生需要承担的决策责任也逐步增加。
当然，这套培养方式还需要解决不少问题。
教师该如何设计课程？如何防止学生过度依赖 AI？怎样判断学生是否真正理解了项目？学生使用不同模型造成的资源差异，又应该如何处理？
这些都需要认真研究。
但至少，我们应该开始讨论这些问题了。
如果大学仍然完全按照过去的方式培养软件工程师，等学生毕业之后，再让他们自己去适应一个已经发生巨大变化的行业，恐怕有些晚了。
六、AI 到底有没有那么牛逼？
写到这里，我想再回到文章最开始的问题。
AI 到底有没有那么厉害？
当然有。
我自己就是 AI 编程工具的使用者，也确实从中获得了非常明显的效率提升。
很多过去需要反复查阅文档、手动调试的问题，现在可以直接与 AI 讨论。很多重复性的工作，也可以交给它完成。
我甚至很期待未来的 AI 能够独立完成更多复杂任务，具备更强的需求理解、系统设计和技术判断能力。
如果有一天，AI 真的能够根据模糊需求，自主研究业务、分析用户、设计架构、实现系统，并且持续优化产品，我会非常乐意使用这样的工具。
这和人类工程师的存在并没有什么必然冲突。
工程师可以将更多精力投入业务理解、架构决策、产品规划和质量控制，借助 AI 完成具体实现。
对于普通用户来说，这样的进步同样是好事。
他们不必为了制作一个软件，先去学习几个月编程，也不需要掌握一整套软件工程方法。
不过，有一个现实问题不能忽略。
即使某些专业能力依然重要，也不意味着相关岗位的数量一定能够维持不变。
当一个人借助 AI 可以完成过去几个人的工作时，企业确实可能减少招聘。
所以我并不赞同那种“AI 永远不可能取代程序员，大家完全不用担心”的说法。
技术进步一定会改变就业市场，我们应该正视这一点。
但同样没有必要因为 AI 能够生成代码，就断言软件工程已经没有学习的价值。
至少在我看来，AI 发展得越快，工程师越需要培养独立判断的能力。
因为当软件实现变得越来越容易，我们可能会看到更多软件被创造出来，更多原本因为成本太高而无法实现的想法进入现实。
这些系统依然需要有人理解业务、制定规则、分析风险，并确保它们能够可靠运行。
对于正在学习软件工程的大学生来说，我觉得最没有意义的两种态度，一种是因为害怕被 AI 取代，就拒绝使用 AI；另一种是因为 AI 已经能够编程，就觉得自己什么都不需要学了。
该学的计算机基础依然要学，该做的项目依然要做。
只不过，我们可以换一种学习方式。
让 AI 参与编码，参与架构讨论，参与测试与优化。
用它节省出来的时间，去理解更多工程问题，接触更复杂的业务，尝试以前没有能力独立完成的项目。
在这个过程中，逐渐建立属于自己的工程经验和技术判断力。
我希望未来的软件工程专业，能够培养出更多懂技术、懂业务、能够驾驭 AI 的工程师。
他们不必以亲手编写了多少行代码为荣，也不需要为了证明自己的能力，刻意排斥 AI。
他们能够理解一个软件为什么要这样设计，知道它可能在哪里出问题，也愿意对自己的技术决策负责。
至于网上那些动不动就宣称“AI 已经把程序员淘汰了”的声音，我觉得还是可以稍微冷静一点。
能够生成代码，当然值得惊叹。
但如果因为 AI 能够在十分钟内生成一个管理系统，就认定软件工程师已经没有存在的意义，那恐怕还需要再了解一下软件工程。
别急着给程序员判死刑，也别急着把 AI 捧上神坛。
软件开发这件事，从来没有写几行代码那么简单。
评论