智能化时代的软件工程：拥抱大模型的正确姿势

智能化时代

Foundation

Model

Software

Engineering

软件工程

以ChatGPT为代表的大模型技术对于包括软件工程在内的很多领域都带来了巨大的冲击，也引发了广泛的焦虑。为了在迷雾中看清一点方向，近期我们基于各种技术文献和实践分享以及我们自身的一些初步探索不断地在讨论和思考“大模型时代的软件工程”这一命题。同时我也参加了几次线上访谈，触发了我更多的一些认识和思考，在此基础上撰写了这篇文章，希望与大家分享并倾听大家的意见。由于到目前为止大模型在很大程度上仍然是一个黑盒，并且大模型技术还在快速迭代和发展之中，同时目前看到的以及我们自己实践的基于大模型的软件开发案例还比较初步，因此本文的很多认识和思考不一定准确，未来还可能会随着技术和实践的发展而不断刷新。

✦

大模型冲击波

ChatGPT（基于GPT-3.5）的热潮还未褪去，GPT-4又横空出世，所带来的冲击是全领域、全方位的。在软件工程领域，学术界和工业界都被大模型在软件开发方面的全方位能力所震撼。一些技术专家纷纷上手体验，通过与大模型对话完成需求分析、软件设计、代码实现、软件测试、代码重构、缺陷检查与修复等各种开发任务，甚至尝试用大模型实现端到端的软件应用开发。其结果自然是震撼式的，以至于很多人惊呼“编程要被终结了”、“程序员要大批下岗了”。随之而来的是各种“软件工程新时代即将到来”的论断，有人称之为“软件工程3.0”，有人称之为“软件2.0”，意思都是软件开发要迈入全面智能化的新时代了。

大模型在软件开发方面强大的能力应该已经是毋庸置疑了，它对于软件开发的颠覆性影响应该也可以预见，也就是说大模型助推软件开发进入新的智能化时代应该是可以确定的了。但我们不清楚的是这样的一种新时代会是什么样的，在可见的未来软件开发模式将会发生什么样的变化，有哪些开发岗位会消失又有哪些新的开发岗位会出现？无论学术界还是工业界，很多人都很迷茫和焦虑，因为看不清楚前面的道路。例如，前哈佛大学计算机科学教授、谷歌工程主管 Matt Welsh预测生成式AI将在3年内终结编程，到那时候软件开发团队中只有两类人会保留，即产品经理和代码评审人员。如果他的预测成真，那么当前软件工程领域的很多研究方向以及相关的工作岗位都不需要了，例如软件架构和软件维护。

✦

冷静思考

ChatGPT（包括基于GPT-4的版本）作为一种智能化工具在软件开发的各个环节发挥显著作用已经是一种既成现实了。这让我想起了20年前所研究的软件复用和软件产品线：通过代码复制粘贴和API调用广泛实现局部复用并不难，难的是通过需求和设计规划实现系统性的定制化产品开发（例如软件产品线所宣称的那样）。与之相似，利用ChatGPT在软件开发过程中广泛实现局部的智能化辅助支持（例如代码片段生成和技术问答）并不困难，难点在于如何利用它们实现端到端、系统性的生成式开发。

在这个方面，一些业界专家已经做了一些探索并在各种公众号上分享了自己的体验。从这些探索可以看到，对于俄罗斯方块、贪吃蛇这类常见的小规模软件应用ChatGPT可以在适当的引导下通过自然语言对话逐步生成完整的可执行程序，产生的代码质量也比较高。由此带来的问题是，这种端到端的生成式软件开发能力能否推及规模更大、复杂度更高的企业软件项目中？这让我想起了Brooks在他的经典著作《No Silver Bullet-Essence and Accident in Software Engineering》中对于软件开发的根本性（Essence）困难和偶然性（Accident）困难的论述：根本性的困难在于对于构成抽象软件实体的复杂概念结构的构思，而产生这种抽象软件实体的编程语言表示只是偶然性的困难。软件工程过去几十年所取得的进展大多在于偶然性的困难方面，而在根本性困难（主要集中在需求和设计）方面则进展不大。

端到端的生成式软件开发显然需要逾越需求分析和软件设计这两座大山，那么ChatGPT在这两个方面的能力如何呢？从目前分享的端到端生成式软件开发案例来看，似乎ChatGPT已经具有一定的分析和设计能力，具体表现在：

① 根据给定的高层需求自动生成细化需求，还可以进行条目整理；

