AI时代的软件工程

在这一章节, 我们来聊一聊 AI 时代的软件工程。

自 2022 年末 ChatGPT 横空出世, 大规模语言模型（Large Language Model）已经可以写出通顺的语句, 并且通过图灵测试。

随着 2024 年智能体工程（Agent Engineering）取得长足进步, 人工智能被广泛应用于软件开发中, 其几乎可以代替人类完成软件编码工作, 且效率更高, 低级错误率更低。

伴随着人工智能的进步, 社会中「程序员即将失业」「未来的程序员都是 AI」的论调甚嚣尘上。随之而来的是许多人的疑问: 既然 AI 已经能够完成大量编码工作, 我们还有必要学习软件开发吗？

我认为有必要。判断这个问题, 不能只看 AI 能不能写代码, 还要先弄清楚软件工程究竟包含什么。

编码是软件工程中的一部分, 却不是全部: 从理解需求、设计方案, 到实现、测试、部署和维护, 都是把一个现实问题变成可长期使用的软件所需要的工作。

电气和电子工程师学会（Institute of Electrical and Electronics Engineers, IEEE）的软件工程知识体系 SWEBOK 也将需求、设计、构造、测试、维护等列为软件工程的知识领域。

接下来, 我们从三个方面来论证, 为什么 AI 依然无法完全掌握软件工程。

自然语言天然具有模糊性

例如, 我们要做一个给大学生找自习室的工具。同学们说“帮我找一个近一点、方便一点的自习室”。 这非常符合人类的直觉, 但其中的“近”和“方便”并没有明确边界, 多“近”才算近, 多“方便”才算方便。每个人可能对“近”和“方便”的定义还不同。

洛夫蒂·阿斯凯尔·札德（Lotfi Asker Zadeh）的「模糊集合」理论提供了一种描述方式: 一个对象可以在不同程度上符合某个概念。“离宿舍近”可以按距离定义不同程度；“未经授权不能查看个人信息”则必须是一条明确约束。

模糊集合描述的是「概念边界」, 应用到软件工程中, 关键是把“近”“方便”转化为产品可以执行的排序标准或筛选条件, 并与用户确认哪些目标可以权衡、哪些规则不能违反。这类能力有时候并不是纯粹理性的计算, 还需要作为「人类」的相通感受, 而这通常是 AI 不具有的。

代码正确并不等于问题解决

假设自习室工具按照测试要求正确地从近到远排序, 却没有考虑开放时间。系统把已经关门的自习室排在前面, 同学们白跑一趟才发现不能自习。回头看测试结果, 距离排序正确, 测试全部通过；但用户的问题没有解决, 因为验收标准只检查死板的距离, 并没有思考类似的问题, 没有覆盖“找到此刻可以使用的自习室”这个真实需求。

更准确地说, AI 在代码生成的训练和评估会检查代码是否符合给定任务、是否通过指定测试；但真实需求如果没有写进任务和测试, 代码即使通过, 也无法据此证明它解决了用户的问题。

对一组 AI 编码任务模拟（SWE-bench）的研究发现, 有些解决方案通过了无人工介入的技术测试, 但在使用产品时仍出现错误。该研究表明, AI 在「生成正确的代码」议题上成功率很高, 但在「真正解决实际问题」上有待加强。这并非否定 AI 的能力: 一旦目标和验收条件设计得更完整, AI同样可以在这些条件下完成实现。但截止撰文日期, 仍未有通用解决方案来保证 AI 能解决真实问题。

软件工程不只是编码

以自习室工具为例, 代码完成后, 还要判断开放时间的数据从何而来、数据更新频率、推荐结果出错时如何处理。如果它与校园地图或统一身份认证系统协作, 还要考虑系统间协同和数据安全。软件是否真正可用, 往往要到它进入真实环境、接触真实用户之后才能检验。而 AI 的不可控通常会让这些检验带来损失, 所以必须由人类接手部分任务并为 AI 提供指导。

对于大学生来说, 学习软件工程不能只理解为背一门语言的语法。编程基础让人能看懂程序如何处理数据和规则；工程知识则帮助人把需求转成模型、把实现转成系统, 并判断系统是否满足预期。AI可以参与这些工作, 也会逐渐接手其中更多环节, 但要把目标和结果连起来, 仍然需要有人理解整个过程。

更应该有的认识是, 学习软件工程不能保证某一种职业永远稳定, 但它让人有能力参与软件的设计、实现和检验。大学生真正需要理解的, 不只是代码如何生成, 而是如何大规模地将人类的现实生活需求稳定、高效、安全地数字化；这仍然是软件工程亘古不变的难题。