网安加·百家讲坛 | 刘寅：人工智能（AI）是解决软件工程问题的“银子弹”吗？

作者简介：刘寅，东南大学电子工程系本、硕，南京大学EMBA，PMP，前科大讯飞技术副总经理，曾就职于中兴通讯、摩托罗拉、趋势科技、初速度等国内、国际名企，多次负责过质量体系从0到1的搭建，DevSecOps工具链的建设及在公司内的大规模落地，日活用户超千人，践行软件质量与效能改进的体系化、线上化、自动化、数据驱动化。

自上个世纪60年代软件危机（Software Crisis)起，软件从业人员和软件用户日益意识到由于软件和软件开发维护的复杂性必将导致软件中充斥各种问题（bug），且难以发现和解决。这也常常导致软件研发的投资达不到预期的收益而失败。

在经典著作《人月神话》中，Frederick P. Brooks回顾了软件从业者为了彻底解决这一顽疾而进行的各种尝试，不幸的是，这些努力都未竟全功。在此书出版后的三十多年后，Brooks仍在反复检视业界各种新的尝试，但仍不得不哀叹“并没有一招毙敌的银子弹啊！”

时间来到21世纪20年代，OpenAI为代表的生成式人工智能崭露头角，软件工程师们惊喜或惊讶地发现，这些GPT不仅可以和你聊天胡扯，也可以根据自然语言生成代码或测试用例。

那AI有没有可能成为解决软件工程各种问题的最终解决方案呢？

人工智能现在能帮助我们做什么软件工作？

日益强大的AI现在已经能在很多编码、测试工作中帮助软件工程师，例如：

集成于IDE的代码生成（copilot)：在软件代码编写时，工程师常常被分配的工作是重复性的，即在公司里已经有别的同事写过类似的代码片段了。

Copilot就像个不知疲倦的伙伴，会运用机器学习技术，根据你写的代码的上下文，自动帮助你补足甚至是生成代码。而且，更贴心的是，这些生成的代码是没有语法错误的。这大大提升了工程师编写代码的效率。

代码质量检测：在代码编写完成时，软件工程师需要自检代码的质量。之前，我们用到的类似Sonar、Coverity之类的工具是基于规则的判断，误判和漏判的概率都不低。结合机器学习的理解能力，代码静态扫描工具可以更有效地发现代码中的缺陷、漏洞和“坏味”。如果使用得当，这会大大缓解测试的压力。

自动化测试：AI已经可以根据软件需求和软件代码的理解，自动生成测试用例并执行，常见工具有Selenium和TestNG，这使得测试工程师可以更频繁、更全面地测试软件，从而提升交付软件的质量。

团队协作：运用自然语言理解技术，AI可以读懂代码，并生成相应的文档、演示材料。这无论是对工程师间的协作沟通，还是对新加入员工的培训，以及离职人员的交接都有巨大的益处。

这个列表还在持续延长，一时间，有人惊呼，AI可以按需生成软件（他们把软件简单等同于可运行的代码，这是一个常识性谬误）了，软件的所有麻烦明天就将消散了。

所以，万事大吉了吗？

以商用软件交付为例，一个典型的、忽略了商务活动的软件项目过程大致如下：

需要说明的是，这里虽然用线性的方式表述了这个过程，但在实际项目里，这些环节或步骤常常是迭代往复且有所交叠的。

软件编码和测试只是工作的一小部分。每一位有经验的项目经理或产品经理都知道，写代码和让代码在实验室的环境里跑起来，只是整个项目工作的一小部分。

有统计称，这部分在大部分项目的工作量中占比不超过40%。所以，如果AI只能在写代码、测试代码这些事上发挥作用，那么显然不能称之为“银子弹”。

软件需求收集与分析的重要性未降低。各大AI公司都有不同的演示，口齿伶俐的产品经理在一块白板前边说边画，AI便快速地生成了代码，然后部署在生产环境上，于是用户就可以使用了。

但大多数人忽视了一点，即能把软件系统要干什么描述清楚，这其实不在大多数软件用户的能力范围内，更不用说准确描述软件的系统边界以及在特殊情况下的行为模式了。

在软件工程中有一句名言：Garbage in, garbage out! 这句话在AI时代仍不过时。

做过商用软件需求调研的软件人一定有过这样的痛苦经历，收到的需求是模糊的、不完整的、甚至是自相矛盾的。这倒也不一定是客户代表在故意刁难，而是很可能在实际业务场景下，各个部门用户的诉求就是这样的。这也常常导致，没有业务流程重组，甚至是组织变革，直接上软件系统很有可能导致软件达不到设计的目的。