② 根据要求自动生成需求描述的规范化表示，例如UML顺序图；

③ 根据需求自动生成包含多个类的设计结构；

④ 根据开发人员的提示以一种增量的方式逐步生成应用代码（这要求对原有的代码实现结构有理解）；

⑤ 根据一般的设计原则对代码进行自动化重构以提高可理解性和可扩展性。

⑥ 根据需求自动生成数据库表结构设计以及相应的建表SQL语句；

那么ChatGPT真的会做分析和设计吗？从目前各路专家分享的实践经验看，不能说它不会，但所尝试的软件应用规模较小（例如百行到千行代码），需求较简单（例如俄罗斯方块游戏、图书馆管理等简单信息系统）甚至网上存在大量同类应用的代码和文档。此外，要想通过对话式的过程让ChatGPT端到端地生成完整代码，开发人员需要具有很强的对话和引导能力，不断能清晰表达要求而且还要能将开发要求分解为一系列要求明确的任务并按照合理的顺序引导ChatGPT完成。例如，在张刚的分享《ChatGPT结对编程实录：提升生产力，还是被代替？》中，一个简单的俄罗斯方块游戏的实现过程被拆分为了10个任务，分别是：创建游戏框架、使用GUI替换控制台、在GUI上显示一个L形方块、移动方块并且进行碰撞检测、旋转方块、落下方块并且创建一个新的方块、检测游戏结束、增加整行消除功能、加入所有类型的方块、增加计分能力。这个任务拆解体现了一个非常合理的增量和迭代开发过程，后面的任务依赖于前面的任务，同时每一个任务完成后效果都可以确认（例如程序可运行）。虽然这个任务拆解过程也受到了ChatGPT输出的启发，但仍然需要开发人员掌握整体的迭代过程，而且其中还融入了一定的设计思考。此外，开发人员还需要不断检查ChatGPT产生的结果，及时发现ChatGPT的错误并提醒修正。特别是在需求分析过程中，ChatGPT进行需求细化主要依据常识或某类软件的共性特征，可能遗漏一些重要需求，同时创新性或个性化需求也需要开发人员进行补充。

我们再从大模型的训练方式以及软件开发的本质性问题出发进行一下思考。以下几点是我目前得到的一些认识。

软件开发的规模和复杂性

可能会从人机两个方面

限制大模型的能力

首先，生成式的开发过程高度依赖于开发人员对于大模型的分步引导，这就要求开发人员自身能够完整和深入掌握整个软件的设计和实现过程，这样才能以合理的方式进行任务拆解并按照合理的顺序引导大模型逐步生成代码。当一个软件的规模达到几万、几十万甚至几百万行代码时，人的大脑可能已经无法掌控整个代码生成过程了。而且对于大规模复杂软件系统而言，任务的拆解和实现并不是一个串行的过程，而是存在很多条平行的线索并伴随着不断的分叉与合并。因此，在传统的软件开发中，开发人员需要对大规模复杂系统进行多层拆解，不同的开发小组和个人分别负责不同层次和不同部分的工作，同时开发团队根据需要随时进行沟通协调和设计方案调整。这一过程目前还很难被大模型所取代。其次，大模型本身对于复杂系统开发过程的全局掌握能力也是有限的。例如，我们团队的分享《浅评ChatGPT在软件开发上的辅助能力（附GPT-4对比）》中提到，即使是在规模很小的软件的生成过程中，ChatGPT也可能会“遗忘”之前生成的代码（例如方法名、方法返回值前后不一致）。这导致大模型可能会顾此失彼，难以生成大规模的软件实现代码。最后，人工代码审核的存在使得软件设计和代码质量仍然有着重要的意义。即使目前最乐观的估计也承认大模型生成的代码仍然需要人工审核。如此一来，对于大规模软件系统而言，模块化、信息隐藏、关注点分离、代码可理解性等原则仍然十分重要，否则审核代码的开发人员将难以理解大模型生成的代码并成为软件开发过程中的瓶颈。

大模型可能缺少抽象思维能力

同时在精确性上存在不足

软件设计特别是高层架构设计往往涉及复杂的抽象思考。其中有一些设计抽象存在清晰的逐层精化脉络，例如从接口设计逐渐细化得到具体实现。但还有一些设计抽象涉及全局性的系统抽象，其中往往还包含复杂的权衡决策，例如软件架构风格和模式的选择。这类复杂的设计抽象可能是大模型所不擅长的。大模型的训练方式使得它善于基于平面化的上下文以及提示信息产生相关内容，同时通过细粒度（例如单词级别）的灵活组合实现举一反三、触类旁通的效果，但对于大范围的抽象设计决策可能缺少相应的掌握和应用能力。此外，大模型概率性的本质与软件所追求的精确性之间存在冲突，因此大模型在局部编码任务上经常可以做到八九成正确但同时要求开发人员能够及时发现问题进行提醒纠正甚至直接修改和补充。

软件需求和设计中

存在大量难以捕捉的“暗知识”

大模型的成功很大程度上来自于对已有的互联网文本语料（含代码）和专业书籍等资料的学习。与之相对比，软件开发中的很多需求和设计知识并不存在明确的文字记载，它们可能存在于开发人员（包括架构师）的脑海中、曾经画在白板上或者出现在项目会议的讨论内容中。即使开发团队提供了详尽的需求和设计文档，一般也没有谁会相信关于需求和设计的重要信息都能在文档中找到。此外，需求和设计背后经常有大量的方案对比和推敲，这些决策过程一般都不会明确地被记录下来。虽然我们可以说只要有足够的数据大模型就可以学到需求和设计知识，但这些“暗知识”本身就很难被捕捉到，“足够的数据”这一前提可能难以满足。此外，即使我们通过拍照、会议纪要等方式记录了一些这方面信息，但因为其高度的抽象性甚至模糊性（例如设计图中某个元素的含义以及对代码实现的影响）大模型可能也难以学习和应用这些知识。

大模型对于复杂软件系统的

长期维护支持能力存疑

企业软件系统一般都有着很长的生存周期，在此期间可能由于多种原因（如需求变更、使用环境变化、缺陷修复、性能提升等）进行修改，同时也可能会面向不同客户进行定制。这些软件维护和演化过程中蕴含着很多软件工程问题和挑战。要实现系统的软件智能化开发支持，大模型显然不能只做一锤子买卖（即只负责最初的代码生成）而需要在长期的软件维护和演化过程中根据需要完成各种功能扩展和代码修改任务。这要求大模型能够理解代码中业已实现的各种需求、设计方案以及需求/设计元素与代码元素之间的精确对应关系，同时需要知晓并处理代码修改与各个部分之间的交互关系（如修改带来的直接或间接影响）。此外，大模型生成的代码本身可能存在很多重复的地方，这些重复代码（代码克隆）的长期维护特别是一致性修改可能成为一种负担。

✦

拥抱大模型的正确姿势

大模型在一些编程任务上的优异表现让很多人感到很兴奋，同时也对大模型颠覆软件工程、实现全面的生成式软件开发的前景感到很乐观。但我觉得，要谈大模型的软件开发能力首先要区分所开发的软件类型。对于小规模的软件应用，甚至适合最终用户编程 (End User Programming)的应用开发任务，利用大模型实现端到端的完整代码生成是完全可能的。而对于大规模的复杂软件系统而言，根据需求陈述实现端到端的完整代码生成还不太现实。

拥抱大模型对于软件企业提质增效而言肯定是一个正确甚至必要的方向。事实上，如果不考虑信息泄露风险的话，在企业研发过程中直接使用ChatGPT这类大模型就可以直接获得显著的开发效率和质量提升。然而，要想实现系统和全面的软件智能化开发，还有很多基础性的工作需要去做，同时还有一些关键问题需要探索。以下是相关的几点思考和建议。

扎实做好软件开发的

数字化和知识化积累

软件开发为很多不同的行业提供数字化解决方案，然而软件开发自身的数字化程度却很低。例如，通用软件资产（如公共组件）未得到有效整理和复用，重新发明轮子（如重复实现相同的功能）的现象十分普遍；每次代码修改的前因后果不清楚，例如引发代码修改的开发任务（如特性实现或缺陷修复）以及代码修改所带来的影响（如引入代码问题以及度量指标的变化）缺少系统化的记录。此外，软件中所蕴含的需求和设计知识缺少明确的描述以及与代码的清晰映射关系，导致开发人员经常就相同的问题重复思考。在这种情况下奢望大模型直接带来跨越性的全面智能化开发体验可能是不切实际的。正确的做法可能是扎实做好软件开发的数字化和知识化积累，在此基础上再与大模型结合实现更系统的智能化开发支持。例如，构建特定领域的通用组件库并建立描述体系，建立软件代码克隆以及软件供应链的全面跟踪和管理体系，建立开发任务（特性实现、缺陷修复等）、开发人员、代码提交和修改内容之间的追踪关系，建立并维护高层设计描述及其与代码单元之间的映射关系。这些数字化和知识化建设本身就可以提高软件开发质量和效率。而大模型不仅可以为软件开发的数字化和知识化提供技术和业务背景知识，而且还为我们整合数字化和知识化平台中的信息和知识提供了一种有力的手段。