软件的本质复杂性日益提升。几乎所有的商用软件既不是从零写起的孤立系统，既需要在之前版本上升级，也需要与其它已存在的软件系统协同工作。

所以，软件工程师需要花很多时间去了解、理解现有的软件系统，然后才能谨小慎微地实现自己的那个需求，类似于“在已有的迷宫里去增加一个小迷宫”。AI在这样复杂的环境里构建软件的能力仍需验证。

AI生产代码的一致性疑问。AI时代之前，软件研发本质上还是“大规模的手工业”，团队与团队之间，甚至是团队内部在解决类似问题时可能采用非常不同的技术思路与方案。

在书法作品里，同一个”之“字，书法家喜欢写成不同的形式以展示其艺术性。但这种个性化在软件工程里却是一个灾难。

虽然，古早的软件管理者希望通过技术标准和技术规范等方式来约束，不得不承认，软件一致性仍然一直是巨大的挑战。其征兆就是一个错误可能在不同的代码片段里用不同的方式展现出来，外在表现形式也千奇百怪。特别是，经过一段时间后，软件的可维护性必然持续降低。AI生成代码仍有某种不可预测性，所以软件一致性问题并未得到缓解。

对软件未来使用的预测仍不可知。一个好的架构师在做架构设计时都会面向当前的使用场景，且适度地考虑未来的可扩展性，但这本质上是一个基于各种考虑因素的综合妥协。即使是一流的架构师，仍不能规避短视或过度灵活的误判，一年后，甚至半年后拍大腿的场景屡见不鲜。目前看，AI在这方面也不太可能提供可靠的帮助。

同样，这个列表目前也挺长的。所以，目前AI还远不能称之为“包治百病的灵丹妙药“。

那么，我们能期待AI在哪些领域进一步提升呢？

AI应可以帮助收集与分析需求。拥有自然语言理解能力的AI不仅应可以不厌其烦地从不同层级的用户处收集需求，还应可以从大量的文档记录中了解竞品的情况、当前在用软件的问题、甚至是当前业务流的各种场景、例外情况、以及协同机制。从而，构建与持续维护软件需求的全景图。让软件工程师和客户代表既能观之全貌，也能快速了解细节，”构建从3万英尺到12英寸不同高度的视角。“ 进而彻底消除软件需求层面由于误解导致的质量问题，规避冲突的需求，减少无效需求。

AI应提升在复杂业务环境里修改软件并保持一致性的能力。简单地实现一个排序，或者用户消息处理这样的需求是容易的。

但要保持与业务环境里其它系统或本系统其它部分的一致性就不那么容易，例如，在排序问题中，对相同条目应该如何处理？要不要去重？在响应用户消息时，如何处理异常输入？这既要求AI能全局性地理解本系统的代码和周边相关系统的边界、行为，还要有能力控制使其代码输出的一致性，彻底规避其”一本正经地胡说八道“的情况。

AI应提升软件验收的能力。简单地根据需求文档和代码去设计测试用例和生成测试代码与数据是手工时代的无奈妥协。

我们期待AI还可以从客户业务流程记录、过往系统使用日志与维护日志、相关联系统的交互消息等更全面的信息出发，总结提炼出更全面的软件验收测试方案，并设计出相应的测试用例、数据与测试代码。

如果能进一步做市场与客户分析，对软件未来的使用场景进行合理的预测，进而进行相应的测试那将更有帮助。

AI应能帮助用户更好的使用软件。尽管软件项目团队通常会在软件试运行和正式上线前给目标用户做培训，也会准备相关的用户使用手册。但比较常见的是，系统上线后，服务支持人员还是要疲于奔命，回答用户的各种各样、稀奇古怪的问题。

站在用户的角度，新的软件系统就是令人费解，让人充满挫折感。即使一个本来应该很简单的财务报销系统，普通用户就是不知道该如何填写，导致每每被财务人员无情地打回。

具备自然语言理解能力的AI理所当然地被期望成为软件用户的私人助理，帮助用户正确使用软件、解决用户问题、提升用户满意度。

结语

”AI来了，软件工程师要全员下岗了。“ 这个事短期看还不会发生，因为软件工程面临问题的复杂性、可变性、难以预测性等特点还是没有改变的，还是需要受过专业训练的工程师持续努力。

但仅从写代码这个工作讲，其难度门槛已经在持续降低了，事实上这在AI时代之前，也是在降低的。

所以，正面地看，AI在重塑软件工程，软件工程师将不得不持续拥抱AI。被AI武装的软件工程师将更高效、更有全局观、更有客户视角，从而能更敏捷地构建与维护软件，满足客户持续且多变的需求。