更加重视需求、设计、验证等

软件工程基本能力建设

我比较认同Bertrand Meyer在《Communications of the ACM》的一篇博客文章中所提到的观点，即：ChatGPT这类大模型并不会带来编程的终结，而是会复兴软件工程领域的一些根本性的技术，例如需求分析、精确的规格说明以及软件验证（包括动态测试和静态分析）。这些软件工程传统技术有望在大模型时代重新焕发青春，但可能需要考虑如何与数据驱动的大模型技术有机结合。同时，如前所述，也需要加强需求、设计、测试等方面的数字化和知识化基础设施建设。

探索能有效整合大模型、开发人员

以及各种工具能力的智能交互引擎

我们当前在软件开发领域所面临的局面与Gartner近几年力推的超级自动化（Hyperautomation）所针对的问题很像，也就是存在很多自动化工具系统（如调试与测试工具、编译构建工具、代码静态检查工具等）同时形成了丰富的资源库和过程库（如通用组件库、开源代码仓库、软件开发在线问答系统、缺陷跟踪系统、版本管理系统等），但面临的问题是如何在人工智能技术的支持下将这些自动化能力和资源无缝衔接构成全过程的智能化体验。对于软件开发而言，还有一个重要的问题是如何将人（开发人员）和机（大模型及各种工具）的能力有机融合、实现高效的人机协同。如前所述，大模型在生成式软件开发过程中所发挥的作用与人的交互和引导能力密切相关，同时人的经验在高层决策以及代码审核等环节还要发挥重要作用。因此，系统性的智能化开发过程不能完全依赖于开发人员自身与大模型的交互能力，而是应该追求建立一种能够统一调度并有效整合大模型、开发人员以及各种工具能力的智能交互引擎。例如，依托下一代IDE形成的开发人员统一门户可以通过一个智能交互引擎理解当前的开发任务及进展态势，在基础上灵活调度和利用大模型的生成能力（如细化一段需求或生成一段代码）、已有的数字化信息和知识积累（如代码依赖关系、通用组件、软件设计决策等）、各种工具能力（如运行代码静态检查或自动化测试、查询相关的缺陷报告信息以及提交新的缺陷报告等）以及开发人员的主观判断（如作出需求和设计决策、审核大模型产生的结果等）。这一过程的一个突出特点是智能交互引擎主导，将开发人员的经验判断与各种工具的能力以及大模型的智能有机结合，并实现高度顺畅的智能化和自动化开发过程。此外，智能交互引擎还需要实现开发人员与大模型之间的人机交互过程的会话管理，支持以“多线程”的方式与大模型开展交互式探索同时支持这些探索线索的按需拆分（fork）和归并（join）。在此过程中，智能交互引擎需要做好会话状态和上下文的管理和切换。

结

束

语

Ending

✦

拥抱大模型对于软件企业提质增效而言肯定是一个正确甚至必要的方向。但是，如何实现系统和全面的软件智能化开发还需要冷静思考，同时还有很多基础性的工作需要去做。对于企业而言，扎实做好软件开发的数字化和知识化积累以及需求、设计、验证等软件工程基本能力建设仍然是十分重要的，而且也是实现更高水平的智能化开发的基本条件。对于学术研究而言，面向系统和全面的软件智能化开发还是有很多工作可以做的，这也要求我们在理解大模型能力的基础上对于软件系统的复杂性以及软件需求和设计有更深的理解。

作者简介

彭鑫，复旦大学计算机科学技术学院副院长、教授，中国计算机学会（CCF）杰出会员、软件工程专委会副主任、开源发展委员会常务委员，IEEE高级会员，《Journal of Software: Evolution and Process》联合主编，《ACM Transactions on Software Engineering and Methodology》编委，《软件学报》编委，《Empirical Software Engineering》编委。主要研究方向包括软件智能化开发与运维、人机物融合泛在计算、机器人软件工程等。

CodeWisdom